I will test with the devices I have on hand and attempt to generate the same error. I will also reach out to a colleague with a Sculpfun device and invite him to do the same if his schedule permits.
I have escalated this to the Developers.
I am looking forward to their response.
Thank you very much. If you need some more tests, I will do it.
It is very unpleasant to debug serial line on Scupfun, because fan is as loud as 72dB and I cannot concentrate on PC well :(. It is stupid to run fan on full speed when LASER is off.
Also thanks to [misken] to confirm same issue.
DTR seems to be handled from within applications and client cannot influence it anyway:
0.00000120 LightBurn.exe IOCTL_SERIAL_CLR_DTR Serial2 SUCCESS
Just remove the power cable from the laser module, then you can test everything except the fan is turned off.
Here is a video that I created in July last year, where I had such a behavior: https://diode-laser-wiki.com/wp-content/uploads/2023/04/26.07.2022_10.28.19_REC.mp4 I hope you can see what I’m doing 
When I clicked on the devices button, I did a right click. I made it for the Sculpfun team to debug the connection issue, but this was not solved back then (obviously )
Yes, you have found a same issue. I have also found a remedy for this, it has been already described here.
It seems to me that Sculpfun producers are doing a bad job - the fan could/should be controllable. My 3D printer has controllable fan with measuring rpm. It is even more safe than to run a fan forewer, because you always know whether fan rotates or not. Even when you hard turn a fan on, control unit knows nothing whether it rotates or not. Fan hang could damage and melt extruder - analogy to LASER.
This makes some problems with debugging such issue. The connector on LASER head could be detached. But is seems to me that this type of connectors are not produced for repeatable connecting and detaching.
That has been considered but discarded. The cooling of the diodes has a very high priority, and usually diodes are driven close or above specification. Cooling is crucial and if it stopped too early or not started at the right time, the diode will die in seconds. That’s why it’s most user-proof to leave it on.
You should take care about the connector, but I constantly change laser heads for testing and cleaning and never had an issue. I think I unplugged more than a hundred times. But you need to do it with care, sure. But it’s true, with the new Ultra series, they changed the connector to avoid problems they had with the old ones.
If the developers are looking into the serial communication, I’d suggest to include this fix as well: [Feature Request] or [Bug report]: Reset command for 32bit boards (ctrl+x) - #2 by berainlb
I know how to do this task even more safe (for LASER) than original solution. Once you measure fan speed you can immediatelly cut LASER power when rpms are lower than threshold. There could fall something to fan and stop it. There is no check whether fan really works.
I just guess that the thermal capacity of aluminium block is high and the critical overheat time is not seconds but minutes.
The problem is that a suitable fan that measures rpms 9WFA0624P6G001 cannot be bought anyway:
https://cz.mouser.com/ProductDetail/Sanyo-Denki/9WFA0624P6G001?qs=vHuUswq2%252BswdS4REC3NqCQ%3D%3D
If the developers are looking into the serial communication, I’d suggest to include this fix as well:
Thank you for a hint. I hope that this confuses every new user before he finds some workaround or the SW gets fixed.
Thank you for this reminder. I’ll confirm that this is in motion. Ctrl+x was requested on another thread as well.
I hope that this problem will be fixed and nobody else will fall into this trap.
I can imagine some solution, but I cannot fix a code (only serial communication).
I tested a Monport on Friday and Multiple G0 did not induce the strange state.
Monport is produced by different manufacturer than Sculpfun. I can test whatever you ask.
I have read that there is a new firmware out. It is questionable whether this deffect is already gone or not.
I do not want to change my setup to verify the Lightburn to fix with the same setup.
You have nice videos for beginners, but please keep in mind that this problem occurs in combination LightBurn and SculpFun.
Power cycling of anything - PC or GRBL can work, but it is too bad solution. I recall Windows 3.1 that must be power cycled several times because of deffective software inside. When software workaround is known it should be used and preferred.
Or the LightBurn programmers could claim that they never plan to workaround this.
@Fojtik Which Sculpfun device are you seeing this with?
We have a Sculpfun S9 board in testing and it is a Makerbase DLC V2.1 board.
The Firmware Version is
[VER:1.1h.20190825]
[OPT:V,15,128]
I believe that the option codes indicate that this is an 8-bit control board the same as yours.
We could not recreate the initialization failure with either a Macbook Pro running LightBurn 1.4.00 or with a Laptop running Win 11 and LightBurn 1.4.00. @daniellb even downloaded LaserGRBL and attempted to replicate the lock-up by jumping back and forth between LightBurn and LaserGRBL. We also did not see the multiple G0 generated by LightBurn, Nor were we able to put the controller into the unusual state you have described by manually sending successive G0 multiple times.
I have reviewed a support ticket from March where a user had Successive G0 and a failure to connect. In this particular case LightBurn had defaulted to a different device profile. A second device profile for another engraver was available and it operates at a different baud rate.
Do you own more than one laser engraver? Do you have more than one device profile in LightBurn?
Would you mind confirming the baud rate in your serial port reader?
I believe the Sculpfun S9 is expecting 115200 as a default.
@misken You are testing with a very different board. Is yours the Sculpfun S30?
Can you confirm that the communication parameters of the Sculpfun are not changed by LaserGRBL?
thank you very much for your response.
I have only one GRBL device Sculpfun S30 Pro Max 20W.
I do not own another device. I have read that this engraver has a different board.
I am using a standard communication speed 115200.
I am absoluitely sure that communication speed is not an issue.
I can “repair” device with sending $i from serial terminal and then LightBurn works again without power cycling. Also LaserGRBL works on a same COM without power cycling.
I propose one option - to upgrade firmware (I will read somewhere how) and a problem might be gone.
If the issue wouldl gone, you can document on LightBurn www page that firmware upgrade is recommended and it is a known issue. I did not upgrade firmware yet to keep same setup.
I can fix your code. When LightBurn fall into endless loop sending “g0” command (the COM line traffic sniffed), I will try to emit $i after ~ 10 failures. This should fix a problem I hope. You can add this into LightBurn source very easily. You can add this into your code without S30 I hope.
I have experimental notebook with Windows 11 and I can give you remote access to it. I will physically detach LASER and you can observe issue yourselves. I will discuss this access on Email only.
I has been upgraded a firmware of S30 device (very unpleasant task), but unfortuantelly
some problem is still here. It is not a bug it is just a feature from manufacturer.
Too bad :(((((!
Lightburn cannot run after LaserGRBL.
I am using FW sculpfun-S30-12-26.bin after upgrade.
Firmware upgrade process is described here: Firmware Update & Settings - Diode Laser Wiki
$i
[VER:1.1h.20221226:]
[OPT:V,15,128]
Target buffer size found
ok
The string has been changed from 20220925 to 20221226.
Multiple G0 problem seems to be changed:
14:29:37.708 D: "Attempting to connect" busy: false state: 1
14:29:37.708 D: "Connecting..." busy: false state: 1
14:29:37.710 D: O: "G0\n"
14:29:37.963 D: "Connecting..." busy: false state: 1
14:29:37.965 D: O: "G0\n"
14:29:38.218 D: "Connecting..." busy: false state: 1
14:29:38.220 D: O: "G0\n"
14:29:38.473 D: "Connecting..." busy: false state: 1
14:29:38.475 D: O: "G0\n"
LightBurnLog_failure.txt (57.6 KB)
LightBurnLog_success.txt (7.3 KB)
-reset your GRBL by entering into the console: $RST=*
Cannot emit anything, lightburn falls to endless loop
-try changing the transfer mode to ‘Synchronous’:
Does not help
-try increasing the baudrate to 230,400 and set back to Buffered. (If its an ESP32 chipset then it should be able to handle this fine and may prefer this speed).
Do not know how
-research firmware versions for your Sculpfun, and try upgrading
done
-use debug mode (Help>Enable Debug Log) and connect to the Sculpfun, when the connection is unsuccessful, close LightBurn and look in your Documents folder for LightBurnLog.txt, attach that here:
done
I tested with the Sculpfun S10 board (MKS DLC32 clone mostly) and the S30 mainboard. Both ESP32 boards. The 8bit boards (S6/S9, MKS DLC) do not have that problem. I will try to do some more testing, I think I might find some time at the weekend.
Thank you very much for your interest. It seems that this problem is related to only S30 Pro Max.
You just created a video : 26.07.2022_10.28.19_REC.mp4 and it means that you have ever faced this issue before me. Use serial port terminal and you will not need to power cycle GRBL device. The unpleasant state can be undone from serial port.
I am a programmer, but it does not help me too much here. The most I can do is already done.
It’s not only S30 Pro Max. It’s all (Sculpfun) 32bit Boards. I encountered the same problem with the S10 mainboard as well.
This is all excellent discussion - thank you all for your contributions.
At this point it appears that LaserGRBL may be leaving Sculpfun’s boards in a state that allows some comms settings to persist after disconnection. We’re still discussing internally, and once we have pinpointed the issue we’ll reach out to our contacts at Sculpfun to let them know. If it’s possible to fix on LightBurn’s end, we will move it to our internal systems to address the issue.
May be that I have found possible source of problem:
If I run Serial port terminal AFTER LaserGRBL, this is printed:
ets Jul 29 2019 12:21:46
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6352
entry 0x400806b8
Grbl 1.1h ['$' for help]
Please note that a first word ets is not mistyped.
If I run Serial port terminal AFTER LightBurn, nothing is printed!
So it means that LaserGRBL garbaged serial device output/PC input and exits before flushing input buffer. This might corrupt LightBurn to start properly. The LightBurn programmers should flush input buffed by reading it.
Could any LightBurn developper confirm that serial line input buffer is fully read after LightBurn starts?
I have made another test. I run LaserGRBL/LightBurn/Serial port terminal.
And the cached string on input is a same. It means that LightBurn DOES NOT FLUSH its input. After input flushing in Serial port terrminal LightBurn seems to work.