Stepper motors and linear scale closed loop setup?

Hi guys,
I have a fairly standard three-axis milling machine with stepper motors. I have an idea of adding linear scales. I know it has been done before but can't figure out how to do that in terms of hal and ini file modifications. There is a 7i76E, three stepper motors + spindle encoder so running out of encoder possibilities. I would appreciate if someone told me which daugthercard to use to add three+ encoders.

The linear scales I have in mind are SINO KA300 with 1µm resolution, If the 5µm resolution works I can use that, but have read somewhere that smaller resolution is better.

From what I have understood from another post here, the way to give the feedback to the pid is as belowOf course adjusted for the actual encoder naming.
Is there anything more that is needed?

I use 7i76e with 7i85s for that.

I see, makes sense. So I can select from the DB25 daugthercards and the one you have seem to be a perfect fit.

Starting to look at the hal file.
Are the lines in the first post enough to get the feedback loop closed?
What about P, I and D parameters, they must be important now.

Hi Andy, I missed your reply. But it is not too late.

I just started to work on this. I am not sure where it will end up, if it will be useful or not. I will learn a lot, and that can be good enough for me.

I am documenting what I do in Youtube videos. I am about to add encoder feedback.

Mounting and connecting.


Looking at following errors.


So the f-error I see come from timestamp dither? It is basically removed by PID P=1000.
In the tests I made I see the commanded_pos - encoder_pos is in the order or 20-30 µm while joint.0.pos-fb is not above 1.3 µm. I could think that the larger value is the one to focus on.
The idea I had was to just replace joint.0.pos-fb with encoder.position (and velocities if applicable).

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,