Tips on speeding up tag-based OPC UA communications

Ignition
1

Quick background... We use Ignition as a full MES, with communication to all workcell PLC's, cycle complete signals, MES acknowledge signals, and so on. This is 100% being done through a handful of tag change scripts living in a UDT folder of standard tags that we just import into any workcell. Many of the tags being written are OPC tags linked to shop floor PLC's.

It is often not very fast. An operator might have to stand there and wait for the machine to release a part because the acknowledge signal is taking 10+ seconds to complete. Some delay is always to be expected, but it is getting worse, and complaints from the floor are increasing. We also miss quite a few "writes" that cause production to stop until a bit can be manually toggled by a controls tech or myself.

I am wondering if anyone has some general tips on speeding something like this up and enhancing robustness of communication. Some of my ideas to test are below...

  • One thought is the Tag Group -- I noticed we have this set to 500ms for everything. Is there any nuance to changing this to something like 100ms, could that cause other issues, etc.?

image

  • Using Transaction Groups instead of the web of tag change scripts that are currently in place. But TG's seem more oriented toward synchronization rather than an MES handshake system. I have not played with this feature at all yet.

  • Looking into system.opc.writeValues instead of system.tag.write (we are still utilizing the legacy tag read/write functions). It makes sense in my mind to look into writing to the OPC address directly instead of writing to the tag which then writes to the OPC address (if that's how that works...) ?

  • We also don't utilize Gateway-scoped tag change scripts at all. It seems like such a useful tool, for example when a cycle complete tag flips (from the PLC), run a script in here that updates our production database and then performs a system.opc.writeValue directly to the MES acknowledgement tag address in the PLC such that production can keep moving. That sounds fast and reliable in my mind, maybe...
    image

I realize this might be pretty vague or open ended... definitely still in an exploratory phase here, and I need to test a lot of this out for myself. Any and all thoughts and ideas are welcome, especially if you have been through this problem and came up with something elegant.

2

This design is always going to be fragile, because tag change events directly attached to tags are not intended to be used for complex tasks--there's only one global thread pool to run all of them in the whole gateway, by default only three threads. This means anything you do in such events must execute in single digit milliseconds or less, or you will bog down the whole system. (In other words, no direct database or network calls allowed, and definitely no .sleep() calls or spin loops.)

Yes, there is a config parameter in ignition.conf to increase the pool size, but that's a band-aid only.

Tag change events that are defined in a project and supplied with a list of tags to monitor get their own thread, and won't block unrelated events. Use them.

Consider adding start and end timestamp captures (using java's System.nanoTime()) to all of your tag events and log warnings when any script takes more than a couple milliseconds.

2 Likes
3

That is awesome advice. I always knew the tag change scripts were "bad" but never knew why exactly that is. I definitely need to play around with this on our test server :thinking: Thanks for the insight Phil.

4

Check the diagnostics page for the devices involved and make sure your current 500ms is even being met. You may simply be overloaded.

5

I don't deal with MES in the systems I work on, but is there not some PLC that can actually do the control of the system and only pass on the data to the gateway for logging the data. I personally don't recommend using an HMI for automating a system and leave that control in the PLC and use the HMI system for monitoring, logging, and operator control so that the automation is handled by the appropriate "tool" for the job.

If there's something with MES requiring acknowledgement by the gateway to verify data has been recorded, as @pturmel mentioned, start tracking times to see where the bottleneck is, and refactor the code/script and possibly move to project tag change scripts to improve performance.