Exploring methods for project: Alarm Journaling, Transaction Groups, Tag Change Scripts

Ignition
1

Project Goal

Log the timestamp, tag name and tag value when tag value alternates between 0 and 1 to our SQL database. We are estimating total 40,000 tags (80 machines and each machine has 500 tags). The methods we are aware of for consideration are Alarm Journaling, Transaction Groups, Tag Change Scripts. Any other suggestions and how do they compare with these three methods?

Tags and Structure

image
image581Ă—481 113 KB

In our plant, we have 80 machines, each with 500 tags connected to our server. The above picture shows an example machine called Inline 225. We created 2 folders – Alarm Names (to hold the name of the alarm or tag) and Alarms (to hold the value of the alarm or tag). For example – one of the tags is called Bottom Guide is Missing. The name of this tag is “Bottom Guide is Missing”. The value of this tag is either 0 or 1. We want to log to SQL only when the value changes. Similarly, you can see other tags such as Coin Feed Not in, Coin Feed not out, etc. So we will be having 500 such tags for the machine Inline 225. Most of these tags will have default value 0. At any time, the most tags that will have value 1 will be 5 to 10.

We want the below end result. All the 40,000 tags will go into 1 SQL table with the values as shown.

image
image778Ă—297 81 KB

We did few of the tags manually as detailed below.

We first created tags manually in ignition tag browser. Below is the OPC tag to hold the value

image
image1038Ă—567 134 KB

For the same above OPC tag we also created a memory tag to hold the name of the tag.

Then we added both the above 2 tags in 1 transaction group along with Line_name (which is another memory tag to represent the machine name). See below picture

image
image1125Ă—573 147 KB

Our question is how to do the above task more efficiently. Based on our research we think we need to follow the below steps, but we want to confirm if this is the best approach.

Creating Tags

  • We will create a JSON file with tag structure
  • Then import the JSON file into the tag browser.

Creating Transactions Groups

  • We will export an example transaction group (that we created manually before) using the Shift key and Legacy Export to provide the structure for the next step

image
image670Ă—507 79.9 KB

  • We will update the exported XML file
  • We will then import back into Ignition transaction groups.

So, with the above approach we will end up with 40,000 tags and 40,000 transaction groups. The good thing is all data is logged into 1 SQL table, so it is easier for us to do subsequent data analytics.

Question

Is there anything that hasn’t been mentioned for consideration above, in regards to the best method for this project?

2

Why not Use UDT's instead of singular tags?

I would explore Gateway Tag Change Scripts. It is possible to write a generic script which would result in your example output. This would remove the need of 40K separate project resources, to perhaps just a few resources.

1 Like
3

Sounds like a proper job for the standard historian. Set each to on-change, deadband style "Discrete", and a zero minimum time between changes.

When retrieving, always use "As Stored" and "Tall" return format.

1 Like
4

Will the UDTs work if the tag name is slightly different between the lines. For example - if I take tag# 1. It could be called as “Bottom Guide is Missing” for line 1 but it could be called as “Bottom Guide missing” on line 2 and may be called “Missing Bottom guide” on line 3 and so on. But they all mean the same for tag # 1 . Similarly we have tag# 2 that may be called “Coin feed not in” on machine 1 but called as “coin feed in not” on machine 2 and so on. So will UDTs work with these slightly different names of the tags?Also "Could you please elaborate further on the Gateway Tag Change Scripts? any documentation reference on that?

5

I think you are confusing PLC Tags and Ignition Tags, while similar they are not the same.

Ignition tags that need to connect to devices generally use OPC Tags, which means that you give them a device specific address. So in that since UDT's can be made to work with "slightly different tag names between lines".

It "can be made to work" with slightly different Ignition tag names, but that would mean not using UDT's.

The one of the biggest advantages of UDT's is that it standardizes and organizes the tag names, but do not get caught in the trap that UDT's in Ignition have to match the names or structure of device UDT's. A tag organizational scheme that makes since for the PLC/Device may not be as useful in the SCADA system. UDTs in Ignition can include tags that don't even exist in the device, or not include tags that do exist in the device.

You can read about Gateway Tag Change Scripts in the manual:

The advantage here is you can have multiple tag changes which trigger the same script. As long as the script is written in a way that is generic enough for each of the tags then you have a single script to manage.

Tag Value Change Scripts (on the specific tag) are not suitable for long running tasks, including database operations.

1 Like