SLC as Remote I/O on ControLogix Ethernet

[patb63 0]

We are working on changing out the controls for a customer who is currently using PLC 5 and SLC 5/04 controllers. The customer has requested all new ControLogix processors and for all interconnections to be via Ethernet instead of the current data highway. Currently, one system has a SLC 5/04 processor in a 13 slot rack, with another 13 slot rack connected to it by an expansion cable. We would like to use these two racks as remote I/O from the ControLogix processor, but we are not sure what hardware to use to enable us to effectively use all the I/O points. The problem is in the layout of the current I/O; the first rack has the processor in slot 0, then an input card in slot1, an output card in slot 2, input, output, input, output,.......all the way to slot 12. The second rack has an input card in the first slot, then an ouput card, input, output, input, output....until slot 10 and then it has 2 more input cards. Using an ASB module would be fine for the first rack, but we would have to add another remote rack and reconfigure the I/O for the second rack. Any ideas?

[Ken Moore 23]

From the AB website: The adapter module must reside in the left-most slot of the remote chassis and can interface to a maximum of 30 1746 I/O modules residing in up to three interconnected chassis. There are three 1746 I/O adapter modules: the 1747-ASB for remote I/O communication, the 1747-ACN15 for remote communication via ControlNet, and the 1747-ACNR15 for remote communication via ControlNet with redundant media port. Looks Like you only need one adapter.

[Ken Roach 194]

Ken Moore is right on; the 1747-ASB will handle 30 slots. Two 13-slot racks, that's 25 addressable slots, so you're fine. The 1756-DHRIO will be your scanner for the ControlLogix. There isn't an "Ethernet ASB" for 1747 I/O chassis, and the ControlNet adapter works only with PLC-5C15 and SLC 1747-SCNR scanners. You cannot connect 1747 chassis to ControlLogix over ControlNet.

[paulengr 44]

What's wrong with leaving the PLC in place and just having it turn into a "data shovel"...delete the program and simply let the CLX do MSG instructions to copy data from the I: map and to the O: map? Speed should be relatively the same. And if you need to support block I/O, the SLC would be much more efficient at doing this than the DHRIO card anyway. And the implementation will be cheaper and have far less risk since you never actually physically yank the processor out, assuming that a SLC 5/04 can do Ethernet (I'm only familiar with the 5/05).

[Bill Wiewandt 0]

The SLC5/04 does not have an Ethernet port like the 5/05. I personally don't recommend using messaging for I/O but it all depends on what your application can tolerate, I guess.

[BobLfoot 302]

Yeah Several. First of all if your customer absolutely insists all internconnects between Controllogixs be by Ethernet make sure that Ethernet Network is isolated from the normal building "office data" network. If not you can roll the dice on round trip data exchange timings. Second you can install a 4 slot CLGX Rack with a CPU and ControlNet scanner and repalce the PLC 5 CPU with 1771-ACN and use controlnet as your backbone. This is a proven method as is replacing the PLC 5 CPU with 1771-ASB. THis method lets you quickly roll back to the PLC 5 during the dry and wet run test phases. Third the SLC 5/04 would be best converted with an ASB as well. You can still connect your new CLGX's by ehternet but use the other network topology for I/O connectivity to your CLGX Cpu.

[Bill Wiewandt 0]

BobLFoot, Excellent post. I should have been concentrating more on the main question at hand rather than just a small detail. I may be new to this forum but I don't think I could have said it better myself. "Keep the main thing the main thing"...

[patb63 0]

Thanks for all the replies. They have been pretty helpful in working on the planning for this changeover. I need to clarify a couple of things and also ask another question. First off, the network for these controls will be a separate network system just for the PLCs and I/O; this customer is planning ahead for their communications network and is investing in the hardware to make it right. BobL, per this quote "Third the SLC 5/04 would be best converted with an ASB as well. You can still connect your new CLGX's by ehternet but use the other network topology for I/O connectivity to your CLGX Cpu.", I take it you think we should stick with the DH for remote I/O connections. My concerns with that are that it doesn't meet the customer's expectations and I thought the DH/RIO was limited to 8 words of addressing. Wouldn't we have to put an ASB in each of the thirteen slot racks? This would cause a lot of re-addressing existing I/O as well, plus adding a third rack for the card replaced by an ASB in the second rack. Ken (Moore & Roach), am I mistaken in my thoughts on the DH/RIO? Will the I/O as laid out in my original post work without having to re-configure and add another rack? Thanks again for your input and sharing of knowledge.

[Bill Wiewandt 0]

PatB63, A DHRIO channel, when configured for Remote I/O, can communicate with up to 32 unique rack numbers and have a maximum of 32 physical devices connected to it. What this means is if you have 32 devices that all use 1 FULL rack (8 module groups) or less, then you can comm with all 32 remote racks. But, if you have 16 physical racks that all take up 2 logical racks each (16 slot racks addressed as 1-slot addressing for instance), then you will only be able to connect to 16 physical racks as you have met the maximum number of 32 logical racks. Hope this makes sense. Here are some other points to ponder. You can keep the 1771 and 1746 by removing the processors and replacing with adapters. A-B has several I/O networks available. Ethernet - Excellent choice except there are NO Ethernet adapters to put into 1771 or 1746 racks. This is not a supported option. ControlNet - Another excellent choice but this one carries a bit more baggage than Ethernet (need to schedule using RSNetWorx for instance). You can use a 1771-ACN®15 in the 1771 racks but you cannot control 1746 SLC I/O on ControlNet with a ControlLogix controller. This is not a supported option. DeviceNet - You could use 1771-SDN and 1747-SDN but these require you to still keep the existing processors. Probably not a good choice. Universal Remote I/O - This option replaces the controllers with ASB adapters. This provides the best bang for the buck IMHO but you will be using older technology (RIO can be very solid network however.). Be sure to check whether all your SLC modules can be used in remote racks however. In this scenario, you add a 1756 rack with a processor (1756-L6x), a 1756-EnxT Ethernet bridge (for corp LAN), a 1756-DHRIO (or 2 if needed) to communicate with Remote I/O. Finally, you could do some sort of a mixed network such as using ControlNet to control the 1771 I/O then bridge to the SLC over RIO using the DHRIO module but this may be more confusing than its worth. \

[patb63 0]

Bill (and others), Thanks for the help. The customer has decided to replace existing SLC 5/04 processors with 5/05s. This gives them the ethernet connectivity and prevents having to reconfigure any I/O.

[BobLfoot 302]

Contact your local Rockwell/AB Distributor. There was a time when AB offered "upgrade path" savings if you swapped a 5/04 for a 5/05 rather than buy the 5/05 outright. Don't know if they still do given how long the 5/05's have been around.

[Bill Wiewandt 0]

Check with your local A-B Distributor to confirm the amount of the return credit but it looks like replacement of a 5/04 with a 5/05 may be elgible. This is part of the StepForward program. Use this link for more info. http://www.ab.com/stepforward/

[kaiser_will 65]

Comment: FYI - The original I/O card layout in the racks is psuedo-double-slot addressing. It appears the original rack builder was versed in the old double-slot addressing days from the PLC-2, in which I/O cards were arranged in groups (Rack/Group/Slot). I believe it is only an asthetic detail in SLCs and PLC-5s. Question: Your customer has requested to upgrade processors to ControlLogix and convert the communication protocol to Ethernet-based, but what is the business justification? Data Highway is a solid communication protocol, and SLCs/PLC-5s are in the middle of their obsolescence plan. I have seen customers take the bait from sales guys telling them their hardware is obsolete, yet A-B implements very long-term obsolescence plans. For future installs, I can understand the desire to go to an open-fieldbus based communication protocol with a CompactLogix or ControlLogix CPU, but I see no deliverable in capitalizing the upgrade on existing, running production lines. Step back and ask WHY five times to build the business case for the customer's request. Edited 3 Apr 2009 by kaiser_will

[JesperMP 2]

You basically said it yourself. The smart customer do not wait until the last minute. Costs for maintenance and spares WILL increase. At some time spares WILL become completely unavailable. There will be an aftermarket, but you are at the mercy of what is available. It starts with the most esoteric and rarely used hardware, and in the end even the most common hardware will be hard to get. Also human expertise fade. At some time, for every plant, it becomes more advantageous to upgrade than to nurse.

[paulengr 44]

Not true. RIO is solid but AB has escalated the pricing on PLC-5 and SLC parts to the point where maintenance becomes a business case. Losing a 5/40E is over 5 digits now. Many of the cards that support RIO are now "classic"...as in as long as the parts hold out, AB will continue to custom build them (for a price) on demand, but don't plan on keeping them around. Many of them have also disappeared forever. As RIO is also a bus-style network, there's also a case to be made for reliability. Just like DeviceNet (AB's modern bus network), one little problem with a single part on your IO network and ALL your remote I/O can stop communicating. So the question becomes a matter of overlaying and absorbing your PLC-5 and SLC processors into a more modern PLC system. Then phasing out the old I/O as time and money permits. But it is a difficult uphill battle quite often to justify getting rid of the processors themselves because the cost usually becomes much greater than that of phasing out a section of I/O here and there over time.

[patb63 0]

Our customer is pretty forward-thinking at this stage of the game. Their business is good (despite the rest of the economy) and the capital funds are available to the project manager to make the switch now to upgrade their system. We are replacing some PC-based controllers with CompactLogix processors for some sortation equipment, so the project manager is using this opportunity to upgrade the whole facility (unfortunately for us, it's one sorter at a time). Thanks for the reminders on the Step Forward program.