PLC-3 to Logix5000 Platform

[tcgjeg]

Has anyone done a successful [-LARGE-] PLC-3 system conversion to Logix while retaining all of the existing 1771-I/O? My main concern at this point in time is putting together an architecture that will work without scan time and hardware issues for an “UM” proposal.

To be more specific and bring you into our abyss, we have (2) two individual PLC-3 hot-backup systems that have about 40 chassis worth of I/O on each PLC spread across three scanner modules in each PLC system. (12 Channels / Networks each PLC – 24 channels total) The total I/O count doesn’t come close to Logix max. capability.

It would be desirable to bring all of this into one Logix processor using a primary/secondary setup. Sounds easy enough, but there are some concerns where the 1756-DHRIO module are concerned.

If we swap blue hose from all of our scanner module channels (24 in all) and apply them directly to the DHRIO module(s) ports we end up using 12 of the DHRIO modules. Each port would then support anywhere from two to ten drops based on existing routing of blue hose. We may be able to better this by combining some blue hose runs in the field increasing the drops on some channels. Anyway,,,, I know Rockwell’s claims of “Processing speed” – but is this a realistic application were scan time (RPI/NUT) is concerned? Has anyone out there tackled such a beast using the 1756-DHRIO? (P.S. Blue Hose = Belden #9463)

The use of redundant rack numbers is also a concern. Based on limited literature it seems like it may be possible as long as the same rack number is not used/configured on the same DHRIO module/network. Not sure…yet.

The amount of drops/racks off each channel is also a concern. (32-?) It just doesn’t seem realistic. We would feel more comfortable staying below (16). Not sure….Anyone exceeding 16?

Sorry for being long winded, but the application is quiet large and we need to get it right the first time. Any experienced advice would be appreciated so that we may get this project off the ground on the right foot. We are in contact with Rockwell direct. But,,, we would like to here about some real world experience. In our eyes, nothing speaks like experience. That’s when it all crawls out and is exposed.

(Software will be the next migraine. Don’t care to think about it yet.)

Thanks

 

[Bitmore]

I'm not a hardware expert but I do remember AB part numbers. It seems to me that you have put the perverbial "CART" before the horse.
Butt it's just my opinion. Look to reviving your remote I/O first, "usually the new stuff will talk to the old". Then with the new technology available in the field your question becomes mute.

 

[Gerry]

Sorry, no specific conversion experience and no redundancy experience - but I'm interested so did some reading.

First off, it appears that the DHRIO modules capabilities when scanning 1771-ASB's is very similar to the 1775-S4A/S5 - 16 rack numbers or 16 adapters per channel. If you have 16-slot chassis using single or half-slot addressing, you have to configure each rack number as one of the 16. Rack numbers have to be unique on any one module - i.e. no duplicates across channels, but across modules is OK. The RIO update times should remain very similar if you don't change the layout.

The DHRIO modules have to be in separate chassis from the redundant processor pair's chassis. In fact, you might as well split them between two chassis since the redundancy setup requires a minimum of two nodes in addition to the redundant processor pair on the ControlNet.

The thing you should quiz Rockwell about is whether or not your proposed configuration will be within the CLX processor's connection limits.

P.S. are you AllScott's 'friend'?
If you're unfamiliar with the PLC3 and ControlLogix, you've got your work cut out.

 

[kersl28]

I am not sure what you mean by "primary/secondary", but Redundancy or "hot backup" backup requires all I/O to be control net based. No other networks are supported for I/O connections.

 

[tcgjeg]

Bitmore: Not sure we are seeing eye-to-eye on this. But thanks for your reply.

Gerry: 16 per channel sounds more reasonable to us even though their manuals says quote: “A channel can have a maximum of 32 rack numbers and a maximum of 32 physical devices connected to it” Hmmm… We are looking at publication 1756-UM514B-EN-P (8-4). Very interesting about the DHRIO module not being allowed in the redundant processor pair’s chassis. We are due to continue our discussions with Rockwell today. Your input will make for good discussion. Sorry, I am not AllScott’s friend. I started in the business on 2/30’s & 3’s. Have lived all of the 5’s. Now doing some Logix w/training behind me from Rockwell. And now for the last year I have been doing major reworks/reconfigurations on the 3’s. (Full-Circle…ha) Our 128K ME module failed the other day in one of the 3’s causing downtime up the ying-yang, so as you can probably imagine the big push is on for the Logix replacement. It would be nice to get the plant into this century.

Kersl28: Sorry for not being clear. Yes, redundancy. We were looking at Rockwell’s redunacy PDF at the time of our post showing Primary & Secondary chassis’. Very interesting point you make. We will peruse this with Rockwell. Thanks for your input.

All input is greatly appreciated.

 

[Gerry]

We are looking at publication 1756-UM514B-EN-P (8-4).

That's the DHRIO manual.

You need to study the redundancy manual: 1756-UM523C.
For reasons unknown to me, it states quite clearly that you are limited to 16 rack numbers or adapters per channel when using ASB's. Presumably this is specific to redundancy applications.

ControlNet: the two redundant processor chassis and the two chassis holding the DHRIO's have to be linked with ControlNet - no options. There's also a separate connection between the two SRM modules.

Sorry, I am not AllScott’s friend.

I guess it was just a coincidence that there were two posts about converting a large PLC3 system only a day or two apart.

Good luck! - should be an interesting project.

 

[tcgjeg]

Gerry,

Thanks again for your input and interest in this project. We will browse the publication you have listed. Turns out that the Rockwell Home office in “Milwaukee” was much more willing and supportive in our project then our “Local” Rockwell support was. Here is what we have learned from the home office as it relates to our project in the past 24hrs:

We were concerned that all of our existing ASB modules may have to be of the same revision level. Rockwell says “No”. This is no longer a concern for us.

We were concerned about the claims in amount of drops listed in the publication that we mentioned previously. Rockwell says “Yes” the literature claims 32 drops, but (There’s always a but…..) under the most pristine conditions. Their final recommendation was to stick with what we currently have on the exiting system with no channel greater than nine drops. We have decided to proceed with a channel-to-channel swap between our existing scanner modules and the new DHRIO modules.

Trying to bring two PLC-3’s under one Logix processor with duplicate rack numbers on separate DHRIO channels. Again, Rockwell Milwaukee is the best!! Overnight they experimented on their test-stand to simulate this. They couldn’t make it work. Logix didn’t like it. We have moved forward and have now completed our architecture drawings for presentation.

Again, thanks for the information on redundancy. Seems as though we are now within those parameters.

Next Stop……Software Conversion & Software, Software Software……..

 

[Bitmore]

Please don't take this the wrong way. I still stand by my initial evaluation.

bitmore

 

[Eddie Willers]

The "gotcha" that I've heard about the most with large 1771 RIO installations is the ControlLogix CPU limit on "cached BT connections".

Analog and specialty modules in 1771 use block transfer instructions to get configuration and runtime data. This is still true with ControlLogix using DHRIO scanners; the only difference is that now it's a MSG instruction instead of a BTR/BTW instruction.

When you send a ControlLogix MSG instruction, the connection path has to be established between the CPU and the device. This involves some black magic involving "Forward Open" requests and connection buffers. When the message is complete, the resources that were used by it are returned to the system.

You can keep the message resources allocated by selecting "cache connection" in the MSG configuration. This makes all subsequent messages that use the same connection run much faster.

But the ControlLogix has a per-CPU limit of 32 Cached Connections. That's not a limit of the DHRIO, or the CNB, but of the ControlLogix CPU itself.

If you have more than 32 analog modules out in your many racks of 1771 I/O, you're going to run out of cached connection and will have to resort to uncached connections, which might take too long to complete for your purposes.

The first step I always take is to remove Continuous-mode BT's, and to make sure that BT's used for diagnostics or configuration are not being sent when they don't have to be sent.

A-B offers a "process RIO" scanner module that's meant for the ProcessLogix that can handle much large numbers of block transfer instructions.

This might also be a great opportunity to run a RIO analyzer (the old SST 5136-SD card came with one) and find out exactly what your RIO scantimes and block transfer completion times actually are. That way you have a baseline to aim for when you set up RPI's and so forth to the DHRIO modules.

 

[Derek McFarland]

PLC-3 to CLX

Try these guys.

http://www.isac-inc.com/eng/plc3.htm