Ladder Logix Bool Addressing (Pointer AND(NOT31))/32

Hi all, i found a post from 2011 talking about bool addressing and was trying to figure out how it works. I am not trying to accomplish something but just trying to understand how this works. I am using Studio 5000 Rockwell.

You can find the old post that talk about it Link: http://www.plctalk.net/qanda/showthread.php?t=88479

The poster said
"Create a loop and index through:
XIC BOOL[Pointer] OTE "DINT[(Pointer AND(NOT 31))/32].[Pointer AND 31]"
Bool Is a structure of BOOL of 100
DINT is a structure of 5 dints

Example if the value of pointer is 64, it will write a 1 to bit DINT[2].0.

What I would like to understand is:
I tried changing the "(NOT31)/32" and the "AND 31" using other numbers to see how this reacts. The result is always different depending on the numbers I use.

Find attached a picture of the logic. Look at rung 11 i changed the values.

Thank you

Summary


That code only works if the divisor is a power of 2 (1, 2, 4, 8, 16, 32, etc.).


Detail


The [AND (NOT <DIVISOR-1>)] operation is a convenient shorthand for the MOD (MODULO; remainder) operation that only works when the divisor is a power of 2.



TL;DR


If the operation (a/b) = (a divided by b) = (c remainder d), then [a MOD b] is d,


If B is a power of 2 (1, 2, 4, 8, 16, 32, etc.), then [a AND (b-1)] is the same as [a AND (b-1)].



32d is a power of 2.


32d - 1d = 31d (decimal; base ten), which is 1fh (hexadecimal; base sixteen) or 0000 0000 0001 1111b (binary; base two).


The AND is required because integer division in Logix-land (dividend/32) will round the quotient up when the remainder is not less than half the divisor; the (AND (NOT 31d)) ensures the remainder in the dividend will be 0


When ANDing with the NOT of a number, e.g. 10, that is not one less than a power of 2, the resulting AND-mask will have bits in the "remainder" section that are not 0, and so will carry those bits from the initial value to the dividend, which will in turn affect the possibly-rounded result.






Speculative TL;DR


The rounding of Logix integer division was a design decision. Back when dinosaurs roamed the plants, there were no floating-point values in PLCs. However there was still a need to convert values to readable units e.g. 123 would represent 12.3. If 0PSIG yielded a 4ma signal was converted to 1000 counts by the PLC Analog Input Channel (AiC), and 34.78PSIG yielded a 20ma signnal that was converted 20000 counts by the PLC AIC, for a gain of about 46 counts per 0.1PSID, so ((counts-1000)/46) would yield the engineering value in dPSI, with rounding.

N.B. it may not work in 5000, but in 500/Micro,
will yield the same result as

drbitboy said:

N.B. it may not work in 5000, but in 500/Micro,

Code:

DINT[(Pointer AND (NOT 31))/32].[Pointer AND 31]

will yield the same result as

Code:

DINT[0].[Pointer]

Click to expand...

Great explanation in your first post by the way!

But, the second, apples to oranges. You don't need to point to the word in 500/SLC/Micro. One of the many differences between the two. I can say B3/324 if I want to, not so much in 5000.

Phrog30 said:

Great explanation in your first post by the way!

But, the second, apples to oranges. You don't need to point to the word in 500/SLC/Micro. One of the many differences between the two. I can say B3/324 if I want to, not so much in 5000.

Click to expand...

Right, good point, thanks!


Beginner I am; syntax and vocabulary a problem still.

drbitboy said:

The rounding of Logix integer division was a design decision. Back when dinosaurs roamed the plants, there were no floating-point values in PLCs......

Click to expand...

To be pedantic, the math instructions using all integer operands do not calculate as float then use rounding to store the result.

All integer math is done purely as integer math, and therefore the appearance of the result value is truncated.

So : 5/2 = 2 : 10/3 = 3

BUT ! If you have any one of the source operands as a floating-point (REAL) value, it forces the controller to "elevate" all the source operands to f.p., then do f.p. math. So it will calculate 5/2.0 as 2.5, and 10.0/3 as 3.3333

Then it looks at the destination data-type, and if it is integer, then the instruction will "round" the result before storage.

Logix500 : 2.5 will round up to 3, and 3.3333 will round down to 3

Logix5000 : 2.5 will round down to 2, and 3.3333 will round down to 3

Notice that the rounding produces different results in the different families .... This is because the rounding method used in Logix5000 series is the "Round-to-Even" method, so all numbers ending in exactly 0.5 (i.e. an odd number divided by 2), will be rounded to the nearest even number, not upwards.

This of course means you have to be vigilant in your data-type selections, and extra careful when dealing with PLC5/SLC500 converted code.

You don't even need to use math instructions to see this happening. Simple MOV instructions will exhibit the same.

e.g.'s
MOV, 24.5, dest_INT will result in dest_INT = 24
MOV, 25.5, dest_INT will result in dest_INT = 26

The logix5000 method of rounding is sometimes know as the Banker's Rounding method.

daba said:

To be pedantic ...

Click to expand...

... Logix500 DIV rounding, not truncation, always occurs and does not depend on operand types and subsequent MOV:





Environment: RSLogix Micro Starter Lite 8.30.00; MicroLogix 1100 B.


Sidebar: can anyone tell me how to MOV/COP/CPW S:13 and S:14 to a user file?

drbitboy said:

... Logix500 DIV rounding, not truncation, always occurs and does not depend on operand types and subsequent MOV:


View attachment 56661


Environment: RSLogix Micro Starter Lite 8.30.00; MicroLogix 1100 B.


Sidebar: can anyone tell me how to MOV/COP/CPW S:13 and S:14 to a user file?

Click to expand...

My apologies - been a long time since I did any 500 stuff, but what I said about 5000 rounding is true, so watch out if you ever migrate onto 5000.

daba said:

My apologies - been a long time since I did any 500 stuff, but what I said about 5000 rounding is true, so watch out if you ever migrate onto 5000.

Click to expand...

Actually it's nice to know 5000 does the "right" thing with integers.



I suspect the ca. 500 behavior is motivated by backwards compatibility to support legacy apps from a time when real values were but a dream.

drbitboy said:

Actually it's nice to know 5000 does the "right" thing with integers.

I suspect the ca. 500 behavior is motivated by backwards compatibility to support legacy apps from a time when real values were but a dream.

Click to expand...

I raised the issue because "back in the day" a colleague wrote some nifty code to convert old-style PanelView pseudo floating point numbers (where the digits and decimal point position were separate variables) to proper floating point values.

I can't remember the details, but I do know that it relied on the "round-up" at xxx.5, so a subsequent conversion of the code to Logix5000 made it so that it didn't work anymore.

We had great fun tracking down why the values entered on the PanelView were not being interpreted the same way....

Everyone, thank you very much. Great explanation DrBitBoy. Daba, thank you. I understand how it works now. Nice to see Phrog30 still helping(he commented the post from 2014).

Cheers,
Roibex