Compactlogix produce/Consume tag fail state

[davidvu]

My PLC has a Boolean consume tag that gets data from another PLC via ethernet. Is there a way to make the consume tag fail to 0 when the ethernet link between the PLCs is broken?

Thanks.

 

[jstolaruk]

When properly configured, Produced / Consumed tags should have as the first element, a member named ConnStatus of data type CONNECTION_STATUS. This pre-defined UDT has the boolean members "RunMode" and "ConnectionFaulted". When ConnStatus is the first element, the communication drivers will populate these members so that you can get the status of the connection. And with that data, you can determine the legitimacy of the remaining data being transferred.

 

[ASF]

Expanding on the info from jstolaruk: my standard practice when doing produced/consumed is something like this:

|
|    ConsumedTag.Status.RunMode     ConsumedTag.Status.ConnectionFaulted      Comms_Valid
|----------------| |--------------------------------|/|---------------------------( )------|
|
|    Comms_Valid     ConsumedTag.SomeBit                                    CommsIn_SomeBit
|--------| |----------------| |---------------------------------------------------( )------|
|
|    Comms_Valid   ConsumedTag.AnotherBit                                 CommsIn_AnotherBit
|--------| |----------------| |---------------------------------------------------( )------|
|
|    Comms_Valid    ConsumedTag.HobBit                                     CommsIn_HobBit
|--------| |----------------| |---------------------------------------------------( )------|

This gives you the "fail to zero on comms loss" functionality you describe, and also gives you "fail to zero if the producing controller is not in run mode" functionality.

Of course, it's important to ensure that all of your comms bits are the logical equivalent of "failsafe" - that is, zero is the safest state to assume the signal to be if you can't trust the data source because it's offline or not running.

One final caveat: the CONNECTION_STATUS data type (and therefore this approach) was not always an option - from memory it was added somewhere around v19 firmware (but I stand to be corrected on that). If you have an old firmware processor at either end, you'll either have to flash up to a more recent version, or use a heartbeat approach to detect comms failure instead.

 

[davidvu]

Expanding on the info from jstolaruk: my standard practice when doing produced/consumed is something like this:

|
|    ConsumedTag.Status.RunMode     ConsumedTag.Status.ConnectionFaulted      Comms_Valid
|----------------| |--------------------------------|/|---------------------------( )------|
|
|    Comms_Valid     ConsumedTag.SomeBit                                    CommsIn_SomeBit
|--------| |----------------| |---------------------------------------------------( )------|
|
|    Comms_Valid   ConsumedTag.AnotherBit                                 CommsIn_AnotherBit
|--------| |----------------| |---------------------------------------------------( )------|
|
|    Comms_Valid    ConsumedTag.HobBit                                     CommsIn_HobBit
|--------| |----------------| |---------------------------------------------------( )------|

This gives you the "fail to zero on comms loss" functionality you describe, and also gives you "fail to zero if the producing controller is not in run mode" functionality.

Of course, it's important to ensure that all of your comms bits are the logical equivalent of "failsafe" - that is, zero is the safest state to assume the signal to be if you can't trust the data source because it's offline or not running.

One final caveat: the CONNECTION_STATUS data type (and therefore this approach) was not always an option - from memory it was added somewhere around v19 firmware (but I stand to be corrected on that). If you have an old firmware processor at either end, you'll either have to flash up to a more recent version, or use a heartbeat approach to detect comms failure instead.

Thanks for the help. Do you know which part of the PLC scan cycle updates the consumed tag?

 

[jstolaruk]

The RPI of the consumed tag sets the update time.

Manual on Produced Consumed Tags

 

[ASF]

jstolaruk is correct again - produced/consumed data is like any other I/O, be that a digital input card or a VSD on ethernet/IP. The update rate is set by the RPI settings, and happens asynchronously. That means that it could be updated at any point, even when your PLC is halfway along a rung.

Theoretically, it's possible for this rung to execute true and turn on the OTE:

|
|     ConsumedTag.BOOL1    ConsumedTag.BOOL1                 Output
|------------| |------------------|/|-------------------------( )---|

All that has to happen is for the consumed tag to be updated in between execution of the first XIC and the second XIO, and for the value of ConsumedTag.BOOL1 to be true prior to the update and false after the update.

It's extremely unlikely, of course, but it's possible. So you should account for this in your programming. That's another reason that I always map my produced/consumed tags in the manner above, just like I do with physical I/O. Practically, there's no difference between a digital input module and a consumed tag being read from another PLC.

 

[davidvu]

jstolaruk is correct again - produced/consumed data is like any other I/O, be that a digital input card or a VSD on ethernet/IP. The update rate is set by the RPI settings, and happens asynchronously. That means that it could be updated at any point, even when your PLC is halfway along a rung.

Theoretically, it's possible for this rung to execute true and turn on the OTE:

|
|     ConsumedTag.BOOL1    ConsumedTag.BOOL1                 Output
|------------| |------------------|/|-------------------------( )---|

All that has to happen is for the consumed tag to be updated in between execution of the first XIC and the second XIO, and for the value of ConsumedTag.BOOL1 to be true prior to the update and false after the update.

It's extremely unlikely, of course, but it's possible. So you should account for this in your programming. That's another reason that I always map my produced/consumed tags in the manner above, just like I do with physical I/O. Practically, there's no difference between a digital input module and a consumed tag being read from another PLC.

I noticed the behavior that you mentioned. I was hoping producer/consumer is synchronous so that I can write simpler logic to reset consumed tags to 0 when comm is not valid.

I tested the logic below and I noticed INT_Consumed flicker between 0 and 1. Producer/consumer tries to maintain the last valid value when comm is not valid.

CommValid
--|/|--------------MOV(0,INT_Consumed)

I had to do this instead

Commvalid
--||----------MOV(INT_Consumed, INT1)

Commvalid
--|/|----------MOV(0, INT1)