I have several Transaction Groups set up to log filter test results to a single database table. Each transaction group executes on a trigger (change in value of a float tag). Since only one filter can be tested at any time, there is no possibility of more than one transaction group executing at the same exact time. The trigger tag (included in Basic OPC/Group Items) is normally set to 0 in the PLC and once a filter test concludes, the PLC updates it to a value between 101 and 109 depending on the filter number. At the same time other group tags are also updated with test result data and the Transaction Group executes. Some time after, the PLC resets the “trigger” tag value back to 0.
The transaction groups are working flawlessly 99% of time but occasionally log 0s instead of actual values and I have no idea why. This is an issue since the collected data is used for monthly reporting purposes. Below screenshot shows an example of an entry that incorrectly logged all zeros (see entry with timestamp of 2022-07-02 14:18:31).
Here is another, more bizarre example. Most values were logged correctly except for two which were incorrectly logged as 0s (see “stop psi” and “lrv” entries with timestamp 2022-07-23 9:59:34).
I checked the Transaction Group events and status tabs and everything looks good. I also checked the Gateway events logs and no issues there.
Here’s my transaction group setup:
Action: Timer (1 second)
“Only evaluate when values have changed” is checked and the before mentioned float tag selected
“Execute this group on a trigger” is checked and before mentioned float tag selected as “Trigger on Item”
“Only execute once while trigger is active” is checked
Trigger condition: is active = 10x (x=1 thru 9 depending on filter number); non-active != 10x
Looks like a common race condition. You are logging from tags. Tags are subscribed, with varying delivery timing. Transaction groups are executed on an interval. Group executes just after trigger tag is updated by its subscription, but other tags have not yet updated. Group executes with its snapshot and you get garbage.
Triggered transaction groups must have items that are sure to be up-to-date when the trigger happens.
Since this can be difficult to ensure, there is a mode (under options) where the OPC mode is “Read” instead of “Subscribed”. In this mode, OPC items other than the trigger are not subscribed at all. Instead, the group waits until the trigger happens, and then reads the rest of the items.
For this to work, the items cannot be tags. They must be direct OPC items (dragged from the OPC browser, not the tag browser). In fact, you do not need tags for them at all.
That makes sense. Thank you! I do have one question. I have 2 Expression Items that are based on Group Tags. One takes the trigger tag value (101, 102, etc.) and converts it into an actual filter number (3001, 3002) and the other converts a message tag value (1, 2, etc.) into a string message (Test Passed, Test Failed, etc.). Would you recommend setting these up as Triggered or Run-Always Expression Items?
Thanks for the sharing your knowledge. I am experiencing the exact same issue. I did what you suggested and it look like it worked for a few days and then it happened again. It seems the 0s are entered in a record right after the customer runs a new part. It's random, it never happens on its own, but randomly after a new part is run.
Don't log from tags. Use a tag as a trigger, but the other items should be OPC items that bypass tags, and the group should use OPC Read mode. In your PLC, ensure that the record data is fully populated before the trigger tag is set.
Got it. Do you know if within Ignition there is a option to "wait for x seconds" after the tag trigger goes HIGH, to make sure all of my tags are fully populated?
No. As @lrose points out, picking "x" for normal conditions will break under abnormal conditions. The only safe approach is to order the operations in the source so the trigger is set last, and explicitly read everything in Ignition after the trigger.
