We are using Ignition 7.9.18 with Ignition's OPC-UA server and Rockwell ControlLogix 5580/5570 PLCs, just wondering if this would be achievable for us or whether it only applies to Siemens PLCs? If so, can you elaborate on how to get an OPC tag to present as a JSON string when reading a UDT? If not, is there another strategy we can use for Rockwell PLCs to optimize reading and writing of UDTs with OPC-UA?
Same strategy applies to any OPC UA server using structured datatypes.
If you can't just browse to the Variable Node with the structure type, drag it in, and have it show up as a Dictionary/JSON then the server may not support the (now legacy) DataType Dictionary mechanism for exposing datatype definitions to connecting OPC UA clients. If this is the case you won't be able to read structured values.
I wouldn't be surprised if a server that is onboard/embedded on a PLC didn't support the legacy mechanism because it's based on relatively large XML documents.
Rockwell's OPC/UA functionality is quite slow, and is lower priority than any EtherNet/IP messaging. You should probably not be using it with Ignition.
Just to clarify, we are using the Allen-Bradley Logix Driver for all of the device connections to our PLCs. We are not using the OPC UA server embedded in the PLCs, just the Ignition OPC UA server. Apologies if I am misunderstanding something, my knowledge of OPC UA is pretty limited.
This thread and any strategy related to JSON/Documents is irrelevant for you.
The driver exposes the structures as tags and takes care to read the whole structure value behind the scene when it determines it's appropriate.
1 Like
@Kevin.Herron
Do you know if OPC-UA structs will be directly supported with the new Ignition version 8.3?
What do you mean by "directly supported"? They're supported now.
Yes, sure.
What I mean is: Today, the Ignition clients reads the OPC UA structured data type and transforms it to a json formatted value.
Directly means would to define the structure in Ignition (maybe as an UdT) and map the OPC UA structure type to the UDT keeping the transactional context.
Or are there better ways to model transactional context data in an OPC UA server for Ignition?
I don't think its representation as JSON/Document is likely to ever change at this point.
What I do hope is that our JSON/Document tags become more powerful... instead of being a practically opaque blob you can only deal with via scripting or expression functions, it should present its structure as something you can further browse in the tag browser, and expose "virtual" tags, each of which can have their own alarm, history, etc... settings, and each of which can be addressed at a sensible tag path given its location in the JSON object.
I lobbied for this before we even introduced the JSON/Document type but can't seem to get much traction - perhaps because the implementation would be quite difficult and there's some open questions about how configuration persistence would work given that the "shape" of a JSON object could change at any time.
2 Likes
Ah okay, understood.
I also read that Ignition 8.3 will support OPC UA 1.05. Does this mean it will support the new DataTypeDefinition Attribute which replaced the DatatypeDictionary to support structs e.g. in new OPC UA servers like S7 1200? That would be really helpful.
Yes, supports it, uses it by default for new connections. If you want to switch an existing connection so that it's used there will be an advanced config property.
1 Like
The issue with the json document is that any writes to any of its members writes the whole document, leading to issues writing values from multiple locations at once, unless I'm misunderstanding something.. It's a similar issue writing to dataset and document tags: you have to be super careful as you have to read the tag, update its value, and write it back and ensure that nothing else writes to it at the same time
The whole reason the Optimistic Writes setting exists is to solve the race condition writing to JSON/Document tags.
Most servers, especially those on a memory budget, only a expose the structure Node and don't expose the structure + all its members as Nodes as well. When this is the case there is not even a possibility of anything other than writing the whole structure value every time.
2 Likes