Joint following error on stepper system

Hi LinuxCNCers,

Over the last couple of years I've had occasional joint following errors on my stepper-based router. I understand that FERROR, MIN_FERROR and [TRAJ]MAX_VELOCITY together define a linear function describing the following-error threshold, so that the allowable following error is proportional to the motion speed. What I'm not sure about is how to determine suitable values for FERROR and MIN_FERROR given the other machine parameters.

The machine has 400 steps/mm on all three axes, and I've settled on a BASE_PERIOD of 20000 ns, giving a per-axis speed limit of 125 mm/s (7500 mm/min):

( Frink syntax)

I did note that stepconf output had the per-axis MAX_VELOCITY set to 0.95 x the theoretical limit - what's the reasoning for this, and should I be doing the same?

The overall [TRAJ]MAX_VELOCITY is set to 250, since diagonal 3D moves could be up to sqrt(2) x sqrt(2) x per-axis max velocity. Is that reasonable?

The per-axis acceleration limits (following some experimentation) are:

The following-error parameters are currently set as follows:
Would it be appropriate to raise one or both of these, and if so, how to calculate a sensible value? What's the relevance of following-error for a stepper-based machine?

Thanks!

400 steps/mm * 125mm/s = 50000 steps/second, the absolute maximum possible with a 20000 ns base thread. This leaves no headroom so the maximum stepgen velocity must be somewhat lower and the machine per axis velocity limit lower still

base period max velocity > stepgen max velocity > machine max velocity
If you do not have this, you may get following errors

Each step requires headroom (say 5-25% each)

Thanks for the quick replies! I didn't appreciate the need for headroom on the joint/axis speeds, and the joint velocity limits are simply set to the 125 mm/s limit imposed by the step frequency limit. I'll try lowering those (and the f-error limits) somewhat. STEPGEN_MAXVEL is not currently set; the docs mention it as an axis setting, but it's listed under a warning that "These are not used by the LinuxCNC software", and there's also a comment that it's for older configurations, so I wonder if it's still applicable..?

Does it make sense to set [TRAJ]MAX_VELOCITY to 2 x the joint MAX_VELOCITY values so as not to artificially limit the speed of diagonal travel?

I've experimented further with joint velocity limits reduced to 100 mm/s (0.8 x step rate limit) but the following error values remain high. I've halscoped them (with raised f-error limits) to get a better picture. Here's a fairly large spike during one of the tricky jobs (an engraving task with a lot of small movements):



If I'm reading that correctly, the following error spikes over 0.5 mm (500 milli mm)!

Even when travelling at constant speed (at the speed limit), the f-error is around 0.04 mm:



How should I proceed? Is there still not enough headroom for stepgen? Should I lower MAX_ACCELERATION and/or raise STEPGEN_MAXACCEL? Would it be useful to scope the per-axis speeds along with the f-errors to see how they compare? Thanks!

I have seen some odd behaviour in the stepgen when close to the limits in the presence of jitter.

One thing that helps is setting the stepgen max-accel to about 125% of the maximum axis acceleration.

If you have backlash compensation enabled, stepgen maxaccel needs to be about 250% of axis acceleration

Can you post your hal/ini files? It may be something else going on

I've noticed that the f-error spikes seem to occur at (or just before) points where the velocity is low. I've tried to pinpoint where in the G-code this was occurring, and found that a particularly bad spot had three consecutive lines with the same co-ordinates. I wonder if these are confusing LinuxCNC's planner somehow. I also suspect that the steppers are losing steps at these points, as it makes quite a "clunk". Here's a cut-down standalone portion that produces a following error spike in the Y axis:



Here's a halscope snapshot of what happens at that point (note that the f-error is less here than in the full job, but is still quite dramatic):



Here's the current machine INI file (I've restored the speed and acceleration limits to highlight the problem):



...and the HAL config:



Hope this helps!

Ahh... Pretty sure this is a known TP bug, I believe its been fixed but the fix is not merged
yet.

The bug is with crazy small blending settings (you have blending set to 1 micron)
2 microns fixes it for your sample code

Ah-ha - yes, that is crazy small! When I saw those consecutive moves to the same position, I realised I should try different path blending settings (particularly movement merging in the Naive cam detector), but didn't have a chance until just now. With G64 P0.01 Q0.01 it seems well-behaved, with following errors staying under 0.05 mm both at speed and at those redundant moves. With G61 it's also well-behaved (albeit with a lot of vibration!). But with fine path blending but no move merges, as you've gathered, it doesn't work out well. I wonder what's magical about the 2 micron threshold you found...but for now I'll get into the habit of specifying either G61 or G64 with both P and Q.

I should also contact the developer of the CAM tool I'm using to see if the redundant moves could be culled there.

Thanks heaps for helping troubleshoot this! Hopefully I'll be able to run a successful engraving job this week.

the following error for stepers can also be incresed to above 1
as no return from stepper at all

and your basePeriod can be easy be at 100000

you shoudt see good speed
WHY is Scale 400 is it per inch
if per mm way to high get microstepping down