Currently have a tag with a tag change event enabled for value change which previously was working though has spontaneously stopped firing when I change the tag value. I’ve added a logger and a write to a bool tag to debug, though nether are working when I change the value of the tag. Any ideas why this might be happening? Network? Gateway Configs?
Is the script self-contained? If not, is there a syntax error showing for the shared script you reference?
Their is no syntax errors, We were getting slow performance issues where the scan class rate was not being met, so we increased the scan class. After doing a gateway restart the event was able to fire again, then shortly after the event stopped firing during value change.
The Script is not self contained.
I have a current batch count and a previous batch count that gets updated on a tag change event for when current batch count changes in value. As can be seen, previous batch count stopped updating at 300 and the value change event on the tag BatchCount doesn’t fire.
You’re probably going to have to search your gateway log for errors relating to your script(s). However, system.tag.write generally doesn’t throw errors. You’d need to use writeSynchronous instead.
Turns out the tag change event stops working for every tag change event until restarting the gateway. It will temporary work after the restart though will stop firing again.
Ah, you probably have one or more events scripts that are tying up the event handling thread pool. Infinite loops or some extra-long task. You should take care that any event script called from either tag events or tag change event scripts executes at least as fast as the scan class of the tags involved. Consider adding logging to all of your event scripts to find any slowpokes.
Phil, do you know if errors are logged in the gateway when the event buffer is overrun? I believe I’ve run into this same issue, except I can’t prove it without a log entry.
Not that I know of. I don't think it is "overrun", either. The documentation says that later events will simply be delayed. That's why you would need your own start & finish logging in your events to debug such problems.
We had the same issue couple of weeks ago…but in our case it was due problems with Sepasoft functions running in UDTs for T&T module. At the end all threads fell in waiting state for an specific thread that never ends and system collapse and the only option it was restart the gateway to fire again the events.
Sepasoft provided us some advices as use system.mes. calls instead of object calls. And from Inductive side they recommend us to modify the config.file adding the next sentence.
“wrapper.java.additional.8=-Dignition.tags.scriptthreads=12”
For the moment we did not suffer again the issue.
1 Like
Thanks Daniel. Did they mention what the default number of script threads is?