UDT Parameter on Perspective view

Ignition Early Access
1

You can give a udt parameter to a template, but how does this work in perspective views?
I can’t just set the udt as parameter.

1 Like
2

To do this you will do the following:

  1. Create a new view that will be used as a drop target for your UDT. This would be similar to a template in vision.
  2. In the View, there is a dropConfig.udts property. You will configure this in the following way:
  • type: The name of the UDT Definition
  • param: A value you select that will be defined in the PARAMS area of the view later on
  • action: For property binding purposes, use bind. For indirect tag bindings, use path

  1. In the View PARAMS area, add a new Object with the key equaling the name you defined in dropConfig.udts.param

  2. In the view you just setup, add components you wish to bind the UDT members to.

    If you are using Property Bindings (Read Only), you will add a property binding to the parameter you just created in step 3 adding a .<UDT Member Name> to the end. e.g. view.params.<PARAM>.<MEMBER>

    If you are using Indirect Bindings to allow for bi-directional writes, you will add a tag binding (Indirect) and set the tag path to use the parameter in step 3 adding a /<UDT Member Name> to the end. e.g. {PARAM}/<UDT Member Name>.

    As of 8.0.6, spaces are not supported for UDT member names within UDT bindings in Perspective.

  3. Create another view

  4. Drag a UDT instance onto the view and you should be provided the View Name that you linked the UDT to. Click it to drop an embedded view component onto this view that is bound to the UDT.

At this point you will see params show up in the property editor with the Bound UDT values. If you have any bindings that aren’t working, this is where you can confirm the name used as a key. You would adjust the settings in the primary view and then confirm they took in the view that it is embedded in.

Garth

12 Likes
3

I can’t do this when I put my instance inside a Folder.

4

I am experiencing the same problem. When the drop config is set to path, it works to drag and drop the instance. However it only works if the UDT is nested directly under the Data Types directory. If a folder is created under Data Types (to organize UDT libraries), this functionality is broken.

Edit: After further troubleshooting, the folder path must be included in the name of the UDT on the view props. This is not automatically bound though. If the UDT is moved, all references need to be changed on the corresponding views AND the individual instances. Hopefully there is an easier way…

1 Like
5

@derrick.marlow,

What version of Ignition 8 are you using? This issue should be resolved in versions 8.0.10 and higher.

Thanks,
Garth

6

@ggross I am using Ignition 8.0.12, and it does seem to be resolved.

7

@ggross, what do you mean by instruction 4 in your explanation? Could you possibly provide a screen shot illustrating it? It is incredibly frustrating (and unfair) that this information on using a UDT in Perspective is needed to complete the certification test, and yet it is nowhere to be found in the online training course.

2 Likes
8

@dennis.engleman,

Re-reading step 4 I can understand why it is confusing. It can be better worded like:

In the view you just setup, add components you wish to bind the UDT members to. You will add a property binding to the parameter you just created in step 3 adding a `.<UDT Member Name>` to the end. e.g. `view.params.<PARAM>.<MEMBER>`
As of 8.0.6, spaces are not supported for UDT member names within UDT bindings in Perspective.

An Example:
I have a UDT Definition of UDT_Def with a member named Member1.

  • In step 2, I set a param value of udt_binding.
  • In step 3, I create a param named udt_binding for the embedded view.
  • In step 4, I add a Label component to the View and setup a Property binding on props.text to view.params.udt_binding.Member1

You may want to check out the this post and some of the discussion leading up to it:
[Question-Resolved] Perspective Components (Template).

It has examples and screenshots that might further assist learning this concept for Perspective.

Garth

1 Like
9

Thanks, I did read those past examples but still struggling. How do you then get this parameter that has been set up in the embedded view to link to a specific instance of the UDT? I’ve tried indirect bindings and property bindings without success. If you could explain with screenshot that would be very helpful.

Dennis

10

@dennis.engleman,

Sorry for the delayed response as I missed the notification.

I would recommend you loading the resources in the last post of: [Question-Resolved] Perspective Components (Template) and looking at the different methods that I have configured.

I added the Tags that were submitted by the user asking the question to the post so everything is all in one place, and cleaned up issues that might occur if you are using a Realtime provider that is not default. I feel that a functioning example will do you more good than screenshots when all is said and done.

Notes about the views you should be looking at:

  • Main_View: Uses the Embedded Views and has the drop targets working. Also has some notes of where to look in the designer to see relevant information. All items should display values and there shouldn’t be bad bindings.
  • Shape_Template2: Uses Parameter Bindings. Note that the values will not display until dropped into a different view as you can’t get the .jsonValues binding to occur in the view you are building. See MainView.root.EmbeddedView.params.instance_number to understand how this holds together.
  • Shape_Template3`: Uses Indirect Bindings. Hopefully things make sense as all bindings are indirect to the path that is passed in. All items should display values and there shouldn’t be bad bindings.

Garth

1 Like
11

@ggross

I, too, am frustrated with the UDT binding / view params functionality of Perspective. While I love the idea of Perspective and the shift towards more of a traditional web dev feel, there are some things that are still clunky to me and not well documented - this being one of them.

I don’t understand why you aren’t able to add a UDT datatype as a view parameter, similar to how you can in Vision. I have a Machine UDT and I want to be able to pass in an instance of the entire UDT to the view. I can do this with Vision - why can’t I do this in Perspective? It feels like this is really over-complicated. Maybe I’m just missing something?? Any help would be greatly appreciated.

1 Like
12

@andrea.tidwell

We have received similar feedback from others and internal discussions are being had on how to make UDT bindings in Perspective easier to accomplish. It is very clear to us that this experience is very frustrating to users and changes need to occur.

For development purposes, it is going to be far easier to use Indirect bindings for UDTs rather than property bindings for the following reasons:

  1. It will be easier for you to manually set a UDT instance path as the input parameter of the view and see example data in the views you are creating.
  2. It allows for write capabilities to the UDT members.

I have updated the above steps to (hopefully) clarify how this is done. Please let me know specific issues you run into and I will try to clarify them as best I can.

Thanks,
Garth

2 Likes
13

Thanks for your response. This works very well for Embedded Views, but unfortunately falls apart when using the Carousel component. I’ve tried to create an object with the same key as my View Param from Step 3 above in the views.0.viewParams within the Carousel component. I then tried to bind the viewParams object to the instance of my UDT. My viewParam object just shows up as null.

I was able to figure out that you cannot bind your viewParam within the Carousel to a direct UDT tag instance. Instead, you must manually type the tag path to the instance of your UDT you’d like to pass to the embedded view within the Carousel.

14

I recently renamed and moved a UDT definition (into subfolder). When I attempted to re-point the child UDT instances to the new parent location, all the child UDT member tags disappeared, leaving only the parameters. (I also deleted an unused parameter, but it remaind in the child instances).

Some of my UDT parameters, member tag names, as well as those member tag OPC expression parameter bindings have spaces (I was not prevented from creating them that way)

combination of moving (into "Broken" subfolder)/restarting the UDT tag instances brought the child UDT members back (not sure which actually solved the problem)

Is this a bug or perhaps related to the spaces issue? Should I reconfigure all my UDT tag member names to use _ instead of spaces?

None of these are bound to any views yet - is this related only to UDT<>View bindings?

15

@hunterdg
For the issue you are reporting, it likely isn’t related to spaces in member tag names. I just want to confirm the steps you are performing:

  1. You have 2 UDTs:
    1. UDTA: Has a couple of member tags
    2. UDTB: Has UDTA set as it’s Parent Data Type and maybe a couple other additional tags.
  2. You moved UDTA into a new folder, which breaks the Parent Data Type link for UDTB
  3. You fix the Parent Data Type in UDTB to point to the new location for UDTA
  4. After doing this, you don’t see the inherited members of UDTA showing up in UDTB

Does this represent what happened?

In this case there is a bug occurring where UDTA doesn’t look to be restarted/reinitialized when it is moved preventing the inherited members in UDTB from showing up in the UI. The issue will be resolved when the UDT Definition is restarted or the Gateway is restarted. A ticket for this will be prioritized.

As for should your UDT Tags Members be reconfigured to not use spaces, if you plan to use these UDTs in Perspective at some point in the future it would probably be something you will want to consider. This will only become an issue when property bindings are used with UDTs and Perspective Components.

Garth

16

Thanks for the response! Thought I might’ve made a mistake by replying to old (ish) thread

  1. I have 1 UDT:
    1. UDT: Has ~40 member tags (including subfolders)
    2. UDT instance tags: Have UDT set as their Parent Data Type and maybe a couple other additional tags.
  2. I moved UDT into a new folder, which breaks the Parent Data Type link for child UDT instances
    1. **this immediately causes child UDT instance tag members to disappear (understandable because missing definition), while UDT parameters remain (presumably because they are not dynamic)
  3. I fixed the Parent Data Type in child UDT instances to point to the new location
  4. After doing this:
    1. the tag browser still shows the old path in the Data Type column
    2. child UDT instances do not reacquire their tag members, even after “restarting” both the child UDT instance tags and the parent UDT.
    3. If I move the broken UDT instance tags (into a “Broken” subfolder, for example), the tag browser then shows the correct/new path in the Data Type column and child UDT instance tag members re-appear, after which I can then move the tags back to original location.

Version: 8.0.16 (b2020082513)

Regarding the spaces issue - dang, one of the things I love about Ignition is that I don’t have to use underscores everywhere like all the other SCADA systems I’ve used, so e.g. for descriptive labels/hover tooltips, I can often avoid binding to the “description” field in favor of the tag name itself! Oh well, guess it was too good to be true!

I suppose I should also avoid spaces in UDT parameters as well (assuming I can bind to them in perspective)?

17

@hunterdg,

The behavior you are noting it due to a problem similar to problem I noted. The changing of the parent type doesn’t look to be reinitializing the tag properly. While the changes are being saved, it would take a restart of the Gateway, Provider, or Tag Folder for the change to be detected. We will get it working in a future release.

For the record, spaces don’t cause an issue at this point in time other than warnings appearing in the designer. The underscores would be to future proof your system and ensure your future self less potential headaches. While we know about this specific scenario and test around it, there could be a release in the distant future where this specific case was missed.

UDT Member Tag Names should be the only thing that you need to be concerned about when it comes to spaces in the names. UDT parameters are not going to be auto-populated into Perspective View input/output parameters (which is where the space issues is currently causing problems). For reference, this is how the drag/drop of UDT bindings works in Perspective:

  1. You define a Parameter that a dropped UDT Instance will bind to
  2. When you drag the UDT Instance to a perspective window, it is creating an embedded view with a binding on the defined parameter to <UDT Path>.jsonValues which is a JSON object for the dropped UDT Instance. This binding has keys with the UDT Instance member names with subscribed values as the values. Because Perspective parameters don’t support spaces in the name as of 8.0.6+, this is where things get problematic.

I hope this helps.

Garth

1 Like
18

@ggross,

I see in 8.1.3 that parent UDT types can’t be changed any longer, and remembered this thread.

Only workaround I can find is Edit (raw) > Rename, Save, then delete the original UDT instance and rename the new instance to match. Edit (raw) > overwrite doesn’t work.

I also thought there was a way to “Paste JSON” for tags, but maybe that’s just Views

Any thoughts? might the capability be coming back in the future?

EDIT: resolved by using parent UDTs

19

@hunterdg,

Sorry for the delayed response. You are correct, editing the parent UDT type functionality was changed in 8.1.3 to prevent the modification. It ended up causing stability problems when the parent was changed that required us to make this change. We realize this has broken the workflow of customers and in 8.1.6 we attempted to resolve the issue, but it introduced a regression that caused 8.1.7 to be required that backed out the change.

Ultimately, we know some form of this functionality is needed. It will be more like 7.9 though where it will only be allowed via import. Please watch the 8.1 release notes for updates to this issue.

Garth

2 Likes
20

Hi @ggross , this explanation was really helpful for me.
I got it working up to step 4 with the property binding.
But I have to be able to write to the UDT, and really can't get the indirect tag binding to work...

This is how I got the property binding to work:

image
image1742×642 164 KB

I'm trying to do the indirect tag binding like this:

image
image1666×558 168 KB

or like this:
image

But I always get this error:
image

Any idea what I'm doing wrong here?
Or how to troubleshoot this?