From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-11-2014 12:28 PM - edited 07-11-2014 12:40 PM
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?
07-11-2014 03:44 PM
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
07-11-2014 05:04 PM
Welcome to the world of encoder jitter 🙂
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.
07-11-2014 09:45 PM
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.
07-12-2014 03:14 AM
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
07-14-2014 07:43 AM
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!)
07-14-2014 08:28 AM
Have a look at http://www.ni.com/example/31251/en/
07-14-2014 08:42 AM - edited 07-14-2014 08:42 AM
try the attached filter. try setting n=5 to start with and move higher if you still have issues.
07-14-2014 09:42 AM
Mine can easily be made shorter by changing the U32 values to U16 or U8.
Bruce