Stepper motors and linear scale closed loop setup?

Hakan wrote: The idea I had was to just replace joint.0.pos-fb with encoder.position (and velocities if applicable).

As you are already using a PID for the stepgen this might well work.

Try it...

Are you using a very recent version of LinuxCNC? There was a recent change in the PID component that may cause a noticeable following error in the stepgen (with local feedback). If you are using a very recent version of LinuxCNC with PID feedback and stepgens, you should disconnect the PID command-deriv pins on all stepgens

If this is not a recent version of LinuxCNC you may just need to tune FF2
FF2 should be set to the number of seconds between stepgen position read and stepgen velocity write, typically around .0001 and .0003 seconds on Ethernet cards. (the DPLL pre read time is part of this value)

Yes I use the latest version, a week or two old, and I see that pid.x.command-deriv is connected to joint.0.vel-cmd. OK, so the result I got could be better without the command-deriv. I can try.

Before that I can show the results of
- using position and velocity feedback from encoder 0 (mixed up with joint.0.pos-fb in the previous post. Should have been position-fb from stepgen there)
- pid.x.deadband = 0.002 (step_scale = 400 on x)
- P = 200
the same +1 mm and -1 mm movement as in the video.


The real following-error is below +-10 µm now. Was +34.5 -10 µm before.
Who is putting the axle back to zero after 10 msec? motion? The pid has no I term at this point, only P.

At P=1000 there was a spontaneous oscillation, so that seems to be too much.

From what I can see, the backlash is basically gone. I will try some more, this looks good.

Some further tests with pid parameters. Here is where I end up.
P = 400
I=0
D=0
deadband = 0.0013

P is the important parameter. As far as I can tell, it should be as high as possible, without spontaneous vibrations occuring with some margin.
I will eat up the remaining error. But not in this machine. While idle and with a tad of f-error I can hear the motor taking a step say every second. But the motor doesn't seem to be strong enough to move the table just one step, at least the encoder will not pick it up. This results in a step taken every second without effect. (step = microstep). I never tested because I got so annoyed of the step-sound, but I guess the table will move after some tension has been built up by the motor (stick-slip). I also would like to see that the I-counter do not count when the f-error is inside the deadband, but the I-counter always integrates the error it seems. So I was set to 0.0.
D was also set to zero. I tested quite a bit but could never get a critically damped signal. It was easy to get a vibration of the X axis at 4 Hz. Decreasing D so it didn't happen still did not improve the overall f-error. So the only reasonable thing was to set it to 0.
Deadband was also undergoing some change. Up and down, it seems 1.3 µm is a good value that doesn't cause oscillations and keep things steady.

I am also a bit interested in the appr 100 Hz vibration that seems to always be there when the X-axis moves. Not dependent on speed nor acceleration. Some eigen-frequency in the milling machine? It could also be some effect from the closed-loop stepper motors.

The result is that the real following error stay below +- 15 µm at all speeds. I have tested with fast and slow, G0, G1. Without load. I guess I should test while milling as well.

One thing to note is that when jogging the X-axis in the positive direction, the motor doesn't "sing" anymore. It is more growling like when cutting threads in the lathe,

Hakan wrote: I will eat up the remaining error. But not in this machine. While idle and with a tad of f-error I can hear the motor taking a step say every second. But the motor doesn't seem to be strong enough to move the table just one step,

This is where I-gain comes in, to take away the steady-state error.

I know, it was just that the motor never stopped reposition. I thought it should stop doing that once inside the deadband, but it just kept on although not very often, one microstep every 5-20 seconds or so. Wasn't used to that, I guess.

When using the I-parameter it happened that the position was 1 µm off (seen on the DRO). I just let it do its thing and yeah eventually the DRO switched to 0. So it does its work. It is very sensitive to large I-values, it is easy to get the axis to oscillate.

I now have two sets of parameters that work fine.
P=250, I=0, D=0
P=300, I=10, D=0.5
I really can't see much of a difference in the axis response. Had to lower P from earlier post, jogging very short distances 0.01 mm was a bit sensitive.

Also made a quick milling test, milled in the X axis direction. Following error was a bit noisy like in the figure before, but inside 0-10 µm. So load doesn't seem to be a big factor. Admittedly light load.

Also noticed that the f-error from joint.0.f-error is different from "my f-error" which is encoder.00.position - pid.x.command. "my f-error" is larger than joint.0.-f-error (can be seen in prev figure), I wonder if "my f-error" is wrong.

Why do we use velocity mode? I don't know so I switched to position mode and tried to tune the PID loop. Got worse result, the best result f-error was at least double the f-error with velocity mode. So I run velocity mode again. For servo motors I see the point using velocity mode, but for stepper motors at least it felt more logical to use position mode. But that didn't work out in reality.