Tag Event Scripts vs Gateway Tag Change Scripts

Hi all,

Just looking for some advice/ recommendations about which script handle to use for doing an action on a Tag Change event.

At this stage, I am trying to run a SQL query when a boolean tag value goes True.

There are two places to define such a script:

  1. Gateway Event Scripts -> Tag Change
  2. Tag-> Tag Events->Value Changed

Are there any benefits to using one over the other?
Having them all in one place in the Gateway Event Scripts would be easy to see and manage in one place…
But the Tag Event scripts look like they have more parameters to utilize.

We use the Tag->Tag Events->Value Changed. Mainly because you can then utilize UDT’s with tag change scripts for multiple items. It also keeps everything to do with tags in the tag folders, so we can easily move tags between systems and retain all scripting.

1 Like

Thanks for the reply, thats a good idea about the UDT’s.
Just had a look at what i’ve been doing, and decided I need to group my 5 individual tags into a UDT.

Just wondering, how do you reference UDT Properties or UDT Tags in a Tag Event Script?

I’ve tried to create a memory tag in my UDT to contain some parameter values, but i haven’t got it working.

My SQL Query:

query = """INSERT INTO QATestRecord (TestType) VALUES (?)"""
args = ["[.]TestType"]
system.db.runPrepUpdate(query, args, db)

SQL table result for column TestType:

[.]TestType

I cant get rid of the " " because then the Python compiler isn’t happy.

Hi there!

Correct me if I’m wrong, but it sounds like you’re trying to insert the value of the “TestType” tag into your database table, but the script is taking the string literal and inserting that into the database. Is this correct? If so, then the problem is with the argument.

In a script, you can read the value of a tag with a call to system.tag.read(), as opposed to using a string literal of the tag path (which is the correct syntax for Ignition’s expression language). Also, when specifying a tag path in a gateway scoped script, it’s a good practice to be explicit with the tag provider. Try modifying your code to something like the following (assuming the tag is located in the provider named ‘default’):

query = "INSERT INTO QATestRecord (TestType) VALUES (?)"
args = [system.tag.read([default]TestType).value]
system.db.runPrepUpdate(query, args, db)

Hi,

You’re on the right track, I am writing a Tag Event change script for the following UDT tag on the TestNow tag:

Gisborne01/ProdSystems/QATests/QA_BConcTest

But the tag i want to insert into my query is part of the same UDT as the tag change script. ie: tag TestType. So i was hoping there was a neater way rather than using

system.tag.write()

This is the UDT i am using:

To reference UDT properties you must create an expression tag in your UDT, so in your example if you want the UDT TestType tag to contain the contents of the TestType parameter, the tag in the UDT must be an expressiontag and the expression is “{TestType}”.
To reference tags inside your UDT from the tag event scripts you use [.].
So if you want to read the contents of the TestType tag in the event script you need:
testtype = system.tag.read("[.]TestType")
Then you use testtype.value in your code.

That worked great, thanks!

For another function im trying to write on the same UDT, how can i write to an expression tag “TestTime”?

The following code doesn’t seem to work.

	system.tag.write("[.]TestTime", system.date.now())

Neither does adding tag provider “[Default]”.

That code should definitely work, can you double check your TestTime tag is of the datatype Date.

Why are you trying to write to an expression tag? They get their value from their expression on every scan. Did you mean a memory tag?

Yes my TestTime tag is a Date datatype.

And sorry I had a typo there.
I am trying to write into a memory tag (TestTime), using a different expression tag (TestNow).

Edit: Solved it, was a combination of a couple of small silly mistakes. Typo in the tag name i was trying to write, and the Tag Change script on the tag instance being overridden, so recent changes weren’t pushed through.

Thanks PTurmel. Learn something every day!