Strange operation with Quadrature on eTPU

[v8dave]

Hi all,

I am still getting strange effects with the eTPU quadrature input. I am not getting counts for each detent on the encoder as expected. In some cases it registers 2 counts and in some 3 counts and sometimes changes direction even though I am going in the same direction all the time.

This QD input works slightly different to what I expected. It seems to count on every edge from the encoder (ALPS EC11E15204A3) which generates 30 pulses per rev but the QD input measures 30 indicating that is reads on every rising edge of the pulses on both channels. This would correspond to the datasheet for the QD input.

Normally, when working with quadrature I read only 1 channel and use the second channel to determine the direction of rotation. Not sure if this is the correct procedure but it does work for me.

According to the datasheet, the encoder generates 1ms of bounce per channel with less than 3ms of chattering.

I think I need to do a little more with the setup of the QD input to get this much better. Looking at the datasheet there is window settings etc but not 100% sure how it all works.

Any help in the mean time would be appreciated otherwise is down to experiment (which is the fun of it all in the end and a good learning exercise at the same time)!!

Cheers,
Dave...

[tony]

I suspect you have noise on your encoder lines.

From the website http://usdigital.com/support/faq/

#
I am having some problems with noise affecting my encoder signals. What should I do?

There are several ways to improve noise immunity. Separate motor driver wires from encoder wires, and be sure to separate encoder channels from each other (i.e., do not twist CH A with CH B or CH I). Shielded twisted pair cable is recommended for encoder lines. Also, be sure to separate the ground lines of the motor/amplifier and the encoder since high current switching in the motor can cause noise in the encoder output lines. Pull-up resistors help somewhat with noise rejection. Additional circuitry, such as line drivers/receivers and optocouplers, is much more effective in rejecting noise. In really noisy environments, additional circuitry may be the only way to totally eliminate a noise problem.
#
I am trying to drive a fairly long length of cable. What kind of additional circuitry should I consider?

US Digital makes a variety of cable drivers. For maximum noise immunity and minimum cross talk, a differential cable driver and receiver is recommended for cables longer than the 6 to 10 foot range. Our line drivers use the industry standard 26C31, which sources and sinks 20 milliamps at TTL levels. Each channel pair should drive a twisted pair in a multi-pair cable. US Digital receivers terminate each pair with a 110 Ω resistor to eliminate ringing.

[v8dave]

Hi Tony,

I thought that myself at first but I have a 10nF cap and a 10K pullup on each input.

Looking with the scope at the Netburner module I can see really nice clean edges.

As the encoder has detents I can see 2 counts per detent but only 1 on the scope because it is reading the second inputs edges too. If I move the encoder slowly between detents I can see 1 count and as it settles onto the detent, I can see the second count. This is if I do it slowly. When I move it faster for normal input use, it misses counts. That's the strange part, I am missing counts, not increasing them but it could also be detecting a direction change if it sees noise.

I need to do more hardware testing to make sure that the hardware is clean. I'll rig up the logic analyser tomorrow and see what that sees from both channels when I turn it.

Dave...

[pbreed]

Slowing down an edge detection input with an RC filter is not always a good idea.
If you can see the whole pulse on a scope then you cant see noise, this should respond to glitches as
narrow as 50nsec.

Try a Schmitt trigger in front of the input and see what happens.

Or generate some quadrature signals digitally with gpio or timer pins and see if they behave as you expect.

[tony]

I took a look at the data sheet for the device you indicated Alps EC11E15204A3. It is specified as a 5V device. What voltage are you running it at? Do you have a voltage translation device between the device and the MCF5234?

[v8dave]

Hi Tony,

The device is effectively volt free as it is purely a contact only device. I am running it at the same 3.3V of the Netburner module. There is a pullup on each line.

I have removed the caps as you are quite correct they will affect the rise and fall. No difference though.

If I could only get it to count on the one channel it would make a difference I am sure but there is no settings for this.

Dave...

[Ridgeglider]

Dave: I'd go w/ Paul's suggestion and use Schmitt triggers on the inputs. The edges need to be clean and fast. The eTPU quadrature inputs are designed for motor control probably w/ 1K+ counts per rev at very fast (5000+ ?) rpm. Handling 30 counts per rev on a manual dial should be no problem, particularly if are only looking at one channel for the count. Most quadrature apps use both channels and consequently get 4x the count resolution.

[v8dave]

Thanks RG,

I am busy respinning the prototype PCB anyway to sort some IO timing on the LCD controller so I will add in a couple of Schmitt triggers on the outputs of the encoder. I'll knock something up temporarily on the existing PCB to give it a quick try out tomorrow.

Thanks for all your suggestions.

Dave...

[v8dave]

Hi all,

I now have a 40106 HEX Schmitt device on each output from the encoder but I am still seeing missing counts and change in direction. The 40106 is wired so that 2 gates per encoder output invert the signal from the encoder. On the scope it is lovely and clean edges.

As the board is no respun I need the find a fix for this.!!

Dave...