There were many posts that were very useful regarding how to wire up the encoders (I believe, they were Andy Mark). But before we get into the fun stuff of splicing the wires, our adviser insists that we figure out how to read its output values, so Programming can do their job. Would anyone happen to know how we can test this?
Thanks much in advance!
Are you using labview or C++?
If Your using C++ wpilib has an encoder class.
Encoder *e = new Encoder(1, 2); //1 & 2 = your dig io pins for channel a & b
e->Start();
int distance = e->GetDistance();
// use distance for whatever you want
The output values are easy to read. But they can be done only once you splice up the wires. I suggest you probe it on to a Oscilloscope and look at the quadrature signals. As you ramp up the motor, the signals should come closer to each other. If there’s not a ton of noise, and if it looks “alright” then you should splice it. I wish they gave us two PWM outs instead of 1 4-lane cable.
Once you splice it and connect the correct A & B ports, then it’s really simple, just go to WPI Libraries -> Sensors -> Encoders and do the usual thing with Open, Get, Close. Though, this time, you may want to fiddle around with the Configuring the Timers.
It’s pretty easy in labview. There’s an encoder vi in the library. Just tell it what digital IO pins you’ve connected it to and that’s all there is to it.
how accurate are your encoders? Our mentor says 1 of the values wasn’t returning that well…
I think he said it know the distance but not the rotations or something…
Also do these break easy? im guessing we should have extras?
The encoders do not return the correct value for rate.
Here is the announcement of the bug:
http://forums.usfirst.org/showthread.php?t=11343
Here is the thread that isolated the bug:
http://forums.usfirst.org/showthread.php?t=11004
ok so reading through the isolated thread, dont really see how to fix the issue…
sorry just clarify what you meant, isolate as in just push the problem aside? or isolate as in fix the rate problem?
By “isolated the bug” he means that it discovered the source. As indicated in the first thread that he linked to the bug is going to be addressed in the next software update.
ok thanks a lot.
does anyone know when the next update will be coming out?
I hope soon for our sake!
It went beta the first of last week - I thought it was going to be released by the end of the week.
The thread on the FIRST forums suggests a new update will be out tomorrow (Monday). The issue should now be resolved.
It’s supposed to come out sometime tomorrow (Monday) and the encoder problem is fixed. If you were just reading distance or the count, that has always worked. The problem was just with reading the period or rate.