Lightburn Hanging With Laser Busy
As the title indicates using Lightburn with Mini Gerbil I'm finding it hangs and becomes non responsive in certain situations showing Laser busy and will not accept any further commands until a reset is sent. Particularly if X axis is less than 10mm from home and entering "?" command or even sometimes jogging with the Move panel. This became apparent to me after the second Lightburn update 0.9.09. The first Lightburn update 0.9.09 also exhibits this problem although not as bad on my machine. I can replicate the "?" command hanging Lightburn all the way back to 0.9.07 with the X axis anywhere from 0-9mm but once it's to 10mm it seems fine. I can run the same commands through Gcode sender without any problems at any coordinate position.
I've also been communicating with Lightburn on their forum but have not come up with any solution. Has anyone else noticed any behavior similar this? Or does anyone have any clue what could possibly be causing this? Thanks in advance.
Update, It seems this problem also exists with Gcode sender. It's most apparent to me when X is under 9mm from home but I wouldn't eliminate it as being a problem at any coordinate. I'm just able to easily recreate it at <9 mm from home position. It seems Gcode sender has a bit better/worse error handling with hangs than Lightburn is why I didn't recognize it previously. In addition I had to disable Status polling within Gcode Sender. If status polling enabled @ 200ms it has always respond with Ok to ? command.
So what appears to be happening is when sending "?" command to the Mini Gerbil all is fine up until I go to G0X9 or below at which point the Mini Gerbil doesn't respond with an answer immediately. In Lightburn this causes the application to sit at "Laser Busy" and is no longer responsive. In Gcode Sender it sits at ">>> ?" without a response waiting for the next input command. At some point it seems the Mini Gerbil does respond to all the previous requests in a single larger than normal packet as if it were waiting for a buffer to fill.
With Lightburn I've also had it hang just jogging around from Home position so I don't think this is specifically related to the ? command. I'll attach the USB sniff and console responses for you to review. Hopefully you have some insight to what's causing the problem and is a easy fix.
Couldn't upload the capture file so had to rename it MiniGerbil.pdf. It needs to be renamed .cap and opened with your favorite analyzer.
And the MiniGerbil_GcodeSenderHangs.pdf is a .txt document so needs renamed .txt. Couldn't upload text docs either.
Uploaded files:
I am a bit perplex since I can't replicate the issue. What device driver are you using in LightBurn?
Hi Paul,
I've tried Gerbil-STM which was my original default, added Gerbl but they both have same problem. I'm really at wits end with this and LB trial is coming to an end shortly. I just did a USB sniff side by side with Lightburn when it hangs to upload to them but I'll post here as well. I don't really know what else to do at this point. Below are the steps and responses during the video.
Host is PC, 3.25.3 is outgoing to controller, 3.25.1 is incoming from controller.
Line 1118 First Command from Host G0X10Y0
Line 1119 Response from 3.25.1 "Ok"
Line 1785 Host Send G0X15Y15
Line 1786 Response from 3.25.1 "Ok"
Line 2177 Host Send G0X9Y0 (First time X under 10mm from Home)
Line 2178 Response from 3.25.1 "Ok"
Line 2786 Host Send $H
Line 2799 Response from 3.25.1 "Ok"
Line 3718 "?" from Host. There was no "?" command given, the input was to Jog X15 and should have been "G21 G54 G91 G1 X15 Y0 F6000 S0 G90" but it never made it to the USB wire. (Just received communication from Lightburn and they indicate ? is put on the wire prior to jog controls to verify within bounds)
So this would be the point of the hang when a ? is sent to the controller while in Home position. This seems to keep going back to the ? command being sent to the controller when the hang occurs when X is within 10 mm from home.
https://drive.google.com/open?id=1MePj5sIhyC76wEhmBrJQHHx0UAyNRNRn
I believe I found the problem. The Mini Gerbil came default with $10=31 but from what I can tell that's not a valid option for $10. This page indicates only 0, 1 & 2 are valid options unless that's not the correct page for our version.
https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#10---status-report-mask
I've set $10=1 and it appears the hangs have gone away when issuing ? command when X axis is within 10mm of home.
I see you also have it listed on your Default Settings page as $10=31. Is this an error or can you explain this setting in more detail and or why it created a problem in my situation?
https://awesometech1.wpengine.com/what-are-settings/
Hi, thanks for chasing that up. $10 had multiple options for debugging which the official Grbl might have watered it down to improve the communication speed.
I will update the $10 report settings so we don't get that issue anymore.
Originally it was documented as below:
$10 - Status report mask:binary
This setting determines what Grbl real-time data it reports back to the user when a '?' status report is sent. By default, Grbl will send back its running state (can't be turned off), machine position, and work position (machine position with coordinate offsets and other offsets applied). Three additional reporting features are available that are useful for interfaces or users setting up their machines, which include the serial RX buffer, planner block buffer usage, and limit pin states (as high or low, shown in the order ZYX).
To set them, use the table below to determine what data you'd like Grbl to send back. Select the report types you'd like to see in the status reports and add their values together. This is the value you use to send to Grbl. For example, if you need machine and work positions, add the values 1 and 2 and send Grbl $10=3 to set it. Or, if you need machine position only and limit pin state, add the values 1 and 16 and send Grbl $10=17.
In general, keep this real-time status data to a minimum, since it takes resources to print and send this data back at a high rate. For example, limit pins reporting is generally only needed when users are setting up their machine. Afterwards, it's recommended to disable it, as it isn't very useful once you've got everything figured out.
| Report Type | Value |
|---|---|
| Machine Position | 1 |
| Work Position | 2 |
| Planner Buffer | 4 |
| RX Buffer | 8 |
| Limit Pins 16 |
Cheers, Paul
Yea it caused me a lot of grief & consumed a lot of time figuring this out. I found 0 & 1 worked fine but 2 caused it to hang for some reason, similarly to what 31 was doing. IDK why unless it's this variant version isn't the same as what's listed on the Github page.