Hello,
I am using the OnChange option in the tag configuration to perform certain operations when a tag value changes. When the tag changes I perform for example a write to another tag using system.tag.writeBlocking(paths, values).
The problem is that when I perform tests and change the value of a tag (test Memory Tag) I noticed that sometimes the write of this tag executes after a very long time. It is several tens of seconds. At first when I tested this I thought the OnChange scirpt was not working. When I glanced at the tag after some time it appeared that it had saved but with a long delay.
Now when I test it the OnChange script executes immediately. I've never had a problem with this but the question is where does the delay sometimes come from? I'm keen for the write immediately in every time of change. Are there any suggestions?
Greetings
Michal
That means you have other tag event scripts that are hogging the thread pool. Look for any such scripts that perform any DB calls or blocking tag writes or any direct OPC reads/writes, or any API calls. All such actions reach out from the gateway to do something across the network, and stall the tag event thread pool.
If you are doing complex or long-duration operations in tag events, you are screwing up. Each tag event script must execute very quickly--single digit milliseconds at the most, sub-millisecond ideally--to not hold up other events. Especially do not allow sleeping or looping waiting for a condition.
I use these scripts (OnChange) on a very large number of tags and there has never been a problem with it but actually had simple tasks like writing to another tag with a simple "if" statement.
I have recently started using much more complex scripts on tags could this be the cause? I haven't reached the thread pool before because as you mentioned earlier it was executing very quickly?
What is the pool of threads to be achieved, how do I control this properly?
Regards
Michał
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 gateway tag change event, not an event defined on the tag.
Algorithms that need delays must be implemented as state machines via gateway timer events.