Allen Bradley 1762-IF2OF2 12 bit resolution, but 0-32760? Does anyone know why?

TimWilborne · Jul 24, 2019

Hi guys, I'm working on an article about the bit resolution and precision of a 1762-IF2OF2. I know it is 12 bit which is 0-4096 and that the data is shifted by 3 bits to take up bits 3-14, making the range 0-32,760 instead. But I'm not sure I fully understand why this was done.

Does anyone know why this was done? Here's the explanation of the shift, I just think it leaves a big question lingering as to why. Obviously it makes the value look more precise, but that just doesn't seem like the correct answer.
https://www.theautomationstore.com/rslogix-500-analog-bit-resolution-and-precision/

GaryS · Jul 24, 2019

I can' say for sure but I would think is the resolution of the chip they use in card
12bit analog to digital are more common and cheaper, while they do make higher resolution chips they start to get pricey

TimWilborne · Jul 24, 2019

Yes, but 12 bit is 0-4096. There is a 3 bit offset making the 12 bits use bits 3-14, changing the range to 0-32760. Why?

danw · Jul 24, 2019

Probably ease of data transfer over the backplane bus and within the operating system, where data words are likely 2 byte/16 bit words. Sign bit uses the MSB.

Ken Roach · Jul 24, 2019

I don't think there's a low-level technical reason, but rather a collection of decisions for compatibility and history.

MicroLogix is based on the SLC-500 operating system, of course, and the old 4-channel analog modules for the SLC used 12-bit A/D converters and provided a value between 0 and 4095.

But the newer MicroLogix 4-channel analog modules (1762-IF4) had higher resolution; 15 bits plus sign.

So when they built a low-resolution combination module for the same platform, the question arose; do we make this compatible with old examples and legacy code from the SLC-500, or do we make it as close as possible to its 4-channel, 15-bit siblings ?

The evident decision was to just shift the data left, so that the full-scale value was similar despite the resolution being lower.

TimWilborne · Jul 24, 2019

Ken Roach said:
I don't think there's a low-level technical reason, but rather a collection of decisions for compatibility and history.

MicroLogix is based on the SLC-500 operating system, of course, and the old 4-channel analog modules for the SLC used 12-bit A/D converters and provided a value between 0 and 4095.

But the newer MicroLogix 4-channel analog modules (1762-IF4) had higher resolution; 15 bits plus sign.

So when they built a low-resolution combination module for the same platform, the question arose; do we make this compatible with old examples and legacy code from the SLC-500, or do we make it as close as possible to its 4-channel, 15-bit siblings ?

The evident decision was to just shift the data left, so that the full-scale value was similar despite the resolution being lower.

Thanks Ken. I figured I was missing the obvious. I didn't think about matching up to the 1762-IF4's units.

Now why didn't they continue that with built in analog?

Peter Nachtwey · Jul 24, 2019

Allen Bradley 1762-IF2OF2 12 bit resolution, but 0-32760? Does anyone know why?

Yes! We do this internally on our products. Analog inputs are 'normalized' by shifting them left to make signed or unsigned numbers. We shift unsigned inputs left 15-number of bits and signed inputs 16-number of bits. This way all our code is written for 0-32767 or -32768 to +32767. Sometimes we filter the inputs. The lower bits arer used then. When computing analog outputs for a servo valve or motor, the outputs are always normalized to be -32768 to 32767. If the output has only 12 bits then only the upper 12 bits are used. However, we keep track of the lower bits to provide a PWM effect on the lower bits.

Things have changed with the new 32 bit CPUs. We now have 18 bit analog inputs but the values are still shifted left

I think this is common in motion control. It doesn't surprise me at all that others would do the same. This way the main part of the code always treats the values the same regardless of the number of bits the inputs have.

TimWilborne · Jul 24, 2019

Peter Nachtwey said:
Yes! We do this internally on our products. Analog inputs are 'normalized' by shifting them left to make signed or unsigned numbers. We shift unsigned inputs left 15-number of bits and signed inputs 16-number of bits. This way all our code is written for 0-32767 or -32768 to +32767. Sometimes we filter the inputs. The lower bits arer used then. When computing analog outputs for a servo valve or motor, the outputs are always normalized to be -32768 to 32767. If the output has only 12 bits then only the upper 12 bits are used. However, we keep track of the lower bits to provide a PWM effect on the lower bits.

Things have changed with the new 32 bit CPUs. We now have 18 bit analog inputs but the values are still shifted left

I think this is common in motion control. It doesn't surprise me at all that others would do the same. This way the main part of the code always treats the values the same regardless of the number of bits the inputs have.

Thanks for the explanation Peter. It makes more sense to me now.

parky · Jul 25, 2019

Interesting.... Siemens use the lower 3 bits as diagnostic bits, years ago this foxed me a little (RTFM doh..) So in that case we used to move the lower 3 bits to flags for diagnostic purposes then shift the data to remove them giving the correct value.

Allen Bradley 1762-IF2OF2 12 bit resolution, but 0-32760? Does anyone know why?

TimWilborne

Lifetime Supporting Member

GaryS

Member

TimWilborne

Lifetime Supporting Member

danw

Lifetime Supporting Member

Ken Roach

Lifetime Supporting Member + Moderator

TimWilborne

Lifetime Supporting Member

Peter Nachtwey

Member

TimWilborne

Lifetime Supporting Member

parky

Member

Similar Topics