Subscribed tags in Standard Transaction Group recorded values of 0


I have a transaction group that is executing off a trigger. Some of the tags have values that change in the PLC. Some have values that are fixed. The tags with changing values resulted in recording 0s, but based on the PLC logic that should not be possible. The tags with values that do not change have their correct values recorded.

The tags are all in the same transaction group (trigger included), are set to Subscribed, with a poll rate of 250ms.

The transaction group also has an OPC data mode of Subscribe, with an execution schedule of 500ms. The settings for the transaction group are in the attached screenshot.

There are nothing in the Ignition gateway logs that indicated there was any issue.

PLC is a Rockwell CompactLogix. Ignition Version is

The MariaDB database has default values set to NULL for these columns.

Basically, I need to determine what the root cause of these 0 values was, as we do not see how this could have come from the equipment.

Is it better to use Read vs Subscribe in this situation?

If the dynamic values are typically zero before the trigger, and are updated in the PLC to correct values at the same time as the trigger, then this behavior is expected. That is, subscriptions have no defined order of operation. Meaning if the trigger is seen as the first subscribed value to change, the others may still be zero when the transaction group runs.

Changing the mode to “Read” instead of “Subscribe” will definitely help this situation. (The trigger will still be subscribed, but the rest of the items will be read after the trigger.) To be certain you aren’t still racing, you need to make sure the PLC logic updates the trigger last. Or, perhaps, use the CPS instruction in the PLC to update an entire structure, including the trigger, uninterruptibly.

1 Like

Thanks for the reply.

We do shift our shift register via CPS commands, and wait until a rotary table is in position for the data log trigger to activate. There is essentially a guaranteed 250ms+ (no correlation with the original 250ms scan time) between the shift of the shift register and the log trigger activating.

We are really banging our heads against the wall with this one. Which is why I am wondering if there could be some improvements to my configuration, specifically “Read” vs “Subscribe”.

The only way those 3 tags would be set to 0 is when the table is empty with no components, but at that point we would have no reason to activate the trigger in the PLC.

Are you suggesting changing the tags themselves to Read, or the Transaction group’s OPC data mode?

This. And make sure the items in the transaction group are actually OPC items themselves, not Ignition tags (those run on their own subscription).

1 Like