PLC 5 TO CONTROLOGIX conversion

Hi Gents,

I am having a very difficult time in setting up the configuration for a PLC 5 system with remote i/o racks and redipanels,DCM cards to be controlled by a Clogix L61 Cpu.

This is the PLC 5 system:

1 physicall rack 16 slot set up as 1 slot addressing. This rack has a 1771 ASB series E adapter connected to a DHRIO scanner.The DIP swicth is set to rack 0.
This pyisical rack is set up as two logical racks ,rack 0 starting group 0 for cards from slot 1-8 and rack 1 starting group o for slots 9 -16

1 physical rack 16 slot set up as 1 slot addressing . This rack also has a 1771 ASB series E. The rack address is set up as 2 on the DIP switches.
This pyisical rack is set up as two logical racks ,rack 2 starting group 0 for cards from slot 1-8 and rack 3 starting group o for slots 9 -16

1 redipanel set up as rack 4 starting group 0 (full rack)

1 1747 DCM card in a SLC PLC set up as rack 5 1/4 rack starting group 2.

1 1747 DCM card in a SLC PLC set up as rack 5 1/4 rack starting group 4.

1 1747 DCM card in a SLC PLC set up as rack 5 1/4 rack starting group 6.

1 redipanel set up as rack 6 starting group 0 (full rack)

the control logix system has a L61 slot 0 ,1756-ENBT slot 1 and 1756-DHRIO slot2 as the scanner for the remote I/O described above. Channel B is DH+ and channel A is RIO.

PLC5 program all converted and downloaded .System runs but there are some massive delays in the I/O not sure how big but sometimes I am missing Inputs completely.

Otherwise I can write /read from all the devices on the RIO including DCM's and redipanels.

The other extraordinarily strange issue is that on logical rack 1 group 6 slot 0 I have a IFE analog input card which if I try to send a MSG with a Block Transfer Write to configure the card the L61 enters a weird state as it will kick me off line but it will keep controlling the machine/line. The only way to get back online is to place the L61 in program mode ,then remove it from the 1756-A4 rack !!!! then put it back go online disable the MSG instruction which locked the CPU up and key back to run then software back to run and it's all running again.

I have no errors on the RIO adapters as in the lights are green.

If the DCM's and redipanels are removed from the configuration and physically disconnected then the speed is good but I still cannot write the message with the Block Transfer to that one particular analog card. The other analogs in the system work perfectly.

Just wondering if anyone have seen something similar at all?

Just to make things more clear the DIP switch settings are as follows:

1771 ASB series E in the first physical rack.
S1 ALL ON. S2 1 ON the rest off


1771 ASB series E in the second physical rack.
S1 5 OFF rest ON. S2 1 ON the rest off

The Redipanels and the three 1/4 racks (1747 DCM cards )I didn't check the DIP switch settings as they work absolutely perfectly with the old PLC5 system.I got the system configuration uploaded from the OLD PLC5 channel 1B (RIO) config.



Just forgot to say that the original running configuration has a 1771 ASB series B adapter in the first remote PLC5 16 slot rack. I've tried setting the system up as such that the first 1771 ASB series E adapter rack 0 has the Series B emulation enabled.The second physical rack (logical rack 2) had a 1771 ASB series B adapter set as original (rack 2 ) and the speed was deplorable and I couldn't write to rack 1 group 6 slot 0 IFE 12 bit analog input module. Just wondering if the fact that if I try to configure the IFE input module with a MSG instruction locks up the CPU has anything to do with the fact that I am missing inputs sometimes and inputs get back to the CPU slower.

I also have to say that the DCM cards are off line if that part of the line is not used. The old PLC5 can handle that as nothing slows down but with the Logix system if I turn them off it further slows the system down to the point that I cannot actually run the machine in a safe manner.

I tried to inhibit these modules so they are not scanned but still no improvemnet in speed. Only if I remove from the config I have an improvement.

Further clarification :

In the I/O Configuration under the 1756 DHRIO I have this:

(2)1756-DHRIO/E DHRIO
CH B,Remote I/O
B <000 0 1> 1771-ASB RIO_ADAPTER_1 - 1771-ASB series E
B <001 0 1> 1771-ASB RIO_ADAPTER_1_1
B <002 0 1> 1771-ASB RIO_ADAPTER_2 - 1771-ASB series E
B <003 0 1> 1771-ASB RIO_ADAPTER_2_2
B <004 0 1> 1771-ASB Redipanel_1 - Didn't check DIP sw
B <005 2 1/4> 1771-ASB Robot1 - 1747-DCM
B <005 4 1/4> 1771-ASB Robot2 - 1747-DCM
B <005 6 1/4> 1771-ASB Robot3 - 1747-DCM
B <006 0 1> 1771-ASB Redipanel_2 - Didn't check DIP sw

As I said I connot write to <001 0 1> group [6:0] but I can write /read to all other analogs.

This sounds like an interesting challenge !

Let's see if we can put some numbers on "massive" and "deplorable".

Did you have any scantime information from the PLC-5 installation ? Was all of this I/O on a single channel on that PLC-5 as well ?

What RIO data rate are you running at: 57.6, 115.2, or 230.4 kb/s ?

My recollection is that the rule of thumb was that you can scan a RIO network at about 7 ms per adapter. With 9 adapters, that's about 63 milliseconds to scan the whole network, before you add in any errors, retries, or block transfer traffic.

In RSLogix 5000, there's an RPI value for the 1756-DHRIO itself, which is the diagnostic connection. The default is 25 ms. There are also individual RPI's for each Adapter, and the default is 48 ms.

The RPI for the adapter doesn't actually do anything to make the data move faster or slower on the RIO network. I always set it for half the time of the expected scantime of the RIO network. I would change yours to 32 ms.

The 1756-DHRIO has some diagnostic information on the Scanner's "Channel B Link Status" and "Channel B Protocol Errors" tabs. Take a look at these and see if there are any obviously incrementing error counters that indicate a physical or electrical problem on the network.

You can also access these objects using CIP Generic MSG instructions inside the controller. I like to do that on large systems so that I can programmatically tell when error counters are incrementing. I'd have to look up the precise object codes (Class, Instance, Attribute and structure) on the RA Knowledgebase.

The frequent disconnection of some of the adapters might be an issue, but probably not the most important one. Some RIO scanners have a settable Retries value, but I think the 1756-DHRIO has a fixed Retry of 3, so if a device is unplugged from the network it will poll it three times before moving on to the next device, which might introduce significant delays.

The PLC-5 also had a very elegant set of block transfer buffers and handlers, while the ControlLogix implemented that function into a general-purpose MSG and has a relatively low limit of 16 Block Transfer messages per controller.

It's a notorious issue with some older ControlLogix firmware that a "hung up" MSG instruction can cause the controller to stop responding to other Messages and can even cause it to not respond to the keyswitch being switched to Program mode. If you're automatically re-triggering a MSG instruction whenever it's Done or Errored, you can experience this condition when the target device isn't responding.

Automatic re-triggering of Block Transfers was a poor practice but was very common in the PLC-5, and it handled the issue relatively well by offloading the block transfer function to the "domino plug" daughterboard. The ControlLogix, like most thoroughbreds, is more high-strung.

I also have to say that the DCM cards are off line if that part of the line is not used. The old PLC5 can handle that as nothing slows down but with the Logix system if I turn them off it further slows the system down to the point that I cannot actually run the machine in a safe manner.

I tried to inhibit these modules so they are not scanned but still no improvemnet in speed. Only if I remove from the config I have an improvement.

Click to expand...

I've actually investigated this in depth with a protocol analyzer and oscilloscope. Inhibiting an Adapter in a 1756-DHRIO scanlist has no effect on the RIO network itself: the Adapter is still polled and retried.

Inhibiting the Adapter only stops the data from being exchanged between the DHRIO module and the ControlLogix CPU.

I would recommend adding another 1756-DHRIO so you can move the 1747-DCM modules to their own RIO network to avoid this issue.

This may or may not help, but when I have a crossbred system between ControLogix and 1771 IO, I use message manager coding to ensure that I only have one MSG to an ASB at a time. I know this was recommended when using a DHRIO module as RIO, but I found it to be much more reliable and "deterministic" than just letting the MSG restart.

Ken Roach said:

This sounds like an interesting challenge !

Let's see if we can put some numbers on "massive" and "deplorable".

Did you have any scantime information from the PLC-5 installation ? Was all of this I/O on a single channel on that PLC-5 as well ?

What RIO data rate are you running at: 57.6, 115.2, or 230.4 kb/s ?

My recollection is that the rule of thumb was that you can scan a RIO network at about 7 ms per adapter. With 9 adapters, that's about 63 milliseconds to scan the whole network, before you add in any errors, retries, or block transfer traffic.

In RSLogix 5000, there's an RPI value for the 1756-DHRIO itself, which is the diagnostic connection. The default is 25 ms. There are also individual RPI's for each Adapter, and the default is 48 ms.

The RPI for the adapter doesn't actually do anything to make the data move faster or slower on the RIO network. I always set it for half the time of the expected scantime of the RIO network. I would change yours to 32 ms.

The 1756-DHRIO has some diagnostic information on the Scanner's "Channel B Link Status" and "Channel B Protocol Errors" tabs. Take a look at these and see if there are any obviously incrementing error counters that indicate a physical or electrical problem on the network.

You can also access these objects using CIP Generic MSG instructions inside the controller. I like to do that on large systems so that I can programmatically tell when error counters are incrementing. I'd have to look up the precise object codes (Class, Instance, Attribute and structure) on the RA Knowledgebase.

The frequent disconnection of some of the adapters might be an issue, but probably not the most important one. Some RIO scanners have a settable Retries value, but I think the 1756-DHRIO has a fixed Retry of 3, so if a device is unplugged from the network it will poll it three times before moving on to the next device, which might introduce significant delays.

Click to expand...

Hi Ken,

The RIO data rate is 57.6 ,the whole system was on one RIO channel on the existing PLC5.
Regarding the speed settings I have the RPI set at 100 ms on the DHRIO and 30 ms on all of the adapters.

Regarding using another DHRIO to do the DCM 's it's not an option as part of my project is to remove the OLD SLC's with the DCM cards and install new MLogix 1400. All what is interfaced now using RIO and the DCM cards I will do on Ethernet if I manage to sort this speed isue out.

This is a working system production is happening on it right now. It's 2 am here and I'll be back on site at 8 am so I'll be able to have a look at scan rates and errors.

Ken Roach said:

The PLC-5 also had a very elegant set of block transfer buffers and handlers, while the ControlLogix implemented that function into a general-purpose MSG and has a relatively low limit of 16 Block Transfer messages per controller.

It's a notorious issue with some older ControlLogix firmware that a "hung up" MSG instruction can cause the controller to stop responding to other Messages and can even cause it to not respond to the keyswitch being switched to Program mode. If you're automatically re-triggering a MSG instruction whenever it's Done or Errored, you can experience this condition when the target device isn't responding.

Automatic re-triggering of Block Transfers was a poor practice but was very common in the PLC-5, and it handled the issue relatively well by offloading the block transfer function to the "domino plug" daughterboard. The ControlLogix, like most thoroughbreds, is more high-strung.

Click to expand...

What you described above is correct the old PLC5 was/is able to handle the errors on the BTW/BTR by continuously writing and reading and unlatching the error bit !! The old code even sets the TO bit !!!! without any condition.

Oakley said:

This may or may not help, but when I have a crossbred system between ControLogix and 1771 IO, I use message manager coding to ensure that I only have one MSG to an ASB at a time. I know this was recommended when using a DHRIO module as RIO, but I found it to be much more reliable and "deterministic" than just letting the MSG restart.

Click to expand...

Hi Oakley,

Even completely disabling the messages to all analogs gave me slow response time. The only way I was able to speed the system up to "acceptable" levels was to remove racks 4,5 & 6 from the configuration and disable the message which goes to group 6 on rack 1.

I will have another try in a few hours and update.

this is pretty "low tech" compared to the other suggestions – but I suggest that you take a good look at the terminating resistors ...

reason:

I have several pieces of equipment in my lab that have worked PERFECTLY for years on a blue-hose Remote I/O network with absolutely NO resistors installed – but – without the resistors, these same pieces of equipment will NOT work at all through a 1756-DHRIO module – even with exactly the same settings and configuration ...

to be specific:

if I leave the resistors off, and plug the blue-hose into a PLC-5, the system works fine ... on the other hand, if I move the blue-hose directly over to a 1756-DHRIO module, the connection won't work at all ... but ... when I put the proper resistors in place, the ControlLogix system picks up and starts working ...

going further:

I have another piece of lab equipment which will work OK through a 1756-DHRIO even without the resistors ... but ... if I increase the speed control, the blue-hose Remote I/O network suddenly gets all scrambled and loses communication ... (remember the grinder, Jeff?) ... then when I put the resistors in place, the 1756-DHRIO connection works fine even at higher speeds ...

so ...

I'm just saying that simply because your system works OK through a PLC-5 doesn't necessarily mean that it will work OK through a 1756-DHRIO module ... if the resistors are truly an issue in your system, then none of the other things you try are likely to completely fix your problem ...

good luck with your project ...

Ron Beaufort said:

this is pretty "low tech" compared to the other suggestions – but I suggest that you take a good look at the terminating resistors ...

reason:

I have several pieces of equipment in my lab that have worked PERFECTLY for years on a blue-hose Remote I/O network with absolutely NO resistors installed – but – without the resistors, these same pieces of equipment will NOT work at all through a 1756-DHRIO module – even with exactly the same settings and configuration ...

to be specific:

if I leave the resistors off, and plug the blue-hose into a PLC-5, the system works fine ... on the other hand, if I move the blue-hose directly over to a 1756-DHRIO module, the connection won't work at all ... but ... when I put the proper resistors in place, the ControlLogix system picks up and starts working ...

going further:

I have another piece of lab equipment which will work OK through a 1756-DHRIO even without the resistors ... but ... if I increase the speed control, the blue-hose Remote I/O network suddenly gets all scrambled and loses communication ... (remember the grinder, Jeff?) ... then when I put the resistors in place, the 1756-DHRIO connection works fine even at higher speeds ...

so ...

I'm just saying that simply because your system works OK through a PLC-5 doesn't necessarily mean that it will work OK through a 1756-DHRIO module ... if the resistors are truly an issue in your system, then none of the other things you try are likely to completely fix your problem ...

good luck with your project ...

Click to expand...

Hi Ron,

When you say proper resistors you refer to the resistor across the blue/clear cable on the last device on the system?
I have checked that and I have a 150 Ohm resistor there .I also put another one at the other end of the RIO also 150 Ohm. No improvement. I also tried 80 Ohm resistors at both ends and at only one end but no measurable effect.

The old PLC5 runs with a resistor across one of the DCM 's which is a 1/4 rack starting at group 4.This resistor is however across the DCM which hasn't got the last rack dip switch set.!!

As I said the PLC 5 system works fine woth these settings but the new CLogix through the DHRIO is very slow when I add these DCM's to the configuration.

So My question is if somebody knows what happens if to set the DIP swicth in one DCM as being the last rack but the resistor is across another DCM?? Will this cause a slowdown? Unfortunately I simply run out of time today before I could try to change the last rack switches.I had to return to the old PLC5 system as I needed to return the line to production.

I will send another email with what I found very shortly.

Thanks for your attention and help.

The term "Last Rack" is a little misleading: it does not indicate that a device is physically the last device on the daisy-chain, nor does it indicate that a device is the highest-numbered device.

Instead, it designates that a device is the last fractional-Rack Adapter in its Rack Number. This allows old PLC-2/3/5 scanners to stop polling for higher Starting Groups within a single logical Rack that's broken up among multiple physical devices.

You definitely need two terminating resistors, 150 ohms each. Disable, remove, or switch off any additional terminating resistors.

While the PLC-5 performance is a decent guideline, the DHRIO and PLC-5 don't have identical electronics and the DHRIO is known to be less resistant to noise and miswiring than the ultra-rugged PLC-5 scanners were.

Ken Roach said:

The term "Last Rack" is a little misleading: it does not indicate that a device is physically the last device on the daisy-chain, nor does it indicate that a device is the highest-numbered device.

Instead, it designates that a device is the last fractional-Rack Adapter in its Rack Number. This allows old PLC-2/3/5 scanners to stop polling for higher Starting Groups within a single logical Rack that's broken up among multiple physical devices.

You definitely need two terminating resistors, 150 ohms each. Disable, remove, or switch off any additional terminating resistors.




While the PLC-5 performance is a decent guideline, the DHRIO and PLC-5 don't have identical electronics and the DHRIO is known to be less resistant to noise and miswiring than the ultra-rugged PLC-5 scanners were.

Click to expand...

Hi Ken,

As I said any combination of resistors made no noticeable difference. I left the system with one 150 ohm resistor exactly as it has been working for many years.
The last rack setting is ok then as the DCM where the last rack setting is applied starts at group 6 (the highest in the rack) which tells the PLC5 to stop polling. That's ok then.All the DCM settings are correct.

Now what I found today shed some light over this big puzzle.

Issues found: The redipanel at B <004 0 1> 1771-ASB Redipanel_1 has a sticker on it saying that it is a reconditioned device. That's all good. However quite astonishingly the redi panel terminal itself 2705-K11C1 has been assembled incorrectly. The labels printed on the terminal logic module are 180 degrees inverted which make switch assembly one appear as 3 SW2 is in the middle so it is the same however switch assembly two appears as one. I had another redipanel nearby and compared with that and the switch assembly on that one matched the labels on the logic terminals. What an unbelievable mistake !! To assemble that incorrectly and get someone not very familiar to set a terminal like this up it's a perfect trap. Consequently whoever tried to set the system up managed to set the baud rate to 230 instead of 57 kbaud. One problem.

The other issue is even more astonishing. The software conversion from PLC5 to Contrologix converts the BTW and BTR block transfers as MSG 's. All nice and good.As I said I was fighting multiple issues at the same time in a system with problems everywhere and the last thing I needed is to discover that the message control block generated by the conversion simply doesn't work. Not only does not work but also locks up the CPU into a state where there is no way out but pull the CPU from the rack.
As soon as I changed the control tags for the MSG's (BTW and BTR) the message become OK and it never skipped a beat.
I never saw or heard anything like this before. I will have to check the structure of the block which doesn't work with the one which does as soon as I finish typing this.
This made me paranoid a little bit so I rewrote all messaging with new control blocks.
At this point the system was still slow. very slow as in the old/existing PLC5 system stops the main tray of an oven at a certain height ensuring that there is enough clearance to a bar which comes out from the oven every time after the tray is indexed.
With the new PLC same logic new configuration this stopping height is higher so the clearance is gone which makes the unload bar to touch the tray to the point that it can jam.

So resistors in place at both ends 150 ohm and all racks in the configuration the system is slow tray stops too high with the new CLogix.The 1771 ASB & 1756 DHRIO all happy and solid green lights. No problems just too slow.

The instant and second when I remove the "robots" so the DCM'S from the configuration :
B <005 2 1/4> 1771-ASB Robot1 - 1747-DCM
B <005 4 1/4> 1771-ASB Robot2 - 1747-DCM
B <005 6 1/4> 1771-ASB Robot3 - 1747-DCM

the system becomes faster but still not the same as the old one.Much better almost good /safe.

If I slow the messaging down from (full on speed based on the control block enable bit) to 1 x sec which is plenty the system comes to the same speed like the old PLC5 so clearances are all ok.

The time slice is set to 20% all this time.Total Scantime is ridiculously low can't remember but to the order of 3 miliseconds or similar.

As soon as the DCM's go back in the configuration everything slows down and can't use the new system.

Because I have to convert this system and make it seamless so there is no interference with production and we can return to the old one at any given time I will have to eliminate the DCM cards as part of the project is to upload the old fixed IO SLC's to micrologix 1400's. So I could do messaging over ethernet for whatever is done now using the RIO network. The interfacing is low speed and only a few bits in two words. This way I don't need the DCM's in the new system.

Also I am half way through the PV+ 1200 application which will replace the two redipanels so they'll come out too.simplyfying the configuration on the RIO.

Only issue I will have probably is that I will upgrade only one SLC with the DCM and interface it with the existing PLC5/30 CPU using ethernet rather than RIO so when production starts at the end of that particular day we will have only two DCM's and a new Micrologix 1400 talking wit the PLC5/30 over Ethernet.Repeat the exercise twice and I have the PLC5/30 talking with three Micrologix 1400 over Ethernet using MSG rather than RIO.

So when I remove the PLC5/30 CPU and switch over to the new system I will not need to add up to the configuration the DCM's as they will be long gone never needed again.This was the project plan from the start only that I hoped that I will be able to switch over to CLogix first by adding the DCM's to the config and run the plant like that the convert the SLC's with the DCM one by one with minimal risk.

Don't understand however why the DCM's slow down the system that bad. Even when the DCM's were turned off but were added to the configuration the system got slowed down.

Successful day as I had cleared most of the "voodoo" from the issues the only two are why the conversion tool from PLC5 to Clogix give you message control blocks which "destroy" the program and lock up the CPU and why the DCM's slow down the system drastically.

If you have any answer to these two question please let me know.

Thanks again for your time.