Products > Robotics and Automation

Linear encoders recommendations

(1/2) > >>

I am confused with the linear encoders!
When you go to Renishaw or Heidenhain, their proffered output signals are listed do not match to what servo drives list as their preferred inputs. Why are there so many different encoder interfaces and which ones to go for or avoid? Tried calling a number of application engineers/reps, but you do not really get the honest advice, because they need to make a sale at the end of the day.
Any pointers, experience sharing would be much appreciated.
At the moment I am looking at either magnetic or optical incremental encoders due to budget constraints. Are magnetic ones as bad as the reps say they are? Do absolute encoders have any other advantages outside of loosing the position? The cost difference is considerable between incremental vs absolute  and optical vs magnetic encoders.
Also, the lead times are getting out of hand with the brands above, maybe somebody can recommend a smaller manufacturer?  I'm UK based.
Thanks for any help.

p.s. rant is over, I'll go get my coffee and back to my corner.

Those linear encoders are not really fit for direct use with (industrial) servo motor controllers.
The motor controller needs signals that are n phase with the rotor position and their magnetic fields, and when you go through couplings, backlash, thermal expansion and other error sources the motor controller may get confused if you use the feedback from anything else then something directly connected to the motor shaft. Those industrial servo motors also have encoders directly on the motor shaft.

The linear encoders are normally used with an extra control loop to compensate for the error mentioned earlier, as the user is interested in the final position of the linear movements, and not in the position of the motor shaft itself.

If you have severe budget constraints, then have a look at the stuff from Ebay / Ali / China. Some time ago I bought a set of two readout boxes and 5 linear scales (Mill & Lathe) for around EUR500.

The STM32 (and probably other uC's too) have hardware support for 2-bit gray input code. With such a uC it should be a breeze to make your own read-out box. Others have also already done such things and you can find projects on sites like github.

I have not even considered looking at Heidenhain or Renishaw. I would not expect their prices to be anywhere near something decent or realistic.

In the last 10 years or so, encoders that are built into the linear bearing rails are becoming more common. Even manufacturers such as Hiwin have these in their assortment, although a lot of dealer that sell (genuine )   Hiwin, do not by far have the whole assortment that Hiwin makes.

The cheapest would be those capacitive rules, that look like (and are) calipers without the beaks. These apparently do not have a very good reputation. The only experience I have... Well. I bough a bunch of those cheap calipers and I threw them all in the garbage bin. Several of them were even unused an new in pcakagings. Instead I coughed up EUR 100 for a 150mm Mitutoyo, and that one just keeps on working.


--- Quote from: V_King on April 23, 2021, 08:25:59 am ---When you go to Renishaw or Heidenhain, their proffered output signals are listed do not match to what servo drives list as their preferred inputs. Why are there so many different encoder interfaces and which ones to go for or avoid? Tried calling a number of application engineers/reps, but you do not really get the honest advice, because they need to make a sale at the end of the day.

--- End quote ---

In what way do the drive requirements and encoders differ? When it comes to off the shelf drives, then you're often at the mercy of the drive manufacturer's recommendations for encoders, so it may be worth investigating from that perspective. There may be ways of adapting between different interfaces, but it depends on what your issue is there. If it's a rotary motor that you're driving to create linear motion, then you'll probably need some intermediate control (rotary encoder) for motor speed feedback and something else to make corrections for the linear motion errors... if the error in the linear motion is too great to ignore/improve mechanically that is.

In more general terms, the annoying thing with most encoder technologies is that they're all a compromise and it's just a matter of finding one that is slightly less of a compromise for your application. I've not had much of an issue with magnetic encoders, but all the nice benefits of magnetic, such as resistance from oil and dust are lost if you want better resolution... where you need to reduce the sensor/pickup clearance to almost sliding contact. So it very much depends on your application as to why any particular option may be better or worse.

For incremental vs absolute, then yeah, generally, absolute is more about keeping track of position during power off, but can also be more resilient to electrical noise or fast mechanical bumps and vibrations that can exceed the count rate of an incremental encoder (without any reference marks to self-correct periodically can cause errors to accumulate).

Heidenhain and Renishaw are definitely top tier and their prices reflect their opinion. I've never regretted using their products on any project, except when we are trying to justify the cost to the customer.

I've also had good luck with rotary and linear encoder products from these OEMs:
Sick:  A German company with a very broad array of sensor and encoder technologies.  Good time-of-flight distance measuring sensors, out to 100 meters! Great for cranes.
Balluff: Another German company. I have integrated a dual position loop servo with their BML-S1G0 linear magnetic encoder to 30 meters on large aerospace manufacturing machines.   

None of these encoder or distance measuring products would be considered low cost by any means. They are best applied on machines where the business case can justify the cost.   
Your other recent post also mentions trying to integrate a linear encoder with a servo drive that would be controlling a linear motor. Designing a linear motor into a machine is never the low cost solution, especially if the platen travel is long. Linear Magnet stacks are pricy! And is usually only justified if you are requiring ridiculous acceleration or extremely high speed with a very light load.

The conventional machine design approach is to employ a rotary motor to drive a pinion and linear rack assembly. And then if the backlash is excessive for your machine requirements and cannot be compensated in software, then add a linear encoder to the mechanism. To support the linear encoder, your servo drive or motion controller will require the ability to support a dual position loop - not trivial but much easier nowadays. It will also need to include a backlash compensation algorithm but also trivial with modern software based motion controllers.

Siemens, Allen Bradley, Delta Computer Systems (RMC200), Kollmorgen, Yaskawa, Delta Tau and many others offer products that are capable of integrating rotary or linear servo drive/motor with a linear position encoder. Unfortunately there is no standardized configuration and each manufacturer may offer substantially different hardware. Sometimes you just have pester them relentlessly to get what you need. Good luck with your machine!     

Hello JeffK, thank you for your post.

When I was mentioning the low cost, I did not mean arduino level sourcing from aliexpress. I do understand the cost implications on such projects. So far my research has shown that the price for the "same" specification varies greatly. Up to 3x between brands which I am trying to understand why. Same with encoders. What I did notice though is that usually the number of layers of management/sales functionaries until I get to the application engineer, very easily corelates to the multiplication factor the the cheapest cost option on the drives I found   ;)

I was in contact with Balluff two weeks ago, their resolutions are very low at higher velocities.


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version