Testing positional repeatability with a ball screw

Hi Everyone

I have done some initial testing of positional repeatability that may be of interest to those of you working on CNC type applications. Consider these numbers to be the worst case scenario as I am using the cheapest ball screw I could find ($27 USD) and the worlds least rigid setup.

Yes, the ball screw is attached to a MDF board with wood screws and the ball nut is attached to the linear slides with double sided foam tape… but its a start. In the video below I am commanding the controller over usb to move 50,000 counts away and then back again with the speed limited to 4000 RPM.

The position at each return in the video are (microns):


The positional repeatability looks to be about ± 18 micron with a 3 to 1 gear reduction using a timing belt. The claimed repeatability of the digital indicator used is 3 microns. Again, consider this the worst case scenario with things only able to get better from here.

The following firmware parameters were used:

.pos_gain = 95.0f
.vel_gain = 10.0f / 10000.0f
.vel_integrator_gain = 0.0f
.current_lim = 75.0f

Motor used is an SK3 5055 280KV, the encoder provides 2400 counts per rotation and the system is running off a 24V ~15A switch mode PSU.

1 Like

You should set the velocity integrator gain to something > 0.0 or you will get a steady state error due to friction.


And with load ? :stuck_out_tongue_winking_eye:

It would be interesting to retreat 20 μm and then re-forward 20 μm. Stick-slip is an important phenomenon on very small movements.

It is an excellent result since it is already not bad that this mechanics happens to do this.

what is the step of the screw?

[quote=“crinq, post:2, topic:258, full:true”]
You should set the velocity integrator gain to something > 0.0 or you will get a steady state error due to friction.
[/quote]I agree . It is important to integrator to avoid static error, even if it is delicate because of the stick-slip.

You’ll get steady-state error there anyway. Positional steady-state error also has a velocity 0, so the velocity integrator isn’t going to be doing much!

I’ve been doing some testing on a simple jig setup, just measuring step response and such. I’ve seen good repeatability to +/- 1 encoder count. No load, no backlash though. That’s next :slight_smile:

1 Like

That’s not true: for example, during a steady-state position error with 0 velocity, the position controller is feeding the velocity controller a non-zero velocity command, one that should decay the position error. That means that the velocity controller sees a non-zero velocity command, and also 0 velocity feedback, which is a non-zero velocity error: which does get amplified to torque over time from the integrator.

1 Like

Ah right good point. Output of the position controller is the velocity setpoint, which will be non-zero.

I just tried playing around with the gians but I did not see any improvement in the repeatability. I think this is because the poor mechanical setup is currently the limiting factor rather than the driver. I also tried adding a sizeable mass (7.5 Kg) and while it worked just fine, the whole setup is not ridged enough to get any meaningful data. I did notice that the 50W resistor became quite warm after jogging the system around for a while with that mass even with a reasonable heat sink attached. Active cooling will definitely be required for an XY table type application.

The backlash on these ball screws (they are 4mm pitch) looks to be at least 25 micron and so I might move on to a belt drive (~ 0 backlash) before trying smaller steps with a more moderate mass.

What is your metric for quite warm? Keep in mind that metal is too hot to touch at about 50C, and the HSA50R47J is rated to 200C.

Well it was warmer than body temperature but not so hot that it could not be touched. So perhaps ~45c. I didn’t realise they were rated to such a high temperature. Perhaps passive cooling will be fine for most applications then.

you can apply a deceleration at the end.
with this the stop will be smoother at the end when you get closer to the stopping point.
Does the system have this capability?

We do not yet have trajectory generation and tracking, which will allow specifying a smooth acceleration/decelleration. It is a planned feature, see here.