Historian for SNAP PAC

[gchase]

Sorry I’m late to the party, I was out of the office this week, I am happy to discuss this also… I guess you can call me grant2

Our approach is similar to what @grant1 has described however, we do have many SNAP PAC’s in our system(s) as well as PLCs from other manufacturers.

We also use InfluxDB and Grafana as our data visualization stack running on Ubuntu server. We use two methods to move data to InfluxDB; Node-Red via the InfluxDB node as grant1 has described and MQTT via Ignition Edge using the Cirrus link driver and MQTT transmission to Telegraf, which ingests data to InfluxDB.

We use the EPIC as a data collection gateway in both instances.

Both of theses methods are reliable and both have advantages and disadvantages which I will attempt to outline.

Using Node-Red:

(Our approach is nearly identical to grant1’s but I will elaborate on some of nuances)

1. For each PAC control strategy a series of PAC Control nodes, one for each data type: int32, float, etc., reads ALL the tags of that type in a batch.
   ↓
2. The batch data can be parsed and manipulated at this point to adjust and tag names or add data fields for InfluxDB (more on that later).
   ↓
3. Batch write to the database using the InfluxDB node.

Advantages:

1. Small foot print
2. Few dependencies
3. If your tag names are consistent, I hope they are, and your batch is set up correctly then it can be very scalable and a new tag if added to the PAC Control Strategy will be added to the batch read and write to the database so, the new data point is added to the historian automatically.

Disadvantages:

1. If your tag names are not consistent then there will be lots of “hand”manipulation of tag names for each case.
2. Depending on your network topology true 1 sec resolution my not be possible due to the many layers of communication inherent with HTTP/HTTPS and REST API. But you can get pretty close…… Our system has a few wireless control points that need more time due to network latency.
3. Care must taken with polling a SNAP controller too fast as it will become impacted and begin timing-out your requests. Because each data type must be called one at a time it may be 3 to 5 seconds before you can call all the floats again. (For more info on deployment practices see this post on Optimizing Node-red)

Using Ignition Edge, Cirrus Link, MQTT and Telegraf:

(Ignition is a extremely powerful platform. I want to preface this by saying that this is a very different way to use Ignition Edge as I am using it essentially “headless” with no HMI and this use case was originally employed due to our need to get data from non-Opto PLC’s)

1. Using Ignition Edge and the Cirrus link diver for SNAP controllers tags are added to a designated MQTT transmission folder with in the Ignition designer. Cirrus Link MQTT transmission publishes tags to the MQTT broker using the Sparkplugb protocol.
   ↓
2. The Telegraf configuration subscribes to MQTT topics filtering them using the desired Sparkplugb topic namespace and wildcards, decodes the google protocol buffers, formats the namespace for value tags and fields, captures the value and passes it on to Influxdb.

Advantages:

1. The Cirrus Link Divers, I believe @beno correct me if i am wrong, use a different method to communicate with the SNAP controllers. It’s faster than REST so 1 sec resolution is more attainable.
2. Using Ignition’s extensive driver library, you can connect to most an PLC.

Disadvantages:

1. More dependencies than the Node-Red method.
2. Debugging Telegraf is much more difficult, can be downright painful.
3. Lots of set up to only use a small part of Ignition edge’s capabilities.

Grafana OSS

Now that the data is in the database we use Grafana Dashboards for all operations staff.
I completely agree with grant1’s statement below.

@grant1

Nobody but me goes into InfluxDB. That’s just the database that nobody needs to look at. Everyone (even low tech people) uses Grafana and finds it easy and intuitive using the time selector. It’s easy to build different dashboards, charts, etc. for different needs.

@edom to answer a few of your questions:

@edom

It’s important that the graphing software is fast and allows navigation between different dates and zoom levels without delay, even when handling large amounts of data.

Grafana is also a very powerful tool, 1 sec resolution works great up to a certain time window but…. if you try to look at 1 years worth of data @ 1 sec resolution even the most powerful tools can falter. To give operators control without having to know how to write a query we use what they, Grafanistas, call dashboard variables to make query’s more dynamic. We have a data resolution drop down on each dashboard that allows operations to adjust the interval from 1 sec all the way to one hour if needed. Then you can use the mouse to select a portion of the graph to zoom in, then you increase the resolution.

@edom

Another requirement is the ability to export portions of the data to Excel for further analysis.

This is a native feature in Grafana. Once you have the time window selected you can export individual graph panels as .csv with excel headers.

@edom

I understand that, of all the solutions we’ve been considering, Ignition is the most comprehensive, and given that we have the budget to implement it, perhaps it would be best to focus the implementation effort on that option? Are there any drawbacks to choosing Ignition over other alternatives, aside from the higher cost?

Ignition is an amazing product, and yes very comprehensive for the industrial control space. However if you are not planning on using all the tools ignition has to offer, HMI, Alarming, Reporting, etc., I would suggest getting an EPIC, PR2 to give you the firepower to handle the 1000 tags you want, and a Linux server to run InfluxDB and Grafana. Ignition has a stepper learning curve compared to Grafana when building dashboards for data analytics.

In regards to InfluxDB, grant1 is spot on!

@grant1

The key is to very carefully plan out your fields and tags. This video is ~8 years old, but I still found it valuable to help plan out everything.

This is essential as it will dictate how you retrieve your data.

That’s plenty to chew on for now so I’m going to stop here.