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?
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.
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?
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.
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?
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.