Tank Volume in PLC and HMI

[Bullzi]

Tom,
Thanks for posting the spreadsheet. I think I understand what is going on but want to run it by you just to make sure:
d/D is the fraction of the tank diameter the liquid level is at. So in my case if the liquid level is at 5.5' the d/D fraction would be 0.5. With a d/D fraction of 0.5, the volume fraction in the tank is 0.5 also. So in my case 12,655.5 Gallons.

So to make this equation work I need to scale the input from 0-1 and enter this number in the polynomial (d/D) portion. Then take the result from the equation and multiply it by the total tank volume. Is that correct?

Thanks again Tom for your help!!!

 

[Tom Jenkins]

Your understanding is correct. However, note that this equation is for a horizontal cylindrical tank only. If your tank is any other configuration the formula isn't the same. I posted the spreadsheet to demonstrate a technique of taking a set of data and using Excel to determine an empirical formula. In your case you indicated that you had a set of depth vs. volume data for your tank, so you could substitute your data into a blank spreadsheet and develop the formula.

 

[Bullzi]

Finally getting back to this thread. Been on the road for the last few days.

Some more basic questions:
1. I have another tank with a strapping chart. It goes 0-40' in 1/16" increments. That is a lot of data to trend. Would you recommend entering the data say every foot or every 1'-1"? Obviously the more data the more accurate the equation will be but I am sure there is a point that the amount of data becomes too time consuming for the accuracy gained. Just looking for some opinions.

2. How many orders do you normally use in the Polynomial? The Spreadsheet you attached showed three. is that normally good enough? Is there a max number of orders a AB processor can handle?

Thanks for any help!!

 

[Tom Jenkins]

The deciding factor for many of your questions is the coefficient of regression, R squared. The closer this is to one, the better the equation matches the curve. If adding points or increasing the order of the polynomial doesn't materially improve R squared then the change isn't justified.

The number of points is a little arbitrary and more limited by your willingness to enter data than by the capabilities of Excel. I recently used this technique to chart efficiency for three different blowers on one chart, and each had 6,400 data points. I guess I'd start with every two or three inches and see what it looks like.

I generally use 2nd or 3rd order polynomials. On rare occasions I've gone to 4th order. Again, I change number of orders in the polynomial or change the equation type until R squared flattens out and then I quit.

I have no idea on the limit of the equation function in the PLC. I suspect it varies with the model of CPU.

 

[kinser06]

Just another alternative solution.

If this is for local display only you could create a new tag in the redlion and select complex and use the following code

return (3.1459*tank radius*tank radius*your_liquid_level transmitter_tag)/7.48052;

This would also only be for horizontal tank, your transmitter and AI need to be scaled in FT.

Should only take a couple minutes to implement...

 

[ndzied1]

If you find yourself needing to calculate higher order polynomials on a resource limited PLC you should have a look at
Horner's Method:
http://en.wikipedia.org/wiki/Horner's_method#Description_of_the_algorithm

 

[Lancie1]

I am still working on getting some OCR Software set up on my computer.

I used the Microsoft Document Imaging software to read your smaller tank data PDF file and converted it to a *.DOC file. Then I copied the DOC file data into Excel and cleaned it up so that all of the data are in 2 ordered columns. Here are both the DOC and XLS files. I corrected any mis-read characters when I noticed them, but there could be some that I overlooked.

 

[widelto]

Lancie1: What a great task.

 

[Lancie1]

Lancie1: What a great task.

William, I let the computer do the hard part of converting the PDF to characters.

There were about 7 places where the character reader put in a decimal point in place of the comma (that I only noticed when the plotted curve made some crazy zig-zags). Here is the corrected spreadsheet, with Tom's chart and curve-fitting added for the data.

 

[Bullzi]

Thanks Lancie,
Just got back from North Dakota and was going to try it out. Looks like it made a pretty nice curve. I am going to try the same thing on a very large tank and see what I get. I will post back the results.

Thanks again everyone for the help!!

 

[daba]

Thanks guys for the heads-up on Excel capabilities (new one on me, but will certainly be using it in the future), and the use of OCR for getting large amounts of data into a system - nice.

Lancie1, I created a chart of the data in the spreadsheet, spotted the dips, and just did a couple of search/replace operations in the volume column... search "." replace with "," worked like a treat.

Bullzi, This is certainly a "do-able" method in both processors...

The MicroLogix 1100 doesn't support the CPT instruction, so you'll have to do a chain of MULs and then a couple of ADDs. Here's how I did it to test it, x goes into F8:0, y comes out of F8:7 ....

MUL F8:0 F8:0 F8:1 ;gives us x^2 in F8:1
MUL F8:0 F8:1 F8:2 ;gives us x^3 in F8:2
MUL F8:2 -0.0129 F8:3 ;gives us -0.0129x^3 in F8:3
MUL F8:1 2.55072 F8:4 ;gives us 2.55072x^2 in F8:4
MUL F8:0 81.46839 F8:5 ;gives us 81.46839x in F8:5
ADD F8:3 F8:4 F8:6 ;partial result
ADD F8:5 F8:6 F8:7 ;final result

The CompactLogix supports the CPT instruction, in which you can enter the y=x equation directly, but you might like to consider using the same piecemeal math instructions like you did in the Micro. CPT performs less than the equivalent hard-coded maths instructions in all cases.

Now you almost certainly don't need this calculating every PLC scan... consider that your HMI update rate will most likely be no better than half a second, and also consider how the information will be used by the operator. I would put this code into a subroutine that only gets called every xxx seconds, (you decide), and would use an STI program file if it is not used for something else.

 

[Bullzi]

Well I have been playing with this on by test bench (SLC 5/03 Processor and G306). I put the polynomial in a G306 tag called TANK_VOLUME. When I manually put a value into the PLC, I get a number that was not as accurate as I thought it would be.

For example if I put 131 into the register in the PLC F8:0 I get 24194 in my TANK_VOLUME tag which is 1117 gallons low or about 4% off. I thought I was doing something wrong in the HMI so I put the equation into Excel and when I put in 131 I got the same number out. Any idea what I could be doing wrong? I can deal with +/- 1% but not 4%.

I have attached all the files I am working with except the PLC program. there isnt much in the program. I am just using F8:0 as a data entry field.

Take a look at what I have done and let me know if you have any ideas.

Thanks!!

PS: I know I can enter the formula that Kinser posted but I want to try and make this work. I get a lot of tank tables and if I can make a formula work with the given data it would really make integrating tank tables into the PLC much easier.

 

[ndzied1]

At the high end of the curve, the 3rd order equation is much better than the 4th order.

If you look at sum of the errors squared (one indication of how well the curve fits) the 3rd order is much better than the 4th order. I'm not sure why the R value is a little better for the 4th order but I'd go with the 3rd order approximation myself.

 

[Lancie1]

Yes, unfortunately this particular curve-fit equation has a large error from about 128 to 131 inches. There is also a curve mis-match between 1 and 20 inches. You can see these it you grab a corner of the graph and expand it about 25%. That spreads out the data so that you can see the difference between the black data line and the red equation line. You could throw in an adjustment factor when Level > 128, or you could search for a better fit.

It is possible also that there were some errors in the original data - the actual tank volume may have been slightly different.

As a double-check on the accuracy, for a horizontal cylindrical tank of 131.375" x 431.375", the formula in cubic inches would be:
Radius r = 131.375/2 = 65.6875'
Radius squared = 4314.8477
Volume = Pi x r^2 x L = 3.14159265 x 4314.8477 x 431.375 =
Volume = 5,847,501.087 cubic inches
(cubic inches in 1 cubic foot = 12" x 12" x 12" = 1728 cu. inches)

Volume =5,847,501.087 cubic inches / 1728 = 3383.9705 cubic feet
Volume = 3383.9705 x gallons/cubic feet of liquid.

For water, it is approximately 7.48051948 gallons per cubic foot
so Volume in gallons = 3383.9705 x 7.48051948 = 25,313.857 gallons.

That is about 2.857 gallons more than what was on your original chart for 131".

 

[Lancie1]

PS: I know I can enter the formula that Kinser posted but I want to try and make this work.

Be careful that you use the correct formula for a Horizontal Cylindrical Tank. I am sure that Kinser's formula will work ONLY if the tank is vertical and the measured variable is the height of the vertical liquid.

If this is for local display only you could create a new tag in the redlion and select complex and use the following code

return (3.1459*tank radius*tank radius*your_liquid_level transmitter_tag)/7.48052;

For a horizontal tank, and with the measured variable being the height of liquid from the bottom radius, then the formula is more complicated:

Volume in Cu. Feet = Cross-Section Area X Length, where:
R = known Inside Radius of Horizontal Tank,
L = Inside Length of Tank,
h = measured Height of Liquid in Horizontal Tank,
Pi = 3.14159265,
Cos-1 = Inverse Cosine
While Level is <= R/2, Area = R^2[Cos-1{(R-h)/R}];
While Level is > R/2, Area = R^2[Pi-Cos-1{(h-R)/R}];

Gallons = 7.48051948 X Cubic Feet

A problem I have run into is that most horizontal tanks are mounted with a slight tilt or slope. For fuel tanks the tilt is so that any water will settle out in the low end and not be sucked into the fuel line. For other liquids often the tilt is the other direction so that the last few gallons will run toward the drain pipe. Any tilt from true horizontal will cause a small error if using the above formulas.