Two of Five encoders are giving identical values

[Analog]

We've got an encoder on every wheel and one for steering. We noticed that two of the five encoders return the exact same value. It is not a hardware issue, as we have isolated each one by physically unplugging them etc. It seems the software sees them as the same, even though they are declared and started separately.

In addition, we can 'control' which two mimic each other. Its always the first and the last in the code where they are declared. We verified this by rotating the declaration list, and sure enough, they followed each other - which further confirms that it has nothing to do with the hardware.

Any ideas?

[TimCraig]

Originally Posted by Analog

Any ideas?

I wasn't able to find exactly why it's happening without really digging, but I'd guess from some of the code in ChipObject\tEncoder.h that there's a limit of 4 encoders built into the system. If you look at the #defines at the bottom of the file, they go from Encoder0 through Encoder4. My guess is that since it's the first and last that you get reading the same value, that when you try to add the 5th encoder to the system, you get a "wrap around" situation and it replaces the first one and the instances of Encoder that you're holding in your code representing the first and fifth end up pointing to the same underlying I/O points. It appears to have something to do with kNumSystems but I can't find where a value is assigned to this. I guess we're not privy to the source for those modules and only have the compiled version in the library and the class in the header is our portal. Makes debugging a bit hard.

[AustinSchuh]

I was talking with Brad Miller last night, and there is a 4 encoder limit. With the newest version of WPILib though, there is an optional parameter you can pass to the constructor that will let you have more than 4 encoders.

The parameter is "EncodingType encodingType". The documentation in Encoder.cpp is pretty good in this respect and from it you will be able to figure out the side effects of initializing an encoder with the k1X or k2X flags instead of the default k4X flags.

[Joe Ross]

From the Programming Guide:

There are four QuadratureEncoder modules in the FPGA and 8 Counter modules that can operate as quadrature encoders. One of the differences between the encoder and counter hardware is that encoders can give an oversampled 4X count using all 4 edges of the input signal. Counters can either return a 1X or 2X result based on one of the input signals. If 1X or 2X is chosen in the Encoder constructor a Counter module is used with lower oversampling and if 4X (default) is chosen, then one of the four encoders is used.

The LabVIEW encoder open will return an error if you try to allocate more then 4 encoders (with 4x). In the C++ Encoder::InitEncoder, there is a comment that says

//TODO: need to check for errors here

[M.Rehberg]

Our development systems have update 3, however when we try to use the "k4X", or "k2X". The compiler returns the following error:

C:/WindRiver/workspace/Encoders/encoders and gyro.cpp:35: error: `k2X' undeclared (first use this function)

[M.Rehberg]

Looking into this further it seems that the WPILib has added this parameter (k1X, k2X, k4X) to CouterBase.h, Encoder.cpp, and Encoder.h. However I don't see it in /ChipObject/tEncoder.h

What are we missing here??

[Ken Streeter]

Originally Posted by M.Rehberg

Our development systems have update 3, however when we try to use the "k4X", or "k2X". The compiler returns the following error:

This is a scoping issue. We found that we needed to qualify the constant with the class where it is declared. I suggest using one of the following:

  CounterBase::k1X
  CounterBase::k2X
  CounterBase::k4X

--ken

[Analog]

Originally Posted by Ken Streeter

This is a scoping issue. We found that we needed to qualify the constant with the class where it is declared. I suggest using one of the following:

  CounterBase::k1X
  CounterBase::k2X
  CounterBase::k4X

--ken

Ken, I really appreciate your insight. Thanks.

[1jbinder]

Thanks for this insight. I made the code work. When you have a second could you explain why we need to do this in our code, but the library does not have to in encoder.cpp

Thanks
Julian
Team 852

[Ken Streeter]

Originally Posted by 1jbinder

Thanks for this insight. I made the code work. When you have a second could you explain why we need to do this in our code, but the library does not have to in encoder.cpp

Encoder.cpp inherits from CounterBase, so variables and constants defined in CounterBase can be referenced from within the Encoder without the need for explicit namespace references.

Your code, however, was presumably in an object which was not inheriting from CounterBase, so the explicit references are needed so the compiler knows where to find the value for k1X, k2X, k4X, etc...