Best Approach for High-Volume Flow Meter Calculations and Alarming in Ignition

Hi all,

We’re working on a quite large-scale project and need some guidance on the best approach to handle a computationally intensive task in Ignition. Here are the details of our setup and requirements:

  • Setup: Over 200,000 tags and 500 flow meters.
  • Using InfluxDB for tag history. (So calculating the volume over the past hour is handled here)
  • Requirement: Calculate the volume from each flow meter for the past hour and store the result in a tag.
    • The calculation needs to run every 5 minutes.
    • We want to do alarming based on this calculated value.
  • Concerns: Given the scale of the operation, we are concerned about the performance impact and want to ensure we choose the most efficient solution.

Potential Approaches We’re Considering

  1. Using a runScript expression on the flow meter tags
  • Embed the calculation logic in an expression using runScript.
  1. Using a Timer Script on the Gateway
  • Create a gateway timer script to iterate through the flow meters and perform the calculations.
  • Publish the results to corresponding tags for alarming.
  1. Offloading the Calculation to an External System
  • Perform the calculations outside of Ignition, possibly using a custom application or script.
  • Publish the results back into Ignition via MQTT.

Questions

  1. Which approach would you recommend for this scenario?
  2. Are there any best practices for handling such computationally heavy tasks in Ignition?
  3. If using external calculations, are there any specific tips or challenges when integrating MQTT for this purpose?

We’re especially curious about how others have approached similar large-scale, tag-intensive operations in Ignition. Any advice, including alternative strategies, would be greatly appreciated!

1 Like

Definitely #2.

2 Likes

Yeah, #2 sounds reasonable as long as all the calculations for all the meters can finish under 5 minutes. I guess the other thing to be concerned about is what this does to your gateway CPU usage, though it should only be 1 core if this is CPU intensive.

1 Like

Do the flowmeters already have a totalizer built-in that you're reading? If so, this could be very simple and just subtract the 5 minute ago value from the current value, and store the current value into the 5 minute ago tag.

3 Likes

BTW, is there are reason you aren't using your flowmeters' own totalizing functionality? (Flowmeters for serious use have that.) It is much more reliable and precise than using history calculations.

Record the "Odometer-style" totals in a 5-minute scheduled event script. Then query the values recorded an hour before to compute the one-hour values for the "live" tags. Much less computationally intensive. (Win for reliability, precision, and performance. It would be a slam dunk for me.)

3 Likes

How would you reference the prior 5min read of the totalizer... I am curious as it could solve a problem for me in calculating usage in general within a time frame
do u have to store in an array ?

As @pturmel mentioned, you could store this in a database, but if that's not an option, you could add a memory tag to your UDT that's just named "PreviousTotal" or something like that to store the current value in every time you do your 5 minute update.

How would you deal with the fact that the totallisers reset every period (e.g. every week)?

Don't let them reset. Let them roll over at a known value, like an odometer. Any intermediate reset loses information.

5 Likes

Fun problem! I agree with others above. With some assumptions made, I would:

  • Read & store the 'lifetime accumulated volume' from the meter (if using Historian, set reasonable values for Max Time between samples, etc).
  • Never (rarely) reset the totalizer in the meter, reset the calculated 'Hourly/Daily/Weekly Accum' values (by changing which values in time you're referencing). Handle a negative accum for those rare cases of meter reset.
  • In addition to options above, another might be (#3) to let the Historian calculate your period accums. For example: 'previous hour average rate' by (change in value)/(change in time) - where timestamps are from 1)most recent value, 2)value nearest to one hour prior.
1 Like

Man I love this community, thank you all for you valuable input! :heart:

I'll definitely respond, but first some family time these weeks :slight_smile:.

Nice project.

I would suggest you paying attention with overflow according to datatype you choose for totalizer datapoint type.

16 bit INT max value is 32767
64 bit INT max value is 2147483648 (edit)
32 bit INT max value is 2147483648

Then in your Ignition template you may calculate statistics with some kind of round robin array with scripts (as memory datapoint)

  • HourlyVolume array [0..12] (array index = current minute/6) (every 5 minute)
  • DailyVolume array[0..23] (array index = current hour)
  • WeeklyVolume array [1..7] (array index = current day of week)
  • MontlyVolume array [1..31] (array index = current day of month)
  • YearlyVolume array [1..12] (array index = month)

Then display it with some kind of vertical bare chart for situational awarness.

I think you mean 32 bit. 64 bit max is much larger. If one uses full 32 bit rollover (to max negative), the full range is > 4 billion.

Yes, I mean 32 bits. Sorry.

But, I think it is not clear how many bit are used by ignition related to INT1 to INT8.

I guess INT1 = 1x8 bit and INT8= 8x8=64 ?

As an exemple, we may expect someting like that :

What do you mean by rollover? If I understood correctly, I assume that within ignition is INT and not UINTvalue ?

Well, you are on the right track, but 4x8=32.

The numeral in INT1, INT2, INT4, INT8 are a reference to the number of bytes.

2 Likes

Yes thanks. (I notice that I'm not starting the new year quite in the right way. :smirk:)

Thanks for all the input guys.
We will evaluate if we can use internal totallisers, and alternatively use the gateway timers.