Does gateway tag change script work with UDT instances?

[rohitdas104]

I’ve created a Sensor UDT that contains a measurement tag of type Document, located at:

[default]_types_/Sensors/measurements

I have more than 10 instances of this UDT (Sensor1 through Sensor15), all created under the Sensors folder in the Tag Browser. My goal is to write the values from these measurement tags to a MongoDB database.

I’m attempting to do this using a Gateway Tag Change Script with the following configuration:

• Tag Path:

  [default]Sensors/*/measurements
  
  

• Script:
  For testing purposes, the script only contains logger statements.

However, the script behavior is inconsistent. It runs occasionally, but most of the time it doesn’t trigger at all. The logger statements often don’t appear, even when I manually force tag value changes.

This setup is part of a client POC running Ignition 8.3.3. Interestingly, I tested the exact same configuration on my personal laptop using Ignition 8.3.4, and it works as expected there.

Additionally, this logic works reliably when implemented as a UDT Tag Event Script instead of a Gateway Tag Change Script.

My questions are:

• Is this issue related to the use of a non-terminal wildcard (*) in the Gateway Tag Change Script?

• If so, why does it work correctly in Ignition 8.3.4 but not in 8.3.3?

• Is there a better or more reliable approach for writing these UDT instance values to MongoDB?

[pturmel]

@rohitdas104

non-terminal wildcard

This is new for v8.3, and obviously didn't work right out of the box.

Consider using the following technique:

Java concurrent queue for tag change scripts

Continuing the discussion from [SOLVED] Are tag Value Changed scripts running asynchronously?: We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on …

[rohitdas104]

Thank you! For my use case, I can trigger this from a Tag Value Change script. However, since I prefer to keep all business logic centralized in the scripting module, and those scripts aren’t directly accessible from Tag Change events, I’m planning to expose the required functionality through a WebDev API. The Tag Change script would then simply call that API using system.net.httpClient.getAsync().

Does this approach make sense? Also, since system.util.getGatewayAddress() isn’t available in Ignition 8.3, what’s the recommended way to reliably obtain the gateway address in this version?

[pturmel]

@rohitdas104

Does this approach make sense?

No. WebDev adds a ton of overhead to what would otherwise be internal calls. You should set a Gateway Scripting Project to contain project library scripts callable from tag events.

(But keep any tag events fast--single digit milliseconds--by avoiding any operations that call out over the network.)