Hi - Looking for some recommended approaches (or pros and cons) to:
Importing PLC UDTs into Ignition (I am using S7-1500 via the Siemens OPC-US Server in the PLC).
General use of said tag in Ignition (to UDT, or not to UDT!)
Importing
I'm not too familiar with how tags work in Ignition. Can I import a single tag as a UDT type and will it automatically pull its child tags, or do I need to create individual tags in Ignition for every single member of the PLC UDT. The latter seem like a bit more work (even if I can export / import a tag list)
Create UDTs in Ignition that 100% match / map to the PLC UDTs. This seems problematic and not flexible to me as changing the UDT structure in the PLC for any reason breaks this. I am still in development so would not prefer to do this.
Create UDTs in Ignition for common re-usable elements and pick from the imported PLC UDTs / tags as required.
Not use UDTs in Ignition and just rely on the PLC UDT structure as imported.
I'm leaning toward the 2nd option, but maybe the 3rd would work? I'll probably have re-usable popup faceplates so I'd need to be able to assign an instance of a UDT. I'm used to using tag parameters from FTView and or using indirect tag references via parameter in WinCC.
Definitely 2.
Bringing an entire PLC UDT into Ignition, besides tightly-coupling the two things together as you mentioned, is also killing PLC comms performance and putting extra load on the gateway. Only bring in the values from the PLC that you actually need.
A helpful development tool: If you bring in a bunch of tags as raw tags in the tag browser, you can right click them all and 'Create Data Type From Selected' to automatically create a well-formatted UDT 'skeleton' that you can then further customize.
You can also, while authoring a UDT, use the OPC browser to bring in as many tags or folders as you want from a particular device, which you could then parameterize:
The only wrinkle in Paul's advice is that the Siemens OPC UA server performs terribly when you read too many individual tags vs reading the struct/UDT as a whole... it's optimized for the latter case and depending how many tags you need, you may have to resort to some combination of 1 and/or 2.
3 is easiest but you'll probably see the performance impact pretty quickly.
@PGriffith@Kevin.Herron
As a follow-up to this, assuming I am using Siemens OPC-UA server, it appears the best way to reference complex / structured data types (with lots of members) is to read the PLC UDT in as a Document and then use "jsonGet" in a Derived tag to access the individual members. A great thread was here.
Is there any official training or reference material in the online manual that shows more examples, or are most examples going to be from the forums?
So in my case:
I'd set up an OPC tag to, let's say, "CM_Pressure[1]" via the OPC-UA server on the PLC, Let's call the Ignition Tag "Pressure1"
Create a Derived tag to access a particular member. Let's say I am accessing Pressure[1].HMI.bAlarmEnable and this would be set up as a Boolean type.
Point the Source Tag Path to the source Ignition Tag "Pressure1"
Set the Read expression with a jsonGet:
jsonGet({source},"HMI.bAlarmEnable")
Set the Write expression with a jsonSet:
jsonSet({source},"HMI.bAlarmEnable", ?????)
More questions:
I'm not sure where I go with the "value" parameter ????. Is this another tag that holds the value to be written (in this case, true or false / 1 or 0)
What prevent this derived tag from constantly writing? If this was bound to a pushbutton object in the HMI, I only want the write to occur when the button is pressed.
Is this method of using the JSON object unique to OPC UA, or just a quirk with Siemens? I intentionally chose OPC UA as opposed the Siemens TCP driver since I cannot access symbolic tags that way.
If I was using a Rockwell / AB CLX PLC over the native Ignition OPC drivers, I assume this support accessing UDTs directly this way or would there be a similar approach to accessing PLC UDTs (I'm sure this is a while different topic.).
Derived tags have a special {value} reference you'd use.
They only write when written to. There's no fundamental issue here, they aren't polling or evaluating constantly or doing anything that would cause that to happen.
OPC UA structured values are represented as JSON/Document in Ignition. This is how any structured values from any OPC UA server would be handled.
Totally different, mainly because neither IA's native Logix driver (nor my alternate) support reading whole structures as documents, but does optimize structure accesses when multiple items in a structure are subscribed (or read or written in a batch). (And there's no arbitrary limit on number of subscribed items, which contributes to the motivation for the whole-structure-as-document access.)
It's easy to miss in the other threads, but if you plan to write to these members, them make sure you put all the tags from the Siemens PLC(s) into a separate Tag Group with the Optimistic Writes option enabled.
I don't love how convoluted working with complex types from OPC UA is, but it's what we've got. I wanted our implementation of JSON/Document tags to be far more powerful, exposing a hierarchy of virtual tags underneath a single parent tag, but for reasons this didn't end up happening.
The Siemens OPC UA server does expose all the member tags individually, but unfortunately accessing too many of them in this manner causes too high a load on the server. Hard to blame them, though - what they've managed to accomplish in terms of OPC UA support on the 1200 and 1500 given the extremely limited hardware constraints is impressive.
I think there's a new hardware revision of the 1500 that came out this year (or is coming out?) that uses a much more powerful Siemens-designed CPU and more memory. Should help with all aspects of comms, not just OPC UA.
I have not worked with OPC-UA at this level before (I didn't even realize it structured tags using JSON objects). I would say most people new to OPC-UA still approach it as a just "the new OPC DA" and don't realize the additional complexity and capability. Regarding the complexity, it isn't that complex once you understand it. I think some application examples in the help documentation (beyond what is there for JSON formatting) might go a long way.
This is precisely what I was concerned about. I wanted expose things in a Server Interface on the S7 PLC, but Siemens restricted the amount of tags that can be exposed this way, so I have to enable the "Standard SIMATIC Server interface" which exposes everything that has the OPC-UA visibility setting set to true. In general I've been impressed with the S7-1200 and 1500 after many years working on Rockwell but each platform has it's pros and cons.
