GRBL itself manages homing - LightBurn just sends the command, and the controller takes over from there.
Homing the machine in ONLY X/Y likely means building your own version of GRBL with the Z-homing disabled.
The toggle to disable the Z axis in LightBurn just means that LightBurn will not emit Z-moves in the job sent to the laser. It still allows you to jog the Z, and any commands on the controller that also move Z, like the home command, will do so as well - we donât control the homing cycle.
This is because it is not a LightBurn thing, it is a grbl thing. When you say âEither it works or it doesnât.â, what are you referring to? What is âitâ? If you want grbl to work as you describe, you will need to code and change grbl then build that version for your use. Nothing to do with LightBurn.
LightBurn sends the command $H to GRBL and GRBL performs the entire homing cycle. I have no control over which of the axis are involved - that is entirely up to the configuration of your GRBL device.
âEither it works or it doesnâtâ - in the places I am able to control, it absolutely works. It doesnât work in the places I am not able to control. Being aggressive and confrontational here isnât going to get you better help.
I know all about the recompiling of GRBL for the homing. However I have not found that info in the LB docs. Does that imply that your customers should completely understand GRBL to use your software. I use Windows and Linux and donât know 5% about them. Has anybody ever thought about putting two sentences in the docs that says this does not work or this works a certain way or this doesnât work at all with GRBL and even if you are new to the game you should know that. QUE Books got filthy rich writing books with information not found or easily found in the beginnings of all this PC business. I bought many of those and the Idiots Guides. My first computer was a Radio Shack Color Computer then I stepped up to an Apple 2e in ''83-'83.
I do like your software and it works well. Thank you for your time.
Correct, this is because we are not the folks that produce or document grbl. We work with the official grbl releases and do not require any recompiling of grbl to do so.
No, it does not. It is helpful if the user has some familiarity with the equipment they plan to use, but we also try to offer guidance and shared knowledge to help them âunderstandâ what they need to know to accomplish their lasing goals. We try very hard to offer this help.
You are asking for grbl to support something that can be done, but is not part of the official releases unless you code it, submit that change back and have your changes accepted by the owners of that project.
Documenting grbl is outside the scope of LightBurn.
LightBurn supports a fairly wide range of hardware, including multiple DSP controllers, GRBL, Smoothieware, and Marlin. With the GCode controllers marketed as DIY systems, I feel like a lot of people ignore the âYâ part of that and never bother to learn anything about how the hardware works. LightBurn supported the DSP controllers first, then added the Gcode controllers because it was relatively easy to do so.
Because LightBurn is an alternate software for several different hardware systems, we generally assume that users know some basics about their hardware. No, we donât require you to know this, but most users donât get upset about the minutiae of which axes are involved in homing, either.
Mea culpa Mea culpa Mea maxima culpa. The above quote explains much. I also see that you say it is marketed as a DIY system for Gcode. I found the new documentation. It is much better than the Docs available from the Help menu in the software.
Thank you for what you do. I apologize for the ruffling of the feathers. I also edited my config.h and recompiled - does exactly what I want.