Sign in to follow this  
Followers 0
Conor

Calculate expression for a balloon

23 posts in this topic

Hi all, I am looking to do the following calculation, it harks back to the problem I was having with trying to compensate the bouncing in the Analogue signal coming back from my Airanger unit. Anyway I have never done a calculation expression like this before, so any help would be most grateful. V=Pi/6*H(3(r2-(H-6.605)2 +3*b2 + H2)) With the following meaning V= Volume Pi = Pi i.e. 3.14159 Anywhere I have a 2 this means I am trying to square this, so r2 = r squared, b2 is b squared, (H - 6.605)2 is this squared and H2 is H squared. I have never done a calculation of squaring or used Pi either. I can clarify anything if needed. I have been given this formula by an Engineer and asked to write it into my PLC. This project is on a PLC5. Thanks, Conor

Share this post


Link to post
Share on other sites
I have not used PLC5, but can you move the value 3.14159 to a register and use a reference to this in your calculations? For squaring, you can you multiply the value by itself? (3 x 3 = 3 squared) I would try and split the equation into smaller sections...

Share this post


Link to post
Share on other sites
Doesn't the PLC5 have compute blocks? That would make this easy. In any case you want to define variables in a F block like F8. You do the calculations inside out. What is(are) the variable(s) that have values that change are run time. Know this can allow one to simplify the equation. V=Pi/6*H*(3*(r*r-(H-6.605)*(H-6.605) +3*b*b + H*H)) PI/6 should be a pre-calculated constant. If 3*b*b doesn't change then it should be pre-calculated constant too. Just to get you started, you need to define a few temporary variables in F8. Call the temp0 and temp1 sub h 6.605 temp0 mul temp0 temp0 temp0 mul r r temp1 sub temp1 temp0 temp0 mul b b temp1 mul temp1 3 temp1 add temp0 temp1 temp0 mul H H temp1 add temp0 temp1 temp0 mul temp0 3 temp0 mul temp0 H temp0 mul temp0 PI temp0 div temp0 6 V The last few lines should be simplified. PI*3/6 is simply PI/2 and should be calculated before hand by calculator and stored in a variable PIDivBy2. Your engineer should be embarrassed. Using that information I would shame him into helping you out or at least ask him why he didn't know this. It is more fun to ask these kinds of questions around when there are others to hear it and the reply. // Use this for comments in your code sub H 6.605 temp0 // temp0=(H-6.605) mul temp0 temp0 temp0 // temp0=(H-6.605)^2 mul r r temp1 // temp1=r^2 sub temp1 temp0 temp0 // temp0=r^2-(H-6.605)^2 mul b b temp1 // temp1=b^2 mul temp1 3 temp1 // temp1=3*b^2 add temp0 temp1 temp0 // temp0=r^2-(H-6.605)^2+3*b^2 mul H H temp1 // temp1=H^2 add temp0 temp1 temp0 // temp0=r^2-(H-6.605)^2+3*b^2+H^2 mul temp0 H temp0 // temp0=H*(r^2-(H-6.605)^2+3*b^2+H^2) mul temp0 PIDIVBY2 V // V=(PI/2)*H*(r^2-(H-6.605)^2+3*b^2+H^2) // You can see you save a few steps and saving a division saves a lot because they are slow. I would at least extort a lunch. Your engineer owes me a lunch. You can collect. Edited by Peter Nachtwey

Share this post


Link to post
Share on other sites
Let V = F8:0 , PI = F8:1 , H= F8:2 ; r = F8:3 and b = F8:4 and in a PLC 5 the following CPT will work CPT F8:0 ((F8:1 | 6.0) * F8:2) * (3.0 * ((((F8:3 * F8:3) - ((F8:2 - 6.605) * 2.0)) + ((3.0 * F8:4) * F8:4)) + (F8:2 * F8:2))) this was in a PLC 5/40 enhanced series A. NOTE : CAVEAT - I wrote the code and there were no errors - I not sure the PLC order of operations will give you the correct results without some more parentheses. USE WITH CAUTION.

Share this post


Link to post
Share on other sites
Just to add to this, there is an operator to do an exponential expression (x**y) see pictures below

Share this post


Link to post
Share on other sites
Applying Mickey's Post you get CPT F8:0 ((F8:1 | 6.0) * F8:2) * (3.0 * ((((F8:3 **2 ) - ((F8:2 - 6.605) * 2.0)) + (3.0 * F8:4**2) + (F8:2 **2))) this was in a PLC 5/40 enhanced series A. NOTE : CAVEAT - I wrote the code and there were no errors - I not sure the PLC order of operations will give you the correct results without some more parentheses. USE WITH CAUTION.

Share this post


Link to post
Share on other sites
Hi guys, Thank you all for your replys. I will try out your code on Monday, as it is late on Friday (after 8pm) here, and I have left for the weekend (hopefully). I will let you all know on Mon how it goes.

Share this post


Link to post
Share on other sites
X * X will execute considerably faster (as much as 20x faster) than X**2.

Share this post


Link to post
Share on other sites
From watching the forums I have come to the conclusion that it is impossible to train everybody. What we did is check the exponent. If the exponent is a constant integer then we translate x**2 to x*x. x**3 gets translated to x*x*x. x^4 gets translated to (x*x)^2 which gets translated to xx*xx which takes only 2 multiplies. A smart compiler should do this. It doesn't take much effort. Now the question is what did Rockwell do? You should always avoid divides by a constant. It is much faster to multiply by a constant. On our processors it is about 4 to 5 times faster to multiply than divide. We got smart here to and translate dividing by a constant to multiplying by (1/constant). Edited by Peter Nachtwey

Share this post


Link to post
Share on other sites
If I read your expression correctly, it should be possible to reduce it to: 1.570795 * H * ( 3 * b * b + r * r - 13.21 * H + 43.626) where 1.570795 is (Pi / 6 ) * 3 or Pi / 2 13.21 is 2 * 6.605 43.626 is 6.605 ** 2 which would involve only 6 multipies and 3 adds, no great challenge for a PLC-5 Of course, if any of H, b or r is a constant value, you could also calculate them by hand as well.

Share this post


Link to post
Share on other sites
You forgot a H^2 term but otherwise that is why the engineer owes someone lunch for doing his job.

Share this post


Link to post
Share on other sites
Hi guys, I am going to try this out now, but I can clarify, that all values except H are constant. As you all have stated, I will try and reduce this calculation down as much as possible, to help my PLC. Conor

Share this post


Link to post
Share on other sites
Hi guys, I have written this into code and it is working. As stated before, I did some of the calculations and put them into spare F8's that I had. It does simplify the calculation. I have it added to our Scada now, so I can trend one against the other (original vs new volume) Conor

Share this post


Link to post
Share on other sites
Unless I've blown it somewhere, I think the H2 term cancels out: -(H - 6.605)**2 + H**2 = - (H**2 - 2 * 6.605 + 6.605**2) + H**2 = -H**2 + 2 * 6.605 - 6.605 **2 + H**2 If r and b are both constants, it should be possible to reduce this whole mess to the form A * H * (1 + B * H) One needs to know the values of r and b to calculate A and B of course. Edited by DwalterE

Share this post


Link to post
Share on other sites
Hi Dwalter, Can you explain a little bit please. A= ? B= ?

Share this post


Link to post
Share on other sites
I believe he's replacing r*r with A and b*b with B.

Share this post


Link to post
Share on other sites
Get wxMaxima from sourceforge. It can simply very complicated expressions. The equation above is simple but the engineer that came up with that formula needs it. http://sourceforge.net/projects/maxima/files/

Share this post


Link to post
Share on other sites
How does multiplying X by 1/N stack up against dividing by N when both X and N are integers since 1/N forces a floating point calculation? I'm not a guru on the inner tickings of the processor (I promptly forgot most of the processor design lectures because I was never the least bit interested in that aspect of EE) however I suspect some FP processors might do it pretty dang fast. But would the FP operation be faster than integer division?

Share this post


Link to post
Share on other sites
FP division is often just as fast or faster than integer division. Integer division requires a cycle for each shift and subtract. FP divide often calculated using multiplies and Newtons method. Our DSP doesn't have a floating point divide. It simulates a divide using a multiplies.

Share this post


Link to post
Share on other sites
/* [wxMaxima: input start ] */ (%pi/6)*H*(3*(r*r-(H-6.605)*(H-6.605) +3*b*b + H*H)); float(%); expand(%); collectterms(%,H); grind(%); /* [wxMaxima: input end ] */ 20.75021947696058*H^2+(1.570796326794897*r^2+4.71238898038469*b^2-68.52759982266234)*H$

Share this post


Link to post
Share on other sites
1. The PLC-5 is an interpreted system. There is no compiler. Everything is tokenized. So your statement that "a smart compiler should do this" doesn't apply with an interpeter. Or at least not with a PLC-5. They just took the brute force tokenized language approach. There is little optimization at all. 2. As far as the MUL/DIV/ADD (as in doubling can be done with an ADD) normally I'd agree, partly because I know exactly how it has to be implemented in the ALU. However with a PLC-5, again, this is not the case. MUL/DIV are the same speed. It seems ludicrous in my mind that this is the case since a Booth multiplier takes up a lot of silicon real estate and is far slower than an ADD while a DIV is best implemented with an inversion which takes a long time (O(N log N) or there abouts vs. O(1)!) but hey, it is what it is.

Share this post


Link to post
Share on other sites
The PLC 5 uses a 68000 and I don't think is has a math coprocessor so there is no booth algorithm. The overhead of the interpreter probably dwarfs the difference in execution time difference between a floating point MUL and DIV.

Share this post


Link to post
Share on other sites
OK, I disagree partly. The general point of your arguments however is correct. So I guess I'm having crow for dinner tonight. As in all other systems, ADD/SUB are roughly equals, multiply is slower (but not dramatically), and you have to be desperate or forced into a corner to use a divide. I'm very familiar with the 68000 (and the little 6800 brother) from a design point of view because those are the processors that I cut my teeth on. I'd slightly disagree that the PLC-5 uses a 68000 for everything because in reality, it was a very messy design including no less than 11 ASICs. When I opened one up, I counted at least 3 CPU's one of which was a 68000, one of which was a Z-80 series, and there was at least one or two others in there, too. Even the 6800 had a Booth multiplier. No separate floating point coprocessor. That was an Intel thing that came later and Motorola was forever playing catch up on those. However it was always the ongoing joke that each new Intel processor would come automatically with some pretty severe arithmetic bugs so the controls guys avoided them like the plague (except the 8080 series for register specialization masochists). The 68000 definitely has a Booth multiplier, at least as far as integers go. This design was very common in Motorola processors at the time since they first implemented it in the 6800 series. Hardware-wise it's not too difficult to implement as long as you can do bit shifts in your ALU and add a little extra logic to check the value of the two least significant bits because it does the multiply two bits at a time. There was no floating point unit at all and no division instruction...you had to do those the hard way. So at least with integers, yes, you had hardware accelerated multiplication (such as it was). As I recall from code at that time, the usual strategy was to do an inversion and then multiply to achieve a division operation. There were also lots of folks using all kinds of creative Taylor series and Chebyshev polynomials that mostly just made my head hurt looking at the code. I am probably going to get my exact numbers wrong but I believe the hardware multiply was roughly 5 times slower than an ADD. With floating point, usually the exponents could be added/subtracted, the mantissa (fractional part) fed through the integer multiply, and then some scaling with bit shifting and adding/subtracting on the exponents was necessary to clean up the result, and all this had to be done in software alone. However, with the ASIC's on board the PLC-5 at least one of them might have been a math coprocessor but at this point I'm purely guessing. Only reason that I would suspect this to be the case is that the instruction timings aren't too shabby with floating point operations compared to their integer counterparts (roughly half as fast), leading me to believe that there almost has to be some sort of hardware assistance. Regardless, we don't have to argue about semantics when we have numbers. According to the instruction set reference manual in appendix A (instruction timing), using floating point for the case at hand an add takes 14.9 microseconds, a subtract takes 15.6 microseconds, multiply 18.2, and divide clocks in at 23.4. A compute instruction takes 2.48 microseconds to set up, plus 0.8 microseconds for each operation, plus the normal cost of the operations themselves. This is worst case assuming direct addressing within the first 2048 words of the data table. Last but not least, the high speed exponentiation operation takes 897 microseconds, enough for almost 50 multiplies. Int-to-float takes 8.9 microseconds so be sure to type "0.0" for 0 for instance (I think this is one area where the tokenizer does this for you). Immediate addressing (using lots of registers instead of constants as recommended in previous posts) adds on 1 microsecond per variable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0