LabVIEW Encoder not reliably returning Rate

Hello, all.

Yesterday, I was testing and tuning some code on a test chassis. It has two Toughboxes and US Digital encoders (from AndyMark, 250 count) connected to the last four digital inputs on the Digital Sidecar. In code, I found that Encoder Get does not reliably return Rate: I always get Distance (which I found to be accurate in both forward and reverse, by drawing a line on the wheel and reading the distance both ways. Only one of the encoders returns rate, though, which puzzles me. What puzzles me even more is that when I set the Decoding Type to 4x (Because that uses an FPGA Encoder instead of an FPGA Counter) it works - but only until I reboot (when the problem happens again, and is fixed by switching back to 1x).

I dug into the WPI Encoder Get to see if there was a bug there. WPI Counter Get is returning a time of Inf, which Encoder Get is scaling to 0. I went into WPI Counter Get, but that just talks to the FPGA (meaning I cannot dig deeper). When I first had the issue, I probed the Dev Refs and the non-working encoder was using Cntr 1 while the working encoder was using Cntr 0. I did not probe them using the 4x decoding, but when using 4x decoding, the other side (the one that worked before) now has the issue.

I am sure all of the hardware works. I swapped the encoder wires (Between encoders) and the problem is not the encoder itself. I also know that I am not missing the B-phase, because it counts forwards and backwards. Everything I have looked at points to a bug in the FPGA encoder handling, I am using the latest 2011 image. (I guess I could try the 2010 image to see if it works, but I won’t have access to the robot until Monday).

Has anyone seen this issue? How did you solve it?

We had a similar issue in Java.

We had one returning a reasonably rate and a second encoder that was returning essentially garbage. We spent an hour debugging, swapping connectors and twiddling without any success.

We eventually just wrote our own rate functions and moved on.

We also noticed the encoder rate not working when using 4x decoding and also found the problem coming from the counter returning a time of Inf. The rate returned a value of 0. We changed the decoding to 2x and began receiving rate data.

I’m really curious if the same issue reproduces in any other language. There have been a few issues with the encoder rates in the past, but I had thought we fixed them all.

Have you tried modifying the averaging settings? How does that setting impact the behavior? Is there any interaction between the 2 resources… i.e. if you make one encoder 4X and the other 2X, does it still do this?


<edit>I assume you are using v25 since that is the only non-beta 2011 image</edit>

We ran into similar issues in Labview over the weekend. Like others, we wrote our own rate code and moved on.

Today we tested the 9 possible resolution combinations of our two encoders, which we’ll call Left and Right. When still, the encoder rates both return 0.0; when moving, the non-working one returns NaN (Not a Number). Here are the results:
Y = Yes/returned decimal value
N = No/returned NaN
LeftResolution, RightResolution: LeftResult, RightResult
4, 4: N, Y
2, 4: Y, N
1, 4: Y, N

4, 2: N, Y
2, 2: Y, N
1, 2: Y, N

4, 1: N, Y
2, 1: Y, N
1, 1: Y, N

I did some testing last night:
I found that, after booting up the robot as flashed (1x, 1x) it worked fine for about 2 hours, only rebooting once to change the battery.

After it stopped working, nothing would fix it. Nothing. I rebooted several times and re-downloaded the code. I set the counter to average 2 samples, as advised in this thread, and it worked.

I didn’t spend a whole lot of time testing, so I don’t know if the problem will re-appear after use. I will try tonight.

More testing today (about 3 hours or so):

  1. The encoder does not work, even averaging 4 samples (only 1 side dosen’t work, the other one is fine).

  2. After getting it to work, it worked reliably for about an hour before quitting. Then, after changing some settings (like the decoding type) and rebooting, it worked again (and didn’t quit while I was working on it)

  3. It seems very random, yet always affects the same side. Has anyone from NI been able to reproduce this problem?

  4. I am running image v.25

I have reproduced this and believe it is a bug in our code. I suspect we may document this rather than fix it for this season for two reasons:

  1. It would be a risky fix.
  2. There is the work around of writing your own rate code.

We just got started with the encoders that came in the KOP and are running into the same issue as everyone else. Our right side has both rate and distance but the left side only shows distance (rate is 0).

We’re going to write our own rate code and was wondering…since distance works for both sides if it’s as simple as storing the present distance into a variable and subtracting the saved (previous present distance) from the prsent distance. This will be in periodic task…so that you can divide it by the loop time interval to obtain rate.

We tried this for our working side and came up with similar results as the encoder rate output and are hoping to get it working on the left side.

One thing we noticed though (both with our rate and the VI rate) is that it’s REALLY noisy. When maxing out the joystick it bounces around anywhere from zero to 250 rpm (low gear). We had to up the sample average (which cleaned it up a little) and then added a point by point median filter. The only thing bad about this is that the filtered rate is only 100 rpm (can you imagine the noise to produce this!).

Anyone else have noise issues? We’re still not sure if the rate data will be workable after all this filtering. More testing today…

Might also be the placement of our wires…will test that today too.

One thing that was discovered is that every other encoder works… so if you allocate one and ignore it and then allocate another one, you can use the built-in rate function. Naturally this means you have half as many that you can use, but if you don’t need that many, this may be a good solution for you.


We’ve also had a problem witho our encoder. At first it was working well and i then went on to do some calibration with distance but after about 5 runs of calibration it was then only producing the values 0 and the resolution of .0038… something. We looked through my coding and found nothing wrong and then assumed hardware issued. Nothing was apparently wrong and we left the issue for later. Unfortunetly, someone wasn’t looking and ripped the wiring right out of the encoder. Nonetheless, it died. We reinstalled it but hadn’t wired it up again and tried calibration.

So, was there ever a fix for this?

Sorry. This was deemed not critical enough to fix in the middle of build season by Management. Fortunately there are 2 workarounds… implement the rate calculations yourself (high CPU burden and less accurate) or construct twice as many encoders as you need and only use the even ones (you can only decode half as many).


Can we create these on an unused DIO slot? Unused IO pins on the one DSC we have are hard to come by.

There was a new LV Update released a couple days ago.LV Update 3.1 for 2011.

Does anyone know if this issue was resolved with that update?

Do you have a single document describing all the bugs this season?

The Readme describes some of them, but leaves out CAN issues.
Is there a document that shows new issues, BEFORE a fix is created?

I do not believe this release has a fix for this bug. I saw a post from Joe stating who would not let him fix it. He also didn’t indicate whether he had really really fixed it this time, sorta fixed it, turned it into a feature, or other.

I agree there should be a known issues list along with workarounds. I’m not sure if the support forum has one. That would be the appropriate place to request one.

Greg McKaskle

It has NOT been fixed in this update!

From the 3.1 README:

Known Issues:
When you use more than one encoder, the rate indicator does not update for all encoders. To avoid this behavior, write your own encoder rate code.

The readme for LV Update 3.1 (included in the zip file) lists the encoder rate issue as a known issue and suggests that you write your own rate code.