I have a 3rd party MES that I have communicating with Ignition using OPC-UA, I created an ignition application to keep all of the MES transactions in one place but we have 15 pieces of equipment.
I have been trying to stay away from tag change scripts and ending up many gateway tag change scripts. I am using the gateway tag change scripts to move data between MES and the equipment, I am finding myself with a lot of scripts. I have been naming them with a prefix to keep them close to each other in the list but folders or some other sorting would be nice.
Is there a better or different solution I am not thinking of? How are you sorting your tag change scripts or are you doing something different? Thanks!
Are they similar enough that you can streamline some them into a single script, using the tag path for the proper direction? You could put the script into the project, and send the event to it.
EDIT: Although I agree that a folder structure would be nice.
1 Like
In 8.3 client/gateway/session event scripts are broken up into individual resources. This means that there's nothing fundamentally preventing us (at the resource level) from organizing them into folders, we just didn't undertake it as part of the initial effort to migrate from one resource containing all the event scripts to a bunch of separate resources. It's still a lot easier to manage, especially w.r.t project inheritance, import/export, and version control systems, but not as nice as folders.
3 Likes
They are close and I am on the fence between having individual tag change vs using the tag path. It is a lot more with individual scripts but the tag providers are different which throws a curve ball with the mapping. I’m debating a UDT mapping but i haven’t fully planned it out yet. If that works, ill have just four tag change over 4 per project. Thanks!
This is still 8.1 but moving to 8.3 by the end of the year
Hi, (unpopular opinion) I try to avoid gateway tag scripts. In 8.1 I cannot version them, and they are coupled to absolute tag paths since you have to manually add the tags the script should watch. This is different from defining tag events inside a UDT, where you can use inheritance and add a new UDT instance without having to remember to update a gateway script. IMO this is a good balance in terms of locality of behavior.
Unsure if this fits your use case but I ended up creating a multi-threaded work queue singleton with java.util.concurrent.LinkedBlockingQueue and java.util.concurrent.ThreadPoolExecutor and a context manager that I just push work to via the tag events. This keeps the tag event threads free and I can do IO operations and network calls. A caveat is that you lose out on relative paths but we just have a custom function that mimics the relative path logic. You also have to manage the lifecycle since you instantiate the object.
It has worked great so far with no issues. Kind of unconventional in ignition context but more than happy to go into detail if that's something you are interested in.
2 Likes