We're running into an issue with a Gateway Tag Change Script. It seems like if you define multiple tags as triggers, that the associated script is executed one-by-one synchronously (in series). All tags are in the default Tag Group with rate of 1000ms. So if we add a lot of tags as triggers (let's say 100 OPC tags) and they are changing every 3 seconds but due to script execution time (calling REST APIs) and the quantity of tags and it having to process one-by-one, it may not finish by the time the tags start changing again and I think we may be missing some triggers.
Is this expected behavior? And if so, is there a best practice to do something like this by using asynchronous calls? Or some kind of multithread queueing? Or do I need to modify Tag Group rates so they don't all fire at once in hopes to have another few threads run the scripts on smaller subsets of tags? To get around this issue temporarily, we have broken up the large trigger tag list into smaller groups and have multiple event scripts running but that seems clunky. Especially because we want to use wildcards at the folder level so it picks up new entries dynamically...and don't really want to redesign the tag folders just to account for this challenge of concurrency.
Yes.
The events with snapshotted tag values are not lost--they'll pile up indefinitely until handled, or you crash the gateway for out of memory.
Split up your events into multiple lists of tags. The event script should be a one-liner calling a project library script function, which can be called in parallel from multiple events.
If you must, you can create your own thread pool. Or, perhaps, use asynchronous API calls that free up the main thread to submit multiple in parallel. (Non-trivial, sorry.)
Thanks Phil. Unfortunately, if they pile up too long, our script includes some code (that you wrote for us 
) to collect an image from a Cognex camera using java sockets and telnet. So that image is already changed by the time a piled-up trigger fires the script.
I guess we'll keep doing what you suggested by using multiple lists of tags until we can think of a way to grab a bunch of Cognex images at once.
1 Like
I think you are over worried about tag change script getting triggered for that kind of tag numbers and speed. The tag change events are queued and the REST calls are pretty fast to handle the queue in my experience. It can handle much more traffic than that without throttling.
What kind of issues are you running into! MQTT works one similar principle (but not thru REST calls) which can handle tens of thousands of tags on Report On Exception (RBE) principle.
When the triggers queue up, it's too late for the script to do what it needs to do because the real life event (a camera taking a pictures) has already changed to a different picture.
It's frustrating because we initially used Tag Change scripts themselves (not Gateway Tag Change Scripts) and they worked well...until we realized those only have 2 threads by default and since they were longer running scripts due to API calls, we were missing events. So we migrated to Gateway Tag Change Scripts with "unlimited" threads and queuing only to realize they are executed synchronously one-by-one so the quantity of tags in the trigger list dictates how far behind the script will get.
Oh then taking picture will obviously be slower process than event generated by the tag change script.
Perhaps take a video continuously and mark only the time stamp of the event on the tag change script then ties the two up !
@PRAMANJ - regarding grabbing the live stream and referencing it later, that's difficult with Cognex cameras. @pturmel has a cool Image Streamer Driver Module that I've heard his customers are using for something like you explained but I don't think there was a good way to do it with Cognex the last time I looked.
1 Like
