Strange encoder woes

Graham Stabler

I'm at a total loss with this one. I'm trying to do another printer hack but this time with an epson printer, the idea is to convert it into a flat bed machine.

There is an encoder with 1500 lines so 6000 counts per revolution after quadrature decoding. I hotwired the encoder to find out how far the paper is fed before it triggers the paper pick up sensor, the printer expects this to be correct.

I then got my motorized platen to move in sync with this encoder so that it moves the object you want to print on at the same speed that the paper would have moved, it basically decodes the quadrature encoder and divides this down before sending to a stepper motor driver.

When I position the platen in the correct start position, start the syncronization and turn the paper feed encoder by hand until the platen has moved and triggered the paper pick up sensor I get a certain encoder count (the one expected). However if I do the same but then set the printer printing I get an encoder count 2-3 times bigger for the same movement. After filming what happens however it looks as if the encoder turns the same number of times as it did before so I can't see where the increased count is comming from.

To rule out latency in the spin for the time between the paper sensor being triggered and the position count being noted I even modified the asm in the rotary encoder object to watch for the paper sensor. Still the same result.

It will be pretty high frequency (36khz) but I can't for the life of me work out why my numbers are so far out.

Graham

Nick Mueller

> However if I do the same but then set the printer printing I get an encoder count 2-3 times bigger for the same movement.

This sounds like bouncing.
If you have a scope, see how fast the edge of the signal falls/rises. Maybe you can add a Schmidt-trigger before the signal goes to te Prop.
I had a similar issue and solved it with an digital filter. But I didn't use the QE-code, because it was just a simple rotary encoder that only rotates in one direction.


Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Phil Pilgrim (PhiPi)

Bouncing shouldn't be a problem with a correctly-decoded quadrature encoder. But much depends on the state machine used to keep track of the pulses. Graham, can you post your encoder decoding routine?

-Phil

Graham Stabler

The strange thing about it is that I use exactly the same decoding method to do the syncronizing and that works which makes me think it is not a problem with the condition of the signal.

I have used two pieces of code for the tests, the quadrature encoder object that comes with the IDE and the attached object I created myself which is about as fast as you can probably do it using a single long as a look up table, an idea of Chip's in another thread.

Graham

Phil Pilgrim (PhiPi)

Graham,

Your quadrature decoder looks airtight. I can't see any way for bounce to add extra counts. Too fast a waveform could result in fewer counts, though, if states get skipped (e.g. 00 -> 11). So my suspicions must turn to noise. How are your encoder inputs terminated? Do you have, or have you considered, Schmitt triggers on the inputs?

-Phil

Graham Stabler

Because the motion of my platen is driven by the quadrature encoder signal and the platen moves the correct distance corresponding to the the physical rotations of the encoder wheel it makes me think that the problem is not noise, however I wonder if the extra overhead that program has is doing some digital filtering in essence.

But one thing on the noise front, isn't it the case that on a noisy signal there could be as many "glitches" in the wrong direction as the correct one so it would not tend to increase the total greatly?

I can't help but think there is something else going on with little to do with the encoders at all but I can't really see how I could be getting anything wrong, I simply take a note of the position register after starting the sync and then after the paper feed sensor triggers before displaying the difference via prop terminal.

I'll do some further experiments.

Graham

Graham Stabler

OK some further testing has revealed that I was fooled by strobe like effects on the low frame rate video of the movements, the encoder actually spins at high speed for a moment leaving the stepper standing so that is where the counts come from.

Cheers,

Graham