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.
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.
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.
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.
After performing a Gateway restart yesterday around 1700 CDT, I saw the same tag script behavior when those scripts went to execute at 2300 CDT. This is the first time that I have seen this issue since my last post.
