Quote:
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.
