# Gateway event tag script **URL:** \ **Category:** Ignition\ **Tags:** scripting, ignition81\ **Created:** [April 22, 2024, 2:03pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212 "2024-04-22T14:03:34Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Miguel\_Cimildoro](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@Miguel\_Cimildoro](https://forum.inductiveautomation.com/u/Miguel_Cimildoro)\ **Post date:** [April 22, 2024, 2:03pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/1 "2024-04-22T14:03:34Z")
Hi everyone I am performing a tag change event on a gateway, where if these 26 tags change, and if the change is equal to bit 14 or 12, then it disables them. The script works, but sometimes the tag change event does not trigger, especially when all tags change simultaneously. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/5/4582434ca9085ec91e49613781a562641db4f25b.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/7/b7aee384531347d82120113fe408f5e8277ee781.png) Is it possible that it fails due to latency between the gateway and the designer? regards. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [April 22, 2024, 2:13pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/2 "2024-04-22T14:13:08Z")
Can you show the code of the `bit_variable_deactivate` function ? ---
**Author:** ![Miguel\_Cimildoro](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@Miguel\_Cimildoro](https://forum.inductiveautomation.com/u/Miguel_Cimildoro)\ **Post date:** [April 22, 2024, 2:15pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/3 "2024-04-22T14:15:32Z")
```python def bit_variable_deactivate(bit_position, original_variable_tag_path): bit_value = 1 << bit_position transformer_value = system.tag.readBlocking([original_variable_tag_path])[0].value transformer_value &= ~bit_value system.tag.writeBlocking([original_variable_tag_path], [transformer_value]) return transformer_value ``` I have implemented this script in many mouseClicked and it works correctly. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [April 22, 2024, 2:22pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/4 "2024-04-22T14:22:57Z")
I kinda feel like there's a better way to do this... What kind of tags is this used on ? Where do they get their values ? ---
**Author:** ![Miguel\_Cimildoro](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@Miguel\_Cimildoro](https://forum.inductiveautomation.com/u/Miguel_Cimildoro)\ **Post date:** [April 22, 2024, 2:40pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/5 "2024-04-22T14:40:33Z")
It is a bit decoded tag, where each bit has a specific meaning. When I send a series of changes to "rearm a container", the end result I want is that when I receive a bit 14 or 15 in the BSW tag (which is the feedback from the PLC), then I turn off bits 14 and 12. ---
**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:** [April 22, 2024, 2:44pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/6 "2024-04-22T14:44:35Z")
What you are doing is extremely racy. That is, unreliable. Doing read-modify-write operations on an integer that can also be changed by something else **will** have changes overwritten by one side or the other. Make tags at the bit level for bits you need to write, and let the driver use an appropriate function to write the bit in a race-free way. If the driver cannot do that (like some modbus devices not supporting masked writes), then you simply **cannot** safely use an integer register bidirectionally. ---
**Author:** ![Miguel\_Cimildoro](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@Miguel\_Cimildoro](https://forum.inductiveautomation.com/u/Miguel_Cimildoro)\ **Post date:** [April 22, 2024, 2:53pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/7 "2024-04-22T14:53:18Z")
can you be a little more specific Phil? 😅 Let's say I create a boolean memoryTag that is triggered when the bit corresponding to that tag is set. So when that bit is set, I will set the memoryTag to indicate that I have received the bit? ---
**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:** [April 22, 2024, 3:00pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/8 "2024-04-22T15:00:56Z")
If you are using actual boolean tags, they cannot race with other tags. They don't have any side effects with other tags. (Your algorithms using them could have races, but they don't **add** any races.) If you try to use an integer's bits, where you read, then use bitwise & or |, then write back, your script can run in parallel with other script that try to do the same thing at the same time. One or more of the bit modifications will be lost by overwrite from a parallel thread. This is made worse if an OPC tag, where the PLC can change bits at the same time your Ignition code tries to change them. One modification or the other will be stomped on. Basically, if you use any read-modify-write operation in your code, it is only race-free if the variable is **locked** with a mutex. And there's no such thing for Ignition tags nor for OPC items. ---
**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:** [April 22, 2024, 3:07pm UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/9 "2024-04-22T15:07:19Z")
If you have a complex sequence of events that need to update shared state, don't use tag events. Use a timer event instead, coded similar to a periodic PLC task. It would repetitively: - Use a single `readBlocking()` call to grab all relevant tag values, including the current state memory tag, - Examine all of those values to determine the new state, - Then use a single `writeBlocking()` call to record the new state and update any handshake OPC tags. Since a timer event cannot run in parallel with itself, this provides a naturally race-free way to handle complex state machines. ---
**Author:** ![Miguel\_Cimildoro](https://avatars.discourse-cdn.com/v4/letter/m/53a042/32.png) [@Miguel\_Cimildoro](https://forum.inductiveautomation.com/u/Miguel_Cimildoro)\ **Post date:** [April 23, 2024, 8:47am UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/10 "2024-04-23T08:47:20Z")
Thank you for the detailed explanation Phil As things currently stand, we are not in a position to make alterations to the behavior of the tags. As a developer, I am limited as the project is in production, and making changes of that magnitude carries considerable risk that we must avoid. However, I really appreciate the suggestion and will definitely take your recommendations into account for improvement in future projects, thanks for your understanding and continued support ---
**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:** [April 23, 2024, 11:49am UTC](https://forum.inductiveautomation.com/t/gateway-event-tag-script/89212/11 "2024-04-23T11:49:48Z")
> [@Miguel\_Cimildoro](#): > > we are not in a position to make alterations to the behavior of the tags Then you may be stuck with unfixable bugs. 🤷‍♂️