[BUG-12053,12054,11580] Issues using parameters in data type instances

Issue #1

When modifying Parameters on a datatype instance by double clicking on the data type, then clicking on the edit parameters, then making a change, then clicking apply checkbox, then clicking apply, the parameters list shows the default values instead of the updated values.

Right-clicking on the data type instance, then selecting “Refresh Providers”, then expanding the parameters list, the parameters are refreshed correctly.

Also, after a while of having the parameters list open, the values revert to default.

Observations/Feature request:

  • reduce the amount of clicking required to edit parameters.
  • make it so that restarting a tag also refreshes that tag
  • make it so that refreshing providers does not collapse the entire list (since this requires a lot of clicking usually to get back to the point you were at when refreshing)

Issue #2 - Pre-defined parameters no longer work
In previous versions of Ignition, we could have bindings in a tag such as ns={Namespace};s={Path}.{InstanceName}.{TagName}. Now the {InstanceName} and {TagName} bindings show “null” and don’t evaluate.

Pre-defined parameters are listed as available on https://docs.inductiveautomation.com/display/DOC80/Creating+UDT+Definition

Issue #3
It appears like it should be possible to edit parameters from the Tag Browser (rather than double clicking on the data type instance and editing there), however this does not work for some parameters. The following error is in the console:

19:39:43.274 [AWT-EventQueue-0] ERROR com.inductiveautomation.ignition.designer.tags.util.TagUtilities - Error writing to Path.value: Error_Exception(“Cannot coerce value ‘test1’ into type: interface com.inductiveautomation.ignition.common.tags.model.TagPath”)

The name of the parameter I am using is “Path”, perhaps this name is reserved?

For issue 1, UDT Definitions in tag browser have a number of polish items that we are aware of. They will be prioritized based of perceived necessity.

For issue 2, a code change to fix this is being reviewed currently and a fix should be present in the next couple of days.

For issue 3, that name Path for a parameter is indeed causing the issue. I have created a new issue for this. Thanks for making us aware of it.

Garth

I updated to last nights build (actually I re-installed the gateway from scratch), and issues #1 and #2 seem to be resolved.

Thank you for the fast turn around!