Gateway Tag Change Scripts

I have several Tag Change Scripts that every time I save and publish they seem to fire off even though the value of that tag has not changed. i have unchecked the change on Quality and Timestamp values, but this still happens.

In my case, when tag X changes (a PLC Register) I fire off a script to grab a couple other values from some other PLC’s then instert the data into a SQL table.

Problem is when I tweak the script then save it, it fires right away, I then end up with a “ghost” entry in the SQL table…

Yes I could “filter” those items, but due to auditing issues, I would rather not have them show up at all.

Is this normal for Gatewat scripts to fire automatically upon saving, no matter what the previous state of that tag was??

Yes, it’s expected. You should be able to check the ‘initialChange’ flag in your script if you don’t want to execute on the first change.

If you’re doing this and it’s still firing let us know what version you’re running and whether it’s a client or gateway script - we did just discover an issue with the way the tag subscription and binding system works that causes the initial change in clients to be pretty unintuitive.

if not initialChange:
    #do scripty stuff here
1 Like

Another question for that Tag Change Script mechanism…

the newValue will show the new value of the tag that changed however if there are multiple tags configured in one tag change script is there a way to determine the tag name and path that changed?

I appreciate any comment…

(oh yes on Ignition 7.6.6)

There’s an ‘event’ parameter you can access in tag change scripts that should have a getTagPath() method on it.

can you point me to some documentation that may show the use of the ‘event’?

Thanks!

The event contains a TagPath object, which you can convert to a string representation by calling toStringFull() on if you’re going to use it for comparison.

tagPath = event.getTagPath().toStringFull()

print 'tagPath=%s' % tagPath

support.inductiveautomation.com … g%2Bchange

IA Documentation regarding tag change tag change event object.
Tag Change Scripts
Tag Change scripts are available in both Gateway and Client scopes. Each tag change script can be given a list of tag paths. Whenever one of these tags changes, the tag change script will execute. They will also get an initial execution whenever the scripting system starts up.

Each tag change script can be given a name for organizational purposes. To specify multiple tag for a given script, enter them one per line in the tag paths text area. To quickly import many tags, you can drag-and-drop tags from the SQLTags Browser window onto this text area.

These scripts receive three special variables in their namespace when they are run: event, initialChange and newValue. The intialChange variable is a flag (0 or 1) that indicates whether or not this event is due to initially subscribing or not. The event variable is a TagChangeEvent object, which itself contains the properties: tag, tagPath, and tagProperty. The third, newValue, is the new value for the tag property that is subscribed. These values are objects themselves that contain a value, quality, and timestamp. The following example script should be a good starting point.
Example
print “Received tag change event for %s” % event.tagPath

value = newValue.value
quality = newValue.quality
timestamp = newValue.timestamp

print “value=%s, quality=%s, timestamp=%s” %(value, quality, timestamp)

Tip: The TagPath object that you access via event.tagPath is itself a complex object. You can turn it into a string if you want the whole tag path by using the str() function. You can also access individual parts of the tag path. The most useful is usually the itemName property, which is the name of the tag represented by the path. To get the name of the tag, you can use event.tagPath.itemName.

[quote=“Kevin.Herron”]Yes, it’s expected. You should be able to check the ‘initialChange’ flag in your script if you don’t want to execute on the first change.

If you’re doing this and it’s still firing let us know what version you’re running and whether it’s a client or gateway script - we did just discover an issue with the way the tag subscription and binding system works that causes the initial change in clients to be pretty unintuitive.

if not initialChange: #do scripty stuff here [/quote]

I’m running a client tag change script in 7.7.1. I’m using the initialChange flag:

if not initialChange:

but my tag change script is still firing when I launch a client. Is there any way around this?

[quote]I’m running a client tag change script in 7.7.1. I’m using the initialChange flag:

if not initialChange:

but my tag change script is still firing when I launch a client. Is there any way around this?[/quote]

This is currently not working correctly for client scripts because when the binding system starts up it ends up triggering a change that uses up the “initial” change. We have an open ticket for this and the milestone is 7.7.4. I’ll ask around to find out why it’s not 7.7.3 and if it can be changed.

Edit: It’s going to have to be 7.7.4. The 7.7.3 release is “frozen” while QA preps it for release.