defcon.klaxon
Lifetime Supporting Member
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?
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?