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
Using a runScript expression on the flow meter tags
Embed the calculation logic in an expression using runScript.
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.
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
Which approach would you recommend for this scenario?
Are there any best practices for handling such computationally heavy tasks in Ignition?
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!
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.
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.
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.)
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.
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.
.
)