# Best Approach for High-Volume Flow Meter Calculations and Alarming in Ignition **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [December 20, 2024, 11:25am UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092 "2024-12-20T11:25:02Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [December 20, 2024, 11:25am UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/1 "2024-12-20T11:25:02Z")
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! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 20, 2024, 1:34pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/2 "2024-12-20T13:34:26Z")
Definitely #2. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [December 20, 2024, 3:29pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/3 "2024-12-20T15:29:04Z")
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. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [December 20, 2024, 3:34pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/4 "2024-12-20T15:34:42Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 20, 2024, 3:38pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/5 "2024-12-20T15:38:25Z")
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.) ---
**Author:** ![Giuseppe\_Giammo](https://avatars.discourse-cdn.com/v4/letter/g/5f9b8f/32.png) [@Giuseppe\_Giammo](https://forum.inductiveautomation.com/u/Giuseppe_Giammo)\ **Post date:** [December 20, 2024, 5:24pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/6 "2024-12-20T17:24:21Z")
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 ? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [December 20, 2024, 5:30pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/7 "2024-12-20T17:30:39Z")
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. ---
**Author:** ![Willem\_Ver\_Eecke](https://avatars.discourse-cdn.com/v4/letter/w/a4c791/32.png) [@Willem\_Ver\_Eecke](https://forum.inductiveautomation.com/u/Willem_Ver_Eecke)\ **Post date:** [December 20, 2024, 5:37pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/8 "2024-12-20T17:37:44Z")
How would you deal with the fact that the totallisers reset every period (e.g. every week)? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [December 20, 2024, 5:41pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/9 "2024-12-20T17:41:41Z")
> [@Willem\_Ver\_Eecke](#): > > the totallisers reset Don't let them reset. Let them roll over at a known value, like an odometer. Any intermediate reset loses information. ---
**Author:** ![Chris\_Bingham](https://avatars.discourse-cdn.com/v4/letter/c/e5b9ba/32.png) [@Chris\_Bingham](https://forum.inductiveautomation.com/u/Chris_Bingham)\ **Post date:** [December 21, 2024, 6:09am UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/11 "2024-12-21T06:09:27Z")
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. ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [December 21, 2024, 3:51pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/12 "2024-12-21T15:51:33Z")
Man I love this community, thank you all for you valuable input! ❤ I'll definitely respond, but first some family time these weeks 🙂. ---
**Author:** ![ReyC](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/reyc/32/49461_2.png) [@ReyC](https://forum.inductiveautomation.com/u/ReyC)\ **Post date:** [January 2, 2025, 7:53am UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/13 "2025-01-02T07:53:48Z")
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 > **[Tag Data Types | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/platform/tags/tag-data-types)** > > This page details the different data types that can be applied to standard tags. 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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 2, 2025, 1:19pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/14 "2025-01-02T13:19:28Z")
> [@ReyC](#): > > 64 bit INT max value is 2147483648 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. ---
**Author:** ![ReyC](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/reyc/32/49461_2.png) [@ReyC](https://forum.inductiveautomation.com/u/ReyC)\ **Post date:** [January 2, 2025, 1:35pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/15 "2025-01-02T13:35:20Z")
> [@pturmel](#): > > > [@ReyC](#): > > > > 64 bit INT max value is 2147483648 > > 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 : ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/0/50d51cf6f54820320ce8d849878d8c42e92cf2e5.png) What do you mean by rollover? If I understood correctly, I assume that within ignition is INT and not UINTvalue ? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [January 2, 2025, 1:37pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/16 "2025-01-02T13:37:56Z")
> [@ReyC](#): > > INT4= 4x8=64 ? 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. ---
**Author:** ![ReyC](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/reyc/32/49461_2.png) [@ReyC](https://forum.inductiveautomation.com/u/ReyC)\ **Post date:** [January 2, 2025, 1:52pm UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/17 "2025-01-02T13:52:44Z")
> [@Kevin.Herron](#): > > > [@ReyC](#): > > > > INT4= 4x8=64 ? > > Well, you are on the right track, but 4x8=32. Yes thanks. (I notice that I'm not starting the new year quite in the right way. 😏) ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [January 6, 2025, 8:08am UTC](https://forum.inductiveautomation.com/t/best-approach-for-high-volume-flow-meter-calculations-and-alarming-in-ignition/100092/18 "2025-01-06T08:08:21Z")
Thanks for all the input guys. We will evaluate if we can use internal totallisers, and alternatively use the gateway timers.