I'm trying to automatically create new UDT instances based on a SQL query from a database with the active orders for the production line.
I have succeeded with the creation of the instances with the correct names but I can't figure out how I should populate the nested UDTs...
I use system.tag.configure and according to Wiki, it's possible to both use parameters and "tags":[]. system.tag.configure (example #5 and #6).
I would preferably not use parameters as this UDT is quite large with a lot of nested UDTs so creating a parameter for each tag, link them and have every script point to a parameter instead is quite a lot of work.
Below are pictures of the UDT definition and the result of a system.tag.getConfiguration() from a UDT instance I created manually. The memory tag "Antal" is "Quantity" in Swedish and it is the one I have been trying to populate first, there are more tags I need to do the same thing to but if I can figure this one out I should be able to fix the rest.
I have tried "tags":[{}, {"tags":[{"value":VARIABLE}]}], "tags"[1]:{"tags"[0]:{"value":VARIABLE}} and other different combinations.
Is there a way to do this or do I have to either add parameters or do a system.tag.writeBlocking afterwards to get my desired functioin?
Any help is appreciated!
I'm quite surprised, but AI was able to help me!
For anyone having the same problem, you need to define that you are changing a UDT instance in the "tags":[] block.
So the solution looks like this:
tag = {
"name": VARIABLE_NAME, #Name of the UDT you are creating
"typeId": "Order", #Define what UDT and that it is an UDT Instance
"tagType": "UdtInstance",
"tags":[{
"name": "Orderdata", #Name of the nested UDT
"tagType": "UdtInstance", #Define that you are editing an instance
"tags": [
{
"name": "Antal", #Name of the memory tag in the nested UDT
"value": VARIABLE_AMOUNT
},
{
"name": "A", #Other variables inside the nested UDT
"value": VARIABLE_A
},
{
"name": "B",
"value": VARIABLE_B
}
]
}]
}
If you have even more levels to the nested UDTs, you just add another level by defining it's name and then that the tagType is UdtInstance.
I'd stop here and ask why?
This is a very bad idea, and I'm curious what design path led you to want to do this.
(Creating tags is gateway configuration. Don't make ordinary runtime activities depend on configuration. This will get you in big trouble if you ever need to deploy redundancy.)
The easy answer is I'm new to Ignition so I probably do a lot of it wrong! 
I come from the PLC-world where I store all my data in data blocks and tags so the tag system felt like the most logical choice for me. I chose to use UDTs because I'm used to them from PLC and it was easy to make changes during development.
I noticed that I didn't quite explain what I'm using these UDTs for:
The operators today fill in a Excel sheet by hand which takes a lot of time so I got the task to streamline their work so it gets faster. The Excel sheet shows measurements for the components and what components are included in the final product. They also pair the components together in this sheet so we can look back and see what components went into the final product if we get a complaint.
The end goal is to have history on all products and produce reports for each product.
What other way could I store all this data while having easy access to it to make changes? Is it in the Project Library I should store data for this project?
Store data in a database.
Use UDTs to help structure that data while the work is In-Process. But once it's done, write it to a DB and reuse the UDT for the next order.
Concur. This is a job for a database, with tables for products, product component recipes, and results.
The UDTs should point at the PLC's registers for work in progress. In high-speed operations, consider a set of UDTs for completed work and for preloaded information for the next cycle.
If you have many product spreadsheets containing recipes, consider using scripts with the Apache POI libraries (included in Ignition) to transfer that information to your new database.
Speed isn't an issue here, the operators still need to do some manual work to populate the report.
My plan was to create UDT instances for the active orders, only for the orders that are work in progress. I get all data from either the ERP/MRP system or other SQL databases.
When I then create the report, my plan was to delete the tag and only save the report.
Would you still recommend to store the data in a database? The data is never "stored" in that sense, it's only used as Work-In-Progress in Ignition before it's saved as a report.
This whole application would be possible to create in a native Windows-application but we chose Ignition for its ease-of-use for creating dashboards and connections to SQL databases.
Yes, because saved reports are notoriously difficult when researching problems. Arrange to construct your reports from the database, not from live data in the tag system.
Thank you both for the incredible help!
