Totalizing bulk delivery

H2OTom

Member
Join Date
Jun 2017
Location
Florida
Posts
15
Hello everyone! I've got something I'm trying to figure out and I'm possibly overthinking it. I've got a 25,000 gallon bulk chemical tank with an ultrasonic level meter outputting the tank level in feet. I've taken that level along with the tank manufacturer's strapping table (in one inch increments) and created an array, in conjunction with the FGEN function in Studio 5000, where the PLC interpolates the data and gives me the tank volume in gallons. This is working great.

What I'd like to do is use this data and detect when a delivery starts and stops, giving me the total gallons delivered. I'm thinking about moving the level signal every 10 seconds then comparing and using an increase to start the delivery totalizer. Is there an easy way to do this? This way we have a total to compare with the delivery ticket total provided by the driver.

I've been doing this manually and found that the driver often thinks he has delivered more than he has. Over time, I believe, this has resulted in thousands of gallons of overcharges.

I know the best solution here would be a flow meter, but it's not really an option.
 
Immediately my mind goes to using a simple derivative estimating formula to determine flow rate and use that to determine if you fluid is currently being added to the tank (and only for this - NOT for totalizing purposes). A simple derivative estimating formula can be found on this webpage, first figure in the results section. f(n) is the current volume, f(n-1) is the volume in the last scan, and H is the scan rate in whatever time units you'd like: http://www.holoborodko.com/pavel/nu...-derivative/smooth-low-noise-differentiators/



When you determine that the tank is actively being added to, then you save the start weight. When you are no longer being filled, save the end weight and take the difference. It should be noted that this method (and any method for the available instrumentation) falls flat on its face if the tank is being filled and drawn from simultaneously.

This method would be pretty sensitive to fluctuations in level, so be absolutely sure your level transmitter's noise filtering is set up correctly.
 
Last edited:
i agree with your timer.
have a continuous timer (5 or 10 seconds)
when the timer starts, store the number
when the timer times out, store that number in a different address.
it the 2nd number is lower than the first, you are draining the tank.
move the 2nd number into the first number.
if the 2nd number is bigger, start another timer (10 seconds)
when that timer times out, if that number is still bigger, you are filling the tank.
use the first number as a starting point for filling.
this is a good start, but will need work.
hope this helps
james
 
Rather than trying to detect when a delivery is happening based on a sudden change in volume, can you retrofit a sensor at the point of delivery to detect the presence and absence of the filling apparatus? If so, capture the volume at the start and end of the delivery and subtract to find the difference.
If you are logging the volume to a historian perhaps you can capture the times of the start and end of the delivery and retrieve the corresponding logged data.
How is the delivery driver capturing his data to generate the delivery ticket?
 
I am guessing the pump is not on your side and you are not able to pull an aux contact from the motor starter to your PLC and do as Steve suggest?
 
If the reading has no noise:

  • if the volume measurement (strapping_table_interpolation(level_measurement)) increases from one level_measurement to a later level measurement, then there is a (net) fill occurring;
  • if the volume measurement decreases to a later level measurement, then there is a (net) drain occurring.
However, I would think the problem with that would be would be noise in the measurement, so a single delta is not good enough, unless there is a minimum increase over some set time that could not be due to noise.

Assuming a fill is in progress (with no simultaneous drain), I would expect a fairly constant and minimum slope (fill rate) to a best-fit line; that slope can be calculated using a straightforward least-squares formula over several samples. Even if there is no fill going on, it is likely that the calculated slope of the noise will be non-zero, so proper selection of number of samples, sample period, and the minimum target slope for declaring "fill in progress," or alternatively the maximum target slope for declaring "no fill in progress," are the critical parameters.

We don't know the character of a filling event or more importantly of a draining event, but they will be important in setting those parameters.

As far as the overall approach. assuming that reasonable parameter choices are made, I would think that, instead of detecting a fill event, it will be easier to detect and timestamp periods when the tank contents volume is not changing, and use as fill estimates any difference between two successive such stable periods, where the later value is greater than the earlier value by some minimum difference (presumably filling events are not small increments).

From a random query to The Google, the slope formula is below, which can also be derived; the y offset b can be ignored as we are only interested in cases where m is near 0, so the mean Y value is the best estimate of the stable measurement.
Untitled.png
For a preset N, a running totals ΣY, is simple to maintain with a FIFO of the last N values of Y by adding the latest FFLed Y value and subtracting the oldest FFUed Y value. If we assume X values are always 1,2,...,N, then ΣX is a constant N(N+1)/2, as is Σ(x2), which can also be pre-calculated (The Google sez N(N+1)(2N+1)/6). Σxy can be incrementally maintained by adding NYnew and subtracting the previous ΣY for each new value Ynew. There will be some roundoff error, so LREALs should be used.

P.S. I am pretty sure that I just derived the algorithm for an alpha-beta filter which would yield the same result.
 
Hello everyone! I've got something I'm trying to figure out and I'm possibly overthinking it. I've got a 25,000 gallon bulk chemical tank with an ultrasonic level meter outputting the tank level in feet. I've taken that level along with the tank manufacturer's strapping table (in one inch increments) and created an array, in conjunction with the FGEN function in Studio 5000, where the PLC interpolates the data and gives me the tank volume in gallons. This is working great.

Congratulations! You’re good!!!

…25,000 gallon bulk chemical tank…
…outputting the tank level in feet…
…in one inch increments…
…FGEN function in Studio 5000…

What this information for?


What I'd like to do is use this data and detect when a delivery starts and stops, giving me the total gallons delivered.

You are welcome! Use it!! I do not mind!!!

What is your topic about?

What are the conditions and constraints of the problem? Are there simultaneous loading/unloading through different pipelines? Is there a way to determine (sensor, HMI, etc.) the start/end of loading/unloading? Is there noise in the signal? Is the container of complex shape? Are there effects of temperature, pressure on the container and liquid (thermal expansion, etc.)? Should you do it on the fly or is it possible to parse data from databases? Anything else?



From a random query to The Google, the slope formula is below, which can also be derived; the y offset b can be ignored as we are only interested in cases where m is near 0, so the mean Y value is the best estimate of the stable measurement.

Firstly, congratulations on solving an unformulated problem.
Second, there is no need to cross out steps 4 and 5 in the least squares approximation of a linear function. All this stuff is for step 5. I know exactly what you will object to me. My answer will remain the same.
 
Hello everyone! I've got something I'm trying to figure out and I'm possibly overthinking it. I've got a 25,000 gallon bulk chemical tank with an ultrasonic level meter outputting the tank level in feet. I've taken that level along with the tank manufacturer's strapping table (in one inch increments) and created an array, in conjunction with the FGEN function in Studio 5000, where the PLC interpolates the data and gives me the tank volume in gallons. This is working great.

I assume the tank is irregularly shaped? Otherwise, this would be done with Excel and a normal Scaling block in the PLC (after the reading from the level transmitter reaches the linear part of the tank).

What I'd like to do is use this data and detect when a delivery starts and stops, giving me the total gallons delivered. I'm thinking about moving the level signal every 10 seconds then comparing and using an increase to start the delivery totalizer. Is there an easy way to do this? This way we have a total to compare with the delivery ticket total provided by the driver.
This is going to sound like an awfully stupid suggestion (or likely not possible) in a thread with math from drbitboy, but is that signal possible to be trended? Adding it to an historian would solve your problem as you'd go back on history after the delivery to see the difference. Yeah, it would be nice to get a figure somewhere, but that somewhere can likely trend this value and give you the information in a "nice" format (see comment below).

I've been doing this manually and found that the driver often thinks he has delivered more than he has. Over time, I believe, this has resulted in thousands of gallons of overcharges.

And here comes the nice format, showing a trend with a start and end point may remove the inevitable question of "How do I know your formula is right?" if you only display something on the screen?

And even then, is your instrument calibrated? regularly? As I see it, I think the driver can claim this and you'd be on shaky ground to prove it as a sale of product based on the level transmitter.

Also, as someone said here, you'd have to have an interlocking system (which may exist) that once the tank is being filled, the outputs of the tank are closed shut. Does this exist?

I'm not putting you down, just trying to look a bit further ahead into the discussion around sales and verification of product quantity. And this will be subjected to national law wherever you are and I'm not the expert on that for your country.

Lastly, do you have a weighbridge where you work? where I work our tankers and lorries (both for raw materials and sold product) are weighed in and out and the difference applied. For the sales (because it's sold in bags on pallets), the weight is mostly to confirm that the shipping company will accept the container, but products sold in tankers are checked like this.
 
...
Second, there is no need to cross out steps 4 and 5 in the least squares approximation of a linear function. All this stuff is for step 5. I know exactly what you will object to me. My answer will remain the same.

agreed, there is no need to cross out steps 4 and 5 if we instead insert steps 3.a and 3.b:
Code:
3.a if |m| > ε then stop i.e. do not timestamp the result this cycle as the level is not stable

3.b m = 0
I know exactly what you will object to me.
Was I close ;)?
 
Two questions:
1. How does the driver determine how much he has delivered?
2. Does your facility have a truck scale?

In most states (maybe all), the devices used in commerce must be certified for "custody transfer". Using you tank level, is not good enough for this. I suspect the supplier will not give any credit for your dispute. Most chemicals are sold by weight, not volume. So your tank measurement would have to account for density and temperature.
 
Two questions:
1. How does the driver determine how much he has delivered?
2. Does your facility have a truck scale?

In most states (maybe all), the devices used in commerce must be certified for "custody transfer". Using you tank level, is not good enough for this. I suspect the supplier will not give any credit for your dispute. Most chemicals are sold by weight, not volume. So your tank measurement would have to account for density and temperature.
+1

I was thinking if by volume that you would need a calibrated, certified and sealed flow-meter.
Or, if by weight, you would need a calibrated, certified and sealed weigh-scale.
 
What I'd like to do is use this data and detect when a delivery starts and stops, giving me the total gallons delivered.


Does the FGEN function output an integer (INT or DINT/LINT or U*INT) or a REAL value?

Also, did you want to do this in the PLC or in a separate system e.g. it would be trivial to implement with AdvancedHMI, pycomm, pylogix, etc.?
 
Last edited:
If I were called as an expert witness on the relative accuracies of ultrasonic level versus a dedicated delivery truck batch meter that probably has a state inspection sticker on it, I'd have to truthfully say that the delivery truck's batch meter would be one to define the delivered volume.
 

Similar Topics

Hello, all. I’ve worked with totalizers based on a flow meter. However, I am trying to use ladder logic on totalizing a tank based on volume. I...
Replies
1
Views
1,126
Is this reasonable to do? I am using a SLC 5/05 so there's no totalizing instruction, I think I have to make my own. Anybody done this, any...
Replies
14
Views
4,283
Hi, please i wish to do batch totalizing ( automatic flow control) i wish to use Endress+Hauser flow transmitter with Allen Bradley 1400 to do...
Replies
30
Views
5,926
Hey GE guys, wondering if any of you had any experience with getting the TOTALIZER instruction working in Proficy Machine Edition. Seems...
Replies
9
Views
3,623
We currently have 2 system measuring a liquid similar to water. Density is around 8.3lbs/gal. We take the flow in lbs/min and calculate lbs per...
Replies
15
Views
3,999
Back
Top Bottom