LabVIEW Encoder not reliably returning Rate

[Ryan Gordon]

NI really doesn't believe that this isn't important enough to fix?

[scooperman]

A look inside any industrial control encoder interface shows that typically there is quite a lot of digital filtering done on the A,B,I signals before introduction to the count tracking logic. Take a look at the old HP HCTL-20xx data sheet as an example. They employed multiple stages of demetastabilizing flip-flops, these are necessary because any input signal is asynchronous to the processor clock, meaning that sooner or later you will get a clock edge which is coincident with a signal edge, causing flip-flops to make wrong decisions. After the inputs are synchronized, then more flip-flops are needed to verify that the A,B signals are not in illegal states, because real encoders do not produce signals which are in strict quadrature. After the signals are verified good, then the up/down logic may increment or decrement the encoder tracking count. I suspect there is none of this within the NI device and we can't do much to fix it. On the electrical side, we can filter the power connections to the encoder, shield the wires, shorten the wires, and provide the correct pullup load (US Digital calls for 2.7K ohm pullups) that's about it.

[Greg McKaskle]

NI really doesn't believe that this isn't important enough to fix?

During the beta period and the FRC season, FIRST engineers and NI engineers discuss the risk and impact of all bugs that are found. Some bugs are worth fixing, but others are difficult or risky to fix. Sometimes, as long as the customer is aware of it and they have a good workaround, the best course of action is to leave things alone.

This bug was deferred, meaning it will be fixed after the season is over, and when side-effects from the fix can be discovered somewhere other than your robot on Thursday before an event.

Greg McKaskle

[Ryan Gordon]

Originally Posted by Greg McKaskle

During the beta period and the FRC season, FIRST engineers and NI engineers discuss the risk and impact of all bugs that are found. Some bugs are worth fixing, but others are difficult or risky to fix. Sometimes, as long as the customer is aware of it and they have a good workaround, the best course of action is to leave things alone.

This bug was deferred, meaning it will be fixed after the season is over, and when side-effects from the fix can be discovered somewhere other than your robot on Thursday before an event.

Greg McKaskle

This year encoders will almost certainly be used on most robots so I find it interesting that this was deferred so quickly. I understand NI's point of view (I know how you feel, I've worked in development for 6 years and SQA for 3 and I know how it's like when there are deadlines to meet) but as the end user this seems kind of like an easy fix to do. The hardware is the same as last year so it must be on the code side of things. It worked last year so there was working code before but this year it's broken so it must be a regression. Usually when I have to deal with regressions (unless code was refactored?) it's easy enough for me to do comparisons of code from when it did work to when it didn't and see what caused the issue.

Can an official help document, or something to that effect, be provided to teams? I've read through this thread and I think most of us are still at a loss on the best way to workaround this issue.

Best Regards

[cabbagekid2]

I agree. Some type of how to should be provided to teams for this "workaround". I have opened up the encoder VIs and I don't even know where to start changing things. It doesn't at all look like how we use to do it in C with the IFI controller.

For our noise issue, we are at 1x and still have 50% being noise. Not sure what to do about this now. Is it possible that there's dirt or something in the encoder when we put it together that could cause this? What kind of noise is everyone else getting? I would post a screen capture but our robot is being worked on and not operational at the moment.

[kamocat]

The workaround is to recreate the "rate" from the "distance".
You subtract the previous distance from the latest distance, and divide by the seconds in between the two measurements.

Or use CAN.

[cabbagekid2]

Originally Posted by kamocat

The workaround is to recreate the "rate" from the "distance".
You subtract the previous distance from the latest distance, and divide by the seconds in between the two measurements.

Or use CAN.

We tried this and our rate for left and right are not close. For some reason the encoder that doesn't read rate also doesn't read distance accurately. It reads, but it just thinks it's moving a lot more than it actually does.

[Ryan Gordon]

Originally Posted by kamocat

The workaround is to recreate the "rate" from the "distance".
You subtract the previous distance from the latest distance, and divide by the seconds in between the two measurements.

Or use CAN.

Distance is just an integration of rate; If distance works then rate must work too, right? Or more clearly written, if rate doesn't work then distance won't work either.

[kamocat]

Originally Posted by Ryan Gordon

Distance is just an integration of rate; If distance works then rate must work too, right? Or more clearly written, if rate doesn't work then distance won't work either.

If you look back at the first post, the issue with calculating rate is that the encoder returns an elapsed time of inf.
It appears that rate is calculated from differentiating distance, not the other way around.

[Ryan Gordon]

Originally Posted by kamocat

If you look back at the first post, the issue with calculating rate is that the encoder returns an elapsed time of inf.
It appears that rate is calculated from differentiating distance, not the other way around.

Looks like your right. However it seems like the issue stems even further then that based on cabbagekid2's tests... hmmm

[jhersh]

Originally Posted by cabbagekid2

For our noise issue, we are at 1x and still have 50% being noise. Not sure what to do about this now. Is it possible that there's dirt or something in the encoder when we put it together that could cause this? What kind of noise is everyone else getting? I would post a screen capture but our robot is being worked on and not operational at the moment.

It's possible that you have damaged the encoder and the signal coming from one of them is missing part of the signal. It could also be that the encoder is to far from he sensor and only partially reading it. This assumes that you are using an encoder that you build, not an enclosed unit.

If it really is digital switching noise on the wires, there are digital filters available to you in the hardware, but they are not enabled by default (since we have no idea what the frequency of your input signal should be). You can configure them with VIs in the Advanced Digital Input palette.

-Joe

[jhersh]

Originally Posted by kamocat

If you look back at the first post, the issue with calculating rate is that the encoder returns an elapsed time of inf.
It appears that rate is calculated from differentiating distance, not the other way around.

That is correct. The rate is calculated based on detecting when the position changes.

[jhersh]

Originally Posted by kamocat

The workaround is to recreate the "rate" from the "distance".
You subtract the previous distance from the latest distance, and divide by the seconds in between the two measurements.

I believe there may be another workaround, and that is to only use the "even" encoders. I'd have to test it out myself to say for sure, though. I'll look into it.

Originally Posted by kamocat

Or use CAN.

At the very least, that would be a great way to validate your encoder hardware vs. the decoding.

-Joe

[apalrd]

It worked two years ago.

It worked last year.

It does not work this year.

What changed? Why did you decide to re-write code that worked well? How did none of the beta test teams find this?

We consider encoders and potentiometers to be extremely valuable sensors. The inability to trust the WPIlib to handle encoders correctly is extremely annoying, as is the black-box nature of the FPGA image which prevents us from fixing the root cause.

Could you revert to last years encoder code? It is known to work, and I know of no differences between this years and last years (or the year before that).

[Alan Anderson]

Originally Posted by apalrd

What changed?

The FPGA image changed. That's where the rate calculation is performed.