linear scale and AC servo set up - sanity check

also i looked at the joint.N.backlash-filt in action, and the value is half the value of backlash in the ini file; and it's inverting itself depending on the direction of the move (positive in one, negative in the other).

However, it does not change to 0 if the move doesn't include direction change. So we need a way to add that event in the logic, otherwise we'll just overshoot in all unidirectional moves, won't we?

Thinking again: is this track making any sense? Won't the two loops of the pid be processed at the same time?

Wouldn't a sequence make more sense? Something like (in pseudo code):

pid.enable()
If direction-change-detected == True :
    pid.disable()
    joint.move(actual position + backlash.value)
    pid.enable()
joint.move(position-commanded)

 

ok, upon inspection of joint.0.motor-pos-cmd, I see what is happening. It adds half the backlash to the commanded position on move change in positive direction and substracts half backlash on position change in negative direction. It obivously stays there the rest of the time. So in a way, I guess, it is already doing what we are trying to do, only it adds it to the overall command not to only one PID.

Would one PID only actually change anything for the better?

actually, no. correct me if I'm wrong, but in the case of an open loop, yes it makes sense to keep the backlash value to the motor commanded position, because this extra distance was lost "forever". But in our case, with the scale feedback, this value just helps overshooting in the case of a direction change, giving more velocity at the start, aiming further. The actual position is then recomputed from the scale. So after this the "leftover" backlash value on every move in the same direction tends to create overshoot for the motor. I guess this is what becomes visible when tuning the PID loops and either having to damp the curve to prevent overshoot in unidirectional moves (but then being slow at direction change moves), or being fast enough on direction changes and tending to overshoot in unidirectional moves. Because of the difference between commanded position and feedback which are very different in the two use cases.

I'm wondering if adding a variable (maybe it already exists), in the following part of motion (which you referenced)(line 1657 and down), something like previous-direction or previous-velocity, which records the direction of the last commanded move, could allow to add an extra test to not only check which direction is commanded but if the commanded direction is different from the last one?


 

Hello,

It's been a year.

At some point I got annoyed by the lack of results of this experiment (trying to have linear scale feedback on a trapezoidal screw with backlash comp, and accurate movement). So I just changed to ballscrews. Indeed PID tuning went much easier once I had them installed.

Then I broke my X axis linear scale and used the opportunity to change for a 1um, that also helped a lot for accuracy. I'm not trying to have the axis micron accurate, 0.01 is more than enough for me, but the extra pulses give some comfort margin for the PID loop. I recommend it.

The remaining mystery is the Z axis. I only recently changed the screw to a ballscrew on that one and I have a real hard time setting the PID loop with the linear scale. I must say there is still 0.12 backlash somewhere on this axis, even with ballscrew. I'm having a hard time chasing which part it comes from, as it's all hidden in the column which is backed against the wall.

Anyways, no real question here, just wanted to give an update on this topic.