Bad data using CIP over Ethernet

C

Thread Starter

Cervoman

I am using a Rockwell ControlLogix PLC in an industrial control application. In this application two PLC's exchange data contained in TAGs using explicit message instructions. The problem is the data transfers appear to be non-atomic. I have a TAG named TEST. It is a UDT.

INT Sequence number
INT[100] filled with pattern

PLC 1 fills the tag with data and puts a sequence number in the first member. It uses an explicit message instruction to send the data to PLC 2. The sequence number starts at 1 and increases by 1 each time the data is written.

Ladder logic in PLC 2 checks the sequence number in the tag. When it changes. PLC 2 uses a CPS instruction to copy the data to local non-global tag.

The problem is that it appears that when PLC 1 writes the data, the sequence number changes and PLC 2 copies the data before all the bytes have been transferred. In 5000-10000 transfers 10-15 will have partially updated data.

What gives? Isn't the CIP transfer of a tag supposed to be atomic? How can I reliably know all the new data has been transferred before I process it?

ccervp [at] casepick.com
 
G

Gilles Allard

ccervp wrote:
> What gives? Isn't the CIP transfer of a tag supposed to be atomic? How can I reliably know all the new data has been transferred before I process it? <

The size of a CIP packet is limited to 510 bytes, including overhead. So you can't transport more than 81 DINT in a single packet. I never heard about buffering in Ethernet/IP so I assume you won't get any atomicity for large arrays.

I can propose two solutions:
1) reduce the size of your array to less than 80 or less.

2) move your sequence number at the end of your UDT. This will ensure that the whole UDT is received when you process it.

But there is another complexity if you use the second solution (or any solution that would use more than 1 packet). If your PLC1 send 2 messages in rapid succession, there is a non-null probability that the first packet of the second transaction overwrite the last packet of the first transaction. The data communication is asynchronous to the program processing so you can't protect yourself easily against this problem, even with a CPS.

One solution would be to implement a handshaking between the PLCs. PLC1 may transmit a RTS (Request-to-send) signal and PLC2 would reply with a CTS (Clear-to-send) after it has processed the previous transaction.

If this seems too complex, you may implement this lazy solution: reduce the probability of overwriting by using a minimum time between two transactions.

Good luck.
 
Top