Encoder Trouble

[RedLight]

We use Java and have Grayhill 63R encoders that do not work. We have checked the wiring and it is fine. The a and b signals are taking up 2 different channels, it has power and ground, and the wires are not broken. The constructor is :
driveLeftEncoder = new Encoder(3, 4, false, EncodingType.k4X);
We also remembered to start and reset it. When printing the values, the encoder always returns 0 for the get() method, .25 for the getDistance() method, 1 for getRaw(),and true or false at random for getDirection(). Unless we stop then start it, the rate is 0, and when we do it is a random value. Also without stopping and starting it, it always returns true for getStopped(). We are utterly confused as to what is wrong and would appreciate any help.

[Sparkyshires]

An issue that can easily get over looked is do you have your encoder reset inside a while function? And would you also mind posting your code?

[sarangmittal]

Another thing crucial to getting Encoders to work is using the setDistancePerPulse() method.

You experimentally determine this constant by rolling the robot over a pre-determined distance, and recording the number of pulses from the get() method.

Then it's as easy as dividing distance by the number of pulses, and using the setDistancePerPulse() before getting the distance.

Hope this helps.

If this still doesn't work, maybe try posting the code, and we can look it over.

[Michael U]

For the past two weeks our team has tried to get our US Digital encoder working. We cannot read any values from the encoder at all. Our wiring is the same as this:
http://frc-labs.com/wp-content/uploads/2012/03/encoder.png

And our code is attached.

We have tried to test everything that we could think of. Please help us find what is wrong so we can get them working. Thank you very much for your help, we really appreciate it.

[Ether]

For the past two weeks our team has tried to get our US Digital encoder working. We cannot read any values from the encoder at all. Our wiring is the same as this:
http://frc-labs.com/wp-content/uploads/2012/03/encoder.png

And our code is attached.

We have tried to test everything that we could think of. Please help us find what is wrong so we can get them working. Thank you very much for your help, we really appreciate it.

Are you really connecting the encoders to the DCS PWM outputs rather than the DIO?

[geomapguy]

Are you really connecting the encoders to the DCS PWM outputs rather than the DIO?




Maybe he meant PWM cable

[Ether]

Maybe he meant PWM cable

I hope so. But that needs to be confirmed.

[Michael U]

Sorry for the confusion, we are connecting them via pwm cable to the "DIGITAL I/O" on the digital sidecar.

[Ether]

Sorry for the confusion, we are connecting them via pwm cable to the "DIGITAL I/O" on the digital sidecar.

Does your team have access to an oscilloscope, even a cheap one?

[Michael U]

Yes, we do own an oscilloscope.

[Ether]

Yes, we do own an oscilloscope.

Look at the output of the encoder(s). See if there's any signal coming out.

You may have to carefully strip the insulation of a small section of the signal wires.

[apalrd]

]You may have to carefully strip the insulation of a small section of the signal wires.

I was taught by an smart EE to use a scribe to poke through the insulation of the wire, then touch the probe to the scribe. Super easy, and the wire isn't exposed when you're done (you should still warp it in electrical tape afterward)

The same guy taught me to strip wire using small side cutters, another handy trick.

[Michael U]

We are getting signals from channel a and channel b. (it looks like a pwm signal)

[Ether]

I was taught by an smart EE to use a scribe to poke through the insulation of the wire, then touch the probe to the scribe.

Of course. Thank you. I suppose you could use a needle or a pin in a pinch.

[Ether]

We are getting signals from channel a and channel b. (it looks like a pwm signal)

A and B should be in quadrature. Are they?

[Michael U]

I'm afraid we have gone from our meeting today so I will have to postpone tests to tomorrow. Also, (sorry for being ignorant) what does "in quadrature" mean?

[cgmv123]

Also, (sorry for being ignorant) what does "in quadrature" mean?

Quadrature means the A-Channel signal overlaps the B-Channel signal by exactly half. The encoder can't tell which way it's rotating without it. If the A-Channel is first, the motor is rotating one way. If the B-Channel is first, the motor is rotating the other way. If you can test both channels on your scope, the graphs should like like the ones below, depending on the way the motor is rotating.

http://digital.ni.com/public.nsf/ad0f282819902a1986256f79005462b1/c6c6632a54dba7dd86256275005e18e2/$FILE/encoder-phase.gif

[Ether]

The encoder can't tell which way it's rotating without it. If the A-Channel is first, the motor is rotating one way. If the B-Channel is first, the motor is rotating the other way. If you can test both channels on your scope, the graphs should like like the ones below.

http://digital.ni.com/public.nsf/ad0f282819902a1986256f79005462b1/c6c6632a54dba7dd86256275005e18e2/$FILE/encoder-phase.gif

Good description :)


Quadrature means the A-Channel signal overlaps the B-Channel signal by exactly half.

Exactly 90 degrees (one quarter).

[cgmv123]

Exactly 90 degrees (one quarter).

If you're talking about how it rotates, yes, but if you look at at the graph of the output, it's split in half.

[Ether]

If you're talking about how it rotates, yes, but if you look at at the graph of the output, it's split in half.

No, I'm talking about the 90 degree phase shift between the A and B signals.

If it were half (180 degrees), it would look like this:

|-----| |-----| |-----|
| | | | | |
_____| |_____| |_____| |_____

-----| |-----| |-----| |-----
| | | | | |
|_____| |_____| |_____|

[Michael U]

We can confirm that it is giving the signal at a 90 degree shift.

[Ether]

We can confirm that it is giving the signal at a 90 degree shift.

Well it sure sounds like you are getting a valid signal from the encoders.

Can you post a couple of pictures showing how the encoder wires are connected to the DSC and how the DSC is being powered?

[Mark McLeod]

The code is just the LabVIEW encoder example, so I'm assuming that you changed the Target IP address to match your team and used the Run button to execute it?

Assuming that you are using the default front panel values the encoder expects a minimum rate of 20 ticks, so to test the electronics you need to lower that to 1, then you can test the DIO inputs by shorting the signal to ground a few times to see if it registers on your executing front panel.

Connected to DIO 1 and 2, you said.

As implied, you need to make sure that the three Digital Sidecar power LEDs (5v/6v/12v) are all three glowing a merry bright green.
You can test that the DIO's are receiving power using a multimeter between power and ground.

[Michael U]

http://s21.postimg.org/9xk2ydrb7/photeo.jpg (http://postimg.org/image/9xk2ydrb7/)

http://s21.postimg.org/6rzh868oz/photog.jpg (http://postimg.org/image/6rzh868oz/)

http://s21.postimg.org/5zs7v8f43/photosf.jpg (http://postimg.org/image/5zs7v8f43/)

Here are pictures of our setup. We do have the three merry green lights and we have also used the code from the Robotic Eagles (love them).

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/

[Mark McLeod]

I assume you removed the 37-pin cable to the Digital Sidecar just for the photo?
Won't work without that.

P.S.
Appreciate the love:)

[Michael U]

Yes, sorry about that we were doing some re-wiring at the time.

[Mark McLeod]

The wiring looks good.
The encoder looks good.
The code looks good.

Next on the troubleshooting list is the 37-pin cable.
Look at the male end for bent or damaged pins.
Do you have another known good cable that you can swap with?

Check the Digital Module connection to the cRIO itself.
Take the module out and look for bent pins inside the cRIO side of the module connector.
Also check the pins on top of the Digital Module where the ribbon cable plugs in for bent or damaged pins.

After that would be the Digital Sidecar. Do you have another that you can swap out with?

[BitTwiddler]

http://s21.postimg.org/9xk2ydrb7/photeo.jpg (http://postimg.org/image/9xk2ydrb7/)

http://s21.postimg.org/6rzh868oz/photog.jpg (http://postimg.org/image/6rzh868oz/)

http://s21.postimg.org/5zs7v8f43/photosf.jpg (http://postimg.org/image/5zs7v8f43/)

Here are pictures of our setup. We do have the three merry green lights and we have also used the code from the Robotic Eagles (love them).

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/
I think I spot a wiring error in your photograph. It appears you have the brown wire (ground) from the encoder going to the orange (signal) wire of your digital I/O port. I think you want the encoder blue wire going to the orange wire of the digital I/O PWM cable.
Oops, please disregard. I see you have the PWM connector turned around to account for that. No wiring error there. Sorry.

[Alan Anderson]

The wires go to the right places, but I really wonder about your decision to use backwards coloring on the 3-pin connectors. That'll be a serious source of confusion for anyone looking at your connections. Brown to brown, red to red, and yellow to yellow makes a whole lot more sense than swapping brown and yellow in the middle of things.

[yash101]

Time for some troubleshooting :D

So take a 2-channel oscilloscope and probe each output of the encoder. Turn the encoder/shaft/whatever. If you see a waveform on each channel that looks almost like a square wave, everything should be fine. Then, the problem is either code or those inputs are faulty.

If those inputs are faulty:
Try switching digital sidecars. if that fixes it, you're good to go. Otherwise, try swithing cables. That can be a problem! Go and use your engineer bains and troubleshoot :D

[nuttle]

The description in the original post sounds as if only one of the two inputs (A and B) is being seen, FWIW. For anyone without a scope, if you can see the values of the two digital inputs (test mode, etc.) and you can turn the encoder *very* slowly, you should be able to see both inputs changing at slightly different points.

[Michael U]

So, we have replaced our ribbon cable, and our digital side car, and have not been able to resolve our problem. We also checked for bad connector leads on the cRIO. We also switched out the digital i/o module. We really appreciate your help, checking it on the oscilloscope was a fantastic idea! We hope that we can get these things going.

[nuttle]

driveLeftEncoder = new Encoder(3, 4, false, EncodingType.k4X);

the encoder always returns [...] 1 for getRaw(), and true or false at random for getDirection()


"There are four QuadratureEncoder modules in the FPGA and 8 Counter modules that can operate as quadrature encoders. One of the differences between the encoder and counter hardware is that encoders can give an oversampled 4X count using all 4 edges of the input signal. Counters can either return a 1X or 2X result based on one of the input signals. If 1X or 2X is chosen in the Encoder constructor a Counter module is used with lower oversampling and if 4X (default) is chosen, then one of the four encoders is used." (Source: <http://first.wpi.edu/Images/CMS/First/WPILibUsersGuide.pdf>.)

[Assuming this encoder has A and B connected to DIO 3 and 4 -- it should.]


The two inputs (A and B) in quadrature mean that the four possible states for two binary values are expected in a certain order. Let's call these states 0, 1, 2, and 3. In any given state, one possibility is that we simply stay in this state. This happens if there has no been enough rotation to move the encoder enough to detect the next position. There is one state that is expected to be next in succession for clockwise rotation, and another that is expected to be next in succession for counterclockwise rotation. The fourth state is not expected and indicates an error -- such as incorrect sensing of the encoder lines or processing too slowly to detect each state and skipping over one.

In particular, you expect to see this pattern for one direction: 0 1 3 2 0 1 3 2 ...

And, this pattern for the other direction: 0 2 3 1 0 2 3 1 ...

So, from state zero, you could stay in state 0, or go to either state 1 or 2, depending on the direction of rotation. From state 0, you do not expect to go directly to state 3 and if you somehow do, this is an error.


The symptoms you reported match what you expect if you were seeing the pattern 0 1 0 1 0 1 0 1 ...

The same thing can happen for similar patterns, for example 2 3 2 3 2 3 2 3 or 0 2 0 2 0 2 0 2 or 1 3 1 3 1 3 1 3 ...

These patterns all have only a single bit changing, with the other bit stuck at zero or one.

So this is why I say this looks as though you only are getting a signal on one of your two encoder inputs. See if you can determine if this is happening.