Thursday, December 12, 2013

How To Filter Alarms on Static Associated Data

First of all, I want to say sorry for neglecting the blog since January. Starting this week, I want to post a new blog entry once a week. So stay tuned for new and exciting tips and tricks for Ignition.

For this post, I want to show how you can filter alarms on the alarm status component, alarm journal component, and in alarm notification pipelines through the use of static associated data.

Ignition 7.6 introduced a host of new alarming features; one such feature is the ability to add "Associated Data" to an alarm configuration. Associated data are custom alarm properties that can be added to any alarm. The values can either be static or dynamic. Dynamic properties will often be bound to other tags that represent associated contextual data that may be related to the alarm. Either way, a snapshot of the values of these properties will be taken when the alarm becomes active. These values will be attached to the alarm event as it moves through the rest of the alarming system, meaning that the values will be available from the alarm status system, the alarm journal system, and in the alarm notification system.

Let's assume you already have a couple of alarms configured. It's easy to go back to the alarms and add associated data. Edit one of your alarm tags and go to the alarm configuration area. Select one of the alarms. Of course you will see all of the alarm properties that you have previously configured. Those properties come with every single alarm. We can add our own properties called "Associated Data."

To add associated data simple click on the green plus icon right above the alarm properties (in the top right).

That will add a new property at the bottom of the list. By default the property will be called "New Data."

To rename the property simple double click on the name and type in a new one. Let's call the property "Group." At this point, we can either type in a static value for the property or make it dynamic by linking it to another tag or an expression. Dynamic associated data is important to snapshot other tag values along with the alarm. That way you can go back in time and see what the temperature of the room was or what happened upstream or downstream when the alarm occurred. If we simply just type in a static value than it will never change, allowing us to use it in filtering.

Go ahead and set the value of the property for the first tag to "Group A" and press OK to save. Do the same thing for other alarm we have configured and set the property to "Group B."

If your tag has more than one alarm configuration make sure you add the associated data to each one. Every alarm configuration can have a different set of values.

At this moment we have 2 alarm tags with one tag set to "Group A" and other tag set to "Group B." Let's look at how we can filter for a particular group on the alarm status component. 

Drag the alarm status component onto a window. You will notice it shows every single alarm that is active right now. So both of our alarms are showing up.

To add the filter, right click on the component and select "Scripting." On the left hand side you will see the component's "Extension Functions." Extension functions allow you to hook into the component providing a way to override/implement parts of the functionality of the component. There is an extension function on the alarm status component called "filterAlarm" which allows you to filter the alarms any way you want through the use of scripting. Go ahead and select the filterAlarm extension function.

Set the "Enabled" checkbox to true and the script will become active. The filterAlarm function will get called for every single alarm that would normally show up in the component. You will return True if you want the alarm to show up and False if you don't. The alarms that would "normally" show up are based on the filters you can put on the alarm status component, such as minimum priority or alarm state (active and unacked, active and acked, clear and unacked, clear and acked). Typically you would allow the component to bring back everything and you would filter them out in the filterAlarm extension function.

The filterAlarm extension function automatically gives you a variable called alarmEvent, which has a function called get to retrieve any property of the alarm such as the name, source, priority, or our associated data. So, if we only want to show alarms for "Group A" we can put in the following script:

group = alarmEvent.get("Group")
if group == "Group A":
return True
return False

Now we only see one alarm.

Typically you won't hardcode the group name in the script. Usually it comes from a property on the window like a drop down list or value passed into the window. If you want to grab a value from the screen you can use the self variable just like the event.source variable in event handlers. The example below gets a value passed into the window on the root container:

group = alarmEvent.get("Group")
groupName = self.parent.groupName
if group == groupName:
return True
return False

Notice the second line that goes to the parent (root container) and grabs the groupName property. We than use that variable in the if statement.

If you want to filter on the alarm journal component, it is exactly the same as the alarm status component. The alarm journal component also has the filterAlarm extension function. 

Lastly, I want to show how you could use the associated data in an alarm notification pipeline. That way you can do something different for each group like notifying a different list of people.

Go ahead and add a new alarm pipeline in the designer. First drag in the "Switch" block into the pipeline. The switch block is very similar to the expression block, except that the result of the expression does not need to be a boolean. Instead, it can be a number or string, and it will be looked up against the defined list of expected results. If a match is found, the alarm will follow that path, otherwise the "catch all" output will be used. You can simply set the expression to:


Below the expression, add two values to the list: one for "Group A" and one for "Group B."

Now you have two paths on the block that can do different logic if the alarm is in "Group A" or "Group B." Here is a pipeline that will send out an email to two different lists based on the group (the pipeline will do nothing if the alarm doesn't have a group):

I hope this gives you a good idea of how to use associated data on alarms. They are extremely powerful and they add a lot of flexibility to the alarming system.

Tuesday, January 29, 2013

Dynamically add SQLTags from Ignition Client

I am finding more and more customers that want to create completely templated projects in Ignition where the configuration comes from a SQL database. They usually want to allow the customer to make configuration changes in the client. In order to achieve that, you need a way to dynamically add/edit/delete devices and tags. Ignition doesn't give you functions to do that out of the box.

Now you can! I have written a special module that exposes scripting functions to manipulate database connections, devices, and tags. It is called the "IA Labs Scripting Module." It is a 100% free module that you can download and try out today.

Simply click on the link below to download the module. You can install it in the Ignition Gateway configuration page under Configuration > Modules.

IA Labs Scripting-module_1.1.0.modl

Right now the only documentation for the module is on our online forum located here:

It lists out all of the functions and how to use them. Here is a list of the functions:

Database Functions

Device Functions
system.device.refreshBrowse - Only for AB controllers

Tag Functions

The most popular function is the system.tag.addTag function that adds new SQLTags to Ignition. I get a lot of questions on how to use the function so I thought it would be best to post a few examples.

The first example is very basic, how to add an OPC tag:

system.tag.addTag(parentPath="Folder", name="TagName", tagType="OPC", dataType="Int4", attributes={"OPCServer":"Ignition OPC-UA", "OPCItemPath":"[DeviceName]N7:0"})

Most of the parameters are self explanatory except for the attributes. The attributes is a dictionary of key/value pairs for all the configuration items on a tag. All of the possible attributes are listed in the forum (use the link above). Let's say that I want to add the same tag but store history on the tag as well, the function would look like this:

system.tag.addTag(parentPath="Folder", name="TagName", tagType="OPC", dataType="Int4", attributes={"OPCServer":"Ignition OPC-UA", "OPCItemPath":"[DeviceName]N7:0", "HistoryEnabled":1, "HistoricalScanclass " : "Default"})

You can see two new attributes have been added, HistoryEnabled and HistoricalScanClass. Not only can you add an OPC tag but you can also add a UDT instance:

system.tag.addTag(parentPath="Folder", name="UDTInstanceName", tagType="UDT_INST", attributes={"UDTParentType":"NameOfUDT"}, parameters={"ParamName":"ParamValue"})

That will add a new UDT instance of the UDT named "NameOfUDT". Since UDTs have parameters that must be filled out you can specify another argument called parameters that is also a dictionary of key/value pairs. My UDT had a property called "ParamName" and I set it to the value "ParamValue." 

Next, let's show how to add a tag with an alarm. We just need to specify all of the alarm properties as attributes, like this:

system.tag.addTag(parentPath="", name="N7_0", tagType="OPC", dataType="Int4", attributes={"OPCServer":"Ignition OPC-UA Server", "OPCItemPath":"[MLX]N7:0", "AlertMode":1, "AlertDisplayPath":"Machine A", "AlertNotes":"Notes for the alert", "AlertAckMode":2}, alarmList="Out of Range;Medium;1.0;1.0;0;;;0.0;SEC$")

The only tricky part is coming up with the alarmList attribute value. If you export a tag in the Ignition designer to a CSV file you will see the "AlarmStates" column. You can copy and paste the alarm states value to the addTag function.

Lastly, let's add an expression tag:

system.tag.addTag(parentPath="Folder", name="ExpressionTagName", tagType="DB", dataType="Int4", attributes={"ExpressionType":1, "Expression":"{Path/To/SomeTag} * {Path/To/AnotherTag}"})

The tag is a DB type with two attributes, ExpressionType and Expression. 

There are many other functions you can play around with in this module. I hope to add new functions soon to manipulate OPC servers and transaction groups dynamically. 

If you have any questions or feedback on the module, feel free to post to our online forum.

Wednesday, January 2, 2013

Ignition Designer: Dependencies and Spotlights

Ignition's designer has a lot of features that can make designing new projects easier. Two such features are dependencies and spotlights. We don't really talk about these features in the documentation so I guess you can call them hidden features or gems.

Designer Dependencies

When you are designing screens in Ignition you are constantly linking (binding) properties to tags and other properties on the same window. Each time you bind a property to something else you are setting up a dependency.

Let's look at a small example. Add a tank component and a slider component to a window. Bind the tank's value property to the slider's value property through a "Property" binding. By doing that, the tank is now dependent on the slider. If you try to delete the slider component Ignition won't let you saying "Cannot Delete. Non-Selected component Root Container.Cylindrical Tank depends on selected component Root Container.Slider."

People always ask, "Is there a way I can see who is linked to who?" Yes, the designer has a built-in feature to show all of the dependencies. Just simply click on View > Dependencies > Show All from the file menu in the designer. It will draw arrows from components to other components to illustrate such dependencies.

The direction of the arrow is important. In our example above, the arrow is drawn from the slider to the tank. The arrow shows how data flows. When the slider changes the tank will update. So, if the arrow is going away from the component it means those components are linked to it.

This is an extremely important feature when designing templates or indirect popup windows. Components inside of templates are always linked in some way to the template parameters. That way the template can dynamically change. With indirect popup windows you pass in a value that is used in all of the component property bindings.

In both cases, if you turn on the dependencies you can easily see if one of the components is not linked to the template parameter or the value passed in. If you don't see line drawn to the center something may be wrong.

Pressure label doesn't have an arrow because it is not bound
using the template parameter. In this case that is expected.


Designer Spotlights

Spotlights are another great feature of the designer. Spotlights allow you to see invisible components, components that have bindings, and components that have scripting on the window by painting a box around the component.

There are a lot of situations where you will have invisible components in the designer. It can be challenging to figure out if there are any and where they are. If you turn on the invisible spotlight, it is easy to pinpoint where they are. Click on View > Spotlights > Invisible to turn the spotlight on. The image below shows that there are two components invisible (the purple outline) in this window.

The binding and scripting spotlights are the same idea but show which components have binding or scripting configured.

If you turn on both features dependencies and spotlights, you will get a good idea of how a window is configured.