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.
1 Like
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:
To:
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.
1 Like
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.
2 Likes
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.
1 Like
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.
LightBurn does fully flush the serial port on connect. I would guess that the message you’re seeing is caused by the Serial Terminal application connecting to the board and sending it something it doesn’t understand that is causing it to crash and reset. You see the crash dump sent over the serial connection, not data that was left after LaserGRBL closed.
We’re trying to figure out what’s happening and how we can fix the device after LaserGRBL breaks it.
Thank you very much that you decide to solve this issue.
I am very sure that LightBurn does not flush serial port or your flushing is deffective and only pretends to flush.
When I use “serial port terminal” application, it has really flushed serial port and after it finished / exit LightBurn worked fine. Without serial port cleanup the lightburn stopped to work.
You must pull from scuplfun a same text that I do first.
After connecting to the port, LightBurn runs this command:
bytes = pPort->readAll();
That command reads all available data from the serial port, so I am very sure that what you say is incorrect.
1 Like
I cannot debug your code. May be that object fails to do its job from whatever reason.
Please note that sometimes even library call do not do exactly what is expected. May be that serial line is somehow blocked.
Generic purpose serial terminal can cleanup serial line and your code not. This problem has been confirmed also from other users so it is not deffect on my compurer. I has been tested both x86 and x64 architectures with a same result. Could you at least reproduce this issue?
If everything fails I can arrange for you environment and you could try to connect to my empty testPC and observe problem through netmeeting or something like this (With LASER disconnected of course).
I never said it was a defect on your computer, just that I suspect there’s something about LaserGRBL that is leaving the Sculpfun board in a strange state.
I do not have one of these machines here, so I’ll have to order one if I can’t solve it from logs. I need a board that I can connect to locally so I can look at what’s happening and try different things quickly.
1 Like
Yes, but absolutelly generic application “Serial port monitor” that knows void about Scuplfun can repair serial port line into a state, that LightBurn starts to work without power cycling.
I’m not sure what it is that you’re arguing here. You’ve provided ample evidence of this already, and I believe you, I just don’t know and can’t see which state settings are currently being missed that this one device appears to care about.
I suspect the serial port tool is enabling the DTR flag, which might reset the controller, but without having one on hand to check, I can’t tell.
What happens if you enable this in LightBurn?
Yes, you have got it. Why this option is not turned on by default when it causes too much mess?
Because there is unfortunately no “correct” way to set that. Arduino based boards and some others are automatically reset when that is enabled, and others require the setting to communicate.
That setting is a hold-over from old modem days - it tells the connected device that the computer wants to talk. Unfortunately, Arduino and other programmable boards decided to use that setting to trigger a reset, to make it easier to put the boards into programming mode. If we enable it by default, lots of devices will stop working.