LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

cRIO FPGA digital quadrature encoder count flutter

We have a problem we have been running into with a recent project. We are currently using 2 Micro-E linear digital encoders with .05um resolution and 1.8MHz output freq, hooked into a NI 9411 card in a cRIO 9075. The encoders use TTL logic, wired single-ended. I created a basic FPGA VI that reads the digital signals and increments or decrements 2 separate counters (1 for each encoder). This VI is attached below. The two counters at the bottom of the loop are the problematic ones.

 

The count successfully increments and decrements when the encoder readhead is slid up or down the tape scale. Our problem is that our count randomly "flutters" when the encoder readhead is sitting completely stationary. Sometimes it's a flutter of only 1-10 counts, + or -. Then randomly it will shoot up hundreds or thousands of counts, then stabilize again, then flutter again, rinse, repeat.

 

We originally thought that the encoders, being so sensitive, were the problems, but after a series of scopes and tests with Copley equipment both differential and single-ended, we have come to the conclusion that the encoder is good and the problem lies somewhere in the National Instruments equipment or software.

 

We also wired a Renishaw 32768 count rotary encoder into the 9411 in the same ports as the Micro-E encoders to test the validity of the LabView code, and it worked flawlessly. Something with these Micro-E encoders and Nat

 

Any insight into what the problem could potentially be?

0 Kudos
Message 1 of 9
(1,533 Views)

I would guess you have some noise on your digital signal.  I would add a digital filter right after you read the inputs.  I have attached an example that worked well for me.

 

Bruce

Bruce Ammons
Ammons Engineering
Message 2 of 9
(1,514 Views)

Welcome to the world of encoder jitter Smiley Happy

 

Digital encoders work by taking the analogue signals produced by the encoder and then dividing them into smaller units. Typically, the analogue signals will be a sine and a cosine signal. Plotted against each other as a function of time, they'll trace out a circle. One revolution of the circle is equal to one period of the scale.

 

Digital interpolation works by taking that circle, then dividing it into smaller chunks. For instance, if you have a 0.1 um resolution digital readhead reading a 20 um scale, it's dividing that circular signal into chunks 1/20th of a revolution each.

 

Now imagine that there's noise on the analogue signals that rotates around the signal into the next 1/20th chunk. The interpolator doesn't know whether that's noise or genuine rotation, so the count may jump without apparent movement. This is called jitter.


You could check that your signals are terminated as specified in the installation guide; also, that there's no obvious sources of noise nearby. You could also try differentially receiving A+/A- signals to reduce the effects of noise. Check the jitter spec for the unit too.

 

Another possibility is bounce on the digital output of the readhead. Typically, you'll employ a minimum pulse width filter - i.e. you only react to edges where the signal stays constant for N samples afterwards.

---
CLA
Message 3 of 9
(1,508 Views)

i agree with bruce.  the first fix would be to use differential signals.  if your encoder to does not generate differential signals, i would filter the inputs like Bruce suggests.  however, you have to be carefull of the maximum transistions per second required vs the sample frequency.

 

Stu
0 Kudos
Message 4 of 9
(1,498 Views)
Highlighted

Just re-read my reply this morning and realised I'd meant a 1 um resolution digital readhead reading 20 um scale corresponds to 20x interpolation Smiley Embarassed

---
CLA
0 Kudos
Message 5 of 9
(1,482 Views)

First I'd like to thank you all for your suggestions, it's definitely getting us closer to an answer.

 

Bruce, I tried implementing your digital filter and it works awesome...except unfortunately it's not fast enough. The signal is now extremely stable, but the side effect is we now have to move the readhead incredibly slow for an encoder read to occur. 

 

Is there a filter that is quicker than the U32 filter? I tried to see if I could create my own but it looks like the "Rotate Left With Carry" is limited to U32 only.

 

(By the way, as you can probably tell I am a LabView noobie, my training is in HLL's so I appreciate the assistance!)

0 Kudos
Message 6 of 9
(1,452 Views)

Have a look at http://www.ni.com/example/31251/en/

---
CLA
0 Kudos
Message 7 of 9
(1,422 Views)

debounce.png

try the attached filter.  try setting n=5 to start with and move higher if you still have issues.

Stu
0 Kudos
Message 8 of 9
(1,439 Views)

Mine can easily be made shorter by changing the U32 values to U16 or U8.

 

Bruce

Bruce Ammons
Ammons Engineering
0 Kudos
Message 9 of 9
(1,424 Views)