I have an application using a servo motor, and I’m experiencing a position drift issue. The servo motor drifts approximately 2 mm after 3–4 hours of continuous running.
Hardware:
Servo Drive: ACOPOS P3: 8EI8X8HWD10.xxxx-1
Servo Motor: 8LSA44.DB030S000-3
AS Settings:
Rotary-to-linear transformation: 207.65 mm
Gearbox ratio: 8:1
Measurement resolution: 0.01 mm
Motion Details:
Axis moves forward and backwards continuously.
Velocity: 700 mm/s
Acceleration: 700 mm/s
Deceleration: 500 mm/s
Load: 40kg
Observations:
Drift accumulates over time (~2 mm after 3–4 hours).
Does anyone have any idea what could be causing this drifting issue? Please let me know if more information is required.
Belts or Gearboxes involved? With belts you could have stretching/compression due the belt elasticity. I’ve seen this where the motor is in position according to your accuracy, but the load at the other end of the belt is heavy enough that it’s a few units off where it should be because the belt stretches before the static/dynamic friction is overcome. If there are gearboxes, you might need to make sure you are approaching your measurements from the same direction to compensate for backlash in the gearbox.
Or just direct coupling? How elastic is your coupling?
You can try calculation via gearbox info/belt info, how much backlash/elasticity is in your transformation from motor to load to see if this 2 mm of accuracy falls within the accuracy of the system.
Based on your DB encoder you should have 19 bits single turn and 12 bits/4096 revolutions of multi turn accuracy. If you make your measurement resolution 10x or 100x more precise do you find a smaller amount of drift because motor is measuring a finer resolition of movement?
I think you have faulty encoder is a common when the servo have a 5 years of working or more also can be an electric parasite coming from spindle (if your system have one then check the cables)
Since the encoder is one using EnDat 2.2 protocol and the transfer of everything there is checked internally using checksums, where exactly could some “electric parasite” cost him 2 mm of accuracy after a while?
A fauly encoder will pretty much present itself as a faulty encoder, not just randomly give you a wrong position.
Yes the mechanism is using belt.
Servo motor - gearbox - coupling - belt.
I have a question on this “You can try calculation via gearbox info/belt info, how much backlash/elasticity is in your transformation from motor to load to see if this 2 mm of accuracy falls within the accuracy of the system.” Can you please explain this in more detail on how I can do this or provide a simple example on this?
After discussion with my team, we are considering a 2-encoder control setup, where an additional position encoder is mounted at the belt/load side to compensate for these errors. Something like this:
i only had this when slipping issues occurs or belt jump over or teeth of the belt are lost
or
lag error is set to high - so please have a look at lag error when positioning is complete
or
it is a encoder issue.
So when you can figure out that it is not a issue of slipping of mechanical devices once i had two issues in the past
Encoder: Encoder is damaged or is not fixed to the motor shaft as it should be (slip at the encoder to shaft)
Modulo axis - your application is a linear so it will not touch you. To explain: The drive can only integer numbers for move not Real numbers. So when you put real number e.g. 100.03 inkrements acopos will only move 100 inkrements. the 0.03 will be lost and will cumulate a certain positioning error. there are possibilities to get rid of this problem
So in order to find i would open the shelter in order to see the mecanical devices. Reset all and put a mark to a certain position to wheels and belts. This marks must all the time come back to their origin position in linear systems. if not all marks come back to their origing position you have there a mechanical issue
Accumulation of position error is typical in vertical-axis applications (even with rigid couplings) when no integral action is present in the controller, resulting in a non-zero steady-state error. I can imagine the same occurring for horizontal-axis applications as well. If that’s the case, simply add some integral action and test it..
