Created Date: January 29,2009

Created by: KPrice

sii, yes, what is happening is: any number in V6300 (less than 9999) divided by K9999 will always be less than zero. This means the accumulator will hold zeros. (the stack holds the remainder) Then zero times K50 will = zero. That is why in scaling (or any math) you have to watch your order of operations. In BCD math there is no decimal points used in the calculations (the division remainder goes to the stack). Hope this helps.

Created Date: January 29,2009

Created by: worknhard9062

Here's another way to say it... (oh and yes, I think KPrice meant "less than one ")

BCD math is INTEGER math, which means no fractions. Use the Calculater.exe program built into Windows to illustrate the example. Enter 9998/9999 into the calculator and you'll get something like 0.9998.... a number less than one , therefore a fractional part. Integer math doesn't handle fractions. To illustrate, convert the decimal number on Calculator to HEX which doesn't support fractions (now it's 0). Go back to decimal and multiply by 50 and get 0.

In general it's a good idea to put your multiplies before your divides when doing integer arithmetic. This is true regardless of your programming platform. In other words this doesn't pertain just to PLC's.

Happy programming!

Created Date: January 29,2009

Created by: allukes

One trick I learned back when all you had was integer math, to prevent losing precision when performing integer division, is to multiply first by factors of 10 (10,100, 1000) before doing the division. Then either keep track of the decimal point or divide by the same factor at the end. Although most of the time, I just kept track of it when displaying it on the HMI. You also have to use the Double Word math instruction and have an idea of what the range of values are for your terms.

Created Date: January 29,2009

Created by: AZRoger

... In general it's a good idea to put your multiplies before your divides when doing integer arithmetic. This is true regardless of your programming platform. In other words this doesn't pertain just to PLC's.

I agree up to a point. You still have to watch out for overflow on the multiplies. If you have the possibility of exceeding 8 digits (PLC BCD) with all the multiply terms, you'll need to throw some of the divides in along the way. Integer math also doesn't do rounding . In your example, you'd want to add in K4999 before the divide K9999. In general, you have to add in half the divisor before doing each divide. Accuracy will still be ... not so good.

Adding some 0's (as allukes suggested) and keeping them all the way to the user interface will improve accuracy. Converting to REAL before the math will help even more. But you still have to worry if any of the values you use in the math expression can be very close to zero or close to the maximum that can be expressed.

Roger

Created Date: January 29,2009

Created by: bcarlton

I think in general the last few threads make it obvious that the programmer must study about numbering systems and about how numbers are handled in the PLC. This is true even of computers in general. Every numbering system has limitations. Every computational engine has weaknesses. For best operation know your numbers and keep some mind as to the operations on them.

For the AutomationDirect PLCs in particular you must know BCD, binary/decimal, Real. You must understand how these number types and their storage requirements (including the 'double ' forms of the BCD and binary formats) and limitations. You must understand the different math instructions and their expected operand and resultant types. You must understand the forms and limitations of conversion between the types.