I’m using one popup window with indirect tag bindings as a template for branch circuit power meters (not an actual Ignition template). Buttons on a floorplan window pass values to the popup in order to display the correct meter.
This approach was all fine and dandy until the customer requested specific configuration information be displayed for each meter (breaker layout, load type, load description, etc). This info, of course, is different for each meter.
I added individual configuration screens for each meter to the popup window. Only the configuration screen that corresponds to the meter whose button was pressed is made visible after the popup window is opened.
The problem is that all of the other configuration screens that aren’t visible are still binding when the popup window is opened. It now takes much much longer to open the popup window ( > 5s), which is not acceptable.
Is it possible to disable the components for the config screens that are not currently being displayed? Many other SCADAs/HMIs have an option to disable an entire group, but I can’t find something similar in Ignition.
Sounds like you need to encode the configuration info into a string (JSON, perhaps) that’s passed from the floor plan button, and decoded by the popup into a single configuration screen.
Each panel has up to 84 poles and every panel layout consists of different combinations of 1 pole, 2 pole and 3 pole breakers with several calculated values for each.
I’ve tested a situation where all invisible components are disabled and the delay still exists.
The delay must be caused by property binding.
Is it possible to disable property binding for certain groups until a condition is met?
[quote="justin.dally, post:3, topic:16260"]
Thanks but that is not a possibility.
[/quote]Heh. That sounds like a challenge. Unfortunately, I bill for those. (-:
I think your popup needs a template canvas object, and you'd supply the dataset to drive it from the floor layout button. You'd have a template for one, two, and three-pole breakers, and they would accept parameters for your computations. Template canvas objects are also scrollable, so you can accommodate future expansions.
Binding cannot be disabled on any normal component. Bindings within templates are created and destroyed as holder/repeater/canvas changes its template selection(s).
I would create power type templates for each type, then use a place holder on the popup to load the appropriate template as you need it.
The Popup screen has an area for information which is ‘global’ to all your power meters. On the popup you also have a template component. The template component on the popup is just a place older. The template path dynamically changes with the popup call. As the popup opens identify the Power Meter type either by a second parameter, or if you have formal tagpaths for each type you might be able to identify power meter type directly from the tagpath you pass to the popup.
Once you ID the power meter type, re-direct the temple component property ‘templatePath’ to the appropriate power meter type template. This achieves the same functionality of of your visibility bindings, while only calling what you need.
Make sure you are passing the tagpath as a string, and use indirection. Don’t pass the tag as a UDT.
A unique template for each power meter is a lot of extra work, and yields a difficult-to-maintain mess. With a template canvas, only an new button and dataset would be needed as new power panels are added, and only a dataset needs to be updated as the configuration of the panel meters is changed. In fact, there's no reason all the circuit breakers' displays couldn't be in a conveniently editable table in the database.