I’m using Ignition Vision module, and I’m looking for a feature that I know exists in other platforms, particularly in PanelView FactoryTalk View Studio.
In those systems, there’s something called a Parameter File, where you can create a single screen—for example, for one pump—and then reuse that screen for multiple pumps by passing in a Parameter File that maps to the appropriate tags for each instance. This approach saves a lot of development time because you only have to design the screen once.
I’m wondering if Ignition offers a similar feature that allows dynamic screen reuse by passing parameters or tag references.
Yes. They are called window parameters. In all of the navigation operations, you can supply them. The window's named custom properties on the root container receive the corresponding named parameters.
It is very common for windows (and templates) to be designed to take a string tagpath parameter, which is used within for indirect tag binding.
(Have you taken the free Inductive University lessons? Basics like this are well covered.)
Ignition's window and template parameters do not have to be just tag references--all kinds of data can be supplied this way, far superior to anything FTView can do.
I have to giggle when Factory Talk ME/SE is held up as a standard for anything. It's like asking why my ferrari doesnt have the same 14" wheels my VW Bug does.
I would highly suggest you spend time going through Ignition Universities tutorials and lessons for Vision. I would caution to ignore (if its still there) the lesson on passing UDT types as parameters. Don't do that. As above, pass a string tag path root as a custom parameter to your window or template. Then form the tags you need as indirects within the template or window widget bindings or other custom properties.
As an example you may have a folder called motors. In the folder, a UDT tag called pump1. Members of that UDT, called startpb and stop pb.
On your window create a custom property called rootpath of type string.
On your navigation of the window assign the string for pump 1. Something like [tagpath]motors/pump1
In your window, for a start button, assign a binding as indirect {1}/startpb with {1} as the property rootpath.
God I hated these, I would always pass in the base tag prefix using.. /T?? I think? Much like you do in Ignition, and then using indirect tag bindings to append the rest of the tag name/path to the end to read the tags you need. I couldn't stand parameter files as they're just so bespoke and non-standardisable, and relied on copy paste find replace. What happens if you have 50 param files and you want to add a tag to them
But beware the videos on using UDTType window and Template parameters! These should never be used, despite their veil of enticement. For underneath is a cornered eastern brown (snake)
That never happens. Displays are always engineered with all the data you will ever need, there is never expansion, and this belief that a system may need to change is the real problem.
Well, I don't know about that comparison, being able to use the control logix plc's tag database directly without having to build any tags is a huge plus, and the built in wizards are a real timesaver for a non python expert like me, but I'm getting there. Also, the stupid parameter file hasn't been needed for about 15 yrs, they just keep it there for backwards compatibility, lol.
You shouldnt be using the logix tag database directly. Dont drag clx tags using the OPC browser into ignition. You should be creating ignition side UDTs to mimic CLX UDTS and only grabbing the pertinent data and control.
I have been dragging clx tags using the OPC browser into ignition. Are you saying this is not the way to go? Can you post some screenshots showing an example of what you mean?
It's fine to drag and drop from OPC Browser to Tag Browser, as long as you are not doing it with entire trees of tags. Only make Ignition tags for what you actually need. (And the Ignition tags do not need to follow the same folder and tag names as the PLC if that doesn't suit your system.)
UDTs in Ignition also do not need to match 1:1 to PLC UDTs, and typically should not. UDTs in Ignition are extremely useful for managing complex hierarchies of tags, especially when there are repeating patterns.
I disagree, I use to curse at projects that used direct addressing, as then I've got no idea what tags they're using from the plc when I go to migrate them to Ignition. (Projects should obviously be designed for easy migration to another scada platform )
Hard to know without expanding the tag structure, but those 670 folders and sub tags, if they are the same (added for clarification) could have probably been made into a UDT instance, which then makes passing a root path to the UDT and doing indirects on popups and templates much easier and more robust.
Using tagpaths for UI re-use with indirect tag binding works whether the hierarchy is a UDT, same-named individual tags in folders, or some combination thereof.
If you have created an Ignition UDT to be used with a single instance, you've almost certainly screwed up. (Or wasted a bunch of engineering $$.)
Well of course, but UDTs can be expanded to hold more than just raw tags from the PLC. Mine has alarm routing, root alarm descriptions, device IDs, mouseover info, etc. Im a big proponent of UDTs on the CLX side, as I hate tag dictionaries with thousands of singlet tags. My CLX tag structures rarely generate tag lists over a few pages. And for me, much easier to create multiple instances of UDT types than replicating folder heirarchies.
)