Are tag change scripts run in a dedicated or shared thread by default? If they are run in a shared thread by default, how do I make it run in a dedicated thread? I assume the thread is created each time the tag changes and assume it is dedicated, but just want to make sure.
Also, when a tag change thread is still running and the tag changes again, is another script fired off even though the first change is still running?
There is a single thread pool for all tag events. Three threads by default, IIRC. Can be set at gateway startup with an additional java param in ignition.conf, but I don’t recall the precise syntax.
Events that come in while a prior event is still running are queued. If the script doesn’t “catch up”, excess events are lost. The queue is five per tag, IIRC. I don’t think that can be changed.
If you need more reliable events for specific tags, use a gateway tag change event in a project, not a tag event on the tag itself. Different thread pool, unlimited queue, and other threading options. Naturally, unlimited queuing on a run-away script can yield other problems.
Thank you for the info, I do need a more reliable event.
I am executing a script as each carton passes by a photo cell eye (via a conveyor running at 200 ft/min). The gateway tag change script executes very rapidly (2-14ms start to finish) but the event completes 270ms to 520ms after my scanner returns a value (results from thousands of samples). The scanner is on a timeout read cycle so it delivers the bar code at very consistent times (about 300ms from the scanner eye being triggered and scanner eye is directly connected to the scanner). Hard to believe, but based on the numbers I collected, the tag change eye activation varies up to 250ms. The tolerance for this application is about 100ms (about 3.3 inches).
If the triggering of the tag change event has this much variance, my application won’t work properly. I am not familiar with how to setup a tag change event in a project instead of on the tag itself (via the gateway tag change option). Could you steer me in the right direction on how I set that up? Do I use a gateway timed event? How do I recognize when the tag changes?
Lastly, in this script triggered by the eye, I write three integer values to a an ethernet connected Allen Bradley Micrologix 1100 PLC (this eye is connected to this same PLC). Any idea on how long it takes before the PLC values are set? Would this have any variance in time like I seem to be experiencing from the eye?
I doubt the execution time is your problem. Rather, you have run into the latency limitations of polling device drivers (OPC or otherwise). (250ms sounds suspiciously like a poll rate.) SCADA systems aren’t really intended to operate at PLC I/O scan rates and latencies. The closest you get is my Ethernet/IP driver module, and I’d hesitate to deploy it as the core of the system you describe. To close loops in the sub-100ms range, you generally need a real PLC.
What is the script actually doing?
The script determines when a carton will kick off the conveyor line onto a pallet. The error tolerance for the kicking mechanism is about 5" and Ignition is giving results just outside this range, where maybe 5 in 100 cartons don’t kick correctly.
We have a C# PLC driver from Automated Solutions (or something like that) that communicates to the PLC very close to real-time. I use it successfully for other applications. I didn’t want to go that route since the coding in Ignition is so simple and straight forward, but you confirmed my fears, and I will be implementing it using that driver. Thanks so much, you have been very helpful.
<Cringe/>
One existing PLC gets the photoeye signal and controls the kicker(s) ? You should architect the PLC code to track the product timing vs. conveyor in parallel with whatever decision-making you are doing with Ignition. With such a short actual script execution, it seems to me that getting an answer about which/whether to kick within the time limit should be doable. Just not actually controlling the kick timing.
The PLC handles all the timing and kicking. The only thing done outside the PLC is to determine where it will kick based on a SQL database and a bar code from the scanner. It writes the data to the PLC that triggers the timer and the kicking. It works great except there is this 250ms variation in how long it takes to recognize the eye has triggered and to write the data elements to the PLC. It will be less than 50ms with the C# driver if it works like other applications I have written before I had access to Ignition, Thanks again for your help.
So, how fast are you asking Ignition to poll this one tag? If just one tag Ignition probably can poll at 100ms.
(If an older version of Ignition, you might also need to configure java garbage collection to low latency with G1GC.)
This can be changed, I saw @Kevin.Herron mention it in a post a week or 2 back 
Here is a post on how to make the change:
I’d be looking to verify you’re using an appropriate Tag Group (or Scan Class if this is 7.9) and that it’s keeping up with the polling demands before assuming it’s the tag change script execution that is being delayed.