Totalizer

I want to crete a Totalizer that I totalize a input signal. Does any one know the mathmatical formula for a totalizer. I will be using Optoscript with OPTO 22

Thanks

First, we'll assume that the analog signal you'll be totalizing represents a rate (quantity per unit of time).

If you were to plot the analog signal over time, the accumulated total would be the area between the line representing the signal level and the time axis.

Sample the analog value on a regular basis. Multiply the sample value by the elapsed time since the last sample, add the result to the cumulative total, and apply any factors for units conversion.

Would this example work:

Scenario: Lets say you have a flow meter providing you with an analog signal representing BPD (Barrels per Day) and you want to know how many barrels you have accumulated thus far (total volume).

Proposed Solution:
Every second, take the flow signal and divide it by the number of seconds in a day (86,400). Add the result to the previous result.

I backed off from making a reply earlier because the question look(s) too simplistic.

My first thought was 1+1=2

The only time I have dealt with a system that needed to do a total was a batching system where we kept records of the quantities entered per batch, per shift, per day. The product used some recycled material that changed density which could change the weight of other ingredients per batch, therefore the powers that be wanted to see what was happening as it happened to maintain the QC of the product.

I can relate to totaling batch values but I dont understand either of the examples given. If the device can give you values per volume/rate within a specific time factor why the need to totalize. One example stated "an analog signal representing BPD (barrels per day)". Isnt that already a form of a total?

I think the question was too simplistic. I attempted to look for Optoscript and didnt see any reference to it at Opto site.

I think more detailed info would be needed to correlate a proper response.

Ron, use you car as an example. The speedometer provides rate information, the odometer is a totalizer. Suppose your odometer is disabled and you need to calculate the mileage between two points. If you can maintain a constant speed for the entire duration of the trip, it's pretty simple; just multiply speed (Miles per hour) by time (Hours) to obtain the distance (Miles).

When you can't maintain a constant speed, it becomes a bit more difficult. If your car can accelerate from zero to sixty miles per hour in ten seconds, how much distance have you covered when you reach 60 MPH? If you answer 440 feet, you're assuming a constant acceleration rate.

Let's say you sample the speed once per second, and get the following data:

Start at 0 MPH
At 1 Sec. - 1 MPH You covered 1.5 Ft. in that second
At 2 Sec. - 3 MPH You covered 4.4 Ft. in that second
At 3 Sec. - 7 MPH You covered 10.3 Ft. in that second
At 4 Sec. - 15 MPH You covered 22.0 Ft. in that second
At 5 Sec. - 30 MPH You covered 44.0 Ft. in that second
At 6 Sec. - 45 MPH You covered 66.0 Ft. in that second
At 7 Sec. - 53 MPH You covered 77.7 Ft. in that second
At 8 Sec. - 57 MPH You covered 83.6 Ft. in that second
At 9 Sec. - 59 MPH You covered 86.5 Ft. in that second
At 10 Sec. - 60 MPH You covered 88.0 Ft. in that second

For a total of 484 feet. A different speed profile will result in a different distance travelled.

There is an inherent inaccuracy in the above procedure since you're not traveling at a constant speed over each time interval. By keeping the time increment short, you minimize the error. The calculated distance traveled is larger than the actual distance when you're accelerating; it's smaller than the actual when you're decelerating.

Hope this sheds some light on the issue.


ganutenator,

You'll minimize roundoff error if you accumulate the rate and divide the cumulative total by 86,400 instead of dividing the sample by 86,400.

"The calculated distance traveled is larger than the actual distance when you're accelerating; it's smaller than the actual when you're decelerating."

Steve

There is a way to reduce the error.

Instead of useing the sample points, you use the average between the sample's: X + (X-X(n-1))/2

I use average calculation instead of sample points directly.


Useing your example:

OK, just took a few bricks but now I understand.

average between the sample's: X + (X-X(n-1))/2

Sorry about wrong formula. It is of course: (X+X(n-1))/2 banghead

Thanks for the tip Steve

Thanks for the tip Steve

Could you guys help me with my problem in the thread: pulse to analog to totalizer?

Be sure to pick sample intervals that are will be representative of how rapidly changing your process is. Wait too long and your process will change too much between sample times:

Time Rate

1min 50gpm

3min 70mpg


Using the above sampled data, it would seem as if you rate shot up 20mpg, however assuming that the 2min interval is long with respect to the variation of your process, you have no idea of the behavior of the system between the two intervals (rate could have dropped drastically for 1.5 mins before shooting up to 70, throwing off your totalization).

Too short an interval and you'll just eat up space where ever you are storing your data.

Depending on your PLC. I perfer using a periodic task at about 20 millisec. Then its just a simple Compute statement adding the analog signal to itself.