ControlLogix to 1771 Analog IO

Before I start, let me say I have very little experience using ControlLogix, but have lots of experience programming PLC5's and SLC500's.

I'm in the process of upgrading some PLC5's to ControlLogix processors and have read numerous threads on the subject. Phase 1 of this project will likely involve replacing only the processor and reusing the existing remote 1771 racks and 1794 Flexio. My immediate concerns are how best to handle the Analog module messaging.

We curently have about 36 analog cards consisting of various:
1771-OFE2
1771-IFE/C
1771-IXEB
1794-OF4I
1794-IF4I

My initial thoughts were to retain the RIO "blue hose", but have read some comments on using ControlNet.

I already have a 1756-DHRIO which if I use, it looks like my analog configuration messaging would all be done in the processor. I have heard that the ControlLogix processor has a limitation on how many message blocks it can handle. What is the cause of this limitation? If it is performance, can I slow down the access speed and fully support all my 36 analog cards?

I've also heard of using a 1756-RIO where the message blocks are kept inside the RIO module and don't burden the processor. Would a single RIO handle all 36 modules in this configuration?

What about ControlNet? Is this a good option to replace the RIO? How is the analog messaging done over ControlNet? Is it the same as RIO or are the message table done separately similar to the 1756-RIO?

The ControlLogix processor is a 1756-L63 B

Thank you for your responses.

Rollie Raper
Process Control Designer
Absorption Corp

I would retain the RIO network and use your 1756-DHRIO card (I don't have experience with the 1756-RIO card). There is a limitation of number of 1771 racks you can interface with. I think it is 17? Have to refer to the manual for specifics. I believe the 1756-RIO can do more. I think the 1756-DHRIO was just a card built to work with RIO networks until better IO migration took place, but with the prevalence of RIO installations I think AB wised up and came out with the 1756-RIO to cater to those system migrations that need to keep costs down.

Now, you said "Phase1 ", so what does the next phase do? Are you replacing the 1771 IO? Then it may make sense to jump to ControlNet/Ethernet at that time, but not until them. I'd save on costs and keep the existing.

Now, depending on what your analog does, you can optimize the MSG instructions to them (BTR/BTW equivalent) so you can minimize the hit on the processor. So any analog not used directly for control could be slowed down to minimize the impact, while analogs directly related to process control could run quicker.

I believe that the 1771 Control net adapter has been placed on silver series status, so you'll probably want to stay away from it. If you can't just make a wholesale conversion then DHRIO is the way to go. The DHRIO card supports two networks so if you have multiple chassis divide them between the two networks. We have had several threads discussing 1771 to 1756 conversions that you can find with a forum search.

At one point I was an advocate for keeping the 1771 IO as a remote IO chassis, but as the 1771 system has gotten even older I've changed my opinion to bite the bullet and make the complete change if you can instead of drawing out the pain. If you absolutely cannot take several hours of down time then AB offers a $olution (note $ character substitution) that allows you to re-use your 1771 wiring arms with a brand new Controllogix chassis and 1756 IO, and it can be done in about ten minutes (provided you have the program written in advance). Whether it is worth it or not will depend on how time critical the conversion has to be.

Take a look at this migration solutions brochure
http://literature.rockwellautomation.com/idc/groups/literature/documents/pp/migrat-pp003_-en-e.pdf

And this video:
http://mms.rockwellautomation.com/idc/groups/multi_media/documents/multimedia/1771to1756.wmv

When I say "Phase 1", what i actually mean, is we have been very happy with the robustness of our PLC5 systems, the replacement parts are cheap if bought used and we almost never have any hardware failures. The motivating factors are the PLC5 processors are quite bogged down with speed as they control numerous PID's and complex analog calculations as well as difficulty keeping up with the a number of Panelview Plus touchscreens screens connected over ethernet. Even with Series F PLC5 processors, we still have scan times and access issues.

If it wasn't for speed, we would be happy to stay with a PLC5. Having said that, I'm thinking "Phase 1" where we only upgrade the Processor may be as far as we go for the immediate future.

We are a small company and the cost new for Allen Bradley components is not one we can easily handle.

Rollie

Which PLC/5 processors are you using?

I've still got a couple of 5/20s in service that haven't been converted over yet. Despite my changing opinion on conversion -vs- gradual migration I still really do like the PLC/5 platform. Both of the 5/20s are on a DHRIO network with a CLX in a 4 slot chassis and the CLX has an ethernet IO network (couple of drives and five remote IO groups). The CLX is now doing some of the work that the PLC/5s would have been doing and the three PLCs are co-ordinating with a just few messaging instructions. All of the HMI functions are now running through the CLX. One of the PLC/5s is slated for complete replacement next spring.

Its possible that with some thought you can keep your PLC/5s and just add a simple CLX to free up some resources - its may be worth exploring that option.

rollie715 said:

...

If it wasn't for speed, we would be happy to stay with a PLC5. Having said that, I'm thinking "Phase 1" where we only upgrade the Processor may be as far as we go for the immediate future.

Rollie

Click to expand...

Interesting...are you sure you understand the root cause of your speed issues? The red flag went up when you talked of numerous PanelView Plus terminals. The more that talks to a processor, the more the burden, and it doesn't necessarily improve with a new processor. Granted the CLX processors have more bandwidth and CIP connections, it is something to not loose sight of. Simply adding a RSLinx Gateway server into the mix to communicate directly to the PLC and PanelViews to the server might make an improvement as well. Are the PanelViews talking with the controllers VIA Ethernet?

Paully's5.0 said:

Are the PanelViews talking with the controllers VIA Ethernet?

Click to expand...

Our most loaded PLC5 was running a 5/40E Series F which recently failed and we are limping along with a 5/40B with Enet sidecar. Access time to the PV+'s were slow even with the Series F, but is almost unbearable with the 5/40B w/sidecar. All the PV+'s of which there are eight are connected using ethernet. I tried moving a few over to DH+, but still had issues.

Management has decided not to spend the excessive money to purchase a replacement Series F and has directed me to make use of some existing ControlLogix gear we picked up recently with some used equipment.

I know this might be a crazy idea, but here's a thought:

Leave the PLC5 processor in place along with all it's connected Remote IO and use it only as an I/0 bridge to the CLX. (Kind of like a smart RIO module, but using the PLC5 as the interface). Leave all the present analog Read/Write messages in the PLC5. Transfer the rest of the PLC Logic with the excepton of the analog Read/Writes into the CLX and Message Block all the IO data between the PLC5 and CLX over a dedicated ethernet connection.

All the PV+ screens would communicate only with the CLX.

As an alternative first step, I could leave all the logic in the PLC5 and just use the CLX as a bridge to the PV's, thus relieving the PLC5 of all the ethernet traffic.

I know it's crazy, but I'm just sitting here imagining the many ways to approach this problem.

Rollie

rollie715 said:

I know this might be a crazy idea, but here's a thought:

Leave the PLC5 processor in place along with all it's connected Remote IO and use it only as an I/0 bridge to the CLX. (Kind of like a smart RIO module, but using the PLC5 as the interface). Leave all the present analog Read/Write messages in the PLC5. Transfer the rest of the PLC Logic with the excepton of the analog Read/Writes into the CLX and Message Block all the IO data between the PLC5 and CLX over a dedicated ethernet connection.

All the PV+ screens would communicate only with the CLX.

As an alternative first step, I could leave all the logic in the PLC5 and just use the CLX as a bridge to the PV's, thus relieving the PLC5 of all the ethernet traffic.

I know it's crazy, but I'm just sitting here imagining the many ways to approach this problem.

Rollie

Click to expand...

Rollie, you beat me to it. I'd call it a Data Pump, but, none the less, keeping the PLC 5 as a smart remote I/O processor is a good first step.
And, don't forget, all those PanelviewPluses take connections!!!

I like the idea. Except that (without seeing the system) I'd keep all the logic in the PLC/5, and buffer all the PV data to a couple of data files, then message those files to the CLX (has the advantage of scan syncing PV writes). Let the PVs duke it out with the CLX.

While we are on the subject of messaging, what are the pros and cons of each type? Ethernet? DH+? Controlnet? I am currently messaging between different PLC5 processors using DH+. I was think of using Ethernet for this plan, but have never used it for passing actual data used for control. What is best for reliable data transfer?

I've dealt with this multiple times. I've used the 1756-DHRIO module with good success, but there is a limit on the number of cached connections, so many per channel, and so many per CPU.

What'd I'd suggest as a better option is a 1771-ACNR15, or better yet, 1771-AENT to replace the RIO adapters. I have used the 1771-ACNR15 with very good results, but Ethernet is a better way to go; as someone else mention, the ANCR15 has been Silver Seriesed. I suggest a SEPARATE 1756-EN2T module dedicated to handling the I/O communications.

The 1756-DHRIO: Reasons Why Not

A good RA Knowledgebase summary of the connection limitations of the 1756-DHRIO and the ControlLogix controllers is Answer ID # 41853 (TechConnect Required).

I'll summarize the important parts as they pertain to the 1756-DHRIO:

16 Block Transfer connections per channel.
32 cached Message Connection of any type per CPU
5 Unconnected messages on the backplane simultaneously.

As a practical matter, you could not run 36 analog modules effectively with a ControlLogix and the 1756-DHRIO.

I say "effectively" because in the narrow focus it looks like it might work if you split up the RIO network over two 1756-DHRIO modules and three channels, and you ran some of the messages un-cached, then sequenced them so they weren't active at the same time.

In practice, though, you're probably going to be doing both DH+ messaging and definitely will be servicing multiple PanelView Plus terminals. That's going to put a lot of pressure on the ControlLogix unconnected buffer capacity and I predict that it would end in unsatisfactory performance.

Joe mentioned a "1771-AENT". I have not heard of the development or release of this module, and I try to pay pretty close attention.

The SLC-500 chassis version, the 1747-AENT, spent about three years as a myth before actually hitting the market.

If this were my system and I were in Rollie's shoes, I would use the 1756-RIO module.

As I mentioned, this module can be configured in "Ghost" mode, in which you could read the existing RIO discrete and analog data, so you can migrate and test the logic in ControlLogix piece-by-piece at your leisure.

If you'd like, I can put you in touch with the guys at a local cheese producer who did a moderately complex project with this module.

The story was similar: a large system stitched together out of 1771, 1746, and 1794 I/O on RIO, with a PLC-5/80 that was straining to keep up with the HMI traffic and was down to its last few bytes of RAM.

We worked on this in fits and spurts for months, taking an hour of downtime here and there to do the RIO autoconfigure and the waveform analysis we needed to make sure we weren't chasing bad wiring (decades of caustic washdown) as well as protocol and performance.

We didn't get everything; some of the PID performance we thought would run perfectly was way out of whack. But we did the switchover in the span between two production shifts, with a co-op full of milk producers stacking the highway with tankers because the pass was closed due to snow. Didn't lose a drop.