I have 4 transaction groups set up on my project. All of which are Triggered by separate Trigger tags from the PLC and will write Confirm to separate Confirm tags in the PLC. Every once in a while with seemingly no pattern at all my transaction groups won’t execute. I have validated that Ignition is receiving the trigger from the PLC but the transaction group doesn’t write to the database and doesn’t send the confirm back to the PLC.
I don’t see any errors in the gateway log so maybe I’m looking in the wrong place for diagnostics? Is there something known that I could be doing wrong to cause this behavior?
Thanks,
Matt
With out knowing anything of how you have it set up. I’d look at timing. What is your scan rates for the tags that trigger the transaction groups. How is the execution set up on your transaction group? How does the tag that causes the trigger work, is it a momentary change in state or …? If it is a momentary change in state and your scan class for the tag can cycle in on and off between your scheduled timer of your transaction group, the transaction group may not even see that the trigger was sent. To know for sure we would need to see more of how you have the tag and transaction group set up though.
So the execution scheduling timer weighs in on the execution of the transaction group, regardless of the fact that I have it executing based on a trigger?
For more information:
The scan rate is the default [1 second]
The transaction group execution scheduling is set to timer 1 second
Transaction group execution is
The tag that triggers the execution is held on until it receives the confirm
The trigger is set as run always
Yes, the timer definitely weights in on it executing. The timer sets the frequency it even looks for a trigger. This if from the manual showing the execution cycle of a transaction group.
Personally I always have my scan rate for the transaction group set a little less than the scan rate of the trigger tag to ensure it will see the trigger. I also use the only execute once while trigger is active, same as you did, to ensure if it is still triggering on the next scan that it doesn’t do a second entry.
If the trigger it held on until it receive the confirm I’d have to wonder if the confirm didn’t cause the reset as you would expect. Any chance your monitoring both of these points in the historian to ensure they are triggering and resetting as you expect them to?
Also if it is held on until the confirm is sent on success what do you do if this isn’t received? Do you reset the trigger, and trigger it again? Where you said it is held on if you don’t have an action for when you don’t get a response then you could end up with your trigger stuck on if there was a problem with the transaction group. Personally I’d either add a failed handshake or set up a timer after triggered to wait for the confirmed, if you don’t get it then reset and re-trigger your event or cause some other action so you either know it failed or you cause it to retry. At a minimum you should have it reset after a period of time.
1 Like
I reduced the transaction group scan rates and so far it seems more responsive but I will do some more testing.
My PLC logic would turn the trigger off after a timer elapses if there was no confirm. I had the timer set at 20 seconds and it was timing out regularly. Then I tried some retry logic where if it didn’t receive a confirm after a timer elapsed it would turn the trigger off and back on. It would do this 5 times before alerting the operator. This also didn’t solve my problem.
Is it possible there could be some strange behavior having Tag scan time and transaction group scan time the same?
When you have them the same it all depends on when they fire to what you will see. Both have steps they go through when they fire before getting to what the transaction group needs so there is a chance it wasn’t even seeing the triggers at times. If it didn’t see them then it wouldn’t log the data so your reset would happen.
Even though you were waiting on a reset, I’m not positive on how the the execute once on trigger function works. If it looks at when the value changed last to decide if it should of seen it on the last scan, it may assume that it already was triggered and skip it. I would hope it wouldn’t do that but I don’t know how they handle that function. It good practice in any case to make sure your scanning often enough to make sure you catch every change though.
The other question is how long did you have it off before retrying? You would also need a timer used in the reset to make sure it is off long enough to be seen as off by your scan class. If it just cycles off and then back on in the PLC that can happen at a fast enough rate to where Ignition may not even know it ever happened.
If the time it logs at isn’t critical, you could also try to increase your transaction group scan time and turn off the only execute once while trigger is active. Then when your tag comes on, on the next scan of the transaction group it should see your trigger is on, after it does the write it should write the handshake, turning off the group before your next scan. If it doesn’t turn it off then it should attempt to log the data again on the next scan. Essentially moving your retry into the transaction group.
Maybe it was the execute once on trigger timing with my tag refresh? I can’t recreate the issue so far so hopefully changing the execution scheduling did the trick. Before if I triggered it 4-5 times manually it wouldn’t work.
That is a very good thought, I didn’t have another timer to keep the trigger low for long enough for ignition to see the transition. So my retry probably wouldn’t have worked unless the ignition tag scan happened to be at the time the trigger was off which would have been something like 100 ms.
The time it logs has to be within a 5 second window. Changing those settings in my transaction group is a very good idea for something I could try if I still see issues with my current setup. Thanks for all your help!
