What is the purpose of a rotary encoder?

[TheBlueDot]

I apologize in advance if my post is in the wrong section.

I'm writing a program to control a stepper motor. The motor came with a motion controller and an encoder. I'm not sure how the encoder should be used. I can program the controller to set the "zero/reference" point and tell the stepper to move a certain steps relative to the reference point. I've read some posts on Google and they suggested that the encoder is used for high accuracy, but if both the stepper and the encoder are attached to each other, shouldn't they read the same amount of steps?

Thanks for reading! :D

 

[.Scott]

The stepper won't "read" the same because it is an output device. You may be able to read back the position you gave to the stepper, but the encoder is what will tell you the actual position of the stepper.

Obviously, if there is too much of a load on the stepper, it will not rotate properly. But even in normal operation, there will be times when the encoder will show the position lagging the instructions you gave to the stepper.

 

[Asymptotic]

Is the encoder mounted to the stepper motor?

What is your application? Whether to use an encoder is dependent upon the application, and falls into three bins:

• Not needed. Set the encoder aside for future use.
• Enhances performance, but not necessary.
• Absolutely required.

Consider the stepper motor in terms of the overall system.

A missed step or two every so often isn't a big deal when motion is unidirectional, and normal operating speed falls within a limited range, for instance, when speed matching a section of conveyor between two machines. If moves must be precise, and especially when the motion is bidirectional, an encoder makes good sense. One example is an indexing turntable where the machine or process will malfunction if it stops in the wrong position. In such a system the encoder is usually coupled to track the position of the driven mechanical element to compensate for slippage, and drive belt and/or gearbox 'slop' (hysteresis).

 

[TheBlueDot]

Thanks guys for replying.
From Asymptotic’s comment, I think the encoder is required. My system requires high precision and must be able to rotate both ways, and the stepper and the encoder are connected by a coupling. Mechanically, I’m still a bit confused on why there would be discrepancies between the stepper and the encoder if they’re coupled. The stepper provides the torque to rotate the encoder?

 

[phinds]

You might also want to explore "gray code" which is what such encoders normally are, and for an obvious reason.

 

[berkeman]

Mechanically, I’m still a bit confused on why there would be discrepancies between the stepper and the encoder if they’re coupled. The stepper provides the torque to rotate the encoder?

Sorry if I missed it, but how do you determine the rotational position of the motor shaft after power-up? You can read it from the encoder, or you can spin the motor to a limit switch or similar. But the application may not like having the motor need to spin to a limit switch at power up, depending on what the mechanism is designed to do. If it's a big mean looking robot, you wouldn't want it to flail its arms to the limits after the robot was first powered up, right?

 

[phinds]

Sorry if I missed it, but how do you determine the rotational position of the motor shaft after power-up? You can read it from the encoder ...

And even then, if you aren't using a gray code encoder, you can't reliably tell where it is

 

[berkeman]

And even then, if you aren't using a gray code encoder, you can't reliably tell where it is

Are you saying that I wander away from the "home" sometimes and they have to track me down?

 

[TheBlueDot]

Sorry if I missed it, but how do you determine the rotational position of the motor shaft after power-up? You can read it from the encoder, or you can spin the motor to a limit switch or similar. But the application may not like having the motor need to spin to a limit switch at power up, depending on what the mechanism is designed to do. If it's a big mean looking robot, you wouldn't want it to flail its arms to the limits after the robot was first powered up, right?

No, I would not . I didn’t think about it. My system doesn’t have rotary restriction and my program always home the stage at the start. There is an IR sensor to detect home.

 

[phinds]

Are you saying that I wander away from the "home" sometimes and they have to track me down?

Yes, and you have to be carrying a grey code encoder or they might not find you.

 

[Asymptotic]

Thanks guys for replying.
From Asymptotic’s comment, I think the encoder is required. My system requires high precision and must be able to rotate both ways, and the stepper and the encoder are connected by a coupling. Mechanically, I’m still a bit confused on why there would be discrepancies between the stepper and the encoder if they’re coupled. The stepper provides the torque to rotate the encoder?

@.Scott in post #2 provides the answer. Just because a motion controller has issued a step command to the drive electronics there is no guarantee the stepper motor rotor has actually incremented in position. Excessive mechanical load, or an excessively high ramp rate in relation to load inertia are often at fault.

A given motor/drive combo may be able to generate enough torque to accelerate a load (a flywheel, for example) successfully at a gradual ramp rate, but as accel rate is increased there will come a point where the rotor can no longer follow along with the stator field, and will 'miss' steps. Nearly the same deal with constant overload - you tell the motor to go, and although it tries to get there it doesn't have enough 'oomph', and just can't do it.

One way to use an encoder coupled directly to a stepper motor shaft is to provide a 'following error' function. Details vary between implementations, but the gist of it is to track the commanded move, compare it with encoder feedback, and generate alarms and/or shut down the drive if they get too far out of whack with one another. Let's say 160 steps per second is the commanded move, but the encoder only sees an equivalent rotation that 158 steps would produce. This following error of 2 steps/second may be survivable, but perhaps 5 step/second wouldn't be, and you'd set alarm/shutdown somewhere between the two.

 

[sophiecentaur]

Yes, and you have to be carrying a grey code encoder or they might not find you.

Even a grey code encoder can't take care of wheel slip. It could systematically make the displacement vectors shorter than you thought. It's always a risk with dead reckoning systems so you may require some occasional position feedback to recalibrate the stepper system.

 

[sparkie]

The encoder will give you position feedback, and there is a relationship between the resolution of the encoder and the resolution of the stepper motor. Keeping this ratio intact during movement will allow you to detect fault conditions in the system as the motor moves. It is a good practice to also have some type of sensor (proximity sensors work well) to set a home/zero position upon a 360 degree rotation.

Rotary encoders deliver pulses, which you count, to get position feedback from the motion system. I have only used them on PLC-controlled systems for position feedback and machine timing, never with a stepper motor, but it essentially works like this:

Condition is met to pulse motor to a certain point
Pulses are sent to the motor, and since it is DC we can change our polarity to change direction
Encoder pulses are summed - you can subtract from the count for one direction and add for another
If pulses and encoder count do not match, throw an alarm
Home system with a home position sensor to zero the count and motor position

Hope this helps a bit.

 

[sophiecentaur]

'Observed Position' is always more reliable than 'Dead Reckoning'. To quote from my old Navigation Tutor.