[Bug-13950]Tag Event Scripts - Relative Tag Paths, Inconsistent Behavior

#1

We upgraded from 7.9.10 to 8.0.1 on 5/18/19. Since that time, the tag event script that resets our individual machine counters at the end of each work day have been functioning without issue. This morning, however, I noticed that none of the counters had reset. Looking back at the logs on the gateway, it appears that the script took exception to the relative tag paths used in the script.

This script resides inside of a UDT. The gateway log, script, and structure of the UDT are shown below. I am scratching my head as to why this would decide to fail when it has been functioning for 10 days. While I am using the legacy system.tag.writeAll() function, since it was working without any issues, I didn’t see any need to change the function.


Count_Bug1

1 Like

#2

Do those tags have good quality?

We’ve seen an issue in 8.01 where tags go to bad state after a restart of the gateway. Right-click restart tag resolves the issue. I know there are changes in 8.02 that may resolve this. We haven’t tested 8.02 yet.

0 Likes

#3

The tags do have good quality and the gateway has not been restarted since the upgrade.

It is worth mentioning that they are memory tags that are only manipulated via scripting within the UDT.

0 Likes

#4

@aburgess,

What looks to be happening is Ignition is expecting the Tag Provider to be explicitly defined rather than inheriting the default provider from the project. It is unclear to me why this may have worked (as there was a known issue that tag providers had to be explicitly defined), but this should have been a problem all along. We fixing a number of issues identified with UDTs in 8.0.3 and this specific issue should be part available in our nightly build .

While we don’t recommend putting nightly builds into production, if you have a test system we would appreciate feedback should the issue not be resolved.

Thanks,
Garth

0 Likes

#5

Since these tags are within the UDT, wouldn’t the “[.]” be used to reference the tags within the instance of the UDT from which the script is executing?

I have only seen this error twice since 5/18/19 (once in 8.0.1 stable and once in 8.0.2 stable). Since these scripts run every single day, I am still scratching my head as to why it would randomly decide to interpret the tag path as an explicit tag path?

I will get a nightly build installed on our sandbox machine and see if I see this behavior again.

0 Likes

#6

Best I can tell, 8.0.3 resolved this issue.

If it does come back up, I will update this thread.

1 Like