I am using a standard transaction group type transaction.
My transaction is based on a trigger tag, Every time i turn on the trigger, i expect the data to be sent to db and update my handshake flag and once i see a successful DBStore from the transaction, I verify and turn off the handshake bit from the PLC while trigger bit is turned off in the Ignition itself.
Now my issue is unless i provide at least 500 to 600 milli second transaction between consecutive transactions, I am not able to succeed in my smooth operation.
Providing 500 to 600 milli second delay between consecutive transaction hinders the performance of my machine process cycle time.
I would like to know if there is some option to reduce the delay to at least less than 200 milli seconds, If standard transaction group is not the right way to go forward, I would like to know if any of you can suggest an alternate mode of sending this data without a huge delay.
I’ve attached the screenshots of the Standard group I’ve mentioned above and trigger and options settings.
Use OPC Read mode instead of Subscribe. Don’t bypass the store and forward system (most DBs have significant latency, even if their throughput meets your needs).
If you can’t tolerate the risk of data loss inherent in the S&F system, you may need to add a 1-cycle FIFO to your PLC logic. Then your interlock would be to stop your machine if the previous data hasn’t been processed when the next block of data needs to be written to the FIFO.
Thanks for the reply. Regarding Bypass Store and Forward, I had to enable that to make sure my handshake bit reports the status of DB Store success/fail. Now disabling that again will remove the capability to get the DB Store success/Fail status to handshake bit.
Another technique to reduce the cumulative latencies is to use an integer as a trigger (on change) instead of a boolean. I generally use gateway tag change event scripts for such triggers instead of a transaction group, since the best handshake for such is to echo the integer to a different PLC tag when the DB insert completes successfully. A transaction group can’t do that. No resetting means no possible race conditions and no extra reads/writes. Such scripts need to use system.opc.read*() instead of system.tag.read*() to ensure the rest of the data isn’t stale.
Thanks for the additional suggestion. Will note this down.
And when you mean gateway tag change event script, Should i be using tag change event of the trigger(integer) to write the script inside the same transaction group I am using now?
Gotcha. That would be something I need to look at. I would need to look at some examples using fully scripted replacement for transaction groups and present to my group for making our futur projects fool proof.
