LabView OPC UA Toolkit writing to server not possible (Bad_WriteNotSupported)

[Lüis]

Hello,

I want to use LabView 2021 and the OPC UA Toolkit 2021 to read/write data from/to an OPC UA server (WAGO PLC).

Connecting to the server with the provided client and also reading data is no problem.

However, writing data is not possible (the result status of the MultipleWrite.vi says Bad_WriteNotSupported).

I have not executed my LabView program for a long time but about 2 months ago the writing problem did not occur, today this was the first time.

Instead of using the WAGO PLC server I tried to reproduce the problem with the Unified Automation C++ Demo Server (https://www.unified-automation.com/downloads/opc-ua-servers/opc-ua-c-demo-server.html) writing the node Demo/Scalar/Int16.

And indeed, the same problem occured.

I have attached my used test.vi.

With the UAExpert Client (https://www.unified-automation.com/downloads/opc-ua-clients/uaexpert.html) it is possible to write this node.

I am grateful for any form of help!

If you need any more information, let me know.

Best,

Luis

[Lüis]

I have solved the problem:

I use a timestamp constant instead of a "Get Date/Time in Seconds" block for writing to the OPC UA server.

The question that still remains for me is: why did using "Get Date/Time in Seconds" beforehand and why suddenly doesn't it work anymore?

[themadgreek]

I encountered the same problem. Had a VI that was created earlier that used the "Get Date/Time in Seconds" to perform OPC UA write to a server and it doesn't work anymore. Tried the solution that was posted here, to use timestamp constant, and it works fine.

This got to be some kinda bug with the new updates. I am using LabVIEW 2022 Q4 64bit currently.

[rolfk]

A wild guess: timezone differences in relation to DST? Maybe there is actually a problem that the timestamp ends up to be in the future (even if it may be seconds only) and the server refuses that as implausible. If you use a 0 timestamp, the timestamp is added by the server itself on the moment it receives the data and then that doesn't happen.

The previous report was end of October, likely right after the computer clock on either the client and/or server changed from DST to normal time.