Should the system.tag.writeAsync function always/generally be preferred over the system.tag.writeBlocking function when doing a scripted tag write and the remaining script execution does not read or otherwise depend on that tag?
Early on in my Ignition learning I just defaulted to using the system.tag.writeBlocking function in almost all cases, as the examples in the Ignition documentation seem to use that exclusively.
I suspect it would be better to use the system.tag.writeAsync function when performing a large tag write (many tags at once) but when performing one, or a few, tag writes at once might it be more performant to use the system.tag.writeBlocking function and avoid the overhead of spawning new asynchronous threads?
Known exceptions:
When writing to the same tag multiple times and each write should be processed in a given order (e.g. for tag history).
Typically I use writeblocking in operations that users would expect a slight delay. Buttons, etc...where bindings aren't possible. An async script might show that something is written but isn't actually to the operator.
Tag Scripts, Tag Event Scripts, anywhere a thread lock isn't desired, etc.. we attempt to exclusively utilize async writes.
I don't believe that writeBlocking multiple tags vs writeAsync will have any difference in backend performance. However, blocking locks the thread while the writes are being done. Which could in some places cause issues, and in other places will cause issues.
Neither writeAsync on the client/designer nor the gateway generates asynchronous threads directly - they recycle threads from an internal pool.
In general though, the overhead of successive network operations dwarfs the overhead of thread creation, so the most important thing is to batch your read and write calls together. There's plenty of other advice about when to avoid blocking in particular as well, and in general if you don't actually need a return code or to block execution, sure, go with writeAsync by default.
Bumping this a year later. I have been using writeBlocking up until this point as I really haven’t had much issue with it. Now I am working on a project where I need to write up to 30 tags at once and writeBlocking is taking approximately 1.2 to 1.5 seconds to complete. Would writeAsync be a better option for faster execution? I am already grouping all together and having one write instruction for the batch. This is for a process where reducing by one second per unit is a huge difference.
Moving to writeAsync may reduce apparent latency (basically only if you're in Vision) but will not actually make the wall clock time to write the tags any faster.
If writing 30 tags takes more than a second, that suggests a more pathological issue. Changing scripting functions might be putting a bandaid on a gunshot wound.
Little background then. This is on an Omron CS1 PLC using the Omron FINS driver. This is a tag change script in the gateway that is executing this code. Basically, new Serial number is detected, then we call a SQL Named Query, then write the results of the named query to some tags, the most being about 30, mostly integers. I tried the writeAsync and the script execution time went down to a few milliseconds. Would this be correct or is this just an apparent fix? Thanks for the quick replies though!
You've basically just offloaded the latency to a different pool.
The reported execution time of the change script is indeed reduced (because the tag change script gets to keep executing after the writeAsync call), but the actual write operation is still going to take as much time as it does via writeBlocking.
As long as the latency there is acceptable to you, then carry on. If you don't need to analyze the results of the write operation and it's the last thing in your script, you can use writeAsync.
I would worry slightly about obfuscating your latency; if the writes suddenly start taking thirty seconds, are you going to remember to look at the tag change script that still completes in milliseconds?
I am going to switch it back to writeBlocking for now since historically, this line (we are testing out Ignition to reduce latency compared to the Wonderware instance that has been here 20+ years) has had issues with data corruption when being written to from outside the PLC. I will start a different thread elsewhere to combat the latency that is there since it seems like writeBlocking should not be taking that long with 30 tags.
You should keep in mind that an overloaded driver for ordinary tag subscriptions will impact write performance. What brand and model of PLC is this? And is this an IA driver or a PLC-supported OPC connection?