Quote:
Originally Posted by jhersh
That's an interesting pattern you're seeing there. I'll try to reproduce it tomorrow.
On thing you can tell me is if you think it's related to the order in which they are constructed or the specific hardware that gets allocated. For instance, if you were to allocate one, delete it, then allocate it again, would it work? Or does it only work because the 2nd hardware resource is allocated due to the first one being in use?
Thanks,
-Joe
|
I'm not sure about the deletion. We aren't doing anything to explicitly delete the first one we construct before constructing the next one, and it is probably unlikely the garbage collector runs between those two lines every time.
For your testing, all the encoders will look ok at rest, returning 0.0. It isn't until they are pulsing that getRate starts to give NaN on the bad ones.
Also, the second encoder we construct works for us even if the digital IO ports are unrelated. We first noticed the pattern by doing the following with two completely separate encoders.
Encoder rightEncoder = new Encoder(rightArgs);
Encoder leftEncoder = new Encoder(leftArgs);
With the above code only the left encoder getRate worked. So we tried swapping the order of construction.
Encoder leftEncoder = new Encoder(leftArgs);
Encoder rightEncoder = new Encoder(rightArgs);
After doing the swap the right encoder getRate started working and the left's started returning 0.0 or NaN. After that, we tried the double construction for each encoder, that I described in the first post, which gave us two encoders with working getRate's!
I'll have access to the code this evening so if there might be anything interesting about the specific args we use they can get posted then.