Inconsistent reading from encoder get rate

[rwood359]

I have been getting inconsistent reading for rate from the encoder get VI. The distance is good, but the rate will alternate between multiple values. The values are different depending on the Mode (1X, 2X, or 4X). I thought it was a difference between makes of encoders. It turns out that there is a LV problem that NI tech support has been able to reproduce. See my thread: http://forums.usfirst.org/showthread.php?t=11004

[Kevin Sevcik]

Have you checked the outputs of the encoders with an analog oscilloscope, AT the pins on the Digital Sidecar? That is, leave everything hooked up, and probe the pins while they're still connected. I've had issues with crosstalk between encoder signals before. It was extremely confusing until I probed my inputs with an O-scope and discovered the noise. You'd be looking for spikes in the A channel when the B channel is transitioning, and vice-versa. It's not necessarily something you'd see if the encoders were disconnected, as the O-Scope inputs are much higher impedance than the digital inputs on the cRIO. Nor would I trust that the USB NI device would necessarily be fast enough to pick them up.

This would explain the differing behavior at different resolutions, as the counter would be looking at different transitions on different lines in each of the modes.

Admittedly, when I saw this behavior, it would also throw the encoder counts off. That is, spinning the encoder X revolutions forwards, and X revolutions backwards would leave a significant remainder, as opposed to zero. Have you checked to make sure your encoder numbers are corresponding to reality, and that they're agreeing in each direction?

(Note: This is all speculation sight unseen of the FPGA code. It's entirely possible there's something in that code that's wonky instead.)

[rwood359]

Originally Posted by Kevin Sevcik

Have you checked the outputs of the encoders with an analog oscilloscope, AT the pins on the Digital Sidecar? That is, leave everything hooked up, and probe the pins while they're still connected. I've had issues with crosstalk between encoder signals before. It was extremely confusing until I probed my inputs with an O-scope and discovered the noise. You'd be looking for spikes in the A channel when the B channel is transitioning, and vice-versa. It's not necessarily something you'd see if the encoders were disconnected, as the O-Scope inputs are much higher impedance than the digital inputs on the cRIO. Nor would I trust that the USB NI device would necessarily be fast enough to pick them up.

This would explain the differing behavior at different resolutions, as the counter would be looking at different transitions on different lines in each of the modes.

Admittedly, when I saw this behavior, it would also throw the encoder counts off. That is, spinning the encoder X revolutions forwards, and X revolutions backwards would leave a significant remainder, as opposed to zero. Have you checked to make sure your encoder numbers are corresponding to reality, and that they're agreeing in each direction?)

I would have tried what you are suggesting had NI tech support not been able to reproduce the problem. They have reproduced the results including the speed changes by mode and the alternating speeds. The problem is not unique to our robot.

(Note: This is all speculation sight unseen of the FPGA code. It's entirely possible there's something in that code that's wonky instead.)

I believe the the FPGA is the most likely bad actor. In all cases the distance was correct to within 1-4 inches after 160-170 inches while the speed varied during the entire 15 second run. I found it hard to believe that noise would have a zero sum on all encoders over the 15 second period on dozens of runs that we made.

[Kevin Sevcik]

Originally Posted by rwood359

I would have tried what you are suggesting had NI tech support not been able to reproduce the problem. They have reproduced the results including the speed changes by mode and the alternating speeds. The problem is not unique to our robot.

Why wouldn't you believe that crosstalk between the channels would be a common occurrence that could hit NI as well as you? If it's inherent in the system design for some reason, or if the kit encoders are particularly likely to do so, then there's every reason to assume it would be duplicated on NI's end as well. I agree that it's unlikely, but I think it'd bear looking at if you don't have anything better to do but wait for NI to come up with something.

Originally Posted by rwood359

I believe the the FPGA is the most likely bad actor. In all cases the distance was correct to within 1-4 inches after 160-170 inches while the speed varied during the entire 15 second run. I found it hard to believe that noise would have a zero sum on all encoders over the 15 second period on dozens of runs that we made.

It's possible the FPGA is the culprit here, but I'm sort of doubting it. A period measuring interface like this isn't going to be terribly complicated. All you're doing is capturing the ticks elapsed between edges. All the mode does is change which edges you're looking at. If they're being extra tricky about it and adaptively shifting the number of edges they're looking at depending on how fast the wheel is turning, then I could see it there being a problem. But it just doesn't seem as likely to me.

Meanwhile, it's pretty possible for the encoder to trick you into thinking it's working when it's not. Depending on the timing of the spikes, the rising and falling edge of it could simply be nulling each other out as far as the distance is concerned. But it would play heck with your period measurements. Thus my concern. If you're not willing to attempt it, I'll grab an O-Scope and check the functionality on our robot in a few days if NI is still bug-hunting.

[rwood359]

Originally Posted by Kevin Sevcik

I agree that it's unlikely, but I think it'd bear looking at if you don't have anything better to do but wait for NI to come up with something.

Given the resources available to a high school on the North Shore of Oahu (a 20 MHz scope) I don't see any noise on any of the encoder channels. There is jitter, but nothing that looks like glitches.

If you're not willing to attempt it, I'll grab an O-Scope and check the functionality on our robot in a few days if NI is still bug-hunting.

If you have better instrumentation, perhaps you can take the time to download the program from the other thread, modify it to run on your robot and post the results of both the rate readings while the program runs autonomous and any waveform anomalies that you can see.

[rwood359]

I should have bet you lunch. Email from NI:
Hey Randy,

We figured it out. There is a problem with the FPGA timer averaging
involving channel swapping in specific cases. We're working on correcting
this issue and getting it out ASAP. Thanks for bringing this up! You have
the right mindset that this is what engineering problems really are like!
Kudos to you and your team for isolating this issue. Have a great
afternoon!

Regards,
John Sullivan
Applications Engineer
National Instruments