My setup: DIY Lasercutter, Smoothieboard running a CNC build of Smoothieware (so GRBL mode is enabled)
Problem: When establishing the connection to my Smoothieboard, Lightburn hangs being “Busy” (e.g. streaming data). This happens with any version of Lightburn newer than 0.9.16
To reproduce this behaviour, I power on the lasercutter and start Lightburn. In the Laser tab I click “Devices”, select my GRBL device, klick “OK”. When I select the com-port (Linux: /dev/ttyACM0), I get the following output on the Lightburn console (“show all” is enabled) :
Waiting for connection…
Waiting for connection…
Smoothie
ok
ok
ok
ok
ok
ok
ok
ok
ok
[G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F12000.0000 S0.0000]
Lightburn remains “Busy” at 100% and I can not use the machine. The debug console on my Smoothieboard reports back as “Idle”.
My guess i, that Smoothieware does not answer correctly to one of the initialization commands introduced in version 0.9.17. But I can not figure out which commands are being send during this phase. When I execute the gcodes in the last line individually, Smoothieware answers “ok” to every single one. When I send them all at once (“[G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F12000.0000 S0.0000]”) Smoothieware replies “ok - ignored”.
Questions:
- What happens exactly during this initialization phase?
- What commands are being send?
- How does LB “Query GRBL for buffer size on startup” LB 0.9.17 Changelog
- Which answers are being expected?
- Why might LB stay busy at 100%?
I can modify the firmware on the smoothieboard. Any help is appreciated.
Why Smoothieware in GRBL mode: Until some time ago, the max. S value for Smoothieboards was fixed in Lightburn to be 100. Since LB send the S value with no decimal places to the machine, I only get 1% increments in power. This is too coarse a resolution for me, since I also want to be able to score paper at rather slow speeds on my ~90W machine. So I switched to GRBL in LB which enabled me to set a max S value of 1000. In smoothieware I divided the received value by 10 (custom compilation) and got the needed decinal place. Might be obsolete now, but worked perfectly until LB 0.9.16 