Which is the best solution in a motion control system based on PC:
absolute or incremental encoder?
Do the motion control cards support absolute encoder?

Thanks in advance.

Fernando Gomez

 

Absolute encoders are not usually handled by most PC controllers without an addition of a daughter board and/or firmware changes in an FPGA. I believe some of the PC controllers that handle G-codes, such as Delta Tau and Acroloop have the option... They are usually used to provide exact location after a stop so that restarting the move with exact direction is facilitated and also they are used to reduce dependence on "homing" for all positioning. This can be very important in some applications. The absolute encoder prices have now come down to near those of incremental, so you will probably see more support for them in the future.

Bob Close
Executive V.P.
Precision MicroControl Corp
TELE 760-930-0101
FAX 760-930-0222
[email protected]

 

You can't possibly get any kind of useful answer to such a question without providing much more information...
- mechanical system configuration, drive to load coupling
- required accuracy/repeatability
- distance of travel
- drive capabilities (many provide encoder emulation output, for example)
- environmental conditions
- functional/operational considerations like is it feesible to require re-homing on power-up, fault
- etc, etc, etc

The only simple answer to your question is that PC based motion control cards with incremental encoder input are more common than cards with absolute encoder input.

 

Well, there *should* really not be any difference, at least not as long as both encoders do their work.

The real differences will be quite small since both systems will do their work in most cases.

The differences are:
An incremental encoder reports the changes in position, that means the reciever have to keep track of all changes. If this stops working (ie the reciever forgets the position or if some pulses are missing) the position will be wrong
(changes will stil be correct however).

An absolute encoder always sends the complete position, that means the reciever always get the full picture and don't have to remember anything.

Incremental encoders are easier to make and should be somewhat cheaper.


/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

 

You may find useful a posting on "AC Brushless Smart Position Initialization" of (2/6/2001) How to initialize AC Brushless motor with incremental encoder without position Hall sensors.

-Alex
[email protected]

 

Go with incremental encoders unless you have a pressing need for absolute encoders. Absolute encoders are more expensive, and there is no standardization of interface, so you can run into a great deal of difficulty matching an absolute encoder to a controller.

If you are willing to do a "homing search" move on power-up to establish your position reference, you can use an incremental encoder. Only in the cases where this is not feasible should you be considering an absolute encoder. In virtually all applications, this would have to be a "multi-turn" absolute encoder to cover the full range of motion.

If you have a permanent-magnet brushless motor, you also need to establish a "phase reference" within one revolution of the motor. Exactly how you do this will probably depend on the motor/drive combination you use, but fundamentally you have a choice here as well between reading an absolute sensor (although here it only has to be absolute over one revolution) and a search move.

There are several common options here. One is to use a resolver, which is absolute over one revolution, with a resolver-to-digital converter in the drive for the commutation, producing simulated quadrature for the controller, which thinks it has purely incremental feedback.

The second is to use "hall-effect" commutation sensors (or their optical equivalent -- "hall" or "commutation" tracks on an incremental encoder.

The third is to use a purely incremental sensor do some sort of "phasing search" move to determine dynamically the rotor angle. This is often not feasible when there are significant net loads, such as gravity on a vertical axis, or high friction.

Curt Wilson
Delta Tau Data Systems

 

I have made research thru some vendors for abs. encoder applied on PC-base controller. My research approached to apply steeplechase software control, MEI motion control interface with TE abs. encoder.
Try get more information from MEI motion control, they have case to work on abs encoder.

 

I like Curt's answer. He hits all the bases. There are two other points I'd like to add to the discussion. 1. Most people think position when they investigate absolute encoders, but when used with certain intelligent drives, the feedback can provide higher resolution, which inturn can give you better control over ALL the loops.
2. Also you need to take into account the mechanical stiffnees of the application itself. The control is only as good as the mechanics allow it. One way to help compensate for "loose" mechanics when using incremental encoders is to add a second "load side" encoder, then bring the feedback to the controller and compare it with the motor feedback for corrections. Make sure they have the same PPR or are at least divisable. I.e. your 4096 is a bianary and can be scaled/compared with a 1024 load side encoder.

Jim Watson