Process signal accumulator best practices?

Ignition
,
1

We are using Ignition 7.9.6 as our process historian for a water treatment plant. We also are exploring it for use in our Water Distribution system. There are many uses for accumulation calculations for the utility. Our legacy SCADA has built in functions for generating and resetting accumulations of signals such as flow, for this hour, last hour, this day, last day, this month, last month, etc. These are useful when doing demand calculations to manage water supply; since demand changes each day based on diurnal swings, each season, and also with weather. Better demand calculations result in better process information which means better decision making at the treatment facility and for distribution storage management.

Ignition does not have any ‘out of the box’ accumulation functions (e.g. integration, or ‘area under the curve’ with respect to time) which may be employed for this purpose. There ARE tag events which access currentvalue, previousvalue, etc. which could be modified to generate some type of accumulation calculation; there are also HOUR METER and EVENT METER in transaction groups, which provide a similar but not identical function to accumulation. I can also imagine using a gateway script, probably a timer, to accomplish this.

I would like to be able to create something like a subroutine or template so that I can develop the logic once, and apply it to multiple instances of tags. For this purpose pairing the logic with a UDT may be desirable to enforce structure, data typing etc. In addition to being able to accumulate over differing time frames such as hour, day, month, the implication is that there must also be an associated reset to the total for each of the various time frames.

This needs to be something that can be developed by a process control technician, but not necessarily an SQL expert. It also must be manageable over a long lifespan, and fairly easy to troubleshoot - the output should be easy to get to, think logging and where does it go?

Since there are so many options, I am very unsure of how best to proceed. I don’t want to spend a lot of time developing something that either already exists, or may be better accomplished in another way.

Does anyone else have experience developing and implementing accumulator functions to create values logged to either database tags or memory tags? The accumulated values would be referenced in charts that show today’s process vs. yesterday’s process, or even todays vs. any day in the past? I’d appreciate your input on what you have learned and how best to implement this.

regards,
Paul

2

I’ve done the sort of thing you’re talking about in the past… I think. I don’t fully understand the question.

Do you just have continuous flow, or do you have have a flow totalizer too?

If you only have continuous flow, and are wanting to calculate calculating the total based on the flow rate over time… well I got a B in Precalc. I know there’s a way to do that sort of thing I just don’t know the math behind it. If somebody can link the relevant formula stuff I can tell you how to implement this.

If you have a totalizer available and you just want to track the usage over time. Just make a memory tag to hold the previous value of the totalizer and have a transaction group subtract current from previous to get your usage for desired timeframe. You’ll obviously have to make a SQL table on your own to do this… you could also do a tag change script on a memory tag to use the taghistorian write but that’s a bit whack.

1 Like
3

SillyBear - thank you for your input. The signal we have available is a flow signal, in gpm. I’d like to accumulate flow into a tag with engineering units of gallons. I have found a way to do this on a tag (actually a UDT) where the code resides in the UDT and requires nothing other than configuring and OPC tag as the input. However, I am concerned that the event for the calculation is OPC tag value change; and there may be circumstances (frozen transmitter, manual set transmitter, or manual set input value) that don’t result in a signal change hence the ‘valuechange’ event will not trigger the tag script. So I have looking for another method, or a guarantee that the event will always trigger the script. hmm.

4

I think in that case you’ll want to use transaction groups to catch the edge cases and trigger a script execution or log the data on a timer.

5

I talked with tech support about this yesterday. I ended up with an expression tag member of the UDT that updates on the scanclass timing (think ‘now()’ as a datetime). Then I configured the accumulation script as a change value event on the expression tag. This is working really well.

The next thing I want to add is a user configurable timebase, so that one accumulator UDT serves for units/min, units,day, etc. I would like an enumerated drop down (as I have used in Siemens PCS 7) however I don’t see how to do this just yet. Any thoughts from forum members on that are appreciated.