Hello everyone,
I am currently experiencing an issue with the "Null" data type on an Ignition OPC UA Server.
I have created a string tag (both inside a UDT and standalone) with its value source set as "Memory". The tag is also initialized with a default value of "" (empty string).
The problem occurs when I connect to the Ignition OPC UA Server using an external OPC UA client (UaExpert). The client sees the tag's data type as Null.
I found a temporary workaround: if I click to edit the tag's value, type nothing, and lose focus, the OPC UA client suddenly displays the correct data type (String). However, after some time, it randomly resets back to Null.
Has anyone encountered this issue before? Is there a permanent fix or remedy for this?
Thanks in advance!
Have you deliberately set the memory tag's datatype to string? (Show the tag editor.)
Also, what (precise) version of Ignition?
I'm currently using Ignition gateway 8.3.4 and I confirm that I've set the tag's datatype to string from the Tag editor.
Here's the tag editor.
The DataType that UaExpert shows in the Data Access View is the type of the actual value received for that Monitored Item - it's not the value of the DataType attribute of the Node identified by that NodeId.
What this means is that the Ignition tag value is null for some reason.
Perfect. Since this "absence" of the data type is causing problems on the customer's OPC UA client, is there any known workaround? For example, would setting a specific default value like " " or "xx" instead of "" help prevent this?
Well, to be clear, the actual DataType attribute should still show up as String at all times. You'd need to find this node in the attributes pane of UaExpert to verify that.
It sounds like this client has a problem handling null values. As a workaround you could try putting in different empty-looking or sentinel strings in Ignition. I'm not sure if it's intentional whether a memory tag with an empty string value reverts back to null or if there's something else going on there - @ggross might have a better idea.
It's also worth chasing down the bug in the customer's client. It should be able to handle null values.
