Welcome! Log In Create A New Profile

Advanced

Software workaround for backlash

Posted by khiraly 
Software workaround for backlash
January 15, 2009 01:17PM
Hi!

Im using a Seedling machine where motor shaft are connected to lead screw using pneumatic tubes. (like aquarium tube, but a bit stronger).

The backlash (number of steps before the lead screw start turning when changing direction) is exactly 8 steps (on axis X) and always the same.

So Im looking for some software workaround, when changing the direction on a given axis, the system should step 8 steps before counting the remaining steps.

I would like configuring something like this:
#define x_forward_backward_backlash 8
#define x_forward_backward_backlash 7

#define y_forward_backward_backlash 11
#define y_forward_backward_backlash 13

#define z_forward_backward_backlash 3
#define z_forward_backward_backlash 4

Did anybody look deeper at this? I cant find any trace in the 1.3 reprap gcode firmware about backlash.

Best regards,
Khiraly
Re: Software workaround for backlash
January 15, 2009 02:07PM
8 steps out of 400 steps / rev with (I am guessing M6x1 thread) would be 0.02mm. One fifth of the target resolution and completely swamped by filament tolerance so I can see why it has not been implemented.


[www.hydraraptor.blogspot.com]
sid
Re: Software workaround for backlash
January 15, 2009 09:24PM
Well if you reverse the direction just once you're right chris,

but when you reverse a direction multiple times in one layer it may leed to a visible reduction of target size.
Let's say a zigzag infill pattern on a large object reversing 50 times you'll loose 1mm.
Many objects can have 50 infill lines per layer, so this may be a good idea to have antibacklashing options implemented in the host;
if there's no need for certain machines (darwin, mendel, hydraraptor winking smiley) it can be set to NULL; but for a mcWire it may make sense

'sid
Re: Software workaround for backlash
January 15, 2009 10:15PM
sid, you sure about that? Backlash doesn't add up with with multiple movements, it's just always off 0.02 mm or less in the above example; the only question is which way it's off, which would be determined by the last direction travelled. If it's adding up, you've got a slipping coupling somewhere.

Khiraly, is there really backlash on your leadscrew, and not the stage itself? That would indicate that your couplings are very soft, or too loose.

Wade
Re: Software workaround for backlash
January 16, 2009 12:39AM
> sid, you sure about that? Backlash doesn't add up with with multiple
> movements,

And you? Is the backlash always symmetrical? (I need some more testing and experience to say it for sure)


>Khiraly, is there really backlash on your leadscrew, and not the stage
>itself? That would indicate that your couplings are very soft, or too
>loose.

I have attached a pen to my machine, and, when i draw a rectangle it does not close exactly. I printed some text for fun, and there are some glitches.

I will make some photos. The silicon tube of the Z axis are soft, Im looking something like the FESTO pneumatic tube, but 8mm inner diameter.
(I cant find anything else but 6mm inner diameter).
Re: Software workaround for backlash
January 16, 2009 02:48AM
Backlash isn't necessarily symmetrical, it just depends on the last direction of travel. If you have 0.02 mm of backlash on the X, a positive move after a negative move will be short 0.02 mm, and vice versa for a negative move after a positive one. Two negative moves in a row should give you an exact displacement, as would two positive moves in a row. But it shouldn't add up over time, unless something is slipping.

Try a simple test - push the X and Y stages (not the pen) by hand with a pen attached, and see how wide the mark is. That should show you roughly how much backlash you've got. If it's less than the error you're seeing during programmed moves, you've got a problem elsewhere. It could be noise on the step line, slipping belts (I've been dealing with that one today), software problems, or something else.

What's the resolution on your X and Y Khiraly? That would let me know if I'm in the right ballpark or not. My machine is belt driven, and I think i've got in the ballpark of .3 mm of backlash now, and that's mostly because I've got my belts set pretty loose to avoid skipping teeth (another long story), but it's generally not noticeable at 0.5 mm filament width.

Wade
Re: Software workaround for backlash
January 16, 2009 08:12AM
Backlash isn't all that hard to fix mechanically. Take a look a these simple antibacklash nuts.

[www.nollinc.com]


-------------------------------------------------------

Hell, there are no rules here - we're trying to accomplish something.

Opportunity is missed by most people because it is dressed in overalls and looks like work.

Thomas A. Edison
Re: Software workaround for backlash
January 16, 2009 10:08AM
> What's the resolution on your X and Y Khiraly? That would let me know
> if I'm in the right ballpark or not.

I use a threaded rod (6mm dia) and a long nut. (I will make photos to be clear, or even start a blog. I posted a video some time ago in a previous stage of my machine, its here: [www.vimeo.com] )

Im currently figuring out how everything works (I accidently switched the X and Y motor driver cables, all the axes are inverted (eg: when I say "G0 Z10" the pen is going down and not up).
So it takes some more day to figure out and *measure* the exact numbers and identify what errors comes from what source.

But I use metric 6mm diameter threaded rod and 200 step/revolution stepper motor.

> It could be noise on the step line, slipping belts (I've been dealing
> with that one today), software problems, or something else.
Electrically it works. The system pause for some ms between the gcode lines, but there is no slipping are accident steps.

> Backlash isn't all that hard to fix mechanically. Take a look a these
> simple antibacklash nuts.

My primary source of backlash are not coming from the nuts. It is the motor connection. Although I do not use aquarium tubing, but a bit more stronger silicon tube (I have a friend who works with pneumatics), but the main problem remains: namely it is elastic. So there are about 2mm backlash at the Z stage (it is the worst), and when the Z axis are the lowest stage it can even elongate about 4 mm before start moving.
With time the Z stage will wear together, but I need to find some remedy for it.

I was today in a silicon tube specialist shop, and got 16mm diameter tube with 8mm inner diameter, wich is lot stronger than what I have.

Monday I will go to a teflon specialist shop, where I can browse for the right teflon tube (8mm inner diameter). The teflon is less elastic and more rigid. Maybe it cures my problem.

I have backlash on the X ad Y axis, but they are under 1mm.
The pen and the pen holder stretch too, it adds another source of error.
The pen holder stretch in the Y axis.
sid
Re: Software workaround for backlash
January 16, 2009 10:48AM
Quote

sid, you sure about that? Backlash doesn't add up with with multiple movements, it's just always off 0.02 mm or less in the above example; the only question is which way it's off, which would be determined by the last direction travelled. If it's adding up, you've got a slipping coupling somewhere.
You're right Wade, sorry,
I messed up "ignoring" with "loosing" steps.

but asymmetrical backlash would then leed to a moving print (sorry, don't know how to say)
let's say you move 20 steps, and your backlash is 6 in one and 8 in the other direction.
the pattern will look like this:
      ______________
        ____________
        ______________
          ____________
          ______________
in that case it will add up the two steps in one direction

'sid
Re: Software workaround for backlash
January 16, 2009 10:51AM
Well that just implies that backlash is always symetrical because backlash is definitely not additive.


[www.hydraraptor.blogspot.com]
Re: Software workaround for backlash
January 16, 2009 01:29PM
Yes agreed, it has to be symmetrical then! Khiraly's non symmetrical numbers are probably caused by the squishyness of the connectors.

Khiraly's problem looks like soft connectors though; which I suppose could be fixed with anti-backlash code, but a better idea would be some stiffer connectors.

With 6 mm rod and 200 step motors, you should get 200 steps/mm with full stepping, so 8 steps is 0.04 mm. Not a big deal if you're using 0.5 mm filament. The Z axis is the only place that might be noticeable, and gravity should take care of backlash for you there.

Wade

edit - just to be clear, backlash has to average out to zero over time. If it doesn't, then it's not just backlash anymore, and it means something is slipping somewhere.

Edited 1 time(s). Last edit at 01/16/2009 02:23PM by Wade Bortz.
Re: Software workaround for backlash
January 16, 2009 02:58PM
Ok I have found some tables about pitch on metric threaded rod:
M4, pitch: 0.7mm
M5, pitch: 0.8mm
M6, pitch: 1mm
M7, pitch: 1mm
M8, pitch: 1.25mm
M9, pitch: 1.25mm
M10, pitch: 1.5mm

Im using M6 threaded rod, one turn means 1mm travel.

Currently 1500 GCode unit means 122mm in real life.

I used the default setup in _init.pde file:
// define the parameters of our machine.
#define X_STEPS_PER_INCH 416.772354
#define X_STEPS_PER_MM   16.4083604
#define X_MOTOR_STEPS    400

#define Y_STEPS_PER_INCH 416.772354
#define Y_STEPS_PER_MM   16.4083604
#define Y_MOTOR_STEPS    400

#define Z_STEPS_PER_INCH 16256.0
#define Z_STEPS_PER_MM   640.0
#define Z_MOTOR_STEPS    400

I dont know why these are the defaults, but I should adjust to my
need.
It should be:
#define Z_STEPS_PER_INCH 5080
#define Z_STEPS_PER_MM 200
#define Z_MOTOR_STEPS 200

Maximum feedrate is a bit of confusion for me (Im trying to understand the arduino code).
Re: Software workaround for backlash
January 16, 2009 03:36PM
Those defaults are closer to what a Darwin uses. Mine are like so:
// define the parameters of our machine.
#define X_STEPS_PER_INCH 203.2
#define X_STEPS_PER_MM 8
#define X_MOTOR_STEPS 400

#define Y_STEPS_PER_INCH 203.2
#define Y_STEPS_PER_MM 8
#define Y_MOTOR_STEPS 400

#define Z_STEPS_PER_INCH 8128
#define Z_STEPS_PER_MM 320
#define Z_MOTOR_STEPS 400

//our maximum feedrates (mm/min?)
#define FAST_XY_FEEDRATE 1000.0
#define FAST_Z_FEEDRATE 200.0

The feedrates are the absolute maximum limits, and the Gcode interpreter defaults to them unless you specify something else. They're in mm/min, although I tend to think in mm/s usually.

A Seedling will have lower max speeds, so start with them high, and then play with the F parameter until you find out the fastest speed you can handle without skipping, and then set your maximums below that.

IE, send:
G1 X50 F1000
and if that skips, try F500, etc.

Once you get your resolution correct, 1000 mm/min will probably faster than your machine can handle, so be prepared for some missed steps until you slow it down.

Wade
Re: Software workaround for backlash
January 16, 2009 06:31PM
> Maximum feedrate is a bit of confusion for me (Im trying to understand
> the arduino code).

No need to understandwinking smiley
At 500 it already shakes, at 100 its just too fast, so i finally set it to 80.
Sorry, only registered users may post in this forum.

Click here to login