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.08k stars 1.61k forks source link

XY (non-Z) homing without a recompile #291

Closed gfwilliams closed 7 years ago

gfwilliams commented 7 years ago

Hi,

Apologies if this has already been covered, but I haven't managed to find anything on it.

There's a great howto on setting up homing here: https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle

However I have a laser engraver with no Z axis, and homing with $H searches on Z first. It looks like I can simply rebuild with a tweaked config.h, which is awesome and which I will do.

... However, would it be possible to maybe make limits_go_home check the steps/mm or max speed setting for the axis it is checking? That way, anyone without a Z axis (or without Z homing) could take a totally standard binary, set $102=0, and have it work perfectly with limit switches without a rebuild?

Either that or the $22 homing cycle could take a numeric value, where there were different options for homing style.

Anyway, just an idea for an enhancement - it'll work great as-is with a rebuild.

jahnj0584 commented 7 years ago

You're just going to have to edit the config.h and reflash. It doesn't take much time.

On Oct 14, 2017 12:04 PM, "Gordon Williams" notifications@github.com wrote:

Hi,

Apologies if this has already been covered, but I haven't managed to find anything on it.

There's a great howto on setting up homing here: https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle

However I have a laser engraver with no Z axis, and homing with $H searches on Z first. It looks like I can simply rebuild with a tweaked config.h, which is awesome and which I will do.

... However, would it be possible to maybe make limits_go_home check the steps/mm or max speed setting for the axis it is checking? That way, anyone without a Z axis (or without Z homing) could take a totally standard binary, set $102=0, and have it work perfectly with limit switches without a rebuild?

Either that or the $22 homing cycle could take a numeric value, where there were different options for homing style.

Anyway, just an idea for an enhancement - it'll work great as-is with a rebuild.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gnea/grbl/issues/291, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDBJifUWUsDmg8llx9pB5N7p59Cazks5ssM17gaJpZM4P5aNI .

chamnit commented 7 years ago

Seems like an ok idea but all the remaining flash space is reserved for bug fixes only. There is literally a few hundred bytes left in certain critical configurations. A check like and logical involved would take up a good chunk of that. Don’t fret though. The future ARM 32-bit version will try to eliminate compile time editing for most things.

gfwilliams commented 7 years ago

Ok - thanks for the speedy response. I wasn't aware flash was so tight.

As you say, it was trivial to change in the config - I'd just thought that as so much was configurable at runtime it'd be a nice easy fix.