Log in

View Full Version : Reading Encoders?

Questions4mQ202
21-01-2009, 21:24
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!
elcron
21-01-2009, 21:53
Are you using labview or C++?

If Your using C++ wpilib has an encoder class (http://users.wpi.edu/~bamiller/WPIRoboticsLibrary/).

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
keehun
21-01-2009, 23:03
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.
drkiraco
23-01-2009, 19:19
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.

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!
dani190
23-01-2009, 20:51
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?
rwood359
23-01-2009, 22:22
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
dani190
23-01-2009, 22:27
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?
Vikesrock
23-01-2009, 22:40
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.
dani190
23-01-2009, 22:41
ok thanks a lot.
windell747
23-01-2009, 23:51
does anyone know when the next update will be coming out?
Jared Russell
24-01-2009, 22:23
I hope soon for our sake!
rwood359
25-01-2009, 01:57
It went beta the first of last week - I thought it was going to be released by the end of the week.
Jared Russell
25-01-2009, 20:28
The thread on the FIRST forums suggests a new update will be out tomorrow (Monday). The issue should now be resolved.
BradAMiller
25-01-2009, 20:47
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.