I have an PLC with integrated OPC UA Server and I like to write a value to a SQL Server on value change. It is possible with the transaction group but there is the delay from the timer (for example 250 ms). I there a possibility to trigger an SQL-write immediately (event-driven) when a OPC subscription delivers new data? Maybe with a script instead of a transaction group?
Thank you for a good hint!
Peter
I suppose you could use a gateway event tag change script. Or did you try and there's a reason why it's not appropriate ?
Thank you. That could be a nice solution. I'm new in ignition and in the tutorials the transaction group is more atvertised. I had no knowledge about the tag change script.
To observe serveal PLCs what is the better way? One script for all that has an internal logic to find and process the triggered value. Or should I use a own independent script for every PLC?
One single gateway event script, you can set it up to monitor several tags.
The script itself will have access to the tag's value, name, path... so it should be flexible enough to handle several tags without making the script complex.
That being said, the transaction groups might be configurable enough to remove that delay.
Also, I probably should ask: Why is a small delay a problem ?
This is only the first step to get in touch with the DB communication. In a second step I will get some answer from the DB (if a part ist on the blacklist or not). And I think the sum of delays is the problem. I will have a litte delay from OPC UA and I will have a little delay from the DB. So I try to have a small as possible total delay because it can impact the cycle time of the maschine. What would be your advise for the transaction group? Set the timer as small as possible?
Keep in mind that OPC drivers poll the PLC at a pace, so there's going to be that latency right off the top.
Just how fast do you need to go, and how often?
FWIW, my flagship 3rd party module was created to solve these kinds of problems. (In the Rockwell or EtherNet/IP world.)
I have a project that looks up a bar code 400/min. I had to populate a table in the PLC w/Bar codes and where they should be sorted. 150ms each
Yeah. Polling OPC drivers aren't going to keep up, and your DB might be a problem, too. Non-trivial task. (This is the kind of thing I charge $$$ for professionally.)
Keep in mind OP is talking about an integrated OPC server (no polling).
Not sure about @Kfoldesi
When the operator starts the run. The current list of products and how the operator has setup the sorter runs a SQL query and transfers that data to the PLC. The PLC can make real time decisions to process the product.
Oops, yeah. @Kfoldesi should start his own topic.
You can use the same function in a project script module, but probably should have separate events per PLC calling that function, with dedicated threads, to ensure a PLC doesn't wait on a different PLC's event.
To load the Blacklist into the PLC will be no solution for me. Because of a big buffer stock the blacklist can be huge in some situations.
And yes @ Kevin.Herron is right, the OPC server is in the siemens CPU. The messaging module from @ pturmel won't work for me. I guess the OPC message from Siemens is not exact in sync, because it runs seperate from the plc cycle. But I have to life with this delay.
But I think about the answer of @ pascal.fragnoud. I like to make the sum of delays as small as possible. But is an gateway event tag change script in the end faster than a proper configured gateway event script?
As new user I can't mention other users...
Each has their own behavior. A gateway's project tag change event script, if subscribed to a single tag, will have the lowest structural latency, as it runs on its own thread (IIRC) with an unbounded queue. A Tag's own events run on a thread pool with all other per-tag events with a bounded per-tag queue.
If you can tolerate the proliferation of threads, consider spawning an asynchronous thread for each lookup. This will keep the back-to-back latency low, but risks piling up threads if your DB has a hiccup.
Or, perhaps, establish your own ThreadPoolExecutor with a fixed number of threads to do these tasks.
Thank you! That is a good hint. I will experiment with it and see what fits best.