Backlash compensation problems

Hi,
i'm trying to mill a pcb board on a 3 axis mill bridgeport like (little bigger). My machine uses leadscrews driven by stepper motors and i need backlash compensation. My problem is that the X axis overshoots when it does backlash compensation, after the compensation is over it is right on the path. It is like the backlash compensation isn't fast enough or the other axis don't wait for the backlash compensation to end. The overshoot length is exactly the backlash i have. The x axis is also the one that has the most backlash. I tested along all axis with a dial comparator and with backlash compensation the larger error is 0.01 mm. I also have slow acceleration ramps because my machine is quite heavy.
I tried everything i can remember, milled at 400mm/min and at 100mm/min, tried in various positions on the table, tried doubling and half the acceleration, also changed from emc2 2.4.7 to linuxcnc 2.5.3 and the final work is exactly the same. The program runs from start to finish without any following errors, even reduced the ferror.
I'm running linuxcnc 2.5.3 on Xubuntu hardy on a pentium 3 900Mhz 256Mb ram with stepper motor drives connected to my parallel port.
I send and image of the finished work, the gcode and the ini config file.

Can anyone help me?
Thank you and sorry for my bad english.

Can you mill a circle and post the result? If so mark on the pcb the axis direction.

jbastos wrote:

Hi,
i'm trying to mill a pcb board on a 3 axis mill bridgeport like (little bigger). My machine uses leadscrews driven by stepper motors and i need backlash compensation.

Well, this is the problem with trying to "mask" a fundamental hardware deficiency with a
software patch. No amount of software brilliance can do away with the fact that the
table of the machine is not completely constrained by the leadscrew. No matter what
the software does, the table is capable of moving over a small range without
the computer being able to control it.

Every time the program calls for an axis to reverse direction, the axis is actually
driven farther than commanded by the amount of the backlash value.
But, it takes time for the motor to catch up to the other side of the
backlash distance, thus the table is not being controlled at all for a moment.
If the command to the motor was given faster, it would cause the stepper to
lose steps.

One other problem with this is that the backlash usually varies with position,
as the leadscrews are usually most worn in the center of travel, causing
more backlash at that point than near the ends of travel. LinuxCNC actually
has a way to help with this, using the leadscrew compensation tables instead
of a fixed backlash amount. It allows you to have different correction values
for each direction, thereby placing a different backlash correction for different
places on the screw.

Finally, you should check that the nut bracket buried in the center of the
machine is not loose. If it is, it will allow movement of one axis to cause
a bump in the other axis. (I had this on my machine a long time ago.)

Jon

Thank you for you attention. Yes i can mill the circle, saturday i will post it.

I have rectified the X and Y screw a month ago and they have a 0.01mm deviation along their length and i checked them with the dial comparator, i also made new bronze nuts. If i tighten the bronze nut's to much i get to much load on the axis, even by hand, so the backlash will always exist in this king of leadscrew. I will check the nut bracket if it is loose, thank you.
What's bugging me is if the X axis is compensating the backlash why shouldn't the other axis wait for it to end the compensation and then start to move?

What's bugging me is if the X axis is compensating the backlash why shouldn't the other axis wait for it to end the compensation and then start to move?

I'm not sure it could, imagine a XY circle, when X reverses (and compensation is applied),
Y is at its maximum velocity so likely can not stop without violating acceleration constraints

What's bugging me is if the X axis is compensating the backlash why shouldn't the other axis wait for it to end the compensation and then start to move?

I'm not sure it could, imagine a XY circle, when X reverses (and compensation is applied),
Y is at its maximum velocity so likely can not stop without violating acceleration constraints

But isn't that the job of the trajectory planner. Shouldn't it be planned before with all the restrictions on all the axis and then execute after? Can't the planner predict where and when the next inversion takes place?

I guess it could but that's a fair amount of complexity to add
to solve a problem that's better fixed in the mechanics

How can i do it easy on the mechanic?

Do you have leadscrews? correct? Ballscrews improve the mechanics a lot.
Do you have belts? Direct drive also improves over belts.
Angular contact bearings on the end of the leadscrews? Probably not, they also improve the mechanics...
At the end all are factors that add errors (as soon the commanded position leaves the PC all can be messy )

jbastos wrote:

But isn't that the job of the trajectory planner. Shouldn't it be planned before with all the restrictions on all the axis and then execute after? Can't the planner predict where and when the next inversion takes place?

No, this is the whole fallacy of backlash compensation. It ONLY works for drilling holes,
where there is no smooth X-Y motion. That can be done. Otherwise, it really DOES NOT
WORK! The fact that the table is not constrained by the leadscrew, and has a range
of free motion that the motor cannot control, is the basic problem.

Now, you COULD come up with another scheme, where whenever an axis reversed
direction, all other axes had to stop first, the backlash would be taken up, then the
motion would resume. This would solve one problem, and might not cause any
others, but it would would likely cause some minor artifacts. It would be a special
case trajectory to satisfy the backlash above all other concerns such as a constant
feedrate, constant chip load, etc.

Fixing the backlash, the ACTUAL source of the problem, is a far better solution.

Jon