Create instance of UDT Tag with Python?

Maker
, ,
1

Is it possible to create an instance of a UDT tag with a script (python)?

I’ve created a UDT in my Data Types folder, but when I try to copy the tag with system.tag.copy, it keeps putting it into the Data Types directory.

For example, I’d like to create a UDT from a button click event script. So far I can’t figure out how to do that.

2

A copy of a data type is another data type, not an instance of that data type. You want system.tag.configure.

3

That was the nudge I needed! Thank you!!

I found the answer here under “Add UDT Instance” on the system.tag.configure documentation. For whatever reason, when I read this the first time I thought it meant to create a new UDT. I should have picked up on the word instance.

4

I ran into the same issue as Keith. i found the example (link below) but i a a bit confused what it is looking for in Type id, TagType. which one is the link to the UDT and what is the other for?
Thanks,
Cody Hoffman

https://docs.inductiveautomation.com/display/DOC80/system.tag.configure

5

Figured it out right after I sent this message. TypeID is the path to the UDT you want to use and tagType just stays as UdtInstance

6

Hi @pturmel, I have used the same to insert new UDT Instance into other UDT Instance. But no luck. Not Sure i am missing some thing or its a bug in 8.0.15.
Here's my script written in the button click event.

baseTagPath = "[TagProvider]UDTinstance/folder/"
  
# Properties that will be configured on that Tag.
tagName = "Item1"
typeId = "Dependencies/Item"
tagType = "UdtInstance"
# Parameters to pass in.
param = "{Asset Name}"
  
# Configure the Tag.
tag = {
            "name": tagName,         
            "typeId" : typeId,
            "tagType" : tagType,
            "parameters" : {
              "Parameter" : param 
              }
       }
 
# Set the collision policy to Abort. That way if a tag already exists at the base path,
# we will not override the Tag. If you are overwriting an existing Tag, then set this to "o".
collisionPolicy = "m"
 
# Create the Tag.
ewe = system.tag.configure(baseTagPath, [tag], collisionPolicy)
print ewe

I am getting the following error on executing it from vision client.

[Bad_Unsupported("The target path '[TagProvider]UDTinstance/folder' does not have item 'Item1' for overrides, and cannot accept children tags.")]

7

You are trying to use the merge collision policy when adding. That’s the one collision policy that doesn’t make sense when the tag doesn’t exist yet.

8

Yes you are right, But it didn’t worked Even though i have tried with all collision policies, Same error as mentioned earlier. Is it possible to add UDT instance in an existing UDT Instance.

9

Oh, I see what you are trying. No.

10

Thanks @pturmel , So in ignition can you recommend the best way to have this kind of complex data model. I need to Maintaining the consistent hierarchy kind of creating UDT Instances and adding the required number of Items at the certain level of data model, because globally for all plant my hierarchy is not going to change only the number of Items a particular level may differ.

11

Any reason you can’t use folders for your hierarchy? If you require “meta” information at each sub-folder tier, you could create a UDT for this that you would add to each sub-folder.

12

In a single gateway we are integrating multiple sites, So thought using one UDT instance for each site should be the standardized way and other important aspect is managing the future additions/changes, in which UDT makes our life easy. Whereas in folders there are chances it may deviate and addition efforts needed for management in the future.

13

Based on this, you will already have differences between your sites, so it's not really feasible to have a single "site UDT" definition that will work for every site (unless the variations between sites are finite and defined). You would need a unique UDT definition for each site. I would just create UDTs for the sub-parts that are common across your sites and programmatically instantiate UDT instances for each site within a folder hierarchy as needed. This way if you remove/add something to a site, that only pertains to that site, you don't impact your other sites. But if you change the definition of, say, a pump UDT, it will propagate across all sites.

Sounds like what you are looking for is some kind of UDT hierarchy template that would allow you to define what UDTs are allowed at each tier, but doesn't restrict the number of instances at each tier. Would be an interesting idea for Ignition Features and Ideas | Inductive Automation. Would be a complex ask though as I can only imagine the complexity involved in changing an existing hierarchy template and properly mapping existing instances to the updated template...

1 Like
14

Excuses, I’ll give much more clarity this time. When I mean Hierarchy, Its actually a plant hierarchy, so sections and process in a plant is not going to change, so for all plant its a same situation. as you mentioned only the number of assets(Pumps) is going to change. So my plan was prepare a master plant UDT and assets UDT and thought first to create plant UDT instance for each plant and then inserting assets UDT Instances in an automated way as required. But from my understanding from you and @pturmel it may not be possible. So I need to think now with folder structure it self.

15

Exactly Will @WillMT10, Sure will put this in Ignition Features and Ideas | Inductive Automation. Thank you.

16

Consider using UDT inheritance. Construct a base UDT that has all of the members that will be needed in all locations. Create child UDTs that inherit the base and add the members that are specific to particular plants or areas.

2 Likes
17

I had thought about this but I felt like it added more complexity than it saved. Bad assumption on my part if there is a lot of overlap between sites.