L23E Compactlogix Noisy Analog Input

[Mickey]

L23E QBFC1B

I tried connecting all I+ to common but that did not help.

It's jumping from 28416 to 28500. It seems to just bounce back and forth.

Re-ran cable and grounded the shield at one end.

My suggestion is to jump in+ to in - , for each unused channel. Not to the common.

 

[drbitboy]

According to the documentation I can find, the input data for the embedded analog inputs is:

Bits 0-6: not used
Bits 7-14 (0x7-0xE): 8-bit analog input value
Bit 15 (0xF): sign bit (always positive)

           bits: FEDCBA9876543210

28416 in binary: 0110111100000000

28500 in binary: 0110111101010100

Fixed a minor typo in the above; added color and highlighting.

For the embedded eight data bits (7-14) of the analog input value, there is no change between the two input values. The unused bits should be 0, so perhaps that should be investigated.

Bit-wise ANDing of the input word with 7F80H (32640 decimal), and then, with that ANDed result, scaling 0 and 32640 (or 32767 as a proxy for 32768?) to whatever the engineering values are for 4 and 20mA, respectively, should give a reasonable result.

 

[joseph_e2]

Another option might be to DIV by 128 to right-shift the bits so old bit 7 is now bit 0. That might make the magnitude of the issue easier to see. I'm sure there's a technical reason for having the 8-bit value shifted left 7 positions but I've never known the advantage to having the unused bits be the least significant in the word rather than the most significant.

 

[drbitboy]

...but I've never known the advantage to having the unused bits be the least significant in the word rather than the most significant.

You should see the bit packing of spacecraft Radio Metric science instruments.

I would always AND-mask the input to avoid roundoff from stray bits in the division, and it can be scaled without the divide, but the divide does makes it easier to what being done.

Oh wait: how about a BTD to essentially perform the mask and divide in one instruction?

 

[parky]

@Joseph Actually, Siemens on their S5 system did something similar, the value was shifted left 3 places (or was it 4) & the 3//4 lower bits used for diagnostic bits i.e. wirebreak over/under error I believe so it is not that uncommon. But then they were 16 bit processors so I suppose it made sense to read them in at 16 bit (they did not have scaling in the cards had to be by functions or maths for scaling).

 

[desertsurf520]

No. There is no logic to extract those 8 bits. It just flips back and forth between around those two values.

I am not sure about what you found in the manual buts its not a tiny number. Its not the most significant number but its not the least. Its a tank measure chemical level and it just around .5 to 1". The signal is damped, the mA and VDC (1-5) are very stable. It doesn't appear to be in the instrument but its noise in the PLC.

Not sure if the grounding is acceptable.

 

[ASF]

No. There is no logic to extract those 8 bits.

Well, there's your problem. Look at the value in binary and watch how stable bits 7-14 are during this "variation" - bits 7-14 are your analog signal; everything else is irrelevant.

 

[drbitboy]

Well, there's your problem. Look at the value in binary and watch how stable bits 7-14 are during this "variation" - bits 7-14 are your analog signal; everything else is irrelevant.

^ This.

The non-data bits MUST be stripped (masked out, zeroed out) from the raw data word before interpreting the data in that word as an analog value.

The fact that any of the low seven bits are non-zero may indicate a problem with the module, but that is probably a side issue.

And to be clear, the values 28416 and 28500 represent exactly the same analog signal; the difference is due to neither noise in the electric signal itself (e.g. grounding issues) nor noise in the analog-to-digital conversion (e.g. shot noise) of that signal.

 

[desertsurf520]

There is an SCP block that scales the raw data into engineering units. But the raw only displays bits 7-14.

I really don't understand how there should be no difference between 28416 and 28500 counts. The raw should be proportional. 4mA = 6220.8 20mA = 31104 and anything in between should be linear output.

Ill send a picture in a couple hours of the block.

 

[drbitboy]

I really don't understand how there should be no difference between 28416 and 28500 counts. The raw should be proportional.

The question is which bits in the analog input word, e.g. Local:3:I.Ch0Data, are proportional to, and affected by, that analog current signal?

The 16-bit input word comprises three bit fields:

1. The middle bits, bits 7-14, containing the analog value
   1. The 8-bit ADC (Analog-to-Cigital Conversion) measured value, which value should be proportional to the current signal. The possible range of this value is 0-255 for 0-21mA, but in practice actual values will range from
      1. 49 at 4mA (49 ≈ 255 * 4mA / 21mA)
      2. 243 at 20mA (243 ≈ 255 * 20mA / 21mA)
   2. Before being placed into the 16-bit analog input word, the 8-bit value is multiplied by 128
   3. That multiplication shifts the 0-255 range to 0-32640, so 4mA will be 6272 (=49*128)* and 20mA will be 31104 (=243*128).
   4. The multiplication also effectively shifts the 8 bits by seven bits to the left, i.e. from bit 0-7 to bits 7-14.
2. The low 7 bits, bits 0-6, which have nothing to do with, and are not part of, the analog value from the ADC.
   1. The key thing to understand is that the input current signal and the converted 8-bit result could be constant, while these low 7 bits could change (and apparently they do change), even though the analog signal and the A/D conversion are putting the same 8 bits into bits 7-14.
3. The sign bit, bit 15. This should always be 0.

The difference between 28416 (= 128 * 222 exactly) and and 28500 (=128 * 222 + 84) is 84, which 84 is represented in the low 7 bit (0b1010100 => 64 + 16 4) and has nothing to do with the 4-20mA analog signal or the A/D conversion of that signal.



So if we scale the value without masking off those lower bits, that allows those effectively random bits 0-6 to affect the scaled engineering value from the SCP instruction. That is a mistake.

 

[desertsurf520]

That's interesting. I've been on different projects and have never seen those bits masked or at least appreciated they were.

It's an SCL instruction (FB)

 

[TheWaterboy]

This is an interesting thread. Why would an SCP instruction even allow that kind of aberration to occur, conversely why is there information in the analog register that is not part of the value itself?
You mentioned bit packing so I suppose its a timestamp, or random value used as heartbeat ?

 

[desertsurf520]

I think I found in the user manual where it indicates bits 0-6 need to be set to 0 or there will be a fault but there's a whole other manual on that.

But both Reals I'm using - 0-6 bits are already at zero.

This is an older controller where you cannot configure the range in the module properties. It's a compactlogix brick

 

[drbitboy]

I think I found in the user manual where it indicates bits 0-6 need to be set to 0 or there will be a fault but there's a whole other manual on that.

That's for analog outputs: if we write a 16-bit value to Local:3:O.Ch0Data that is not a multiple of 128, it causes a problem (not a fault, but it puts a 1 in the a field named something like .ChDataInvalid).

But both Reals I'm using - 0-6 bits are already at zero.

We're talking about words (16-bit INTs) not REALs.

Sidebar: the module should be assigning those seven bits' values to 0; if we are reading a value of 28500 for the .Ch0Data 16-bit word, then those bits are not 0 and something might be amiss with the module itself.

This is an older controller where you cannot configure the range in the module properties. It's a compactlogix brick

Those 8 bits (0:6 and 15) should be masked.

 

[desertsurf520]

That's so crazy! How am I supposed to know 0-6 need to be masked? Is there a manual on this?

So, we are using local 3:I.ch0data and ch1.
Local 3:I.ch0datainvalid is set to 1 (on both ch 0 and ch 1)