Can use tag change script on instance of UDT by tracking the UDT?
Consider I have 5 instances of a UDT, and if any of them changes, I want to run a script. I do not want to write a tag change script for individual instance.
Yes, just put the script into the tag within the UDT definition's tag change event. You should make sure your script executes in the sub 100ms range
pturmel
December 6, 2023, 12:53pm
3
nminchin:
sub 100ms range
sub 10ms range for events defined on tags. 100ms is a good rule of thumb for most other non-UI events, and a good rule for user-triggered UI events.
@nminchin I tried that and it only gets executed when the UDT definition changes and not if the value of one of the instance changes.
Can you show a screenshot of your script including the context of where it's located?
This is the gateway script for tag change of UDT "test"
This is the script I want to run if any of the Instance value get updated
This is the tag instances for UDT "test", I do not want to write the same tag change script for each individual test instances.
If you want a script to run on every instance of a UDT automatically, you want a tag event script, not a tag change script:
https://docs.inductiveautomation.com/display/DOC81/Tag+Event+Scripts
Honestly I'm surprised we allow you to add a change script to UDT definitions. I guess it could theoretically be useful, but is almost certainly not what anyone intended to do.
1 Like
Thank you for the solution, I will try this approach.
I want to recall.
Is this practice related to the your advice that execution of biding script must be fast? and long processing script must be place on project script and called from the binding script.
What is the reasoning for this? and what is the symptoms if I have a long execution script on the binding?
--i like to know, coz I work with a team, before I tell them I need to know the why.
Some topics to read (follow nested topics, too):
No, probably not.
The best way is to create a Tag Change Script in the same project you defined that script in, and then call it from the change script.
Do not confuse Tag Event Scripts for Tag Change Scripts in this case. Tag Event Scripts are quite sensitive to the speed of execution and would require your project with the library be defined as the Gateway Scripting Project.
Never do this... there are only 3, iirc, threads for tag event scripts. Tag even scripts must execute sub 10ms so that it doesn't cause issues with other parts of the system.
This is the way to do things like this. Write a project library script do the actual data logging, and call it in the Gateway even script as a single line.
This isn't like the others. The reason for doing a project library script isn't speed, it's code scoping. I don't fully understand it, but I've learned that sometim…
Absolutely.
The thread pool size, by default, is three. That is, once three tag event scripts are running, or sleeping, or waiting on a network reply, all other tag events have to wait.
The pool size can be reconfigured to be larger, and that is reasonable for very large systems, but tag events should still be designed to execute as near instantly as possible, with only gateway-local information.
Any tag change script that needs to perform anything complex needs to be in a project-based gat…
This is a task that takes too long to do directly in a tag event. Use the store and forward engine or use a gateway tag change event (in the project, not on the tag). See this recent topic for why this is true:
If you have very dynamic requirements, such that the event must originate on a tag event, this topic of advanced techniques might help you:
Every once in a while, we have a situation where basically all of our tag change scripts stop processing. I finally saw this error in the Console of the designer Diagnostics. It's almost as if the Basic Execution Engine has run out of threads.
WARN Common.BasicExecutionEngine - Execution rejected... running in calling thread [AWT-EventQueue-0] immediately. [com.inductiveautomation.ignition.designer.tags.tree.TagTreeModelImpl$BatchOp$$Lambda$949/0x0000016597b1a668@d72dc75]
Any ideas where I can…
What is the difference between the tag change configured in the point and the gateway, what is the maximum number of points configured in the point, what is the upper limit of the number of points configured in the gateway, and what is the maximum number of points configured in each gateway event
1 Like
Thank you very much for this..
Will read, and get back here for any conclusion I make.