I have a transaction group with handshaking that is intended to take a queued up data from my AB PLC, however it is not working as expected, the handshake/trigger reset gets hung up on the Ignition side.
On the attached image, you can see the tag ‘Handshake‘ is added to the transaction group as a tag reference, then the tag is used as the trigger item for the group.
The PLC/Ignition logic is as follows:
(PLC) Have an array of datasets filled up
(PLC) When ‘Handshake’ is 0, copy index 0 to IgnOffload (data includes a ‘Handshake’ value of 11)
(PLC) Copy the array down (index 1-9 to index 0-8)
Ignition writes a 12 to ‘Handshake’ on successful transaction to DB
(PLC) when ‘Handshake‘ is 12 IgnOffload is cleared and ‘Handshake‘ is reset to 0
Process restarts until array is empty.
I am seeing that ‘Handshake‘ get’s stuck on value 11, even though the PLC receives a 12, resets to 0, then pushes a new 11. So the rising/falling edge logic is functional, but only to the PLC.
It seems as if Ignition does not have visibility on the tag after Ignition pushes a 12, it is delayed to know the value after the tag is changed in the PLC.
This process DOES work when I add a 250ms delay on my write to IgnOffload once the PLC receives the 12, but this does not cover us in all situations. It should work without delays/timers.
Additional context: Handshake tag is set to Driven mode, 10 ms Rate, Subscribed, and on the transaction group the write target mode is set to Use group’s mode (I’ve tried each option).
You have “Only execute once while trigger is active” checked and the transaction group is not seeing the transition.
On the action tab is your execution scheduling set to the default of Timer and 1 second? If yes, my basic understanding is that the transaction group will execute once per second and read the trigger value no matter what the subscription rate is for the trigger tag that is being referenced.
You will probably have to lower the timer for the transaction group to get this to work, but it will still be relying on your handshake tag being not equal to 11 long enough for the transaction group to recognize it.
Side note. It looks like you may have “Only evaluate when values have changed” enabled. I haven’t used that feature, but I seem to remember a forum post where someone was having an issue when having that enabled and “Execute this group on a trigger” enabled at the same time.
Apologies, I should have added this to my context, but the Execution Scheduling mode is set to Timer and I have it set at 10ms and the Update Mode is ‘OPC to DB‘.
I tried your suggestion by trying with and without “Only evaluate when values have changed”, but no luck.
This should at least give you better visibility to what value the transaction group is seeing each execution. Because you are writing back to the same tag you are triggering on, the easy answer would be to disable “Only execute once while trigger is active”. I would be hesitant to actually do that because I would be worried about getting duplicate records though.
This is almost certainly a task for system.opc.readValues() with a gateway tag change event script on your trigger.
Also, you need another tag for your handshake for acknowledgement from Ignition. For fastest round trip, use an non-resetting integer as your trigger, and a second integer as your acknowledgement.
In the PLC, when trigger ≠ ack, do not write to the arrays--wait for Ignition.
In Ignition, in your event script that monitors the trigger, perform a single system.opc.readValues() to retrieve all desired data in one request (the driver may make more than one, but let it optimize). Write to the database. Write the new trigger value to the acknowledgement tag.
Thank you for the insight, I have adopted a similar thought process with the handshake/acknowledgement but all through the PLC. Basically, give Ignition 500ms to write a confirmation handshake, if not, fault the PLC and clear the queue. What I have here works reliably and I have not seen any issues. I’ve also significantly reduced my timer speed to optimize performance.
