gnea / grbl

An open source, embedded, high performance g-code-parser and CNC milling controller written in optimized C that will run on a straight Arduino
https://github.com/gnea/grbl/wiki
Other
4.04k stars 1.61k forks source link

Setting $101 (step size) does not appear to be having the appropriate result #1223

Closed proffalken closed 1 year ago

proffalken commented 1 year ago

Hey all,

I'm building something that has an X/Y/Z axis so it makes sense to use the same software I use on my CNC machine, GRBL 1.1h

I've followed the steps at https://diymachining.com/grbl-steps-per-mm/ to set the step size, and yet when I try to move the Y axis 1mm, it moves several orders of magnitude more.

As an example, the formula on that page states the easiest way to work out the step size is Updated Steps/mm = (Current Steps/mm) / (Dial Indicator Reading)

I've marked on my Y axis where the gantry starts, then sent the GCode to move it 10mm, then marked again. I've then taken that distance (17.69mm) and applied the formula as follows:

Current Steps * Distance Requested Distance Moved New Step Size
250 * 10 17.69 141.320

Unfortunately, this has drastically reduced the speed at which the gantry moves, whilst also massively increasing the distance!

I'm sure I'm missing something obvious here in my config or my mathematics, but I genuinely can't work out what's going on!

Config is as follows:

> $$
$0=10 (Step pulse time, microseconds)
$1=25 (Step idle delay, milliseconds)
$2=0 (Step pulse invert, mask)
$3=0 (Step direction invert, mask)
$4=0 (Invert step enable pin, boolean)
$5=1 (Invert limit pins, boolean)
$6=0 (Invert probe pin, boolean)
$10=17 (Status report options, mask)
$11=0.010 (Junction deviation, millimeters)
$12=0.002 (Arc tolerance, millimeters)
$13=0 (Report in inches, boolean)
$20=0 (Soft limits enable, boolean)
$21=1 (Hard limits enable, boolean)
$22=1 (Homing cycle enable, boolean)
$23=1 (Homing direction invert, mask)
$24=50.000 (Homing locate feed rate, mm/min)
$25=635.000 (Homing search seek rate, mm/min)
$26=250 (Homing switch debounce delay, milliseconds)
$27=1.000 (Homing switch pull-off distance, millimeters)
$30=1000 (Maximum spindle speed, RPM)
$31=0 (Minimum spindle speed, RPM)
$32=0 (Laser-mode enable, boolean)
$100=250.000 (X-axis travel resolution, step/mm)
$101=141.320 (Y-axis travel resolution, step/mm)
$102=250.000 (Z-axis travel resolution, step/mm)
$110=500.000 (X-axis maximum rate, mm/min)
$111=500.000 (Y-axis maximum rate, mm/min)
$112=500.000 (Z-axis maximum rate, mm/min)
$120=10.000 (X-axis acceleration, mm/sec^2)
$121=10.000 (Y-axis acceleration, mm/sec^2)
$122=10.000 (Z-axis acceleration, mm/sec^2)
$130=200.000 (X-axis maximum travel, millimeters)
$131=200.000 (Y-axis maximum travel, millimeters)
$132=200.000 (Z-axis maximum travel, millimeters)

The only thing I can think of is that I've added in the header pins across M0, M1, & M2 to give the highest precision stepping - do I need to factor that into my calculations as well somehow?

Thanks in advance!

breiler commented 1 year ago

The calculation that you made should be correct. Did you reset the controller after making this update?

proffalken commented 1 year ago

Reset as in send $X, or something else?

breiler commented 1 year ago

You need to issue a CTRL-X real time command or press the reset button on your controller.

proffalken commented 1 year ago

OK, I've just pressed the reset button on the arduino clone (Seeeduino) that is running GRBL.

I then told it to move 10mm, and it moved 18mm according to my measurements.

Is it worth recalibrating it again based on these values?

That would take the step size down to 7.85mm, and that seems way too low.

proffalken commented 1 year ago

Update:

I reset the value $101=250 and then reset the board.

I then told it to move 10mm, and it moved 31.54. (250 * 10) / 31.54 = 79.26, so I ran $101=79.26 and reset the board again.

This time it moved 10.17mm, which is more than accurate for my purposes, and the .17 may well be a measuring error.

As a result, I'm going to close this off - thanks for the support @breiler , I suspect it was the reset that was giving me the wrong measurements!