Analog Totalizing 101: calculating watt-hours example


#1

[B]Measuring values over time - let the “brain” do the math![/B]

In [U]this OptoForum post[/U] we looked at digital totalizing, where we let the brain do the math to measure the On Time of a pump.

But recently I got a “programming” question from a PAC/[I]groov[/I] user measuring watts from a small solar system, who wanted to know wh (watt-hours). In particular, he wanted to know how much power his solar panels generated in a day.

In the picture below, notice the yellow line; and also the totalized value on the left. This is a 2-day trend, so the previous day’s data is in the middle there, and you see a break in the yellow line off to the right when he downloaded his revised strategy halfway through the day.

The total value he needed was essentially the area under that yellow curve. (The “integrated” value.)

While we [I]could [/I][U]write some code[/U] to add up values and whatnot (yay! [URL=“https://en.wikipedia.org/wiki/Integral#Interpretations_of_the_integral”]calculus! fun!); I’m generally lazy err… I mean efficient… and prefer to use the right tool for the job.

In this case, the value he wanted to “totalize” was coming from an analog input - a SNAP-AIPM power module. It just so happens, in addition to the digital On-Time Totalizing function, our super-smart I/O Units (aka “brains” for good reason) also have an analog totalizing function built in. No code calculations needed!

Use this built-in brain feature via PAC Control with just a few simple commands: one to set the “rate” (on PAC brains, this is essentially the [I]units[/I] you want – the analog scanner on the brain updates the total as fast as possible for you, to get the best accuracy possible); and one or two more commands to either just read or read & clear the current total.

[B]First[/B]: The PAC Control command Set Analog Totalizer Rate requires units of seconds. We only need to call this command once to start the totalizing, with the correct units. In the solar power example, he needed to know watt [I]hours[/I]. So, in this case, he set the “rate” to 3600 seconds or one hour. If you wanted to know gallons per [I]minute[/I] (and your analog input was scaled for gallons), the rate would be 60 seconds. Widgets per second, the rate would be 1.0 and so on.

[B]Next[/B]: In a loop (with a delay, of course), use the command Get Analog Totalizer Value to “watch” the number grow. In this case, once a second was enough to just watch it change in that groov page pictured above.

[B]Eventually[/B], we need to use Get & Clear Analog Totalizer Value before it maxes out and can’t totalize anymore. For this application, I recommended doing this once a day (so that number on the left would be a daily total), for example, after the sun has set. He already had some code checking and clearing other values when the day rolled over, so that’s a perfect place for the Get & Clear.

[B]WARNING[/B]: Before adding this new daily total to, say, a monthly total, do a sanity check. Since we’re totalizing an analog input, it’s possible for that value to become invalid: for example, you’d see a -nan (or -qnan, #QNAN, [B]-1.#QNAN[/B] depending on the software you’re using) if the module is unplugged or not receiving enough power. If you add this to a good value, the good value will be clobbered, becoming a NAN itself.

So in order to avoid propagating that invalid number into your good values, use the PAC Control command[B] Float Valid?[/B] first before adding.

In the case of this solar application, the programmer/owner plans to add up each day’s total and eventually display a monthly total (he’s hoping by then it will be kilowatt hours, not just watt hours!) since he gets his power bill each month and the total amount billed is in kilowatt hours. He’ll then see how much power the solar system has saved him.

Totalizing for the win; no need to do that [U]integral[/U] yourself!

-OptoMary


INF, -nan, -qnan, #QNAN, -1.#QNAN
Ability to ignore certain input values for totalizers
#2

[B]he needed to know watt [I]hours[/I]. So, in this case, he set the “rate” to 3600 seconds or one hour. [/B]An hour to update a total? Less than an hour, the total will not change it?That’s too slow, right?


#3

The total is calculated much (much - like sub second) quicker, it is the units that we are setting the rate for.
So in this example, the units are watt hours, so we have 3600 seconds, but when you view the variable in say groov, I see the data update every second (groov’s scan rate).
If I wanted watt days, I would set it to be 86400, but still would see the watt days value update every second.

In other words, you are setting the units, not the update rate.

Make sense?


#4

I understand. “3600 seconds” or “86400” is just a unit, and does not affect the speed of data update.
Data update speed depends on the PAC control strategy to run the cycle, right?

Thank you very much!


#5

To be clear, totalizing happens at the I/O level (on the “brain” vs. the controller). But how often you want to Get (or Get & Clear) that value is up to you and how you program it in your logic. Note: since this does happen at the I/O level, that means, like with PIDs, if your controller and I/O are separate (meaning: you’re NOT using a SNAP-PAC-R series), your controller could completely go away and the brain would still be totalizing!


#6

“analog totalizing function built in”
Just using the command? Do not need to set up the module? I didn’t see this in the settings.
a customer may need this feature.
why?


#7

Here is the best way to learn about using commands;


#8

I see. It’s finished. It’s working very well now.
Thank you!