OPC UA write-only tags must support read to determine data type?

Ignition
1

I have implemented an OPC UA driver module and export some tags that are considered write-only. The DataType for tag is clearly set as Int16. Using the Quick Client if I specify the type in the dialog the write succeeds. If I specify Auto-detect type it fails - because it attempts a read on this tag and it is rejected. If I try a third party UA Client (UaExpert) it clearly shows the type of the tag and the access level as CurrentWrite but when I try to write to the tag it also attempts a read first (I can see the read attempt in my server log file) and the read fails

  • is it just understood (by everyone but me) that write-only tags must still support read in order to detect data type - even though the tag clearly states it’s data type in a property?
2

I think this is just a quirk of the ancient Quick Client implementation.

If you wrote from script via something like system.opc.writeValue it should only read the DataType attribute before doing the value write.

Ignition has never really supported the idea of write-only tags.

3

Ok, but as I mentioned, the UaExpert client does the same thing and tries to read the current value before attempting the write. I cannot figure out how to get this client to write to this “write-only” tag. We had to support read for write-only tags with a DA server as well. I was just hoping that this went away with UA.
Definitely not a show-stopper, I am just trying to discover the quirks of Ignition/UA (this is our first UA project)

4

UaExpert tries to read all the attributes at once when you click on a Node, then again after the write for some reason, but I have no problem getting it to issue the write.

5

Yes, you are correct, I was not looking at my log close enough. UaExpert issues the write but as you said, it follows that with a read of all the properties - including the value property which my driver does not support for this tag.

I am going to change my driver to just support read for all properties, including the value property but we will continue to indicate that the tag is CurrentWrite We will return some reasonable default value in the correct type for the read request.

6

If your implementation doesn't do the right thing, check the access level, and return either Bad_NotReadable or Bad_UserAccessDenied, then you may as well not even bother having the AccessLevel be only CurrentWrite.

It's conceptually just as incorrect as if you had a Node with only AccessLevel CurrentRead but allowed writes to it.

In Ignition 8.3 / Milo 1.0 some of this access control logic now gets handled in the SDK before reaching you, but in Ignition 8.1 / Milo 0.6.x it's entirely up to the implementation to check and enforce access levels.

1 Like