# Recommended approach to importing and mapping PLC UDTs to Ignition (Vision) tags (OPC-UA, S7-1500 PLC)

**URL:** <https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016>\
**Category:** Ignition\
**Tags:** vision\
**Created:** [August 17, 2023, 5:59pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016 "2023-08-17T17:59:48Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 17, 2023, 5:59pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/1 "2023-08-17T17:59:48Z")

</div>

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)

Refer to the attached images.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/6/460c7122e53fe954c305890f9e3a5241c47bba58.png)  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/d/6d669ba02dd572006a698b28dce6124a4ea736fd.png)

**Usage**  
I'm debating whether or not to:

1. 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.
2. Create UDTs in Ignition for common re-usable elements and pick from the imported PLC UDTs / tags as required.
3. 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.

Thanks

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [August 18, 2023, 12:11am UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/2 "2023-08-18T00:11:05Z")

</div>

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_.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/0/8084ab56ef61891563358365683db30e1be628f3.png)

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:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/d/4d6d3bbe735a405871b233c85075a3d3676e572c.png)

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 18, 2023, 12:28am UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/3 "2023-08-18T00:28:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 18, 2023, 4:46am UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/4 "2023-08-18T04:46:35Z")

</div>

Thanks!  
This points me in the right direction.

---

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 23, 2023, 4:35pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/5 "2023-08-23T16:35:16Z")

</div>

@paul-griffith @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](https://forum.inductiveautomation.com/t/opc-ua-struct-data-type/26905).

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:

1. 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"
2. 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.
3. Point the Source Tag Path to the source Ignition Tag "Pressure1"
4. Set the Read expression with a jsonGet:
  - jsonGet({source},"HMI.bAlarmEnable")

5. 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.).

Thanks again.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 23, 2023, 4:46pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/6 "2023-08-23T16:46:00Z")

</div>

> [@kcui](#):
>
> 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)

Derived tags have a special `{value}` reference you'd use.

> [@kcui](#):
>
> 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.

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.

> [@kcui](#):
>
> 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.

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.

> [@kcui](#):
>
> 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.).

Not sure what you're asking here - clarify?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [August 23, 2023, 4:47pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/7 "2023-08-23T16:47:34Z")

</div>

> [@kcui](#):
>
> 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.).

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.)

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 23, 2023, 4:49pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/8 "2023-08-23T16:49:48Z")

</div>

> [@kcui](#):
>
> If I was using a Rockwell / AB CLX PLC over the native Ignition OPC drivers

Ah, second read, do you mean _with_ the native Ignition OPC drivers?

If so, not an issue because the drivers don’t use OPC UA complex types. UDTs are exposed as folders containing additional atomic or UDT members.

---

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 23, 2023, 5:12pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/9 "2023-08-23T17:12:02Z")

</div>

Excellent. Thanks again, super helpful as always.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 23, 2023, 5:20pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/10 "2023-08-23T17:20:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 23, 2023, 5:35pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/11 "2023-08-23T17:35:38Z")

</div>

> [@Kevin.Herron](#):
>
> Tag Group with the Optimistic Writes option enabled.

Yes, definitely noted. Thank you.

> [@Kevin.Herron](#):
>
> I don't love how convoluted working with complex types from OPC UA is...

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.

> [@Kevin.Herron](#):
>
> 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

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.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 23, 2023, 5:39pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/12 "2023-08-23T17:39:08Z")

</div>

> [@kcui](#):
>
> I didn't even realize it structured tags using JSON objects

OPC UA structures are binary encoded. _Ignition_ is turning it into and representing as JSON.

---

<div class="post-metadata">

**Author:** ![kcui](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcui/32/51446_2.png) [@kcui](https://forum.inductiveautomation.com/u/kcui)\
**Post date:** [August 23, 2023, 5:39pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/13 "2023-08-23T17:39:45Z")

</div>

Gotcha, thanks for clarifying!

---

<div class="post-metadata">

**Author:** ![jonathan3](https://avatars.discourse-cdn.com/v4/letter/j/c68b51/32.png) [@jonathan3](https://forum.inductiveautomation.com/u/jonathan3)\
**Post date:** [September 15, 2026, 3:17pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/14 "2026-09-15T15:17:14Z")

</div>

Hi,  
I've got a few questions regarding the performance mentioned here. It was mentioned that reading individual tags impacts the performance more than reading a parent node. First of all, does Ignition read tags or subscribe to tags? If it's a subscription, doesn't the OPC UA server have to sample each tag either way? And when we subscribe to a parent node, isn't the entire structure transferred every time a member node changes as opposed to the one node that has changed?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [September 15, 2026, 3:30pm UTC](https://forum.inductiveautomation.com/t/recommended-approach-to-importing-and-mapping-plc-udts-to-ignition-vision-tags-opc-ua-s7-1500-plc/78016/15 "2026-09-15T15:30:26Z")

</div>

> [@jonathan3](#):
>
> does Ignition read tags or subscribe to tags?

subscribe by default, but it depends on the OPC Data Mode setting of your Tag Group.

> [@jonathan3](#):
>
> If it's a subscription, doesn't the OPC UA server have to sample each tag either way?

if you are only subscribed to the parent tag with a structured value, it only needs to sample that value. Perhaps it builds that structured value from internal memory by reading the individual values/locations, but that's different than reading or subscribing to each OPC UA node individually.

> [@jonathan3](#):
>
> And when we subscribe to a parent node, isn't the entire structure transferred every time a member node changes as opposed to the one node that has changed?

yes
