quadrature encoder to step

I want to attempt to use the output from a printer paperfeed optical encoder to drive a stepper motor so that the motor follows the position of the encoder, i have done lots of searching on the net for information or examples of this but not really found anything that makes much sense. My question is has anyone done this using a picaxe that give me some clue or examples on how to proceed with this. I am not asking for a complete solution and quite willing to do more research on this if somebody can give me a starting point.

Hi,

Can the optical encoder detect the direction of paper movement (i.e. does it have two sensors)? I guess the printer might "know" the direction the paper is moving so a simple "interruptor" might be sufficient.

In principle, I think all you (or the PICaxe) need to do is generate a pulse each time that the encoder signal changes (or to generate two pulses if the encoder only has a single output). For example (pseudo-code):

IF encoder generates a positive edge THEN Pulse coil A then coil B
IF encoder generates a negaitive edge THEN Pulse coil C then coil D.

or if the encoder has two (quadrature) outputs:

IF encoder output changes from 00 to 01 THEN Pulse coil A
IF encoder output changes from 01 to 10 THEN Pulse coil B
......
IF encoder output changes from 00 to 11 THEN Pulse coil C
etc. (total of 8 possibilities)

Of course if the motor doesn't turn at the correct speed, then you will need to increase or decrease the number of pulses which drive the coils (using integer factors). Or even, fully decode the encoder signals to give "speed" (e.g. steps/second) and "direction" parameters, which can be scaled and then used to create a suitable sequence of stepper drive pulses.

Cheers, Alan.

Thanks for the reply Allycat, the encoder fitted to the paper feed drive of the printer does have direction with A and B outputs. I need to try and get my head round what you have told me so i can understand it a little better before i can trying to write some sort of program. The only thing that bothers me at the moment is if the picaxe can read the encoder signals fast enough. I do not have the full details of the encoder disc yet so not sure how many counts per rev there are. I have done a little searching the forum to see if i can find any examples in code of how the encoder is read and then how the input is converted to stepper motor signals which would really help me to look at and try to understand what is being done if you know of any please let me have the link.

wijnendael said:

The only thing that bothers me at the moment is if the picaxe can read the encoder signals fast enough.

Click to expand...

With such an arrangement as you are proposing, the limiting factor is most likely to be the speed of the stepper motor. Stepper motors are usually relatively slow devices and therefore easily controlled by a PICAXE chip. The speed is significantly limited if they need to reverse during travel as your arrangement implies they must. It is more likely that the stepper motor will not be able to keep up with the encoder rather than the PICAXE chip not being able to keep up with the encoder. Obviously, though, I am speculating because you have not indicated just what is turning the encoder and with what speed it does so.

Hi,

Yes, the details on the encoder will be important. If it has a fine encoder disc then it might be too fast for the PICaxe, but at least you shouldn't have any problems with contact bounce. Also the AB sequence might be: 00 , 01, 11 , 10 .... or 00 , 01 , 10 , 11 .. or perhaps something else. But the important thing to realise is that you are looking for changes in the signal(s), so you need code which stores a "last value" (position) to compare with the "present value".

I'm afraid I may have over-simplified the stepper motor. Firstly there are two types (unipolar and bipolar). The unipolar usually have 4 coils (5 wires), but are "easier" to drive; the bipolar only have 4 wires but it is necessary to reverse the direction of current flow in the (two) coils. Also, it is usual to drive two coils at a time, e.g. A+B then B+C then C+D then D+A , etc., or sometimes with more complex patterns.

Do you actually need to sense and drive the motor in both directions? Does the motor need to exactly replicate the steps from the encoder? It might be easier to start by driving the motor in only one direction, and perhaps using just one of the encoder outputs (A or B). There have been a few threads concerning code for encoders, but often the main issue has been overcoming "contact bounce". Code to drive the stepper may be easier, when the type of motor has been identified.

Cheers, Alan.

again thankyou for the replies, i am going to look a little deeper into what the actual paper feed doe now so i have a better idea of what i need to achieve. However from what you say and what i have already observed although the optic sensor on the encoder disc does give A and B signals i think the motor that is driving the paper feed which is actually a DC motor and not a stepper only turns in one direction ( or at least i only want to follow it in one direction ). My idea was to piggy back the signal from the the optic sensor leaving the original motor running via the printer electronics and run a seperate stepper motor from the signal driving a ballscrew to give me the same movement as the original drive shaft of the paper feed. I am trying to get hold of a schematic for the printer but not having a lot of success at the moment.

Okay, I think that I have now caught on to the nature of your enquiry; this is the "direct to garment" printer" that you referred to in a previous post. Therefore you are trying to develop a moving print bed that will move synchronously with the now-redundant paper rollers. I think that the arrangement that you have encountered is that of a d.c. servo motor using the encoder disc as a feedback control, but feedback that does not necessarily inform the motor! - I think that it would be very difficult to try and intercept anything useful from this circuit to mimic the roller position. The equipment manufacturer has almost certainly chosen a d.c. servo motor to gain speed and print resolution. It is possible that the optical encoder in the printer is not actually controlling the d.c. servo motor at all but in fact it is providing the timing signals to the print carriage and print head. That way, the d.c. servo drive only has to keep the speed roughly constant whilst the optical feedback system synchronises the carriage motor and print head rather than the paper drive motor.

Why not think about a direct mechanical arrangement instead? You could remove the paper roller and attach a pulley and toothed belt to the roller drive and then use this belt to drive your moving print bed - the components for toothed-belt drives are easily available. Alternatively, you could look to one of the encoder threads that Alan refers to and perhaps add your own encoder to the paper roller and then use the signal from that to drive your stepper motor in synch. Having said that, I think that it might very rather difficult to mimic the resolution of the original printer with a stepper motor replacing an optically-encoded feedback-controlled d.c. servo motor.

Another solution, and I think this would be my choice, may be to forget about linking your bed drive to the printer drive electronics. If you set up your motor drive to run at a constant but adjustable speed, quite independent of the printer roller, then this could be set to run at the same speed as the printer drive. Then all you would need from the printer would be a simple signal "paper roller is moving" - a signal which is simply available from the wires to the d.c. servo motor itself. In other words, a simple detection of the power to the servo motor starts your print bed drive in motion. Assuming that the paper moves smoothly and at a constant speed, it would be very easy to set up a print bed to run at the same rate. And it would stop when the d.c. servo motor stops.

This would be very easy to calibrate by printing a square and adjusting the bed speed until you actually printed a square. So instead of needing to get into elaborate signal processing, all you really need is a high/low signal from the d.c. servo motor into one PICAXE pin which triggers a PWM output to a motor drive. What do you think?

Hi Circuit, your comments are worth considering and this as you say may be the paper feed rollers are functioning now. I agree that using a signal from the dc servo motor supply to start and stop my print bed would probably work if the original motor always runs at the same speed when feeding the paper but i am not sure if this is the case. From watching the paper feed roller when the printer is printing the roller is advanced in steps to facilitate each line of the printhead, with your suggestion i don't really see this as a problem as when this happens i think the motor always rotates at the same speed. The problem i see is that the motor does run at different speeds when it is ejecting paper after a print (runs faster) and setting the paper to the printhead before starting to print (runs slower). These two operations i could probably do separately with a couple of extra sensors attached using the new motor and ignoring what the original paper feed motor is doing as the print bed is now controlled independently but i think there will be a lot of trial and error trying to get this to work correctly.

wijnendael said:

The problem i see is that the motor does run at different speeds when it is ejecting paper after a print (runs faster) and setting the paper to the printhead before starting to print (runs slower).

Click to expand...

The motor is probably controlled by a PWM drive and this dictates the speed. Therefore you might be able to detect the higher speed paper align/eject modes by analysing the PWM signal to the motor. There are probably only two speeds; the align/eject speed and the print speed. But this may bring in another issue; there is probably a paper edge detector that has to be triggered correctly before the printing will begin. This may be another problem to solve, but it should not be beyond a PICAXE system to handle this as well.

You are correct as i have just had a quick look at the paper feed motor signal while operating the stripped down printer and it does appear to be pwm controlled, however due to the fact i have some of the sensors removed it very difficult to get the timing of the sheet feeder and paper eject sensors operated at the correct time in the printer sequence. I have a service manual for the printer but there are no schematics included and only the power up sequence order is explained so the timing of the ASF/PE and PW sensors is proving very difficult to get correct after the printer has powered up and the green ready is displayed it seems that i am at the moment only managing around 1 in 50 tries to get the sequence right and should probably concentrate on the timing of these signals first and at least try to get the printer to go through a full print cycle. I would still like to find a solution for this if it is possible so that i can improve the design of the print table but may have to set it up firstly with a belt drive or friction drive from the original paper feed roller so that i can at least get some more accurate steady readings while the printer is running