Encoder Trouble
 

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.

Re: Encoder Trouble
 

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?

Re: Encoder Trouble
 

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.

Encoder Trouble
 

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:


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.

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

Maybe he meant PWM cable

Re: Encoder Trouble
 

I hope so. But that needs to be confirmed.

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

Yes, we do own an oscilloscope.

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

A and B should be in quadrature. Are they?

Re: Encoder Trouble
 

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?

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

Good description :)


Exactly 90 degrees (one quarter).

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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:

Encoder Trouble
 

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

Re: Encoder Trouble
 

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?

Re: Encoder Trouble
 

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.

Encoder Trouble
 

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...2009-/LabVIEW/

Re: Encoder Trouble
 

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:)

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

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?

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

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.

Re: Encoder Trouble
 

"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/Firs...UsersGuide.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.