[Logix] Watching ladder logic execute vs scan time

[defcon.klaxon]

Hey guys,

I'm testing radio comms between my ControlLogix and CompactLogix PLCs (Xetawave 4x4e radios via Ethernet/IP). I'm using MSG instructions to read and write data to each site, and one of the things I've done is that if I lose connectivity with a site (by checking connection status with GSV instruction), I skip its MSG commands to keep my polling cycle from grinding to a halt and waiting for the MSG to return an ER bit.

It seems to be working quite nicely, but sometimes it seems like the logic "sticks" or "skips" as I watch it in run mode. At first I thought something might be wrong, but then I noticed my scan times are insanely fast; I'm looking at at typical scan time of ~120us, max scan time of 175us. Could it be that the PLC is scanning so fast that the logic I'm watching can't display it quickly enough? Each remote site has a MSG Group bit in a DINT array that enables its polling step, and when I watch the bits flip I'm noticing they skip around and aren't in perfect order, which makes me think I'm getting logic updates far slower than the logic is actually running. Does this sound right to you guys? Is there a way I can step through the logic manually to make sure it's executing without hanging up?

 

[kamenges]

You are correct. Data is not transferred from the plc and displayed your PC anywhere near as fast as it is executing. So you are seeing little snapshots of status information that are not necessarily in any kind of order.

I've never actually needed to use any tools to slow down or pause execution so I'm not sure what is available.

Keith

 

[defcon.klaxon]

You are correct. Data is not transferred from the plc and displayed your PC anywhere near as fast as it is executing. So you are seeing little snapshots of status information that are not necessarily in any kind of order.

Ok great, thanks for the sanity check.

I've never actually needed to use any tools to slow down or pause execution so I'm not sure what is available.

I'll do some Google searching and see what I can come up with; it might prove useful in the future.

 

[Ken Roach]

... if I lose connectivity with a site (by checking connection status with GSV instruction)

I mentioned this previously but it bears repeating: if you have the CompactLogix in the I/O tree of the ControlLogix project, a small cyclic I/O connection is created. That's what you are checking with your GSV instruction.

This should have minimal impact on your data throughput, but it's worth understanding. My recollection is that the default connection is set up for a 1000 ms RPI, so the timeout period is 4xRPI = 4 seconds.

I skip its MSG commands to keep my polling cycle from grinding to a halt and waiting for the MSG to return an ER bit.

This is one of the method I've used in the past; I execute the GSV *before* executing the MSG instruction, so I don't trigger an MSG that's headed to a device that has been disconnected.

Two additional things you can do with the MSG instruction that may be important:

1. You can modify the MSG timeout from the default of 30 seconds. It's in the MESSAGE type tag, rather than being an option you can get to in the configuration box.

2. You can manually force a MSG to time-out by setting the .TO bit true. I've done that in the past instead of modifying the MESSAGE tag, so that if the /EN stays true for more than a second without the /DN or /ER bits becoming true, I set the /TO bit. The MSG instruction responds by setting the /ER bit just as though it had been an organic Timeout.

 

[defcon.klaxon]

I mentioned this previously but it bears repeating: if you have the CompactLogix in the I/O tree of the ControlLogix project, a small cyclic I/O connection is created. That's what you are checking with your GSV instruction.

This should have minimal impact on your data throughput, but it's worth understanding. My recollection is that the default connection is set up for a 1000 ms RPI, so the timeout period is 4xRPI = 4 seconds.



This is one of the method I've used in the past; I execute the GSV *before* executing the MSG instruction, so I don't trigger an MSG that's headed to a device that has been disconnected.

Two additional things you can do with the MSG instruction that may be important:

1. You can modify the MSG timeout from the default of 30 seconds. It's in the MESSAGE type tag, rather than being an option you can get to in the configuration box.

2. You can manually force a MSG to time-out by setting the .TO bit true. I've done that in the past instead of modifying the MESSAGE tag, so that if the /EN stays true for more than a second without the /DN or /ER bits becoming true, I set the /TO bit. The MSG instruction responds by setting the /ER bit just as though it had been an organic Timeout.

All fantastic information, thanks Ken. I do understand the CompactLogix/ControlLogix polling that's happening in the background, but I didn't know about forcing a MSG timeout, that's very helpful stuff!