Another issue with the difference between 2016 and 2017 I have found is the amount of time a Write function takes to update a tag.
I have an input engine that is synched to the scan engine to Read from about 50 inputs and then write the value to the associated tags.
In 2016 the process is very efficient and the IOVar read and subsequent write to the OPC tag for all 50 tags completes in under 10ms.
Changing nothing else about that code except upgrading to 2017 showed a significant slowdown in the OPC Write vi. This showed up as a large CPU usage in the RT since the Scan Engine was set to 100ms intervals and the 50 tag update was taking 100ms.
The workaround I have done now is to add my own change detection to preclude calling/writing to the OPC UA Write multiple VI.
The other change I can do I suppose is to build up the array of inputs and then call the write multiple outside the FOR loop.
Ok I fully went in and rewrote the code to pull the new updated IOVar data and replaced values in the array of requests and then only used the write multiple variant VI once at the end after all tags. This is vs the original implementation in 2016 where this was not an option.
No gain in performance.
Still had to put in my own value change detection to prevent write if no data change on the list.
Is this the UA client or server write that's slower? Also, are you comparing the Write.vi in 2016 to the Write.vi in 2017 or the Multiple Write.vi in 2017? Just want to make sure because I just finished some OPC UA client stuff that's supposed to run in multiple versions and on a cRIO so I will be a bit upset if performance is going to dip that much in 2017.
I am comparing the speed of the LV 2016 Client Write to the LV 2017 Client Multiple Write - Variant (There is no longer just a Client Write function).
LV 2016 writing to 50 tags individually in a For Loop (each iteration reads from an IOVar hardware input from the Scan Engine) with the new data from the IOVar is orders of magnitude faster than the 2017 Multiple Write version. It is actually slower to gather all of my new data in an array and use Write Multiple once after the reads from the HW than it is to replicate the single write with the scalar data cluster wired to a Build Array to make a one element 1-D array per IOVar read in the For Loop using the Client Write Multiple - Variant.
In our system we do not have the Server use the Write function except to set the defaults for the Tag values as the design allows for it to be hosted elsewhere if needed in the future. We open a local client on the cRIO (which connects fine) and a client on the HMI (that hasn't been able to connect in 2017 yet (you saw my other thread). I wrote some example code to show to the AE working on the Service Request and without any IOVar reads in the code I am seeing the same slow speeds on the Client Write Multiple - Variant.
Sorry for not being clear.
If you are comparing those two functions, I would also be interested to see if there is a difference between:
Of course this is my wish list and am definitely not committing to testing this but if someone had this information I would be very interested in the results. I'll see if I can bug the other AE into testing this as well as what you sent them.
On a somewhat unrelated note, I saw that you asked another question about writing to read-only nodes working in 2016 and not 2017 and figured you would want to know the following if you did not already.
CAR 631356: OPC UA Client API Does not Throw Error/Warning on Read/Write if it has Incorrect Access Level
CAR 630981: OPC UA Client Read Function Will Not Throw Error or Warning if Wrong Polymorphic Instance is Selected
Basically the client API would let you write a read-only node (or read a write-only node) and would let you write/read a double to/from a node which is actually a boolean (any data type mismatch really) and while it wouldn't throw an error it wouldn't actually do anything. Pre-2017 you have to monitor all of this manually and while 2017 won't throw an error, you can at least read the return code to monitor for bad statuses.
Maybe I was unclear again, I did not expect Client Nodes to be able to write to read only nodes, that would defeat the purpose of read only tags.
The Server Write used to be able to Write to Read only tags. We used this to set default values for the server when the tags are created.