Not retaining eventScript with getConfiguration() and configuration()

Ignition
1

Hey, given some condition I want to periodically update a few OPC tags. To accomplish this, I've attempted to pull the current tag configuration with system.tag.getConfiguration(tagPath, False) and make those changes. Afterwards, I write that new configuration back to the tag with system.tag.configure(tagPath, tagConfig).

The problem I'm having is that this overwrites the parts of the tag I do not get from .getConfiguration(). Specifically, the eventScripts are not included and are therefore being overwritten when using .configure(). This results in the loss of the event scripts associated with the tags.

To illustrate, I start with this:

{
  "eventScripts": [
    {
      "eventid": "valueChanged",
      "script": "\tscript()"
    }
  ],
  "valueSource": "opc",
  "opcItemPath": "tagPath",
  "dataType": "Boolean",
  "name": "name",
  "value": false,
  "tagType": "AtomicTag",
  "opcServer": "server"
}

and end up with this:

{
  "valueSource": "opc",
  "opcItemPath": "tagPath",
  "dataType": "Boolean",
  "name": "name",
  "tagType": "AtomicTag",
  "opcServer": "server"
}

I was wondering if anyone has encountered a similar issue or has insights on how to update tag configurations without losing the event scripts. Any advice or suggestions would be greatly appreciated!

2

What does the event script do? If it's anything other than a fast executing script (<5ms) then you should really have the change script in a gateway tag change event script.

Having the script in a gateway tag change event also offers the benefit that, as long as your tag name/path doesn't change with the configuration change, the script can still execute.

1 Like
3

Thank you for your input, Ryan!

The tag's event script triggers on value changes from the OPC item path. In short, the script is parsing some value, sends an HTTP GET request based on that parsed value and processes the reply.

The reason why I want to write to the tags, is to create a redundancy fail-over. There are several OPC connections available that opcServer can point to. If the current connection ever fails, I need one of the other working OPC connections to step in.

Following your suggestion, I have looked at incorporating Gateway Event Scripts into the project. It seem to be exactly what I need, so thank you for that! I'm going to continue experimenting with this approach and see if I can get it to work. :slight_smile:

1 Like