The problem I want to discuss here comes up when you need to reference a user define data type (UDT) that is nested within another UDT, and has been passed into a template as a parameter.
I have a client who would like to use Rockwell Automation’s PlantPAx object library in a logix process automation controller (PAC), however, my client is also using Inductive Automation’s Ignition SCADA as the front end. If you are familiar at all with the PlantPAx object library, the add-on instructions have a hierarchical architecture. In our example, we will look at the P_Ain object. P_Ain is a basic analog input module in the PAC, and it contains other library objects such as: P_Alarm, P_Mode, and P_Gate. The hierarchy looks like:
On the SCADA, the main window will have an analog icon that when clicked will open a faceplate, which will have other templates for the HiHi alarm, which in turn will open the P_Alarm faceplate.
The user clicks the Analog input icon to open the analog input faceplate, while passing the Ain base tag. The Analog Input faceplate has a custom parameter of type P_Ain to receive the base tag. The user then clicks the Input Failure button to open the P_Alarm faceplate which passes the P_Alarm tag from the P_Ain parameter.
The problem is binding the P_Alarm tag (fail in this case) to the alarm button, to open the faceplate. When binding in Ignition, Ignition tries to pass the value of parameter to the object, so the fail item in the property hierarchy isn’t tag, but folder and becomes unbindable. It would be nice if Ignition recognized that the UDT was a tag with a value and just passed the reference, but it doesn’t, so a work-around is required.
The required work-around uses indirect addressing and custom properties within the base template. Place the analog input icon on the main screen as you normally would, and bind the analog input tag to the P_Alarm parameter of the icon template. So far so good, no problems yet.
On the analog faceplate template, create a new custom parameter of type string as shown below:
Custom properties configuration pop-up for the P_Ain faceplate template.
Next, bind the Fail property to the path of fail sub-tag of the P_Ain parameter of the faceplate using indirect addressing and the Meta.TagPath field of the P_Ain property shown below:
Select the expression radio button, and concat the TagPath of the P_Ain parameter passed by the icon with the name of the alarm. In this case “/Fail”.
Then bind the P_Alarm icon. I am using a simple button to the fail tag by addressing the tag indirectly using the string we just stored in the Fail custom property of the faceplate.
Select the Indirect Tag radio button. Then in the Indirect Tag Path click the property button and select the fail property.
This will pass the correct tag to the button as the correct tag type (P_Alarm).
Just repeat this process for each nested UDT of the Ain property and it will work like a charm.
You could skip creating the fail custom property that stores the tag path, and just concatenate the string directly in the button binding. However, if you need to reference that tag in several places in the faceplate, it is cleaner and more efficient to create a common property that stores the string in a one place, then re-use as necessary. If for some reason, later on you need to change that path, you would have to change the binding to that one property versus changing every place in the faceplate that uses it.
Jamie has left Hallam-ICS to pursue other endeavors. If you have questions about this article or other Ignition questions, contact Burton Preston. Burton is a Gold Certified Ignition developer.
Hallam-ICS is an engineering and automation company that designs MEP systems for facilities and plants, engineers control and automation solutions, and ensures safety and regulatory compliance through arc flash studies, commissioning, and validation. Our offices are located in Massachusetts, Connecticut, New York, Vermont and North Carolina and our projects take us world-wide.