running 2 encoders - problems

[wireties]

We are using 4 encoders on 4 nanoboxes. All 4 are wired the same and wired correctly (triple checked). We can see the A and B pulses (with a scope) on all 4 channels. But only 2 servos (using PID controller) are working.

We commented out the enable call for the PIDcontroller classes, ran the motors at a constant speed (manually with the motor classes) and are printing out the encoder values using the GetRate method. Two of the values are NaN which explains the problems with the servos.

Anyone have any clues? I guess we can start replacing encoders but the outputs looks good.

TIA

[Mtg Ruler]

I remember reading awhile back that there is a bug that only allows one encoder rate to be read (at least in LabVIEW, I don't about C++).

I would try getting the values as a distance, then making your own rate functions to determine velocity.

[wireties]

When I change the Encoder constructor and ask for k2X the channels that did not work (with 4X default) are now working!! And the channels that were working (with k4X default) now display NaN.

Something is wrong inside the encoder libraries? I am pretty sure we have the latest greatest robot image because we are using the new Encoder class that can act as a PIDsource.

We are using DIO channels 1-8 if that matters (hope not). But we moved them around a little to see what is wrong and the errors did not change or move to another channel.

[wireties]

Originally Posted by Mtg Ruler

I remember reading awhile back that there is a bug that only allows one encoder rate to be read (at least in LabVIEW, I don't about C++).

I would try getting the values as a distance, then making your own rate functions to determine velocity.

Hmmm - that could be it. If the problem exists in LabView, it also will exist in C++. I'm sure they both use the same FPGA image. I missed the threads about the bug in an earlier search.

[Tom Line]

If you do a search you will find several lengthy discussions on this. I believe it's a known problem with the wpilib and exists in all langauges if you are using the get rate.

Your best bet is to use the count and construct your own getrate using a ms timer.

[wireties]

No combination or order of instantiation gave us a working solution - switched to a software rate calculation and moved on.

[Alan Anderson]

The unreliable built-in rate calculation is most likely a bug in the FPGA code. It's going to be left as it is until after competition season, to keep from introducing other problems accidentally.