LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2016 vs LabVIEW 2017 OPC UA WRITE Speed/Efficiency

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.

 

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
Message 1 of 7
(2,059 Views)

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.  

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
Message 2 of 7
(2,015 Views)

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.

Matt J | National Instruments | CLA
Message 3 of 7
(1,979 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
Message 4 of 7
(1,962 Views)

If you are comparing those two functions, I would also be interested to see if there is a difference between:

 

  1. Multiple Write - Variant and the Multiple Write - <DataType>, assuming you are writing N items of type <DataType>.  In my perfect world I would have the info on all data types but I would at least want to see Boolean, Double, Boolean Array, and Double Array to get a spread of data sizes.
  2. For the Node ID input, would using the node path be any different than using the new node id of ns=<namespace index>;<identifier type>=<identifier>"? The old API only takes in node path so I would assume a lot of upgraded programs would stick with that so I would want to see if that is slower or faster.

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.

Matt J | National Instruments | CLA
Message 5 of 7
(1,945 Views)

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. 

Matt J | National Instruments | CLA
Message 6 of 7
(1,934 Views)

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.

Ryan Vallieu CLA, CLED
Senior Systems Analyst II
NASA Ames Research Center
0 Kudos
Message 7 of 7
(1,895 Views)