Dynamic Bidirectional Property Binding

Ignition
1

Hi all,

I'm building a dashboard composed of multiple "modules," each with its own settings and parameters. Some of these parameters share common names, such as xRunning and ModeHMI. To manage these efficiently, I've used embedded views and passed the necessary props from parent to child where applicable.

To avoid manually adding every prop for every module, I created a module template and duplicated it for each module. My goal is to dynamically add the common properties.

Currently, I’m using an expression statement with the property() method, combined with a custom property on the module's view that specifies the module name. For example:

property("view.params."+{view.custom.module_name}+".ModeHMI")

The reason for why {view.custom.module_name} is necessary is because the params of each module/view are wrapped as a JSON object as this makes it MUCH easier to manage the params. e.g. where module_name = AnodeControl

AnodeControl {
  "ModeHMI": 0,
  "xRunHMI": 0,
  "xRunning": 0,
 }

This works well for displaying information in labels, but I also need to enable bidirectional binding to write back to the parameters. Directly using tags isn’t an option, as the tags are further up the embedded view chain.

Does anyone know if this kind of functionality is achievable?

Thank you!

2

Dynamically accessing properties via property() is fundamentally uni-directional. Consider just not including the module name in the embedded view's custom props.

Also, if anything needs to be bidirectional with tags, you should be passing tag path string properties to your views.

Meanwhile, "modules" is a terrible name. It is already applied to two major technologies in Ignition, using it is just going to exacerbate the confusion. Consider "block" or "assembly" or something else unique.

1 Like
3

Thank you, this has led me down the right path.

For anyone curious or stuck in the same situation, what I ended up doing was to add an expression to a custom property tag_path which created a tag path based on the bay_number passed down from the parent view.

image
image1738×825 49.8 KB

I could then use indirect tag bindings on my Perspective Components.

image
image1718×820 53.4 KB

As for the naming, unfortunately we've ran the idea of Functional Modules everywhere in our control systems architecture long before we started work on the HMI. Each Perspective HMI module maps to a hardware Functional Module, so changing it would be inconsistent and confusing.

4

I think fmod would be a reasonable disambiguation for your use case, in place of module.

1 Like