If I have a value change script on a tag that calls a project script and the tag changes again before the last change finishes its execution, will it interrupt the first script call? Or does the tag change script get run in an asynchronous manner? Is this different between v7.9 and v8.1?
No.
No.
1 Like
I think I might be missing some events for unknown reasons. Would you say it would be better for the script that is writing to the tags which implement the tag change script to be handled with a FIFO buffer/queue instead?
Check the missedEvents flag to find out for sure.
Each tag can have up to 5 pending executions queued before the it “overflows” and the flag is set. You shouldn’t be missing any unless this flag is set.
This seems contrary to this:
Is it possible that if there are other tag change scripts running that you could miss one with out the flag being set? Or do I just not clearly understand how it works?
I’m saying the same thing here. Let’s say your script executes, and then 10 more value changes come in real quick for that tag and it’s still executing.
The queue will have events/values 1, 2, 3, 4, and 10 and your script will execute for these 5 events/values. When it executes with currentValue == 10 the missedEvents flag will be set.
Note that they are also running in a thread pool. If you have lots of events with slow execution, other tag events can be delayed.
I suppose I was referring to the thread pool size of 3, sorry originally had the wrong post linked.
Yes, there’s also a thread pool of size 3 that is shared between all tag event executions. This really only matters in the case you have a lot of slow to execute scripts, as @pturmel mentioned.
Sometimes it’s okay to increase this pool size, but more often it means you’ve done something wrong and should rethink your approach.
2 Likes
My tag script executes in ~100ms, is that too long?
It’s not fast, but it’s only “too long” if it’s causing other tag event scripts to experience an unacceptable delay in execution. You’d need multiple scripts (3+) with lengthy executions at the same time before you started to notice.
I’ll look and see if I can optimize it some, monitor the missed events flag, and test it with several changes at once. I will report back, thanks.
I’d consider that too long. I wouldn’t tolerate more than low single-digit millis for tag events. I would put anything longer in its own gateway tag change event, possibly with a dedicated thread.
1 Like
What’s the difference between the tag change script on the tag versus the gateway script spot?
Biggest difference is that you aren’t limited by the thread pool, each event gets it’s own thread, so 1 long running thread will not cause others to be delayed.
1 Like
If you choose that option. Otherwise it is a shared thread pool. I don't recall the pool quantities, but more generous than tag events. Also does not discard after 5 queued per tag.
1 Like
I tested the tag change script and it would set the missedEvents flag when even just 4-5 tag writes occurred in quick succession. I changed it over to a gateway tag change event testing it up to 75 writes. It picked up every single one 
4 Likes