Using Lightburn with a GRBL controller. The controller Alarms when the limit switch is pressed but lightburn continues to drive the axis. Is there something in lightburn I have not set properly. secondly the Grbl controller has a Z-Axis but the table is only an X & Y axis. How do I get a get controller software that does not have a Z-Axis?
No. Homing is done in firmware, LB only sends the “start” command. So the problem is your firmware configuration.
What do you mean? Most controller boards feature a z-axis control option, but if you don’t need it, don’t use it. It’s that simple.
The catch is that (some) GRBL versions have Z axis homing enabled, which means they will home the Z axis before homing X and Y.
If the controller firmware tries to home the Z axis, but the machine does not respond because there is no Z axis hardware, the homing sequence fails and the controller sits there with a “not homed” error.
Depending on the controller hardware, the only way to not home the Z axis is to recompile the source code or flash precompiled firmware with the Z axis disabled. The former can become what they call a “learning experience” and the latter may be an Easter Egg Hunt for the proper combination of hardware & options.
We’d probably need to know a lot more about your controller to be able to help.
If you’re willing, please type the following report requests into the Console window in LightBurn (pressing Enter after each one):
$$
$i
?
Feel free to, Select and Copy text from the Console window in LightBurn and Paste it directly into a reply here.
If he’s not driving the Z axes and the X or Y axes move, then it’s not trying to move the Z axes. Otherwise it wouldn’t fault with the home/limit switch activation…
The Z axes is supposed to pull away from the work area and it fails to home on Z, then the machine usually quits, it should not move either X or Y axes because it doesn’t know where the Z axes is.
That’s my line of thought… I’m thinking the addition of the Z axes data was a last thought and is really a red herring … ?
He didn’t imply he built it, so it’s likely to have the proper firmware and settings to operate…
I hope @Harold went through the Lightburn Grbl Setup…?
The homing function in the controller starts with Z then X then Y. If there is no Z homing fails. I’ve tried a switch to simulate a Z but still cannot get it to work. I suspect its my controller software. Not sure how to get new software.
This may be way out there, can you disconnect the wires into your Z axis drive? Trigger the home switch by hand if necessary.
Timing is everything, because GRBL expects the switch to trip twice during the home sequence:
- First trip = during the relatively fast movement to find the home switch
- The axis moves away from the switch to release it
- Second trip = during the slow movement to precisely locate the switch
Manually closing the switch once won’t work, nor will tripping the switch twice during the fast movement.
At least one person rigged a cam on a tiny stepper to fake a Z axis, rather than figure out all the intricacies of grafting it onto the actual laser.
GRBL $22=0 means homing is disabled and GRBL will not attempt to perform automatic homing using the home switches.
When homing is disabled, the controller assumes the position at startup is the home position.
If you turn it on when the laser head is not in the home position, then all future positions will be incorrect.
This seems to be a configuration problem, not a homing problem.
Have you tried setting $22=1 to enable automatic homing?
The GRBL doc may be helpful:
That is the documentation i have for the controller.
I have enabled $22=1. and set a manual switch for Z. When i send a $H and press
Z wait and press Z a second time nothing happens. I expected X to start searching for the X switch.
Any suggestions?
As I said, timing is everything. The machine does not have any hardware on the Z axis, so you cannot manually press the switch when the firmware is expecting it to happen.
To make automatic homing work, choose any one:
- Find firmware matching your hardware without Z axis homing
- Recompile the firmware to not have a Z axis
- Gimmick a fake axis with a motor and a switch
Or you can disable automatic homing again and use the machine without switches by following the manual homing procedure every time you turn it on:
Oddly enough, I was having the same issue with homing.
After a lot of searching I found a solution to the problem of the Z wanting to home before the X and Y would.
In the libraries section of your Arduino software find the directory named “grbl”. In that folder there is a file named “config.h”. Open it using a text editor that can display line numbers if possible. I used NotePad++.
Between lines 100 and 120 there is a defines section for homing types. The ones defined are
#define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace.
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time.
These need to commented out using two forward slashes “//”.
Below those defines is another.
// #define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) // NOT COMPATIBLE WITH COREXY: Homes both X-Y in one cycle.
Uncomment that line by removing the two forward slashes then save the file.
Save your machine settings using LightBurn in a file on your desktop. Then compile the program again and upload it to your board.
Reload your settings onto the board using LightBurn.
Now the Z axis move is totally ignored and the X and Y axis will home at the same time. You will need to change the config.h file back if you want to use grbl for CNC or a 3 axis laser.
I hope this might be of help to anyone else that’s experienced this problem.
Regrettably, many of the boards seem to arrive with GRBL preloaded, but without the source code configured for that particular hardware. As a result, tweaking / compiling / flashing the standard GRBL source code generally does not produce a working board.
IMO, unless you know for sure you have source code exactly matching the hardware, flashing it won’t increase the world’s net happiness.
I have an AtomStack laser that I accidentally wrote to while programming another board. I picked the wrong comm port when I uploaded the program. At that point the laser was useless. I flashed it with grbl and it’s been working fine since.
I realize that my solution may not work on all boards made by a company for their laser. But from my past experience many manufactures use grbl right out of the box as their firmware.
My suggestion is more focused on those using grbl on their own boards. Eg; Arduino Uno with a CNC shield.
Thanks for the info.
My problem is i have no idea on how to put together a program to compile for my GRBL board.
Where do i find the source code and what/how do i compile it ?
Hello Harold.
A few questions for you if I may.
- What kind of controller is it? (Arduino Uno or some other controller?)
- Did you buy it already programmed with grbl?
- Do you have a picture of it?
Thanks
For any modern board that uses a Nano chip I’d highly suggest installing LaserGRBL and using the firmware install feature there to install the firmware named " v1.1h, custom, XY Homing 20190830". That’s a known compilation and well managed through LaserGRBL.
I’d suggest saving your GRBL configuration as reference although I believe it survives the firmware flashing process.
1 Like