OPC UA ByteString - Write Issue

[RVallieu]

I am testing out OPC US in LabVIEW 2015 SP1 and I think I have found an issue in the OPC Client - Write ByteString.vi.

I have created a ByteString tag for experimentation purposes.  I have created a VI that updates the ByteString tag with a string that is converted to ByteString by the String to ByteString function from the String palette.  The conversion of the String to ByteString is no issue.  I can read the tag value, no issue.

I can write the Tag Value - but with the following findings:

• Writing a different value into the Tag is recognized IF the change is made inside the ByteString existing array length of data.
• Adding ANY text to the length of the current ByteString and then writing this into the Item does not update the value on the Server.  It is like a complete "Value Change" including ByteString Length is not being performed.
• If I make any change to the existing tag ByteString data and ALSO add ByteString data to the end ot the array by adding text at the end, then the whole ByteString value changes appropriately.
• If I made any change to the existing ByteString inside the original length of ByteString, such as changing a character from 'a' to 'b', then the Item writes properly
• If I delete ByteString data from the end of the array, changes are not accepted when writing the new ByteString unless over 2 bytes are deleted.

When the Item changes are not accepted I DO get a Write Timestamp change as if the Server saw the Item being written, but reading the ByteString returns the ByteString with the Byte I erased still in place.

Is the above expected behavior?

[RVallieu]

Here is a simple example you can use to test the above.

Also note - sending in a blank ByteString does not clear the item.

The last item - having to delete over 2 bytes should read - have to delete at least 2 bytes.  This seems to be intermittent, in that the first time I remove a character and then write the new value into the Item it works.  Subsequent changes require at least 2 bytes to be deleted from the end before the value read is different.

[DECONN]

Hi Ryan,

Thank you for posting the details behind your findings along with that simple example program. This really helped to get a good understanding of the issue. We filed CAR #600499 to investigate the issue further. You can track that CAR in the release notes or patch information as they become available. If we have quicker updates, I will try to update this post as well. In the meantime, as a general workaround, it appears that using an array of bytes, or a string, may give similar functionality. 

[RVallieu]

Thanks for the update.

I'm glad it wasn't just something I was doing wrong.  I can work around the issue for now knowing it exists.

Ryan