PLC 5 TO CONTROLOGIX conversion

[daba]

20% timeslice is the default - try setting it up.

Your scan time is fast - so it seems this application has more comms than logic. So, if you're running ControlLogix V16 or higher, don't be afraid to wind the timeslice up and up and up, but be sure to check the box that lets the processor use unused timeslice for normal processing.

I once had one application with the timeslice set to 75%, just to handle the MSGs for the 1771 I/O that was attached. Sounds like a similar scenario.

Make full use of the number of message buffers available in the Processor and the DHRIO modules - i.e. don't do a daisy-chain "1 message at a time" coding. Allow simultaneous message triggering, up to the limit imposed by the modules.

I've worked on PLC5 to CLX upgrades where huge amounts of 1771 I/O was attached via DHRIO modules, and got great results - with careful consideration of the messaging restrictions.

 

[Latzi]

20% timeslice is the default - try setting it up.

Your scan time is fast - so it seems this application has more comms than logic. So, if you're running ControlLogix V16 or higher, don't be afraid to wind the timeslice up and up and up, but be sure to check the box that lets the processor use unused timeslice for normal processing.

I once had one application with the timeslice set to 75%, just to handle the MSGs for the 1771 I/O that was attached. Sounds like a similar scenario.

Make full use of the number of message buffers available in the Processor and the DHRIO modules - i.e. don't do a daisy-chain "1 message at a time" coding. Allow simultaneous message triggering, up to the limit imposed by the modules.

I've worked on PLC5 to CLX upgrades where huge amounts of 1771 I/O was attached via DHRIO modules, and got great results - with careful consideration of the messaging restrictions.

Yes 20% is the default. I've tried to play with it all the way up to 80% . didn't make any difference.Stoppping height of tray too high. Input got to CPU too late.

The only thing which seems to make a clear difference is the removing of the DCM's from the configuration. That makes a difference. Not sure whether it is normal for three DCM scanners (part of same logical rack) to make such a big difference? It shouldn't. There is barely two words /DCM exchanged.
The only logical explanation I have at this stage is that the wiring /cabling from the PLC5 remote rack (rack 2 & 3 logical) is simply bad. Not sure where it goes as it is impossible to follow the wiring through roof spaces with no access etc. One thing I noticed is that the blue cable which leaves one panel arrives as a black cable at one DCM panel. This cabling is my suspect.
I am not going to repair it as after the upgrade there is no need for RIO at all as what interfacing is happening through RIO now is going to happen through message blocks via Ethernet.

 

[The Plc Kid]

Sounds like this project would be better suited for a L7x processor. More memory and faster scanning and twicethe ethernet connections than a L6X.

 

[Latzi]

Sounds like this project would be better suited for a L7x processor. More memory and faster scanning and twicethe ethernet connections than a L6X.

I don't think the processor has anything to do with the speed issues.There is nothing high speed in the whole system and the actual scan time is ridiculously low as I said it's around 3 msec.

The I/O is not getting back to the L61 fast enough if I have the DCM cards in the system.

 

[Latzi]

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.

Just got back to this project after a few weeks break and I managed to make it work.
What has been done is I did set the baud rate to 230k from 56,7k and lowered the RPI rate of the 1756 DHRIO to 10 ms from 80 where is was set to as well as lowered all 1771 ASB adapter RPI's minimum of 2 ms and everything seems faster as in the machine tray stops at the right height which is a clear indication that the stop input gets to the CPU faster so the CPU can actually kill the output which drives the tray much quicker so it stops low enough to provide clearance.
The old PLC5 scan time was average 12 ms. The new Clogix CPU scantime is 3 ms however scanning the RemoteI/O took much longer.
So, for example, I have seven adapters on my network as I got rid of the redipanels and my baud rate is now 230.4 K, your approximate remote I/O update time would be 7 (# of
adapters) * 3 ms (scan rate), or, 21 ms.
The rule of thumb according to rockwell 1756 -um534b is to set the 1756 DHRIO adapter RPI to one half of the Remote I/O scan time so I set it accordingly to 10 ms and it's all good.
Previously I had 9 adapters on 56.7 k * 8 ms so 72 ms. The 1756 RPI was set to 40 ms so the worse case scenario the inputs from the 1771 ASB adapters came back for processing in RPI of 1756 DHRIO + two times the scan rate of remote I/O which was 144ms+ 40 ms so 184 ms.
So summa summ arum increasing the baud rate on all adapters involved on the remote I/O network fixed the issue and of course adding the 150 ohm resistors and replacing the RIO cables and elliminating the redipanel issues I described earlier.

 

[daba]

...I did set the baud rate to 230k from 56,7k ... and of course adding the 150 ohm resistors ....

For 230K the termination resistors should be 82 ohm, not 150 ohm

 

[Latzi]

For 230K the termination resistors should be 82 ohm, not 150 ohm

Hi Daba. I was actually using some sort of a mental shortcut when I tried to expose what the actual situation is. Every time I have a "window" of opportunity to get to that system for a few hours I change the resistors from 150 ohm on the existing system to 82 ohm on the Clogix/1756 DHRIO,1771 ASB adapter system as that new system is "crancked up" to 230 kbaud.
I didn't say properly what I wanted I suppose. The old existing running system is 56,7 k and I set the new system to be running on 230 K from a Clogix platform every time I have a commissioning session by setting all adapters 1771 ASB ,DCM,1756 DHRIO and Redipanels TO 230 k.In this later case I actually have used 82 ohm resistors.As I said it';s all good and tomorrow morning I will actually try to split the I/O racks/adapters over both channels of the 1756 DHRIO so the overall response time of the I/O will become faster.
The critical I/O in the old system is in the local PLC5 Rack. The scan time is 15 ms. This includes the housekeeping. I believe that for PLC5 systems during the housekeeping the LOCAL I/O table is updated.
The new system has 3 ms scan time but the 1756 DHRIO RPI is set at 10 ms plus I still have the 3 ms x 7 adapters time = 21 ms so the inputs will be updated at 10 ms + 21 ms = 31 ms rate plus the time it takes for the actual output to react to a certain input. This makes the system response time slower.
I will remove the first remote rack (the one where the PLC5 normally sits) from the "CH A" remote I/O configuration and put that physical rack ( 2 logical racks)on to "CH B" and wire it to CH B (only 50 cm away). The rest will stay the same but on 230 k.
This will make the input which is wired to a card in this "first rack" to come back at 3 ms * 2 (two logical adapters) + 2 ms ( 1756 DHRIO adapter RPI set to min) = 8ms later. Not sure whether the 1756 DHRIO can "serve" me that quick (2ms) but it will be surely close enough to that. This will make the response time at least as quick as the old system if not quicker.
Will have some results tomorrow at this time.
Thank you for the observation I wrote this just in case somebody in the future will come across something similar , will have as much detail as possible.
Cheers