Sign in to follow this  
Followers 0
JeffKiper

Distributed I/O choices

23 posts in this topic

I have an open ended question. What types of distributed I/O do you all use? (13) 24VDC In, (10) 24VDC out (well inside the range of a MLX 1100 or new 1400.) This doesn't have to be limited to AB brand. I have a couple of small simple machines that I am going to bid. Small material handling nothing high speed about this, less than 7 picks a minute. When I sat down with the plant engineer he said " we can use RIO from one of our existing processors and not have to buy a new processor" Then he and I had the talk about was he talking AB "RIO" or Remote I/O really meaning distributed I/O? He didn't know there was any difference between them. The communications are what ever I want they have ControlNet, DeviceNet, Ethernet, ModBus RTU, & AB RIO, all in about 25 feet of where I plan on putting these machines. Processors are PLC5/80C, 1769-L35E, 1756-L1, SLC 5/05. I had thought of using AB 1791 Compact Block I/O with DeviceLogix just in case their DeviceNet system failed my machines would still run WITHOUT an processor. Yes I know if any of the others fail to run shouldn't the packer stop as well? What if the head of the machine stops, but the rest of it still runs producing product that needs to be loaded out? I have spoken to several guys that like OPTO 22 stuff with the smart controllers, I have talked to 1 guy from this forum that had bad experience with the OPTO 22 equipment. He and another member took them out and trashed them. Environment is clean, slight oil mist, mixing dust, NOT a forging shop, or foundry so it's OK in my book. I am anal so I always build my panels with positive pressure just in case, NEMA 12. Temperatures will not get over 120° F. Thanks for you input I am just starting to venture out on my own.

Share this post


Link to post
Share on other sites
I use a fair amount of Beckhoff IO with AB PLCs - on Devicenet and Ethernet. Its inexpensive but pretty good quality, and Beckhoff tech support is excellent. No problems at all with it.

Share this post


Link to post
Share on other sites
You list PLC5/80C, 1769-L35E, 1756-L1, SLC 5/05 as your processor possibilities and my recommendations vary by processor. For the PLC 5/80 I'd choose AB RIO first. This has the least setup hassles and a proven robust track record. yes, I know all about it becoming a "legacy" someday. For the L1 I'd choose ControlNet in first place and DeviceNet in Second, RIO would be a distant third. All of these options would allow you to use 1771 or 1756 I/O Racks and Cards. Just my humble opinion here but the 1756 and 1771 I/O cards are more robust and industrial than the Flex or compact blocks. For the SLC 5/05 it would be a tossup between RIO and Devicenet. Neither is pretty in the SLC, but can be implemented.

Share this post


Link to post
Share on other sites
SLC and PLC5 are becoming legacy systems in the next few years and will stop getting full support in the coming years. What I mean is that the pricing levels to justify bringing new equipment on with these processors is not going to be a feasible option. So I would change that to the Compactlogix or the micrologix controllers if you prefer AB. Saying that I can only comment on L61 processors and what distributed IO I have done with this product. This is using a 1756-a17 rack If you have any high speed devices I would keep those located in the local rack to give you that 0.2msec backplane speed. Otherwise using ControlNet you have that 3-10msec NUT delay or the network delay on Devicenet. 1st Network of choice is ControlNet - AB has good tools to use to see what you can do offline before you even install anything in field. 2nd Network is Profibus - usually will give you a network delay of 10msec to sub 2msec delay depending on speed of network. Can be very fast, just have to put in a lot of repeaters. But the selection of Profibus scanners does not allow to get the speeds you would get if you were using a Siemens processor. Since Profibus is a product of Siemens. Use either Prosoft or SST profibus scanners 3rd Network is Devicenet - slow devices on this network

Share this post


Link to post
Share on other sites
I looked at the Opto22 and found the same trashing on the forums. On another forum, it was mentioned that their reliability is questionable which helped me to choose AB IO instead as I cannot afford to have some reliability issues (lifetime warranty on all products though). Also Opto uses flowsheet type instruction instead of standard ladder which is another learning curve (but free tech support and training if you want to go to their headquarters). From a price perspective they cannot be beat and I would be interested in constuctive feedback from other people that have used their recent products for furture projects.

Share this post


Link to post
Share on other sites
Distributed I/O to the extreme is a SCADA system as it is implemented for large power and gas distribution systems. These have RTU's which are really just PLC's in most cases. Most RTU's include an operator interface for local control but usually operate in remote mode. Keep in mind that since we're talking AB, a Micrologix 1100 gives you Ethernet communication, 10 digital inputs, 6 digital outputs, and 2 (crappy) analog inputs on the base module for about $500. You can add expansion modules very cheaply for more capability. Compared to the cost of remote I/O blocks, I've been using Micrologix 1100's instead in many cases. At the next level down, you have the DCS. There are darned few of these left in the world. Profibus as I understand it is effectively a DCS. There's also the system from National Instruments, Delta-V, Honeywell TDC 3000, and others. These systems distribute the logic directly into the remote controllers. The key point here is that the HMI is effectively the "central" system as opposed to a PLC system where the PLC is the center of the system (even in CLX systems which attempt to somewhat minimize the importance of the PLC). They also tend to be exhorbitantly expensive but they have finally been coming down in price in recent years. At the next level down, there are a few "remote logic" type devices such as DeviceLogix, the embedded logic in Gemco resolvers, Opto 22, many PID controllers, most HART "smart" I/O devices, etc. Frequently the goal here is to give you remote I/O at "local I/O" speeds, or even to give you hardware-level (microsecond) response speeds, something difficult or impossible to achieve with the PLC. Finally, there's remote I/O, in dozens of flavors. The idea of having a "local control" is very appealing. I used to be very big on having multiple layers of failure modes, redundancy, etc. However, I've had PLC's in operation for literally decades without so much as a hiccup. After working with hundreds of PLC's over the span of a couple decades, I can honestly only point to a handful of failures of the PLC itself, and most of those were due to external factors (dust/dirt/heat). I know that you can buy redundant PLC's but except for the safety PLC's, and situations where the PLC is so remote that replacing it would take hours (like a remote pumping station in Alaska), it simply doesn't make sense. The only "local control" that I still routinely install is to put in JOA switches on starters (jog-off-auto) which allow you to locally bump/stop motors. These aren't intended for running anything. They are simply there to facilitate maintenance, and they aren't extravagantly expensive. I HAVE had lots of communication cabling and power failures since they can be just as vulnerable as any other cable. The distributed I/O idea CAN make cable damage less of an issue but seems pretty darned limiting in practice especially if you have properly armored up your critical points of vulnerability (power and communication). I know you CAN run communication cables exposed without any sort of protection but that doesn't mean it's a good idea. In the end, I've opted for Ethernet I/O in redundant rings whenever possible because in the end I feel that the major point of vulnerability is the cabling. With Ethernet I/O (and Controlnet), you can run redundant communication cabling. Damage to any single cable does not take down the network. You can also at least run a "star" topology which gives you similar capabilities (damage to any one cable only takes out one remote I/O panel). I've successfully taken control system outages from "once in a while" to "almost never" with this approach even in the nasty environment of a foundry. I'd be hard pressed at this point to justify using DeviceLogix, ML1100 "distributed I/O", or any of the DCS systems for distributed control reasons if the reason is hardening your system against damage. On the other hand if the problem is speed or distance, then distributed I/O comes into it's own and makes a lot more sense in my mind. Speed-wise, think of running the cutter that separates the packages in a lollipop production line running 10,000 pieces per minute or more. The timing is well beyond a PLC's reaction speed. For distance, imagine using a single PLC operating the Alaska pipeline. Edited by paulengr

Share this post


Link to post
Share on other sites
With the given factors in mind, the obvious network to chose is DeviceNet. It is supported by all the processors listed. It is an open standard, supported by many other vendors. It is not on the verge of obsolescence. It is not too expensive. It is performant enough for JAK's application. edit: Oh, if JAK have all these networks in one place, ControlNet, DeviceNet, Ethernet, ModBus RTU, & AB RIO, I think JAK should consider streamlining it by eliminating a few of them. A heavily AB-centric plant should focus on Ethernet/IP + DeviceNet. As to suppliers if i/o blocks, then only AB has hardware for Controlnet and RIO. So much reason for getting rid of those. Beckhoff is the vendor I know of that supports the most protocols, including Devicenet and Ethernet/IP. You might want to consider Beckhoff. Otherwise AB is your primary choice. Edited by JesperMP

Share this post


Link to post
Share on other sites
Not so fast. Just because it's supported by all the processors doesn't mean that this is the intended direction of the plant into the future. I have only 1 CLX processor, about 20 PLC-5's, and 1 SLC. Does that mean that I should design for the lowest common denominator? Heck no. The PLC-5's and SLC's are intended to be maintained but all future processors won't be those. Foundation Fieldbus is an open standard, too. And supported by a whole lot more vendors than DeviceNet. And it is the quintessential "distributed I/O" system since control functions are distributed right down to the device level. But it's intended for a process-oriented plant, not discrete manufacturing, where it would be completely inappropriate. I'd suggest giving serious consideration to whether distributed I/O is indeed appropriate. If so, then for a discrete manufacturing plant, any "solution" is going to be something of a forced one since there's no distributed I/O specifically designed for it. Then, I'd lean towards Ethernet as the I/O of choice for future-proofing. DeviceNet's troubleshooting and configuration issues are legendary, but Ethernet/IP can be a huge headache, too.

Share this post


Link to post
Share on other sites
Paul. Is it even possible to connect AB PLCs to FF ? And he is talking about "machines" which may (maybe yes, maybe no) require a little bit more bandwith than what FF can provide. And did he say that everything was within 25 feet of each other ? No advantage with FF there. And he has already experience with Devicenet. And as far as I know FF's ethernet doesnt go all the way to the sensor or actuator, but must change to RS485 via a gateway. All this tells me that FF is probably not the best choice for JAK. And ethernet FF even less so.

Share this post


Link to post
Share on other sites
As to a direct answer, yes, of course you can use Foundation Fieldbus (FF). For those who haven't seen it before, FF is a standard developed by ISA for refineries and chemical plants. It uses a 2 wire serial protocol at 31.25 kbps (half the speed of AB Remote I/O). The protocol is very sophisticated and allows the individual devices to directly communicate. You can actually load in relatively simple function block diagrams directly into the devices themselves. It is almost essentially a "DCS" as a standard. The serial protocol is called H1. They also have their own Ethernet protocol called HSE (high speed Ethernet) which is intended to be the layer where PLC's and HMI's live. H1 is connected to HSE through gateways called linking devices. The AB branded FF product is the 1757-FFLD. It's an Ethernet/IP to H1 bridge. If you used this of course you'd have a curious situation in which your Ethernet network would be Ethernet/IP rather than HSE. You'd also have to go through the usual gyrations of attempting to access a CIP network from a non-CIP processor if you tried to use a PLC-5 or SLC. In terms of speed, pain-in-the-rear to troubleshoot, etc., I am NOT an H1 fan. There are other fieldbuses out there though. It just happens that there's a bit of a convergence going on where most of the DCS systems out there are dropping their proprietary I/O and converging on FF. Second, all other answers referred to specific grades of remote I/O. I answered the more philosophical question of distributed vs. remote I/O, which is what I believe the question was. My actual recommendation if you are really sold on the conceptual idea of distributed I/O is somewhat different. Real distributed I/O shows up in four target markets: very fast networks where latency is a huge issue, very large geographically dispersed ones (pipelines, utilities), where analog I/O is the dominant feature on the landscape (chemical plants such as refineries), and where multiple levels of redundancy and system safety is absolutely critical (nuclear plants and some chemical plants). The example (medium speed manufacturing line) doesn't really fit any of the typical cases where distributed I/O is virtually the only choice available. You need some speed (FF is out) but it's not blistering fast speeds (where DeviceLogix becomes necessary). So my suggestion was something in between. First, philosophically, it was to point out that in terms of redundancy, distributed I/O is overkill especially in this situation. The number of failure modes where it would actually do some good is probably less than the amount of times where it would get in your way. This is equivalent to implementing control redundant safety circuits (no single point of failure) when in fact you may not even need anything that sophisticated. My second maybe more subtle point is to think of distributed I/O in terms of the overall SYSTEM. What the failure modes could be, and how to deal with them individually (if at all). I actually have implemented one of my suggested distributed I/O networks. I have several ML1100's, and a couple ML1000's which actually act as RTU's in a similar speed production line. In this instance, I wanted to go for a single PLC controlling the entire production line. My boss felt like this was putting "all our eggs in one basket" and that somehow this was risky. So we compromised. I have Micrologix PLC's which act as remote I/O panels. Each one simply runs MSG instructions to block copy the data to the master PLC across Ethernet. Speed tends to be relatively good as far as I can tell (not slower than blue hose Remote I/O). In addition, each one implements "local" functions related to each piece of hardware. You can in fact put each of them in "local" control mode and use the push button panel to run each piece of machinery manually rather than allowing the "master" PLC to run the entire system. About the only "local" type code that gets executed is that there are ink jet printers on the line that get loaded with the appropriate lettering via serial port. So the "master" PLC downloads a set of commands to the Micrologix PLC which in turn converts the high level commands into the appropriate ASCII sequence to set up the ink jet printer (we weren't using the serial ports for anything else). It's a bit confusing to troubleshoot it depending on how much you share responsibilities between the master and local PLC's. I found the safest route is to make the local PLC's as simple as possible. Otherwise, it quickly leads to confusion even when you are the designer/programmer! Edited by paulengr

Share this post


Link to post
Share on other sites
I think I have talked them into using an 1100 or maybe a 1400. Their boss doesn’t know about the 1400 yet so it is a white elephant in his eyes. I still haven’t been given the main controller yet so as long as I can MSG the MLX over the Ethernet I should been good. Side question the serial printer what does the code look like? I have a small job that would be nice to print from just to identify the errors when they happen.

Share this post


Link to post
Share on other sites
You don't want this one. It is an industrial ink jet printer. Check out "Matthews International" or "Pannier". These things are used for printing numbers onto cardboard boxes, onto the edges of sheets of steel, etc. It is much too big to use as a data logger. You CAN get small serial thermal printers from Star Micronics and Zebra. They are used for instance for printing labels or small receipts, such as the printers inside of gasoline pumps. Pricing is usually not too bad depending on how big you want. You can also frequently just use a serial-to-ethernet or serial-to-USB converter and feed raw ASCII serial strings to a laser printer. Most of them will print just fine doing this. But for what you are trying to do, you are probably much better off with a real data logger. There are a couple approaches I use. I've buried circular ring buffers in PLC's to collect data when needed. This has the huge advantage that it can operate at scan rate and captures even "glitch" type events. I have a full blown large scale plant-wide SCADA so it can also do logging. You can also get a small data logger built into either Panelview+ or Red Lion Gxxx operator panels "for free" that do a pretty decent job. There used to be a free SQL data logger available from www.rongage.org but the key component (the ABEL or CELL library) is no longer free so the data logger is kind of useless without it.

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites
Jak, The comments you heard about Opto 22 I/O quality are surprising to me. Opto 22 is actually known for it's quality (it seems by others than the people who've posted). All Opto solid state I/O carries a lifetime warranty. We are able to do that because of the low failure rates. All aspects of our operation including design, test, and manufacturing are done within the four walls of our facility here in Temecula CA (yes "made in the USA", when the Mexico border is 1 hour and 20 minutes away...where everyone else in CA gets their PCB's done). By manufacturing in-house, we can tightly control all aspects of quality as well as engineering, sales, and marketing. If you need references, there are tens of thousands, but I could put you in touch with say a few integrators who've done many jobs with Opto I/O and controllers. Just let me know. There are lots of case-studies on www.opto22.com. Finally - I would encourage you to consider our Intelligent Remote I/O for your A-B CompactLogix or ControlLogix systems. Lots of information (white papers, tech notes) as well as videos showing how easy it is to configure communications are available at www.io4ab.com. One thing to keep in mind that what differentiates our I/O from others, when used with A-B PLCs/PACs is the availability of intelligent attributes, without any programming (not just a bus-coupler). Examples: you can configure a regular DI as a counter and return counts to A-B w/out any programming, for analogs, you can return (in addition to Analog value) "max value" w/out any programming, you can write to the clamp attribute to an AO, etc. Good Luck and Have Fun with your project. Arun Sinha, Opto 22

Share this post


Link to post
Share on other sites
Welcome to mrplc ARUN. Always glad to have a manufacturer's hardware expert to assist our members. Are the Opto 22 modules you say have lifetime warranty the same Opto 22 modules that my electricians change out from time to time in our PC104 based control machines. If so I am missing the boat by recycling them rather than returning for credit it seems.

Share this post


Link to post
Share on other sites
Thank you for the "Welcome", Bob. The modules being used with your PC104 are likely either our "G1" or "G4" modules...and YES, they can be warranty replaced, even though likely 15-20 years old (or more!). To help you identify, the G4 have an LED on them and G1 do not. - Arun

Share this post


Link to post
Share on other sites
I may be getting into this a little late to help, but I will put my 2 cents in. First I cant stand Device Net. Every facility I have worked with has managed to damage at least one component. It just doesnt stand the industrial test that I expect. Ethernet I/P is easy to teach and works well. My rep recently told me that 70% of all PLC to device communications is Ethernet I/P now. Profibus is not generally considered an AB solution, but it works well. Jumping into the Opto issue, I must say I dont have a lot of experience with it. I would be wary about installing an Opto system in what seems to be a facility that otherwise has all AB systems. That means more software and training for the maintenance guys in facility that has generally standardized on AB. No I am not an AB rep... As for the processor, have you looked at the new L2x series of compact logix? Its basiclly the block version of a compact logix. You can only add two additional modules, but you can address 8 Ethernet I/P drops. Hope this helps. Russell

Share this post


Link to post
Share on other sites
I've used DeviceNet, ControlNet, and Ethernet/IP and I have to say I like Ethernet/IP the best. Easy to connect everything and easy to debug when there is a problem. Connectivity issues only bring down 1 device if your network is set up properly. As for the remote devices themselves, I love using SMC's EX500 gateways. The only downsides with Ethernet/IP is that you have to know how to set up the network so it doesn't get bogged down with all the unicast traffic. With any decent amount of devices a managed switch becomes a must, so there is a little more $$ involved, but I think the ease of use and reduction in debug time outweighs the cost.

Share this post


Link to post
Share on other sites
I prefer Ethernet/IP. Ethernet/IP is easy to setup and use with Rockwell PLCs. I can't vouch for the Omron version of Ethernet/IP because I haven't tried it yet. Ethernet/IP allow one to transfer 64 32 bits words as I/O on our controller. I think we may have just expanded that to 128 32 bit words in and out. You just can't beat that performance. Profibus DP can only transfer 32 32 bits words. DeviceNet can only 8 bytes at a time which usually means on one 32 bit value is transfered at a time. That is pitiful. Ethernet/IP provides a lot performance and flexibility that other networks don't. The MSG block allows transfer of parameters and logging data real time. The message data can be very long. I dread it when ever customers chose Profibus DP. There are some experienced Profibus DP users here that know how to configure a Profibus DP system but usually we must do a lot of hand holding for first time users. I haven't used DeviceNet. We have a DeviceNet development system but no one has said you must have DeviceNet or we will not buy your product. Once we say we have Ethernet/IP everything is cool. JAK, if you want more performance out of the pick and place you can always run a Ethernet cable to a local motion controller. A good motion controller can make quick work of a pick and place. Even ones where the conveyor or belt doesn't stop moving, a 'flying' pick and place. What I like about the Rockwell version of Ethernet/IP is that it doesn't require those EDS files.

Share this post


Link to post
Share on other sites
Probably 124 or 125. Unless there have been some changes to the standards the packet limit is 500 bytes. Still great performance. Glad you mentioned it. I have a project coming up and I almost forgot to put Delta on the list of possible motion controllers

Share this post


Link to post
Share on other sites
I know that is a limit due to the size of the dual port ram on the Ethernet cards. I don't know if that is a limitation for all Ethernet/IP devices.

Share this post


Link to post
Share on other sites
Hmmm. JAK said he had decided on an ML1100 or an ML1400. That is quite a jump from talking about RIO/DeviceNet/EthernetIP. Ha ha. I cant believe the discussion rounded FF, and he chose an ML. Those are simply the extreme ends of the spectrum.

Share this post


Link to post
Share on other sites
I will chime in with my 2 cents. I would go with Beckhoff I/O, talking Ethernet/IP to a CompactLogix CPU. If you have any pneumatic or valving outputs, Ethernet/IP to a Festo rack. Heck, you can run all of your I/O from a single Festo rack (pending I/O count).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0