I have a template for a conveyor illustration. It takes a parameter which is a UDT type I created called motor, which has tags for Motor Running Status (integer; 0=idle, 1=running forward, 2=running reverse), HOA status (integer; 0=off, 1=auto, 2=hand), Fault Status (boolean), etc. I decided that making a UDT with everything and passing it in was easier than using separate parameters for each piece of data I needed.
What I'd like to do is have a symbol legend page which would show the different possible states of the conveyor illustration so operators know what each color or each part means. I'd like to use the conveyor template for this symbols page so in case I end up changing colors/animations, that page will stay up to date.
The problem with this is that the template parameter is a UDT, so I can't just pass hardcoded constants to the instance parameters like I could if they were just integers or booleans. I'd rather not have to make a bunch of MotorUDT tag instances just so I can show these templates on my symbols page. Is there a way to use an expression binding on the template parameter that would give it the data in the form of a MotorUDT, without actually creating a tag to hold that data? Similar to how an if statement returns TRUE/1 or FALSE/0 without actually holding that value in a tag. I feel like there should be a way to return data of a specific structure, but I have no clue how.
EDIT: I think what I'm thinking would be kinda like typecasting but to a UDT type. Would I just have to make a function that returns a UDT type to do this or is there an easier way?
Just food for thought, but if you have to identify what the colors mean, then perhaps you shouldn't use colors.
I highly recommend looking at high performance HMI techniques. In the meantime, perhaps consider using a string vs colors.
And here's a quick introduction ...
Thank you, I understand it's ideal for everything to be intuitive, but I can't have every photoeye in the conveyor system showing the words "blocked" or "clear" at all times. It's just not space efficient and would look bad. So that leaves me with colors for now (green for clear, white or grey for blocked) until I develop some better illustration. And I'd also rather have a symbol key regardless of how intuitive everything is. That keeps us from getting phone calls asking what things mean, even the most obvious of illustrations. I will absolutely do some digging into High Performance HMI's. Sounds like it could definitely take my HMI development to another level.
For the time being, however, do you know of a way to pass a UDT type parameter without making a tag to do so? Something almost like a typecasting to a UDT data type. Or a function that returns a UDT type (this is probably my best bet so far if possible).
I'll definitely be giving that a read through.
As I have learned recently, you are severely limited when you use the UDT-type template parameters. Also, there seem to be problems in some aspects of Property binding, as opposed to Tag / Indirect Tag binding.
What I recommend is that instead of using the UDT-type drop target, you use a String-type target that is the path to the UDT (right click the UDT instance and copy path, paste in the template field). It is worth noting that you do lose all drag-and-drop functionality when you do this -- you will have to copy paste tag paths instead.
From there, you have a lot more power by manipulating everything via the path (closest thing you can get to a reference to the object).
To expand a little, if you do something like have two Template Parameters that are tagFolderPath and tagName, you can put references to whatever you want inside of the referenced tagFolder and access them via name.
Might look something like this:
If you have it set up this way, you much more easily can hand it hardcoded constants so that it will work in a template repeater or canvas. You could add more parameters like for each of its different status flags and then hand it those flags. Having it pull those images from a directory that is stored in the core UDT with parameterized filenames would then be a cinch.
I agree with all of this, except I would recommend creating a new root custom prop tagPath and binding it to the 2 params, rather than having to do this concatenation and double indirect binding for everywhere you need them