Guys and gals what influences your choices when choosing I/O in the AB family? Obviously you have to look at the location and cost, but how do you choose between Ethernet (In panel) Flex, Point, Compact, Etc. If you just have I/O in the field that you need to get back to the system and don't want to take the time or money to pull pipe and wire. How do you choose?

What are you familar with and believe that it will do the job without you worrying that in the future your network will fail if adding new devices.

Devices that are hi speed need to be in a local rack on AB products. If you need inputs and outputs that are below 10mSec response you need to go with a local input and ouput. Also hi data devices need to be in local rack with the plc such as ASC2, controlnet, devicenet scanner cards.

ControlNet - remote rack in area for any devices in area within 500 feet of panel. Similar to Remote IO. Scheduled network , Distances are not usually a problem, special tools needed for installation. Special software needed for configuration. Also good for plant PLC networks if not using ethernet. Good for interlocks between PLCs

Devicenet - Low speed devices, Special software needed for configuration.

Ethernet - used for plant networks, remote support. If using for control of IO then the use of seperate networks are necessary from plant ethernet backbones. If control of IO special software needed for configuration.

I use a ControlLogix processor and used control logix remote IO to save on spares. I have recently connected with Opto22 I/O on our system and for their prices you cannot beat them, and they give a lifetime warranty!

If I needed to add an additional drop point I would use Opto22.

It's not a matter of time. I make a practice of not pulling wire for more than 50 feet. It drastically saves not only on installation costs but also on troubleshooting time because you have reduced the size of the problem by quite a bit.

The choice on IO depends on how "concentrated" your I/O is, and the AB PLC you are dealing with.

Going by the networks, unless there's a backwards compatibility problem, stick with Ethernet (if you can) or Devicenet...more on the Devicenet option in a moment. Contrary to a previous post, there's not necessarily any special configuration software with Ethernet I/O. I can give counterexamples for everything including a "no thumbwheel" version that is PC-free as far as configuration goes. It violates some sacred cows but works very well.

With the Logix family as an example, the highest density I/O is achieved with 1756 local rack I/O.

For medium densities, Flex I/O is great and has a lot of options that are simply not available with anything else.

Going further down the food chain, you get to Point I/O.

If you want to have no-enclosure I/O, then the next option is the ArmorBlock stuff which is available in an Ethernet configuration now. The connectors are kind of goofy (they use the European 4-pin round Ethernet connectors) but are otherwise unremarkable.

You can achieve similar performance to the ArmorBlock stuff if you use Brad/IFM Efector/Allen Bradley/etc. "I/O blocks" which have M12 round connectors and a single "fat" cable port and come in blocks of 4 or 8.

If you have extremely low density I/O such as what you commonly get with conveyor belt lines, then I suggest going with DeviceNet. You can get "DeviceNet ready" devices such as photo-eyes and M12-style I/O boxes that simply clip directly onto the flat DeviceNet cabling. It does have some downsides but otherwise it works very well for what it does.

I would avoid "CompactBlock" I/O in it's various configurations and flavors, as well as "PointBlock" and other strictly "Point I/O" networks because although this stuff is definitely cheap, it limits you to DeviceNet and/or various other networks that are less than desirable. Every time I've run calculations of costs "per point" and such, this stuff initially looked inexpensive but when you do a total cost analysis including troubleshooting, cabling, scanners, etc., it rapidly starts to look not so great. Plus once you start using this stuff, it is tough to upgrade to something else later since there's no "network adapter" to change out if you later update to a different I/O network.

I had just started looking at the Block stuff in the various forms. I have seen more and more Point I/O show up on various machines that I have been getting call to service. I have never installed any yet so I don't know what the kind of reliability they have.

I am looking at some low density clusters (groups of 15 or less) I have several Type J thermocouples that are run over and under and all around 480V about 30~50’. I have only setup Flex on a RIO. We have Flex all over this plant with several in the stockroom as spares.



Paul how are you calculating the price per point including troubleshooting, cabling, scanners. Do you include a percentage of the Network module in every card? If I have 8 cards in this location and 2 cards in the next the price per point on the 2 card system will be increased by the cost of the Network module. I had just thought about using the minimum cost per Network Point and then add point cost per point.

If you have mixed I/O including thermocouples, you may want to look at Spectrum. They have some very nice "universal" input cards...as in it can be voltage, current loop, RTD, thermocouple, etc., for every point the card accepts. Very, very nice.

ANY analog I/O, regardless of what it is, becomes incredibly expensive when you get it from AB. Unless you have to have AB stuff, this is one area where I've deviated and started using Acromag I/O. The cards are a bit unique in that you configure them via a built-in web server (which is relatively "idiot proof") but they seem to be otherwise rock solid and far more economical.



I usually use either contrived or actual scenarios figuring "all-in". I don't try to just arbitrarily split out the network adapter because you can't even win on this. I rarely fill up all 8 slots on a Flex I/O node, but figuring on the costs when there are just one or two I/O cards attached to an adapter unfairly characterizes the situation, too. Once you plug all the prices into a spreadsheet, it's pretty easy to try out various combinations to see how it works the best. If you even start to consider "troubleshooting" costs, your card values go through the roof in a manufacturing scenario where you can figure on thousands of dollars per hour of lost revenues from downtime. Or you can go the cheap route and figure on taking your average hourly pay rates and doubling it (to include overhead), and then considering how long it takes to use a volt meter, etc., on a job. I have a pretty good estimate on average number of failures over time since I keep track of this. We made huge strides in costs simply by attacking downtime.

There's a lot more savings to be had if you standardize parts and stick with either M8 or M12 connectors and cabling whenever possible. Brad is right...modularizing your cabling pays huge dividends in terms of reducing down time for maintenance, just as it does with sensors. This takes a lot more creativity though when it comes to things like motors. If you can get most repairs down to unscrewing and screwing connectors together, the time savings are tremendous. In fact recently I put in modular connectors on a set of motors. This was a huge pain to engineer because they were DC motors with series fields and parallel armatures. I finally found that Meltric made the connectors I needed. They're not quite as slick as the setup that Square D and others are selling that integrates the disconnect into the plug but those wouldn't handle the currents and voltages that I needed with 15 HP DC motors. Once it was done, each motor had a jack mounted on the peckerhead. Electricians weren't necessary any more to "unwire/wire" a motor any more. Mechanics were free to pull the plugs out themselves and plug the motors back in. All the electrical work is done "offline".

Finally, here's what I found with regard to diagnostic I/O when I first started using it. Keep in mind this is a manufacturing plant so there's an obscene number of digital I/O points for proximity switches, actuators, etc. In order to minimize downtime, we fuse everything as an SOP. So I have three choices. I can buy fused terminal blocks with fuse blown indicators (these aren't much more expensive than non-indicating terminal blocks and lead to lots of potential troubleshooting issues). I can buy AB terminal blocks where they are available with fuses built into them. Or I can buy diagnostic I/O cards that don't have any fusing at all (they are immune to damage from short circuits) and the input blocks will auto-detect both open and short circuits. It turns out surprisingly enough that the diagnostic I/O card "adder" at least with Flex I/O is very inexpensive. It is less than the construction cost (time) and the additional cost of a fused terminal block. So it turns out to save both money and time.

This works for most I/O but there are two areas where it's a problem. First, there's hydraulics. You can get 24 VDC coils but unfortunately the current draw is usually 2-3 amps, far more than the diagnostic outputs can deliver. In this case, you can get solid state "high speed" hydraulic coils. These are 4-wire devices that allow you to operate a high current coil with a solid state relay driven by relatively low current from the PLC. Not the ideal situation but they work. I bought mine for ATOS valves but ATOS is actually buying the coils from someone else and I've seen several vendors offering similar things.

The second area is starters. Like it or not, to pull in a starter almost requires both AC and higher voltages. This is another area where DeviceNet is the only decent choice. You can buy AB's "distributed starters" for relatively small motors (well, small in the world I work in). Otherwise, there's the 100-DNY41R/42R/42S. These are small DeviceNet "combination I/O" cards with 2 relatively high power relay outputs and 4 solid state inputs, and the price is very good. In fact quite often they are useful in places other than starters because they serve similar purposes to Point I/O as long as you already have DeviceNet. On top of that, the Bulletin 100 devices have DeviceLogix so you can program them with some low level functions such as manual start/stop controls that operate independently of the PLC.

Finally, I'm going to recommend one of my favorite smart I/O cards. If you buy a Micrologix 1100, what you get is 10 digital inputs, 6 digital outputs, two analog inputs (though I hesitate to promote them too much since they are voltage only and extremely poor resolution at that), a very small screen that can be used for some minor programmability, a serial port, space for almost as much device-level logic as you could want, room for up to 4 expansion I/O cards (at very reasonable prices) on the side, expandability into Modbus/RTU, you can insert a flash card and use the built-in data logger, and it operates either on Ethernet (got a port for that, too) or serial. The only downsides are that you have to have a RS-Logix 500 license, AB lists it in the "PLC" section of the catalog, and that it does have very limited support for CIP-based protocols. It's a bit of a laugh but frequently I've found that using Micrologix 1100's as I/O frequently beats all other options when you consider that the list price for these PLC's is less than a 1794-AENT FlexIO Ethernet adapter.

There are 3 areas where I'd like to see more from AB:
1. Get your analog I/O pricing under control. It's not unusual to see $300+ per I/O point in some of my cost analyses.
2. More ArmorBlock I/O. Two cards just isn't going to cut it. I know they are struggling with the two cable solution but it's not so bad. It's a lot better than the alternatives. Perhaps they could make a "siamese" type power/network banana peel type cable.
3. DeviceLogix is really, really slick, and totally underutilized. Need to do more with this. Also needs to be available outside of just DeviceNet.

Paul are you interested in sharing any of your spreadsheets?

Diagnostic IO

I would be careful using diagnostic IO. Remember if you want to use the diagnostic features like resettting the electronic fuses from the HMI, you need to have a seperate connection for that card to the PLC processor. Remember that the PLC has only room for 250 connections (1756-L62 processor, not sure about other processors, might be less if working with other AB processors). AB always recommends that you only go to 80% of the value if you want a stable system but have gone up to 85-90% with marginal problems that I could resolve with other parameters within the processor, or by changing to time interrupt routines of critical processes. This can add up real quick to 250 if you have a lot of remote racks. The good thing about ControlNet is that RSNetworx you can do an offline configuration to see you have exceeded the connections or even if your configuration will not work at all. Also keep in mind on controlnet there are parameters on connections and % that have to be maintained to keep a stable system.

Not sure I follow you. You've got a connection to the HMI. You've got a connection to each I/O card (or rack if you use rack-optimized I/O). The only way I can see exhausting connections in the way you are describing is if you blow the connection limit of the individual cards by programming the HMI to create a separate direct connection, or else blowing the connection limit of the ENBT cards if you use 2 ENBT cards and an isolated I/O network.

Also, there is an RS-Networx version for all 3 CIP networks. It's not just a Controlnet thing. It is not a necessity with Ethernet/IP but it does have a few nice-to-have features such as giving you definitive connection usage data.

If you want to use any of the diagnostic features of the individual card yo have to have a seperate connection to the plc. Does not matter if you want want to bring it out to the HMI or some other programming feature that you want to do in the PLC. Of course the HMI is a seperate connection to the processor and can be up to 4 depending on driver.

I agree using the RSNetworx to make sure what you put in hardware wise will work when you install it, instead of waiting to do the configuration onsite. There is a tech note to show you how to do this Offline configuration.