Tag Change Script vs Script Console

Ignition
1

First - I’ve searched through the forums and found a few related posts but am still lost on my issue.

It’s a lot of code so I won’t be posting the whole script, I’ll just describe the intent and the different results I’m getting.

Scenario 1: I have a tag that when it changes from a 0 to 1 it will trigger a tag change event. That tag change event simply runs a script from the global library. The script in the library takes 2 arguements: startDate and endDate. Currently the startDate and endDate are being set in the tag change event - I have tried hardcoding those dates in the global script itself as well as trying to use memory tags and just readBlocking from the tags (in the change event and in the global script library).

Scenario 2: Executing that global script from a script console. Also have set those dates in various ways.

The results between Scenario 1 and Scenario 2 are different. The first scenario does return results but they aren’t correct whereas the 2nd scenario always returns the correct results. I can’t seem to figure what variable or even why they would be different. I even tried taking the variables out and hardcoding it - still different results between the tag executing it and the script console.

Any thoughts? Below is what the tag change event code looks like:

if not initialChange and currentValue.value:
		enable = system.tag.readBlocking(["[.]Enable"])[0].value
		if enable:
			startDate = system.tag.readBlocking(['[default]Rolling Start'])[0].value
			endDate = system.tag.readBlocking(['[default]Rolling End'])[0].value
			LinkIds.runLinkUpdate(startDate,endDate)

And the script console:

startDate = system.tag.readBlocking(['[default]Rolling Start'])[0].value
endDate = system.tag.readBlocking(['[default]Rolling End'])[0].value
LinkIds.runLinkUpdate(startDate,endDate)

The “LinkIds.runLinkUpdate()” uses the dates for several queries and it tries to match rows between the queries based on an index. Again - it works as intended through the script console but through the tag change event it doesn’t work as intended.

The queries are going against 2 different data sources. 1 is a Postgres database and the other is a BigQuery.

I’m thinking this has something to do with the different scopes between a tag change script and the script console. Just not sure how to remedy it.

2

Are you using system.db.runNamedQuery, by chance?
https://docs.inductiveautomation.com/display/DOC79/system.db.runNamedQuery

That function has two versions, one for the Gateway Scope (tag change script) and one for Client scope (designer script console). The gateway Scope requires the project name as an argument, because it lacks the context of the client scope. I would expect the tag change script to error out if that were the case–so I have no idea if that’s actually your problem. It’s just what I came up with based on your post.

3

I’m using system.db.runPrepQuery() and system.db.runScalarPrepQuery() in the global script. The tag change and script console have no system.db calls, it’s only in the global script.

Those db query scripts - I do have the database name set as a global variable in that library and every db call uses that variable. Unless it’s from an outside source (like the BigQuery) then I reference the database directly.

4

Another question - when running the tag change script and it just executes a script from the global library, does that entire global script run in the tag scope?

And vice versa for the script console - does the console run/encapsulate the whole script and it runs in the designer scope?

I’m thinking if that is the case then it’s probably handling the datetimes differently and I need to figure out how to mimic the datetimes from the script console into the tag change event.

5

Yes, project library scripts run in the scope from which they are called. If you are parsing date/times from strings, the timezone where the code runs matters.

1 Like
6

That was my issue. Forcing time zone specificity in the global script queries makes the executions identical.

Thanks!