LabVIEW Encoder not reliably returning Rate

[lon.bushweiler]

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

[nchen99]

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
Format:
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

[apalrd]

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.

[apalrd]

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

[Doug Norman]

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.

[kamocat]

Originally Posted by Doug Norman

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.

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

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

[Greg McKaskle]

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

[billbo911]

Originally Posted by Greg McKaskle

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.

[cabbagekid2]

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).

Originally Posted by lon.bushweiler

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

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.

[jhersh]

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.

-Joe

[IisMathwizard]

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.