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.