Volume of A Cone

I need to do some Contrologix Math to calculate the Volume of a Cone using a UDT containing

top of cone diameter (Inches)
Cone height (Inches)
Volume in cone (Cubic inches) to (Gallons)

Inputing the values in inches and getting the volume in gallons.

Anyone have this logic

Thanks

Is this going to be duplicated?
Happen in multiple places?
If so, use the array & indirect addressing to accomplish this.
Create your UDT, create an array of them, run a math in Structured Text using indirect addressing, and viola.

Give it a shot, I'm sure you'll get any help you need.

The formula for the volume of a cone is 1/3 * PI * r² * height.

You can algebraically rearrange this to work with diameter as .2618 * d² * height.

1 gallon is 231 in³


If this is a hopper volume application then you should be aware that r will change with the height of the media in the hopper - although this is very easy to calculate. Simple traingle geometry or trig is all that is required.

If the hopper is not large and accuracy requirements are not exact, then a look up table will execute much faster. You create an array that contains the volume of media in the hopper when media depth is 1", 2", 3", 4" and so on up to the height of the hopper.

(edit)
I realize that while this math is easy for some of us, it may be difficult for others. If you have a problem with the math but you are able to use CAD, then lay out your hopper cross section in 2D, then beginning at the apex measure the distance across the hopper (the cone diameter) at one inch intervals and record this in an Excel spread sheet. Use the formulas above to calculate the volumes using Excel for the look up table.

If you need more help, please reply.

Thanks for all the help, What I needed was an expression that would calulate the volume at any level using a Level transmitter scaled for inches. So the UDT looks like this


Wedge_Height
Cyl_Diameter
Wedge_Volume

all to be input in inches.

Here is what I did with all your help, thanks....

((Level*(Cone_Tk_Vol.Cyl_Diameter/2)/(Cone_Tk_Vol.Wedge_Height)*(Level*(Cone_Tk_Vol.Cyl_Diameter/2)/Cone_Tk_Vol.Wedge_Height))*1.046)*Level

That way one enters the Diameter of the wedge opening and the height of the wedge and gets Gallons

EDIT, Sorry but this gives CU Inches , I do the *231 in another rung for gallons

You might want to take another look at this in terms of it's applicability. The diameter used varies as the level changes. Therefore, in your formula you still have an unknown. You need to add another step that provides the diameter of the cone as a function of the level. You can do this with trig functions or by a simple ratio of max diameter to max height.

I think you are making this too hard.

The diameter of the top surface of the media in a conical tank or hopper is a function of the heght and the cone angle.

Perhaps a sketch will illustrate the point.

This first tank has a 45^o conical bottom.


As the media height in the tank increases, so does the diameter used to calculate the media volume. At a depth of 1 inch, the diameter is 2 inches. At a depth of 4", the diameter is 8"

Now this hopper has a 30^o cone.


This changes the height to diameter relationship. Now for a media detph of 1" the diameter is 1.15 inches and for a media depth of 4 inches the diameter is 4.62 inches.

The radius to height relationship in these two examples can be defined as:

Radius = TAN(T) * height
Where T is the angle of the hopper cone.

By using this as our diameter/height to relationship we can eliminate the necessity of entering a diameter which will be chaning with height anyways.

So algebraically rearranging our equation and expressing all values in terms of height and the angle of the tank cone, we get

Volume = (Tan(T)*height)² * height * PI/3
Volume = height³ * tan(T)² * PI/3

PI/3 is 1.0472. Tan(T) will be fixed (unless you are chaning out the tank all of the time). Let K be a constant that you program according to the tank cone angle such that
K = tan(T)² * PI/3.

Then the volume calculation becomse very simple. It is K * Height³

Go one step farther, make K = (tan(T)² * PI/3)/231 to convert to gallons in a single step.

Lets say you have a tank with a 60⁰ bottom.
Then your calculation becomes CPT VOLUME_IN_GALLONS "Height**3 * .01359997"

Thank you very much for the info, I will print it and keep it on file, BUT, Take a look at my [CPT] Instruction, Break it down and you will see that it does calculate the Volume real time as the liquid raises.

Level in inches = LI
Cone Radius = CR
Cone Height = CH

LI * (CR/CH) * LI * (CR/CH) * 1/3pIE * LI

The only ting I would say is consider using the exponent operator x**y) in the compute like Alaric shows. It will just keep it cleaner. You end up with:



I like the idea of keeping it general (without application specific consants) so it's easier to use later for a different application.

Keith

kamenges said:

I like the idea of keeping it general (without application specific consants) so it's easier to use later for a different application.

Click to expand...

Good point Keith. As you know I'm a big fan of object oriented programming, so generic is good. But I also don't like making the processor do billions of unnecessary calculations using values that don't ever change, as it will do over a lifetime. The application can still remain generic if we use a constant to represent CR/CH**2 * PI/3. This can be an element in a UDT rather than hardcoded - thus the constant is entered into the UDT tag for each application.

OK, I agree now that I see where your going with this, With my logic a PLC Programmer still has to enter the Height and Diameter which once done will never change, So like you said why not enter the information above once and have a nice clean instruction.


Thanks Bob

kamenges said:

The only ting I would say is consider using the exponent operator x**y) in the compute like Alaric shows. It will just keep it cleaner. You end up with:

Click to expand...

Don't. X**Y takes up a lot more processing time than X*X. WHY?

constant*level*level*level=volume.
This isn't too messy. Just document how the constant was calculated.

Everything in moderation

Originally posted by Peter Nachtwey:

Don't. X**Y takes up a lot more processing time than X*X. WHY?

Click to expand...

I can't argue that. As I remember the X^Y is performed iteratively with an adder based on a look-up table value. It isn't a native hardware function in the CPU. This will be slow. But, then again, so is code generated using object oriented design methods. That doesn't mean we should kick it to the curb.

In this particular case I think the result will be much more readable using the X**Y format, especially give the absolutely horrible way the CPT block displays in Logix5000. I wouldn't want to make a whole program out of X**Y operatons but I don't think this one occurance will kill us.

Keith

kamenges said:

I can't argue that. As I remember the X^Y is performed iteratively with an adder based on a look-up table value. It isn't a native hardware function in the CPU. This will be slow. But, then again, so is code generated using object oriented design methods. That doesn't mean we should kick it to the curb.

In this particular case I think the result will be much more readable using the X**Y format, especially give the absolutely horrible way the CPT block displays in Logix5000. I wouldn't want to make a whole program out of X**Y operatons but I don't think this one occurance will kill us.

Keith

Click to expand...

I often have to find the current position using 5th order polynomials.
Pos = a + b*t + c*pow(t,2) + d*pow(t,3)+e*pow(t,4) + f*pow(t,5) would lead to non competitive product.

pow(x,y) = exp(y*log(x))

These functions aren't cheap. A taylor series appoximation takes many mulitplies and divides.

x*x*x is very fast. In the case of our DSP it is three clock cycles. Object oriented programming isn't near that inefficient.