I sometimes get an error 9 at mid project and the module stops. Is there a marker in the code as the exact position when it encountered the error?
Is there an option to continue from that marker?
If this is not possible can this capability be programmed into lightburn?
You will usually get some kind of message in the console tab of the cut/layer window.
With a 9 error, I believe it thinks it’s being driven out of it’s working area.
If it’s a grbl code error, attempting to drive it out of bounds, it usually shows up in the console window.
Might want to copy pertinent information off the console and paste it here.
Maybe @misken can lend a hand if none of this works for you.
1 Like
In general, no and no. The GRBL doc says this about errors:
[…] what all professional CNC controllers do when they detect an error in the G-code program, halt. Don’t do anything further until the user has modified the G-code and fixed the error in their program.
The Console message will (probably) have a link to the error description, like this for Error 9:
9G-code locked out during alarm or jog state
That generally means a hardware problem reset the controller while it was running the program and it restarted while LightBurn was still sending the rest of the program. Because the controller must be homed after restarting to know where the laser head is on the axes, it cannot continue. Because the error occurred in the middle of the program and the controller’s buffer contained an unknown number of already-sent commands, LightBurn cannot continue the program from the same spot.
This type of problem almost always happens due to a USB communications glitch or a power supply fault.
Note that GRBL has both Error and Alarm messages, with different meanings:
1 Like
Thanks for the info. As a programmer myself I was thinking of monitoring laser head position or cordinates during the engraving process. It is just an idea that came to mind. That would mean doing a “dry run,” to establish the data of the image. Ok enough! Thanks for the response.
None of the controllers report real-time positioning information, so LightBurn has no idea what’s going on.
Contemporary controllers have enough memory to absorb the entire program and, after that, become pretty much a black box, which is why the LightBurn progress gauge reports only the data transfer percentage.
Old-school Arduino GRBL controllers have a 128 byte buffer, so the data transfer fraction closely matches the actual progress, but that’s not enough for point-by-point tracking.
I think this is well established before or as any code is generated.
Maybe if you can elaborate on what you actually want to accomplished.
@ednisley is correct, there is not much Lightburn can do once the data is shipped to the controller.