Surprised that 0,0 compresses the switches. It’s possible that your homing pull-off is insufficient.
That can be changed in GRBL configuration $27.
Alternatively, change the resting position after job complete in Edit->Device Settings->Return to finish position.
Thanks! I tried setting the Return to Finish value to 3.3 earlier and it seemed to throw off my camera alignment. I’ll try it again.
I’d still like to get homing working like it should though…could insufficient pull-off cause LB to hang?
Edit 1: I tried adjusting $27 to 4 mm and 5 mm, but LB still hangs sporadically on homing.
Edit 2: Confirmed - the camera no longer aligns to the cut result after setting the Return to Finish value to 3.3. I set it back to 0.0.
That should not affect calibration so that’s odd.
Changing pull-off could affect camera alignment if the post pull-off position is 0.0.
Homing should be unrealted to LightBurn hanging. Is LightBurn hanging or is the controller going offline? I assumed the latter based on your description.
In that case it’s most likely a communication issue. You may want to try a different USB cable. Perhaps try toggling DTR signal to see if that makes a difference.
You may want to see if there’s an updated firmware available as well.
Thanks again! Setting the DTR signal to enable didn’t fix it (good call though!). Changing the Return to Finish value definitely does throw off camera alignment. I’ll try to figure out if it’s off by exactly 3 mm. Also, I’m on the latest firmware from Creality.
Is it this below that makes you think the controller is going offline? Is there another way to confirm the controller state? If that was the case though, it seems like other operations would be randomly affected too.
o: gpio_isr_handler_remove(480): GPIO isr service is not install, call gpio_install_isr_service() firste[0m
e[0;31mE (25565096), call gpio_install_isr_service() firste[0m
e[0;31mE (25565096), call gpio_install_isr_service() firste[0m
e[0;31mE (25565096), call gpio_install_isr_service() firste[0m
Lastly, is it right to say that Lightburn records the limit switch stops as 0.0 (home), before pulling off to 3.3?
In what way is it thrown off? Try changing the finish position to something else entirely, like the upper-right of the machine. What happens then?
I’m just going off the behavior. Whenever the controller is unresponsive it’s almost always related to a disconnect scenario or where the controller has crashed. This is most often associated with a voltage drop or static shock. I’m wondering if something with the homing process is shorting the controller. Perhaps the swtiches are not properly grounded or there’s an intermittent short somewhere along the circuit.
LightBurn is uninvolved in position assignment. This is what the controller is reporting and LightBurn relays that. Some configurations of GRBL firmware will zero out origin value post homing. Some do not. When zeroing out post homing it can zero-out after pull-off or before.
Thanks for the great detail! When I’m accurately calibrated and aligned, the camera is off from the result by ~ 1mm. After I change the Finish value, nothing I cut lines up with the Overlay anymore. I’ll try setting Finish value to the upper right corner tomorrow and report back on the camera behavior.
I’ll also try to verify the limit switch connections somehow. That may very well be it since no other operation, other than homing, causes the problem.
Thanks again,
G
Ok, I have tried to get each one of the limit switches to cause the controller to hang (if shorted, etc.), but no luck. I decided to go ahead and set the Finish to 3.3 as suggested and then just make sure that I have a good home before cutting each time (I had auto home off, but re-enabled it). Sometimes I have to restart LB a couple of times to get a ‘ready’ following homing but, once I do, it appears that the camera overlay position remains consistent to the cut result between multiple projects (so far).
I’m still open to suggestions, if someone has seen this type of homing lockup behavior before and has conquered it somehow.
Thanks again for the help,
G
Why do you need to do this? Position should be retained between cuts.
Apologies, I meant to say - make sure that I have a good home before cutting each time, following a cold start of the laser (which I wasn’t previously doing because of the issue). It seems to be working well, except for the problem outlined above. Thanks again for your help and suggestions, I really appreciate it!
A few more observations. When I get a successful home at program startup, I can consistently get a failure on the very next attempt, so I enabled debug logging to see the difference between the two requests. It appears that the start up homing command $I\n, whereas the manual homing call (which fails) is $H\n (see below). Does this appear like it could help figure out what happened somehow?
20:23:21.125 D: “Connecting…” busy: false state: 1
20:23:21.125 D: issuing buffer check
20:23:21.125 D: “Waiting for response…” busy: true state: 5
20:23:21.159 D: O: “$I\n”
20:23:21.160 D: I: “ok\r\r\n”
20:23:21.171 D: “Waiting for response…” busy: true state: 5
20:23:21.189 D: O: “$H\n”
I also discovered that, when the long list of “e[0;31mE (25565096), call gpio_install_isr_service() firste[0m” messages appears in the console at re-startup after a failure, it’s because Lightburn is hung up from the first program close, the one when it prompts me that it’s still streaming. Once I kill that stray LB process, it loads up fine again. It looks to me like Lightburn is hung up, prior to trying to close it down after a homing failure (where the status bar stays at 100%).
Hope this helps in some way.
G
$I is not for homing but is a GRBL command to request information about the controller configuration. Things like GRBL version and compiled options. Try running $I manually and see what happens.
It’s not likely that LightBurn is hung up per se. It’s more likely that the controller is not properly responding or providing proper status updates and assumes that a connection is still live.
What process is this? Is it a COM Surrogate process?
These message are generated by the controller, not LightBurn. You can see what looks like a related issue here in a github repo for espressif:
gpio_install_isr_service( ESP_INTR_FLAG_LEVEL3) fails with 0x105 (resource not found) (IDFGH-7176) · Issue #8777 · espressif/esp-idf · GitHub
It’s an instance of Lightburn.exe that I can see in Task Manager, under Background Processes. I have one stuck in Task Manager right now, from the last time that I closed it. Lightburn itself is not running right now, so is that a surrogate? Edit: there are now two instances running when the program is closed.
I see what you mean about $I, very cool. So, yep. Running $H hangs it every time. Is there a different command to home, like when it’s done from the Move window? Or is it the same command in the background?
I really do appreciate the feedback. Super helpful!
No. Under normal operation you should have a single Lightburn process running and potentially multiple COM Surrogate processes. If you have multiple LightBurn processes running then that’s not ideal and probably from not shutting down properly perhaps because it’s tied up on the serial connection.
All requests to home from LightBurn should use the same command.
It’s interesting that the machine is essentially crashing on soft home request. That really does imply either a firmware issue or some sort of hardware issue.
I’d suggest reaching out to Creality or your retailer to see if they can offer a solution or replacement.
Can you run $I in Console and return output? There may be alternative commands but will be GRBL fork dependent.
Cool, thanks. I’ll get with Creality for sure. This is all that $I returns:
$I
ok
Can you try running that again? It should actually return meaningful information, not just an OK.
That’s all it returns in Lightburn and in LaserGRBL. The firmware version is grbl_1.3a as reported by LaserGRBL at startup (it doesn’t report that in Lightburn).
I’m sure now that you are correct about the firmware, because I can crash LaserGRBL with $H too.
Thanks again,
G
I followed up with Creality and asked for the previous firmware version. They sent me 3.0.20, so I downgraded from the 3.0.24 current version, and the Falcon is flying! I can now home repeatedly without a lockup and the Console returns abundant data (see below). Even the cuts look cleaner. If you have a Creality CR Falcon 10W and are having problems like the above, it’s probably the firmware. Thanks again @berainlb !
$H
b dir:3 head:21
tarx=-660.000000 tary=-660.000000 xmm=-52800 ymm=-52800 xstep=-52800 ystep=-52800
b dir:0 head:21
tarx=10.000000 tary=10.000000 xmm=800 ymm=800 xstep=800 ystep=800
cycle stop
b dir:3 head:21
tarx=-660.000000 tary=-660.000000 xmm=-52800 ymm=-52800 xstep=-52800 ystep=-52800
[MSG:X Axis limit switch on pin GPIO(40)]
[MSG:Y Axis limit switch on pin GPIO(42)]
stop st_go_idleHOMING_CYCLE_ALL:3
ok
$I
[VER:1.3a.20220331:Program End]
[OPT:VNHS*$#]
[MSG:Using machine:ESP32S2_V1]
ok
Nice! Glad you’re up and running.
I wonder if you just had a bad flash or if the firmware itself is broken. Can’t imagine they wouldn’t have pulled the firmware if a lot of users are getting this.
Not sure sir. I re-downloaded and flashed 3.0.24 several times, using the same version of bin files from both of their download areas. I even swapped microSD cards and formatted prior, since I had some card issues in the past with firmware for my 3D printer.
None of my efforts changed the behavior, which is when I reached out to you thinking that it might have been a software problem. I’m glad it’s not,; I really like Lightburn as well as the help that I’ve been given. This is a great product and community!
All the best,
G
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
