# Tag Provider Order of Operations **URL:** \ **Category:** Ignition\ **Tags:** ignition81\ **Created:** [January 22, 2025, 2:56pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232 "2025-01-22T14:56:37Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [January 22, 2025, 2:56pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/1 "2025-01-22T14:56:37Z")
We have had a very specific occasional issue with a "double handshake" with a PLC, and I am trying to understand the underlying architecture of the way the tag provider works. Here is the way the "double handshake" was configured: 1. PLC turns on **DataRequest** tag, and this tag is the trigger for a Gateway Tag Change Script. 2. Ignition completes a query, returns data to the PLC and turns _on_ a **DataAvailable** tag using **system.tag.writeBlocking**. 3. The PLC turns on a **DataReceived\_Ack** tag, and this tag is the trigger for a second Gateway Tag Change Script. 4. Ignition turns _off_ **DataAvailable** using **system.tag.writeBlocking**. 5. The PLC turns off **DataRequest** and **DataReceived\_Ack**. Every once in a while, the **DataAvailable** tag will get stuck on along with the **DataReceived\_Ack** tag. Tag history makes it clear that the **DataReceived\_Ack** tag was turned on at the same time as **DataAvailable** , and we have every reason to believe that the second Gateway Tag Change Script from #3 above executed correctly. Does anyone have any insight into what could cause this scenario? By the way, we had our controls team remove the second half of the "double handshake" so we are no longer seeing this issue. I'm just trying to understand how the Tag Provider processes requests so we don't run into a similar situation with something else. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [January 22, 2025, 4:02pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/2 "2025-01-22T16:02:13Z")
My guess is the transaction is happening so fast that the DataAvailable being turned on/off that quickly in succession that OPC hasn't verified the write or there's a race condition with it being written to immediately after it wrote it to a 1. What might be better is to let the PLC turn on **DataRequest** , then Ignition turns on **DataAvailable** after it retrieves the data, then once the PLC processes the data as an acknowledgement, it just simply turns off both **DataRequest** ~~and **DataAvailable**~~. Does Ignition need to have any other form of acknowlegement from the PLC tha the data was received? Edit: See below comments by @pturmel as he's correct in that the **DataAvailable** should only be written to (and should really only ever echo the state of **DataRequest** ). ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 22, 2025, 4:05pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/3 "2025-01-22T16:05:56Z")
> [@rbachman](#): > > remove the second half Yeah, that's what I would recommend. Turning off `DataRequest` is sufficient acknowledgement. And Ignition then turning off `DataAvailable` lets the PLC know that another request is possible. That is, `DataAvailable` should simply **echo** `DataRequest`, after any requested data is actually available. Everything off is everything idle. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [January 22, 2025, 6:05pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/4 "2025-01-22T18:05:58Z")
> [@michael.flagler](#): > > What might be better is to let the PLC turn on **DataRequest** , then Ignition turns on **DataAvailable** after it retrieves the data, then once the PLC processes the data as an acknowledgement, it just simply turns off both **DataRequest** and **DataAvailable**. This is what we have defined as our standard for handshakes between Ignition and the PLCs. This particular "double handshake" was left over from an old configuration. Ignition does not need any additional confirmation from the PLC. > [@michael.flagler](#): > > My guess is the transaction is happening so fast that the DataAvailable being turned on/off that quickly in succession that OPC hasn't verified the write or there's a race condition with it being written to immediately after it wrote it to a 1. I think you're probably correct with this assessment. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 22, 2025, 6:32pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/5 "2025-01-22T18:32:58Z")
> [@michael.flagler](#): > > PLC processes the data as an acknowledgement, it just simply turns off both **DataRequest** and **DataAvailable**. This is wrong. Do **not** write to `DataAvailable` from the PLC. That is a dangerous race. Only write a given tag from one direction. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [January 22, 2025, 10:15pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/6 "2025-01-22T22:15:23Z")
> [@pturmel](#): > > This is wrong. Do **not** write to `DataAvailable` from the PLC. That is a dangerous race. Only write a given tag from one direction. I'm not quite sure what @michael.flagler meant, but I took his comment to mean that the PLC will turn off both **DataRequest** and **DataAvailable** _only after_ Ignition turns on **DataAvailable**. Unless I'm missing something, there shouldn't be a race condition since the PLC won't start writing to the **DataAvailable** tag until after it has been turned on by Ignition. **Added Note:** To clarify, _only_ Ignition turns that tag **ON** in our environment, and _only_ the PLC turns it **OFF**. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 22, 2025, 11:17pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/7 "2025-01-22T23:17:36Z")
> [@rbachman](#): > > To clarify, _only_ Ignition turns that tag **ON** in our environment, and _only_ the PLC turns it **OFF**. Let me clarify: Don't do it. Have Ignition turn off `DataAvailable` when `DataRequest` turns off. That is the only way to be sure the PLC knows that Ignition is ready for another request. Really: don't write to tags from two directions in handshakes. If you want a faster handshake, use an incrementing integer that doesn't need to be reset (skip zero) and echo that as the "data available" signal. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [January 23, 2025, 1:21am UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/8 "2025-01-23T01:21:30Z")
I edited my post above so anyone coming here and not reading the full thread doesn't make that mistake. Yeah, it makes more sense to have Ignition only echo to **DataAvailable** once the data is available, but then when it reads the **DataRequest** as 0 and echos the 0 back to the PLC, the PLC knows Ignition has seen the **DataRequest** clear out and that it's safe to send another request. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [January 24, 2025, 10:10pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/9 "2025-01-24T22:10:57Z")
> [@pturmel](#): > > Have Ignition turn off `DataAvailable` when `DataRequest` turns off. Can you provide some clarification on the risks? Our standard handshake has been the following, and we have been using it across multiple locations for many years without any known issues. 1. PLC Turns on `DataRequest` 2. Ignition runs query, populates various tags, and turns on `DataAvailable` 3. PLC turns off `DataRequest` and `DataAvailable` I suspect this is what you are recommending for the handshake: 1. PLC Turns on `DataRequest` 2. Ignition runs query, populates various tags, and turns on `DataAvailable` 3. PLC turns off `DataRequest` 4. Ignition turns off `DataAvailable` Are you concerned about a timing issue (i.e. `DataRequest` turns off and on between polls from Ignition) or is there some other technical issue when both the PLC and Ignition could be writing to a single tag? If it's a timing issue, our takt time is around 10-12 seconds, so we've never had an issue with the timing unless there was some other major problem (e.g. network outage). **Edit:** I should add that I definitely can see the benefits of the second handshake above if the handshake needs to happen rapidly between Ignition and the PLC. If both sets of logic understand this, it would likely be much faster and more reliable. Our time between triggers is just so slow (i.e. 10+ seconds) that we haven't had issues with the first handshake above. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 24, 2025, 10:14pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/10 "2025-01-24T22:14:37Z")
> [@rbachman](#): > > Are you concerned about a timing issue Yes. If there is a hiccup in Ignition's polling, the PLC has no way to know if Ignition has seen `DataRequest` turn off, and could turn it back on before Ignition sees it. That could theoretically happen anyways, depending on your poll rate versus your process rate. Any processing delay on either end could put the `DataRequest` off -\> on transition ahead of Ignition's poll that would see "off". Making Ignition write `DataAvailable` off, and making the PLC wait for it to be off, guarantees there's no race. ---
**Author:** ![rbachman](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/rbachman/32/43718_2.png) [@rbachman](https://forum.inductiveautomation.com/u/rbachman)\ **Post date:** [January 24, 2025, 10:15pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/11 "2025-01-24T22:15:04Z")
Got it. That makes sense. Thanks! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 24, 2025, 10:16pm UTC](https://forum.inductiveautomation.com/t/tag-provider-order-of-operations/101232/12 "2025-01-24T22:16:47Z")
Fundamentally, you cannot make your handshake reliable in less than ~~four~~ **two** poll cycles. That is why, for fast cycles, I recommend the integer handshake. It only needs ~~two~~ **one** cycle. Two versus one instead of four versus two: the PLC isn't polling. Writes are _pushed_ into the PLC.