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

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...

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



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.



I would at least extort a lunch. Your engineer owes me a lunch. You can collect.

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.

Just to add to this, there is an operator to do an exponential expression (x**y) see pictures below

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.

[i]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.

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.

X * X will execute considerably faster (as much as 20x faster) than X**2.

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).

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.

You forgot a H^2 term but otherwise that is why the engineer owes someone lunch for doing his job.

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

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

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.

Hi Dwalter,

Can you explain a little bit please.

A= ?
B= ?

I believe he's replacing r*r with A and b*b with B.

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/

Thats good to know - I will definitely keep it in mind if I ever need to do exponents in any of our RMCs.

I always optimize any polynomials I may do using Ax**2 + Bx + C = (Ax +B)X +C to avoid using exponents.



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?

Well that just shows you are trainable and smarter than the average bear. :)
Actually we have a poly function poly(x,a,b,c,d,e,f,g,h) that is faster yet. If the order of the polynomial is variable so you can use just poly(x,a,b,c); Most people don't expect to find a function like this so they don't look.


The difference is that 1/N can be computed at compile time and then executed as a multiply during run time. I just looked up the timing on the RMC75E. The CPU has a 360 mhz clock and it takes 3 to 4 clock cycles to execute a floating point operation unless it is a divide. That takes 33 clock cycles but there is a bigger difference in the real through put due to pipelining. The ratio of execution times of divides to multiplies grows when pipelining is taken into account. Since the pipeline is several stages long the real time between a multiply can be one or two clock cycles. That is pretty fast.


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.

/* [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$

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.

Sure it does. There is little difference between the compiler generating real code, tokens, p-code or what ever.


:(, but back then just having a compute block made the PLC5 far superior at doing math however slow it may have been.


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.

Agreed. However, structurally, you'd see funny things go on with your CPT blocks (expressions get changed) if it worked this way, and probably someone out there would have a fit. "Compilers" for interpreters in the early 80's when the PLC-5 came out were little more than simple tokenizers with no actual optimizer to speak of. The only place you saw threaded interpreters was in Forth (which was considered highly innovative).



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.