DH-RIO Nightmare

Jmeadows7676

Member
Join Date
Oct 2013
Location
Alabama
Posts
158
We have upgraded an existing PLC 5 to a 1756-L81e using DHRIO cards as a substitute for Channels 1 & 2
Due to Short downtime we had to leave the IO as is. This system had 10 1794-ASB and each ASB had 3 to 4 1203-FM1 (RIO to Scanport) modules. Each 1203-FM1 can communicate with 2 1305 Drives. This system has a total of 54 1305 Drives. Now to the problem....
If we use the program as it was converted the DHRIO locks up when we enable all the BTR/BTW Message instructions. First Fix was Scheduling all the BTR/BTWs with a do / done style and not cache the MSG connection. This kept the card from locking up but it took about 3 seconds for a msg instruction to repeat. Second Fix is we split the load between 2 different DHRIO still using the same do / done style sequencing. This got us to about .5 sec round trip. I said all of that to ask this. Would I gain anything to use a 1756-RIO instead of 1756-DHRIO. The RIO handles the BTR/BTW natively instead of using a MSG. I don't have one on hand to try so I wanted to ask before going down that road.
 
Couple questions, are you only triggering your BTWs once on startup? Or are they triggering constantly? Also, it sounds like even if you are only triggering your BTRs constantly, 54 MSGs is a lot for a Logix processor to handle. I see you mentioned you attempted sequencing the instructions, how exactly are you going about this? I recently received a copy of a program that shows Rockwell's recommended strategy for managing multiple/many messages, and it seems to work really well. I've never heard of do/done sequencing before, so it may be the same thing.

EDIT: Disregard this, I had missed the part where you said your sequencing got you down to .5ms round trip and misunderstood what you were asking.
 
I used to do this for a living. Even with the generations of capacity and speed in the ControlLogix, the buffers that the 1756-DHRIO and the CPU can handle for MSG instructions are still limited to just sixteen. Straight PLC-5 -> DHRIO conversions often ran into exactly the sort of problems you describe, even when the signal quality was good on the existing hardware.

>Would I gain anything to use a 1756-RIO instead of 1756-DHRIO

Very likely yes. That's how I did large BTR/BTW systems once it became available. The 1756-RIO does all the RIO block transfers onboard and uses fast cyclic CIP connections to get the data to the ControlLogix.

>3 to 4 1203-FM1 [each with] two 1305 drives

Exposition: the 1305 was a simple low-power AC variable frequency drive, a little brother to the 1336 Plus II. It has the classic A-B SCANPort interface, which connected to 1-port network interfaces (RIO, DNet, CNet, Profibus DP, Modbus) as well as 1794 FLEX (2-port) and 1747 SLC (3-port) I/O platforms.

The 1203-FM1 uses more FLEX backplane power than other FLEX modules so you couldn't use more than 4 of them per 1794 network adapter, even if the platform would support that much data exchange.

I checked the installation manual to refresh my memory, and the 1203-FM1 uses 6 words of Input data and 5 words of Output data.

That's more than the 4 words per "Logical Group" that you can transfer over RIO without using blocks transfers, so it makes sense that every FM1 has a BTR and a BTW.

I believe you could also send block transfers to the 1203-FM1 to do Parameter Reads and Writes; I mostly used the old DNet and RIO single port interfaces, but used to be quite expert at composing efficient "Scattered Read" commands over SCANPort.

The 1756-RIO guts were developed by QTS in Florida (amazing how well it works when you joint-license and cooperate instead of violating patents), and are basically a backplane version of their AN-X module. I believe that they are doing all of their sales and support for the DH+ and RIO versions of the AN-X via ProSoft Technology in California now.

I haven't worked with the AN-X for nearly ten years, and my reading of the Prosoft website shows that it's developed quite a few nifty tricks like being a RIO Adapter/EIP Scanner as well as its core firmware as a heavy-duty RIO scanner. It is definitely the architecture of most large-scale RIO migration projects today.
 
my co corker has done several plc5 to logix 5000 programs and has had to correct some of the conversion parts of the program. messaging and btr/btw is among those he had to redo. i think he inserted a new rung and copied all the rung information, but inserted new msg and btr/btw commands.
regards,
james
 
my co corker has done several plc5 to logix 5000 programs and has had to correct some of the conversion parts of the program. messaging and btr/btw is among those he had to redo. i think he inserted a new rung and copied all the rung information, but inserted new msg and btr/btw commands.
regards,
james

I actually have done several of these and while I often have to adjust timer values and other things, the BTW/BTRs actually worked perfectly right out of the gate.
 
If it were my project I would just upgrade both the remote I/O and the Data Highway Plus to Ethernet at the same time you upgrade the processor.
Before I get into details I would like to clarify something I see here to often for some of you.
Because you said the upgrade is from a PLC5 to Control Logix system it would be assumed that when to refer to DH you actually mean DH+. While DH and DH+ are similar and can use the same coax cable
RIO and DH both use the same cable and some hardware is the same but the configuration is different for the data channels, so looks can be deceiving be careful .
DH was a very early networking system used on PLC2, PLC3, PLC4 and others but when they introduced the PLC5’s they changed the networking to DH+ as stated they use the same cable and look the same. There is a bridging module that can be used to connect DH and DH+ into one network.
In addition both Remote I/O and Data Highway us the same Blue Hose Coax Cable. Pay attention to the network cable connections they are reversed between DH and Remote I/O

The problem with DH+ is that it’s well past it life cycle so no new hardware is being produced anymore so when you have a failure and need a replacement you will be limited to rebuild hardware or what you can fine out there. It may work or not.
Logix processors don’t support Block Transfer so no matter what you do you will have to rewrite the Block Transfers to Messaging and that’s if you want to used the data table blocks. DH+ is very slow and limited in updating the I/O.
Then think about this when you have a failure and have to upgrade even just 1 I/O module on a network while your in an unscheduled shutdown, now you must not only rewrite the code to handle the network change but must also rewire the network add whatever networking hardware needed to complete the repair all while you production is down and your boss hanging over your shoulder wanting answers.
To me it would be far more cost effective to schedule a single down time and complete the upgrade in a planned orderly manner when it comes back up you don’t have to be concerned about it for long time. And if you do have to replace something it will be the new available hardware
 
I actually have done several of these and while I often have to adjust timer values and other things, the BTW/BTRs actually worked perfectly right out of the gate.

If you cut half of the BTR/BTWs off it does work perfect. The problem is I have about 30 Sets total. Thats the issue. I was just asking if the RIO would work better due to the BTR/BTWs get handle natively in the Card itself.
 
If it were my project I would just upgrade both the remote I/O and the Data Highway Plus to Ethernet at the same time you upgrade the processor.
Before I get into details I would like to clarify something I see here to often for some of you.
Because you said the upgrade is from a PLC5 to Control Logix system it would be assumed that when to refer to DH you actually mean DH+. While DH and DH+ are similar and can use the same coax cable
RIO and DH both use the same cable and some hardware is the same but the configuration is different for the data channels, so looks can be deceiving be careful .
DH was a very early networking system used on PLC2, PLC3, PLC4 and others but when they introduced the PLC5’s they changed the networking to DH+ as stated they use the same cable and look the same. There is a bridging module that can be used to connect DH and DH+ into one network.
In addition both Remote I/O and Data Highway us the same Blue Hose Coax Cable. Pay attention to the network cable connections they are reversed between DH and Remote I/O

The problem with DH+ is that it’s well past it life cycle so no new hardware is being produced anymore so when you have a failure and need a replacement you will be limited to rebuild hardware or what you can fine out there. It may work or not.
Logix processors don’t support Block Transfer so no matter what you do you will have to rewrite the Block Transfers to Messaging and that’s if you want to used the data table blocks. DH+ is very slow and limited in updating the I/O.
Then think about this when you have a failure and have to upgrade even just 1 I/O module on a network while your in an unscheduled shutdown, now you must not only rewrite the code to handle the network change but must also rewire the network add whatever networking hardware needed to complete the repair all while you production is down and your boss hanging over your shoulder wanting answers.
To me it would be far more cost effective to schedule a single down time and complete the upgrade in a planned orderly manner when it comes back up you don’t have to be concerned about it for long time. And if you do have to replace something it will be the new available hardware
GaryS
That was the original plan to replace all the 1305s with 525s and split them between 2 1756-EN2Ts but the powers to be said it might take to long. LOL...
I'm reminded of a quote I seen this website years ago.
"There's never enough money to do it right but there's always enough to do it twice "
 
I used to do this for a living. Even with the generations of capacity and speed in the ControlLogix, the buffers that the 1756-DHRIO and the CPU can handle for MSG instructions are still limited to just sixteen. Straight PLC-5 -> DHRIO conversions often ran into exactly the sort of problems you describe, even when the signal quality was good on the existing hardware.

>Would I gain anything to use a 1756-RIO instead of 1756-DHRIO

Very likely yes. That's how I did large BTR/BTW systems once it became available. The 1756-RIO does all the RIO block transfers onboard and uses fast cyclic CIP connections to get the data to the ControlLogix.

>3 to 4 1203-FM1 [each with] two 1305 drives

Exposition: the 1305 was a simple low-power AC variable frequency drive, a little brother to the 1336 Plus II. It has the classic A-B SCANPort interface, which connected to 1-port network interfaces (RIO, DNet, CNet, Profibus DP, Modbus) as well as 1794 FLEX (2-port) and 1747 SLC (3-port) I/O platforms.

The 1203-FM1 uses more FLEX backplane power than other FLEX modules so you couldn't use more than 4 of them per 1794 network adapter, even if the platform would support that much data exchange.

I checked the installation manual to refresh my memory, and the 1203-FM1 uses 6 words of Input data and 5 words of Output data.

That's more than the 4 words per "Logical Group" that you can transfer over RIO without using blocks transfers, so it makes sense that every FM1 has a BTR and a BTW.

I believe you could also send block transfers to the 1203-FM1 to do Parameter Reads and Writes; I mostly used the old DNet and RIO single port interfaces, but used to be quite expert at composing efficient "Scattered Read" commands over SCANPort.

The 1756-RIO guts were developed by QTS in Florida (amazing how well it works when you joint-license and cooperate instead of violating patents), and are basically a backplane version of their AN-X module. I believe that they are doing all of their sales and support for the DH+ and RIO versions of the AN-X via ProSoft Technology in California now.

I haven't worked with the AN-X for nearly ten years, and my reading of the Prosoft website shows that it's developed quite a few nifty tricks like being a RIO Adapter/EIP Scanner as well as its core firmware as a heavy-duty RIO scanner. It is definitely the architecture of most large-scale RIO migration projects today.
Thanks for the knowledge as always Ken.
I think am just going to get a little fancy with the scheduling. At any given time only 1 drive can run so if I break out of my regular update time (0.5s) and just MSG the Drive i'm trying to run at that particular time then go back to (0.5s) update time. I should be able to stop on the home flag. This is a Soot Blower System for a Recovery Boiler.
Anyway I'm going to try something like that after I run it by the Bosses.

Thanks again.
 
One advantage you have with changing everything to ethernet is that you can prewire and build the network while the PLC is still running in production so there is no down time for that part.
If you wait until your backup and running and then have a crash to build and wire the ethernet you will have a very long unscheduled downtime in the middle of the production run. The downtime shuld always be considered when doing an upgrade
 

Similar Topics

hello, I have a problem with my AN-X2-AB-DHRIO Prosoft module, I can't connect with the module because I lost a microSD card that has firmware and...
Replies
12
Views
372
We have a remove PLC rack that is being used to collect data from older equipment via a 1756-DHRIO module. This module occasionally faults out...
Replies
1
Views
406
Does anyone have information or documentation regarding the protocol used in Rockwell's Remote IO, and how the physical layer of the network...
Replies
5
Views
911
I have never understood how the I/O is configured using RIO. In the tree there is only the RIO module, not the racks of I/O attached or all the...
Replies
2
Views
1,287
HI All, I would like to know your opinion about the disposition over the 1734 and 1718 rack for the I/O Cards. - Normally I use for the first...
Replies
1
Views
472
Back
Top Bottom