Simplifying the creation of meta faceplates that use child/nested UDTs

Ignition
1

Okay I’ll try to keep my thoughts organized here and hopefully someone can point me in the right direction.

-Using Ignition Platform 8.1.7
-Building HMI from a Rockwell Studio 5k program through an emulator OPC topic

  • I have different types of object templates/UDTs
    - Drives, E300s, Digital valves, etc.
  • Each object (on click) navigates to a faceplate. Each faceplate is different, but they have nav buttons to similar faceplates which correspond to child UDTS.
    - fault alarm, analog alarm, interlock/permissive faceplates for example
    (Think PlantPAX but custom)

Initially:
I created UDT Types for each object. Each UDT had folders with groups of tags for each supporting FP.
I created a separate faceplate for each objects supporting faceplates.
I.e. E300 interlock, Drive Interlock, E300 fault alarm, SOV fault alarm, etc.

This seems very inefficient. I have decided to halt my progress to find optimal alternatives.

The first thing I have done is change the folders in the UDTs to nested UDTs.

These are some options that I think will be effective, but I am unsure of which to pursue.

  1. Just keep doing what I’m doing. Not too bad of an idea because I’ve done so much like this already. I am just worried about the processing speed of the final product.

  2. Assign the child UDT as a custom property to the secondary faceplate and pass it from the primary faceplate which has the parent UDT as a custom property.
    That way I can have only one faceplate with the custom property assigned and pass it from the different primary faceplates which have that property imbedded in them.

  3. Create a template with the secondary faceplate objects and put that onto the faceplate. Then I assume I can just pass the parent parameter and attach the corresponding child property to the template properties. It does not seem to like attaching a template to a property though.

If you were to begin this project, what would you pursue to streamline the process of creating secondary faceplates?

Please point me to any other reference information if there is something similar already out there.
I can provide any screenshots if requested.

2

This a broad topic with no “right” answer, but here’s some tips on how I think about this:

  • UDT composition is powerful.

    • Let each UDT handle what it’s good at, then nest instances to create larger objects.

  • Template path swapping is powerful.

    • By changing a template’s path at runtime, you can create seamless transitions without managing a bunch of different windows and components.
    • I would rather manage a collection of faceplate templates than a collection of faceplate windows.

  • A UDT that represents an object should contain all the information about that object.

    • This includes all information about the object’s faceplate.

So combining these two ideas: I have a “FaceplateConfig” UDT than contains all the information about the faceplate to use for a device (title, what tabs to show, which tab loads which template, what parameters to pass to each tab/template, the faceplate size, etc.). Then, each object which needs access to faceplate receives a “FaceplateConfig” UDT in its data type.

A side benefit of this is that it plays very nicely with UDT inheritance.

3

That is interesting. I’ll need to keep that in mind for the future. This is my first Ignition project I have been assigned to and I there are several things I would change if I had the luxury of no deadline.

I appreciate the reply though!