E4T Encoder Help

Technical Sensors
1

We are having issues getting values from our am-3132 (E4T) encoder, connected to our ToughBox Mini with Dual CIM input.

We currently have it wired as follows:
Orange Wire --> DIO 5 / 5V
Brown Wire --> DIO 5 / GND
Yellow Wire (Channel B) --> DIO 5 / S
Blue Wire (Channel A) --> DIO 6* / S

*Nothing is wired to GND or 5V

Code (Java):

Encoder enc = new Encoder(5,6); //robotInit()
enc.reset() //robotInit()

enc.getDistance(); //teleopPeriodic()

So far we have tried:

  1. Switching the DIO ports used
  2. Swapping Channel A and B wires
  3. Reading DIO ports using get() --> We found DIO 5 oscillates between true/false when the wheels are turning, DIO 6 stays constant false

Is there something we’re overlooking?

2

Is this in a looping section of your code (like teleop periodic)? If so, you’re calling reset every time before you get your distance, so it gets reset to zero every time.

Also, what do you mean nothing is wired to GND and 5v? It’s clearly being powered as you can tell it’s oscillating.

3

Reset is called during robotInit only. Calling getDistance() is the only thing that’s done during looping teleop

DIO 5 has 5V, GND, and Signal wired. DIO 6 only has signal wired, see response #6 in https://www.chiefdelphi.com/forums/showthread.php?t=133263

A little more info we discovered: the encoder values oscillate between 0 and 0.25 when the motors are moving and stay constant at 0 when they aren’t moving. Does that help clear things up?

4

+1 ? WT?

5

Are you setting the other parameters for the encoder? For getDistance() to make sense you need to set number of pulses per revolution (I think 360 for the E4T), I don’t know what it defaults to. The screen steps detail this:
http://wpilib.screenstepslive.com/s/4485/m/13809/l/599717-encoders-measuring-rotation-of-a-wheel-or-other-shaft

Also try checking the outputs of get() or getRaw() from the encoder object (not the DIO object). These should give raw encoder counts rather than a distance.

6

Oscillating like that means one of the two signal wires is not connected properly. We had a similar issue and it turned out to be the crimp was on insulation and not on the conductive bit of the wire.

7

This is standard for this sort of encoder. They made a cable that goes to two three pin pwm connections, so one cable provides power and ground to the encoder and the second connection is needed only for the second signal wire.

8

So from what I can tell, your DIO 6 (channel B) seems to be disconnected. Connect up a multimeter (or a oscilloscope if you’re feeling fancy) and see if you can get a signal anywhere on the wire (at the connector to the encoder, solder joint to the board). From there you can figure out which portion you need to replace.

9

Thanks for the suggestions everyone. Unfortunately, nothing we tried solved the problem. The encoder still inconsistently oscillates between 0-n*0.25 where n is the number of ticks/rev set in the code.

Here’s what we tried:

  1. Resoldering the connections to eliminate any possibility of faulty wiring
  2. Setting the ticks/revolution in the code among other parameters specified in WPI Screensteps
  3. Switching the wiring to see if the oscillation jumped pins (it did)
  4. Reading the raw output of the encoder

Sadly, nothing we tried got us usable values from the encoder. I guess this means our encoder itself is busted. My advice for anyone reading this thread in the future is to be extra careful when assembling the optical encoders and avoid touching the sensor as much as possible. Thanks again for the help!

10

did you use all the little spacer tools when installing the encoder to the shaft? alignment is very important. it’s also easy to damage the little glass disk. Also verify the cover of the encoder is fully snapped down, one of my students failed to fully snap it down once, and the difference is subtle (you should hear two clicks when installing).

if you take the cover off (carefully) and post a picture (in focus), we can look to see if it looks an installation error.