I have an 8.1 project that is using system.tag.read()
However, it is noted that this function is deprecated. Now it is a year later, and there are issues getting tags in the correct time but its not clear why or if this is related.
Is there a performance reason this function was deprecated?
Also, are there any notes/documentation that records when and why functions are deprecated?
Could you elaborate some more on this? What issues are you seeing exactly, long times to fetch small numbers of tags?
System.tag.read is a blocking single tag read, if you use this rapidly for multiple tag reads you will take a massive performance hit. The more performant way is to create a list of tags, feed that to a single system.tag.readBlocking call, and then pick the values you need out of the returned value list.
I believe there were performance reasons along with the overhaul of the tag system that happened in version 8.
I am almost certain it was deprecated for performance reasons. I think the reason is in line with how you always want to do block reads when reading multiple tags with OPC.
system.tag.readBlocking will read a list of tags and is what you should use.
system.tag.read is, more or less, exactly equivalent to a single-tag call to system.tag.readBlocking.
Describe the actual problem you're experiencing in more detail before latching on to the script method being used as the source.
I am trying to narrow down whether or not this is a plc or ignition issue.
Problem is that I am accessing everything remotely and another vendor is doing the PLC work.
Details are that I have a UDT with multiple tags in it. There is also a trigger tag and a handshake tag. Once the PLC activates the trigger, ignition does a read and then sets the handshake to true so the PLC can delete the data.
Currently all the tags in this setup are system.tag.read for each tag in the udt. However, I have 1.5 s from when the trigger goes true to consume the data and activate the handshake. Each of the tags are in a tag group that have a poll rate of 700ms (at least 2 polls). As far as I can tell, I have plenty of time to consume the data so I am inclined to blame the PLC for not filling the tags that provide the data.
I plan to remove the deprecated tags and combine it into 1 readblocking, to see if that does anything but I am just curious if perhaps the deprecated function was deprecated for a reason that may cause the issue I described. I don't want to blame the function, but if I change to readblocking and that fixes the problem I would like to have some confirmation that it was indeed because of the deprecated function calls.
At this point, I am not sure where the issue is coming from, but I can certainly improve the code to be more efficient.
If this doesn't work, I might have to transition into doing system.opc.read as that will be way faster anyway and I don't have to rely on tag group polling.
This is racy. Handshake bits should not be written from two directions when timing matters. Use two bits. One set and reset by the PLC, the other set and reset by Ignition.
Building on pturml's warning, you should also be using system.opc.readValues to ensure you have the latest values from the PLC. That will send a dedicated request to the device.
This is what is happening. Trigger tag that PLC controls and Handshake tag that Ignition controls.
Ignition does not interact with trigger tag. I apologize if this wasn't clear.
When using two bits for reliable handshakes, you must ensure the PLC doesn't turn a trigger on when Ignition's acknowledgement is still on--the process must wait for round trips to settle.
Based on your procedure description, you absolutely should be using system.opc.readValues() to retrieve the process data that the PLC set up, as only that will ensure the order of delivery. OPC subscriptions do not have ordered value delivery. Setting values in the PLC, then setting the trigger, does not mean that Ignition will get those in that order via subscription.