I have a seemingly strange thing happening with a Transaction Group setup. I have a “Master Alarm” bit that, when set on by the PLC should store a list of “Alarm Reason” bits (only once), then when set off by the PLC should store the same list of “Alarm Reason” bits (again only once). I have set the trigger for the group up as shown in the image below. Note that the trigger bit is also stored to the database.
What seems to be happening is that several consecutive records show a trigger bit (the “Master Alarm”) as reset (“0”), as shown here (data table sorted by timestamp - see records starting at 06:32:33):
Surely this is an impossibility as the setup should only store a record when the trigger bit actually changes state?
The Transaction Group is the only thing running on the entire Ignition installation at this point. Data is coming via ethernet from a single ControlLogix PLC. The Transaction Group is running at a 1 second execution trigger, and all group items are OPC tags. There are a total of 58 boolean values being read and inserted into the table in this group.
Is there something I am missing in the configuration that could cause this? Perhaps there is a timing issue? When a trigger occurs, is the trigger bit re-read before its status is written to the data table?
Well, it is possible the quality of the tag is changing but the value is not changing. You can try logging the quality as well to see the whole picture.
It certainly could be a timing issue, but looking at the data you’ve posted, it seems that the events happen minutes apart. Is there any chance that the transition to 1 is occurring only briefly before transitioning back to 0?
It’s also possible that the “only execute once when trigger is active” option is causing unnecessary complications. It’s not necessary for the “any change” mode- that mode naturally behaves like that. I would recommend disabling that option, and seeing if it makes a difference.
Colby - Yes, the data does change sometimes very regularly. This is why I have the Transaction Group running at a sample time of 1 second to catch these events. However, the fact that a record is created, I would assume, means the Transaction Group has identified a change-of-state. If that is the case, should that state not be stored in the condition it was identified (i.e. rising-edge stored as 1, falling as 0)? Or is the state of that bit re-read before being written to the database after the trigger has been identified? As you say, it makes sense that the “On Any Change” mode does not need the “Execute Once” flag set, so I will clear that and try it for a while and let you know.
Yes, it’s definitely detecting a change, but I suspect it truly is the change from 1 to 0. I think that for some reason the change from 0 to 1 is not triggering it to log, perhaps due to the “only execute once”. I did a quick mock up and was able to see it occasionally log duplicate trigger values (that is, skipping one trigger state) a few times, though I didn’t see it when “only execute once” was off. So, my thought is that there is some problem with that combination of settings.
As for re-reading the values, I don’t think that’s what’s happening, since your trigger seems to stay high or low for several minutes. In general it doesn’t “re-read”, though if a subscription update just happened to come in between the time that the trigger was checked and the row written (a very small window of time), I suppose the wrong value could get written.
Let me know how it goes with that setting off, and I’ll try to look into it more here.
