Backlash

Can you double or half the value and see if it changes? Maybe they have the wrong units or something.

Ok… tried changing the calibration resolution for G425 from 0.01 to 0.001mm … the numbers seemed to be less clustered around 0.12 and 0.06 and started being 0.11 and 0.05 and started being more consistent but still wrong. Had a close look through the source code for G425 and couldn’t find any bugs.

Re-probed my block size and it’s coming out completely accurate within my measured backlash (width off by 0.02mm) not sure why it was off yesterday. The vise is completely parallel… if you look how I mounted it there are four bolts clamping it in sideways I used to adjust it… rechecked it and it’s still parallel with 0.02mm from end to end.

So… time to declare victory (defeat?) I think my machine is ready to start cutting some metal and that G425 is broken somehow.

I’ve been digging in the code a bit and one more thing came to mind: MIN_STEPS_PER_SEGMENT, which by default is 6. Within planner.cpp, within Planner::_populate_block I found this which is rather suggestive:

// Bail if this is a zero-length block
if (block->step_event_count < MIN_STEPS_PER_SEGMENT) return false;

Not fully understanding context, I can’t say for sure that it is the issue but the fact that MIN_STEPS_PER_SEGMENT is 6 and you were seeing 0.06 or 0.12, it seems like more than coincidence. And it’s simple enough to check by setting MIN_STEPS_PER_SEGMENT to 1 and see what happens. And change calibration resolution back to 0.01.

3 Likes

I’m almost sure this is it! Good find, the number 6 was twigging my memory hard and I couldn’t remember why.

There’s even an issue already for something similar:

2 Likes

Jamie you just got another PR into MArlin!!! congrats…and thank you!

So setting the min_steps_per_segment helped.
Movement looks and sounds different when probing. As far as I can tell it should be moving one step at time but the numbers still look at bit big. Probably microstepping would help in this situation if I could get it working.
G425 V output:

Sides:
Top: 47.63
Left: 838.98
Right: 918.12
Front: 450.39
Back: 504.26

Center:
X878.55
Y477.33
Z34.93

Backlash:
Left: 0.07
Right: 0.06
Front: 0.04
Back: 0.05
Top: 0.01

Nozzle Tip Outer Dimensions:
X2.93
Y3.06

T0 Positional Error:
X-0.03
Y0.01
Z0.87

You are most certainly using micro stepping and I would assume changing it one factor will not do anything but it is good to test.
What board and firmware are you using and I can point out exactly what needs to be changed?

I’m using the full Rambo (not mini) board. My firmware is here:

Google failed me trying to find anything about configuring microstepping.
I tried uncommenting this line and all hell broke loose:
//#define MICROSTEP16 LOW,LOW,HIGH

If you have 100 steps per mm then you are already microstepping.

1 Like

You have made some odd changes, You should use mine.

Change those to 8, get rid of your steps edits you made.

And in config.h cut your steps by half.

I didn’t change that line it’s the default marlin bugfix branch setting which I forked from.

I’ll compare against yours thanks for having a look.

Aha ! Good to know. I think I’m going to give up on this G425 thing then.
I’m pretty sure my machine is OK no point in trying to fix G425.

Just curious… is there a reason to used 8x microstepping instead of 16x ?

The only reason I can think of is if the step rate exhausted the cpu capability before the motors lost torque and you wanted to go as fast as possible. The cpu has a max rate that it can toggle the step pin, but for our purposes we are far from that limit.

1 Like

It was suggested as a debug test, not as a solution. If the error changed with different amounts of microstepping, it might have meant something.

1 Like