Rounding a CPT result to nearest whole number

I've done a little research on this but still haven't found an answer.

I'm trying in RSLogix 500 on a SLC 5/04 to calculate an integer I want to use elsewhere in the program. I happened upon the Math overflow of trying to put my non-whole result in an integer file. The question I have is what do I have to do to get a whole result I can use. I do not want to use floating points and can't believe I have to.

Right now with the integers in the formula I am using, I have to divide by 1.0472 (inches per pulse) to calculate the number of pulses before taking the next action. The result right now is 133.3678

Why can't I force the result to be rounded, in this case 133, and stuff the result in an integer file?

Why cant you use floating point to take the result then just move (or move with mask) the result to get the desired integer? Doesnt seem to be more than a couple more rungs involved to do that.

I can, I was just looking for a leaner, meaner (presumably better) way. Maybe it doesn't exist.

I'm not sure what overflow you're getting. You can mix integer and floating-point arguments in a DIV instruction and if you make the destination an Integer the resultant is rounded.

I'm sure I'm missing something in your problem. Post more !

[attachment]

You are right Ken.... but.....

You are correct. Entered properly, it does round the result. Now what I need an explanation for is the difference between these two expressions.

Here is the CPT that faults the SLC and gives me a reult of 3:

( ( N9:2 + ( N9:1 * 2 ) ) * 1000 ) | N9:49

Now with the addition of a decimal and following zero in a couple spots, it works, rounding the result and placing a 133 in my integer file:

( ( N9:2 + ( N9:1 * 2.0 ) ) * 1000.0 ) | N9:49

When I took the first formula that crashes the SLC and put the result in F8:0 instead of N9:22, it changed my formula. Then when I switched back to putting the result in N9:22, it worked with the changes.

So the big question is, why does it see a difference in the formulas that are mathematically the same?

PS - Ken, thanks for the very graphic and personalized reply, it definitely motivated me to tinker more and fix the problem.

If I had looked more closely I would have seen the reference to CPT in your post header and insisted on the formula itself; instead I answered a question you didn't ask !

My guess is that the SLC will fault with an overflow if any of the intermediate results in the CPT instruction creates an overflow. Specifically, if you have a INT1 * INT2 = INT3 expression and the result is greater than 32767 you will have a fault.

Evaluate your original CPT instruction step-by-step:

(N9:1 * 2) = A
(N9:2 + A) = C
(C * 1000) = D
(D | N9:2) = Result

All the arguments in every step of that CPT are Integers, so their results are evaluated as Integers. If C gets greater than 32, kablooey; D will be greater than 32767 and you'll get an overflow.

If you change the constant from 1000 to 1000.0, the intermediate result D will be a Float, thus no overflow.

When you entered a Floating Point resultant for the overall expression, RSLogix was just being heavy-handed by converting all of the constants to Floats. Probably that's just a software engineer's idea of keeping CPT users out of trouble.

It's a little late so I can't quite decipher your equation but it looks like perhaps the SCP (scale w/ parameters) instruction could help you out.???

The help screen will do a better job of explaining than i will so look there

Coffee: Nature's perfect food.

My excuse is that I just missed the last bus home. Isn't it a little late for you fellows to be up enjoying 16-bit math ?

zzzzz

I'm in the Mountain zone, and work until 1:00AM, so I'm still on the job. I haven't checked yet, but I like your answer about the interim results within the equation being floating point. That seems to make sense. I can't say I didn't learn anything today.

Thanks Again.

I'll also look into the SCP function to see if it applies to what I need.

The SCP instruction will work exactly as the CPT instruction as regards to rounding and floating point math.
If there is only integers in the parameters, then the result and intermediate values will be calculated with 16-bit precision and range, thereby opening up for a possible overflow.
If just one of the parameters is a float, then the entire calculation will be done with float precision and range.

It is a good idea to use floats in all math instructions, even if the result will be put in an integer. To my personal opinion it is far more important to avoid a possible stopped production, than to pursue the "leanest" code. Being the author of the program means that you will get a lot of flak when YOUR program crashes. If you are an OEM supplier, then your crashed program can be on the other side of the globe with many days of stopped production as the result.

By the way, it is also a good idea to evaluate the math overflow bit in the last rung of file 2. If the bit is set, then unlatch it and set an appropriate alarm in your HMI. In this way you will avoid crashes caused by rounding errors. You should still use floats wherever possible to ensure the proper functionality of the math in your program.

Thanks, Jesper I will take your advice. This site is the greatest thing since...... Molson Canadian!

To keep the processor from faulting out and stopping I routinely reset the overflow bit at the end of every program. This keeps you running, but you may have to do some other checks to keep the overflow from interfering with your logic.