Help me: Understand Tag groups and data arrival

I am trying to better understand tag groups and tag scan rates in order to ensure that the data is available and current when my Gateway Tag change event triggers.

I have tested and verified the scripts themselves so this appears to be 'late data arrival' issue. Scripts run asynchronous and their time to complete isn't a factor. The scripts check if the data is already used and will exit gracefully. There is no retry mechanism so the operator has to manually release the pallet with no label.

This isn't a fast operation as a couple seconds delay isn't a huge issue. What is an issue, if the trigger arrives before the data arrives.

Operation
Pallet of goods arrives (ID Present = 1)
PLC moves data for Ignition to read, overwriting "old" data
(delays as indicated in timing diagram)
PLC sets trigger bit for Ignition
Ignition tag change gateway script evaluates that trigger =1
Ignition uses the data to create a label which is sent to printer
Printer prints and applies label to pallet
Printer verifies label
upon verification from printer, PLC releases pallet
n+5 seconds later, next pallet can arrive

PLC
In the PLC there are delay timers for moving the data and letting it 'settle' before informing Ignition (Trigger).
Originally there was a 500ms delay before the trigger was set it is now 1000ms

The idea is that Ignition is constantly (200ms) updating the data tag and it should always be current once the trigger bit is true.

Ignition

'ID Present' 200ms direct tag
'Data' 200ms direct tag
'Trigger' 5000ms Driven ('ID Present'=1) to 200ms
Gateway event Tag Change script 'Trigger'

I believe that could give a "worst case scenario" of:

ID present is read by Ignition = 1
The trigger tag read is driven from 5000ms to 200ms
Even if the data isn't read until two cycles (yellow) later I should have 100ms (green) before the trigger is set...

I saw a single occurrence yesterday where the tag change script was triggered, but the data was still the old data as viewed on the HMI and indicated by the tag time stamps. The script evaluated that the data was old and exited. I don't have the time stamps so I've omitted the time scale as all I know is that data in Ignition wasn't valid at the time of the trigger.

This leads me to believe that there can be variability in the scan and tag updates of tags in the same group.

After seeing an occurrence where the Trigger=1 and the Data wasn't current I've now increased the trigger delay in the PLC to 1000ms after the data is moved which should ensure that data is always read and "valid" before the trigger is read as true.

I grabbed these screenshots to show high water mark. Typically the overload is 0-5% when it occurs but is very brief, not sustained.

I believe this should solve the issue but I'd like an expert opinion.

Data arrival for tags is entirely unordered. Repeat: unordered. If you need to ensure that you have fresh data after a trigger tag causes a script to run, you cannot rely on other tags to be up to date. The only reliable method is to use a direct OPC read (via system.opc.readValues()) to make a read of the PLC that is unambiguously after the trigger.

The SQL Bridge module's transaction groups can do this for you by using OPC Items instead of tag Items and setting the OPC mode to "Read" instead of "Subscribe".

In either case, you also have to ensure that the trigger is the last tag updated in the PLC. If so, you need no other delays or settling times.

5 Likes

Thank you. I was hoping there was a way to directly read the tag and make things deterministic. I will do just that.

I really need to get some formal training on this software, the online training doesn't get into all the fun stuff.

1 Like