Version 8.1.44
Vision Module
I am having an issue with a UDT Property Type assignment. I had the same issue yesterday and I ended up having to copy the JSON of the UDT, delete the UDT, then paste it back in to resolve the issue. But that resulted in multiple other clean up issues that I worked on fixing the next few hours. I tried restarting the tag, exporting and importing as an overwrite. I have tried removing the custom properties and reapplying them. But nothing seems to work other than deleting the UDT completely but the one I have today I can't do with breaking a lot of currently running systems.
Here is what shows up for me when I peek at the element data.
I have confirmed I have the correct UDT Datatype selected.
I thought at first it was just maybe a UI bug and the data is still there but when I try to pass data from an instance of that UDT to my popup I get these errors:
Now I know what causes orphaned UDT instance error. But I have the UDT instance bound to a custom property on the root container of which I use a button to pass that data to my popup. But because of the first error it just does not seem to see there is any data there.
Something interesting to note is that I have this same UDT as a child inside of another UDT and I have no issue with getting the element data on it through that parent UDT.
Update:
I tried just copying the UDT and pasting it in the same folder but it is named as 526 Motor. I set the property datatype to it and it works just fine. But the original still has the same issue.
I can use this to work around my issue without deleting the UDT for just this project for now. But would like to know if there is another way to resolve this issue.
Update 2:
Decided to go look at the logs and found this. It is full of these errors.
The issue dates back to June 26 which is where it seems to have started with the same error:
You should get support involved.
Most people stop using UDT properties when they hit the inherent performance issues they have, or discover that their parameterized windows and templates aren't as re-usable as they should be.
This means that bugs like this don't get a lot of commercial pressure for resolution, as the vast majority of the user base uses string tagpath parameters and indirect tag binding instead of UDT props.
Support may help here, but you should plan on migrating away from UDT props.
2 Likes
The only sensible choice is this. I haven't used UDT Type params since the first year I started using Ignition (almost 10 years ago) . I very quickly discovered their flaws and stopped using them
1 Like
My understanding is a lot of the performance issues come from people filling a UDT full of tags then only using part of them with a UDT property. But all of them get loaded in regardless if you only use a few of them. I only ever create UDTs that I will use everything in them everywhere I use them. Or is my understanding wrong?
That's one of the issues, there are lots of other usability issues
So you have lots of windows and templates dedicated to specific UDTs? Eww. That lack of re-use will blow up your project resource collection and cause its own problems. When you migrate to tagpath-based parameterization, you can efficiently re-use windows and templates based on common member names across many UDTs, without needing UDT inheritance.
Not wrong, but not the only factor.
I guess I need to look more into the differences. I haven't ran into any limitations or issue with UDT Props until this point. I have a conveyor system with over 200 conveyors that use a UDT prop to pass the tag values through that I haven't had trouble out of.
Yes and no, where I work a lot of what we are doing is standardized and is safely repeatable through the UDTs we create. There are scenarios where it does not always apply but usually the differences in those cases are so great it wouldn't make sense to spend time trying to make a template dynamic enough to use in both use cases and would be better just to have a second template. Like for example a motor popup using a VFD verse a motor starter. I just have two separate popup templates for those. But for my VFD motors I can use that same UDT for all the different VFDs we use on site. All that being said we still use indirect tagging where a UDT does not make sense to do.
I can't find one of my posts with all the limitations, and it's been so long since I've used them... But, I think they were:
- can't read tag metadata like eng range, units, canWrite, etc (obviously you can use the UDT instances tagpath to the indirectly bind)
- can't use with template repeater
- can't pass UDT Type to popups
- subscribes to every tag in UDT to kill performance
- you used to only be able to associate a single UDT TypeId but I think that got changed... Now it's more lenient I think...
- can't remember the rest
I feel this is something I currently do.
If I create a popup window and drop in my template for the popup. I create a custom property on the popup root container that has the same type of my UDT from the template. I bind the UDT prop to the root container UDT prop and set it for bidirectional. On the window I want to open the Popup from I setup the same custom property on whatever I want to open the popup from or on the root container on the window. Then in the scripting window I select the popup choose the parameter and bind the UDT prop from the custom UDT on that window for the value. From there you can just bind the UDT to that prop and it passes through to the popup. Sounds like a lot and I guess it is compared to indirect tagging.
template prop to root container prop
props from window
setup for passing UDT to the popup.
binding the UDT
Have you tried via scripting?
Referring to passing the UDT to the popup? If so then yes but I couldn’t get it to work.
1 Like
I think it was via script that it didn't work, same reason scripted template repeaters don't work with them either
So you're saying the template graphics on your overview screens, etc use ALL the tags in the UDT? Typically, these template graphics only use a handful for status, alarms, etc, then the faceplates have all the tags utilized there. This is where using just a tag path on the template is much more efficient because only this handful of tags are subscribed to by the client. So for quick math, let's say you have 50 templates on the screen, and each template only needs 5 tags, but each UDT has 50 tags in it total. If you use just the tag path, you're looking at 250 tags being subscribed to, but if you use the entire UDT, you're subscribing to all 2500 tags every time you navigate to that screen. All you need to do then is pass the tag path to the faceplate/popup and then you can set up a custom property there to indirectly bind the entire UDT, or do individual indirect bindings. Either way, your screen loads will be significantly faster.
Ah okay that makes sense.
Yes, if I use a UDT prop I only use it if what I’m passing the tags to can use all of them so that I’m not subscribing to unused tags. If I can’t use all of them I don’t use a UDT prop I use indirect tagging. In my use case related to this issue I have a motor UDT that contains everything I would use in our motor popups. Including controls, statuses, motor data, and VFD data/set points.
You should still get into the habit of passing tag paths to popups, not udt properties. Much more efficient and flexible.
Anything new that I make tends to use indirect tagging instead. The use of UDT Props was already an established standard where I work for the motor/conveyor popups, so we keep it that way because it has worked without issues for years now. Issues like what I am having per this topic allows me to push for a change because passing the tag path would have made this a non-issue for us.
1 Like
