Lightburn sometimes does not work, could anybody else reproduce this issue?

LightBurn Software Questions
1

Sometimes I have problems with serial line communication.

Please could anybody try to run LaserGRBL attach and detach GRBL through serial line and then run LightBurn?

LightBurn is not abble to operate properly from unknown reason.

I have found a way out from this condition:
*I has been used free serial-port-terminal from eltima *
When I detach serial port in lightburn and attach in “serial port terminal” GRBL works
(I have tested $1, $$ and $H commands.)
When I detach serial port terminal and attach LightButn it starts to work without cable
reconnecting, no power cycling GRBL needed no app restart needed.
If a software solution exists, there is no hardware problem.

It seems to me that LightBurn internally loops and perpentually sending “G0\n” and flooding a device. LaserGRBL can attach without any problem even when LightBurn cannot. I has been confirmed this issue on 2 different computers - Windows 11/64 and Windows7/32.

Without patching Lightburn it is not possible to fix this issue.

Please do not blame me about bad cables.
May be that there is something unclean in firmware, I do not know.

LaserGRBL_detach.txt (36.9 KB)
LaserGRBL_init.txt (250.1 KB)

2

I can post only 2 links, so the serialport terminal is here: Serial Port Terminal - test and debug serial port devices

3

And logs from Laser GRBL are here:
LightBurnInitFailure.txt (10.8 KB)
LightBurnInitOK.txt (5.8 KB)

sorry for 3 posts - I was rejected to post it in one post. It is too bad that even 3 attachments are rejected :(! Please setup this forum better that attachments are not counted to link count.

4

This is an automation to prevent very new forum users from posting numerous links. We have found this to be the better way to set up the forum. You are obviously a concerned member of the community (and not a spam generating automation) so I have manually adjusted your trust level which removes the temporary restriction. The temporary restriction fades automatically in a few days after some reading. This offers us some time for housekeeping when needed.

Welcome.

  • I’d like to know more about your Sculpfun.

We have a setup video for the S30 and I have not observed any adverse effects from a repeated G0. I will address this concern last.

USB ports are Dynamic devices and are reassigned ad hoc. Opening the USB Port in laserGRBL prevents opening the port in LightBurn. Force-Closing the port and reopening it with your terminal tool may have an effect nearly identical to disconnecting and reconnecting the cable.

I’m not fully certain that I’m seeing what you’re seeing.
I am interested in seeing this from your point of view.

I see the $I, $H commands being passed on Serial 2 in your LightBurnInitOK file but I see no commands passed in LightBurnInitFailure.

  • Are you entering these report-requests in the Console window in LightBurn or in the Terminal tool Elitma?

  • Does laserGRBL apply a demonstrably different method to connecting to your Sculpfun engraver?

  • Please also confirm that the USB port for the Sculpfun is unassigned to any software when launching LightBurn.

It’s remotely possible that a GCode issue is at hand.

  • Please draw a simple shape or 2-3 lines in LightBurn
  • Then click File, and Save GCode.
  • Then change the file extension to .txt to upload it here.

This may allow me to verify the device type and confirm the intent of the repeated G0 commands.

1 Like
5

Please note, I know a solution how to exit this stuck when it occurs. Then LightBurn works.

>Are you entering these report-requests in the Console window in LightBurn or in the Terminal tool Elitma?
YES, these requests make Lightburn to go alive again after failure

All grabs/sniffed communication are pure communication of software itself.

Does laserGRBL apply a demonstrably different method to connecting to your Sculpfun engraver?
YES, its method is grabbed in a text file already posted by me here.
It always initialises a device properly - I have never observed this kind of failure in LaserGRBL.

Please also confirm that the USB port for the Sculpfun is unassigned to any software when launching LightBurn.
I am not so stupid. I has been developped industry projects that has a same serial port handling. I know this very well.
In such a situation there will be absolutelly different failure.

It’s remotely possible that a GCode issue is at hand.
A, When LightBurn fails to init it is impossible to do this. The console is not operative.
B, When LightBurn initialises properly everytling works as expected and this time is nothing to bugreport.

I can reprodude a problem that LightBurn does not initialise.
In a situation A it is impossible to do so - I cannot issue anything
In a situation B it is useles, because GRBL works as expected

Which situation do you want to see A or B?

If I want you to fix bug that occurs sometimes then I must demonstrate program behavior at failing state.

The G0 sniffed is not a G-code to be engraved, it has something to do with hidden device startup init sequence.

It is possible that S30 firmware sometimes falls into a state where it does not respond to “G0\n” command in a way, that your code expects in endless loop.

Force-Closing the port and reopening it with your terminal tool may have an effect nearly identical to disconnecting and reconnecting the cable. Reconnection cable is much more destructive. It unloads a kernel driver. Force closing only notifies driver about clossing connection. It might lead to “funny” situations, that one application has opened COM on retired driver and a new workable driver is ready. All my tests did not include cable detaching.

6

I’m confused.
The question is LightBurn or Elitma.
Your answer was Yes.

$i and $$ ( report requests mentioned above ) wouldn’t normally change the state of a USB port. I am also interested in the contents of these reports. Manufacturers occasionally update firmware and remove edge cases. I would prefer to confirm the firmware revision number to be certain this hasn’t already been addressed.

Please Copy and Paste those reports into a reply here at your convenience.

My answer to your question is C. It is at a tangent to your inquiry. I am attempting to verify a particular LightBurn setting and version number.

I’m quite pleased how quickly we’re moving this toward a resolution.

I do not see how this three step test is impossible.

LightBurn offers several different GCode Profiles, including some customized ones. This simple test offers the Gcode Profile information and the LightBurn Version number. It may also offer the cause of the repeated G0.

Once I have enough information to escalate this, I certainly will.

It could certainly reduce support workload.

8

I needed to inject a command with Eltima. Lightburn did not work.

LightBurn offers several different GCode Profiles, including some customized ones.
Without knowing this it seemed to me to meke it no sense.

GCODE cannot be uploaded to this forum from unknown reason:
Sorry, the file you are trying to upload is not authorized (authorized extensions: jpg, jpeg, png, gif, lbrn, txt, lbset, lbrn2, csv, svg, dxf, markcfg7, markcfg0, lbcm, lbdev, clb, lbart).

xx.txt (2.7 KB)

$i
[VER:1.1h.20220925:]
[OPT:V,15,128]
Target buffer size found
ok

$$
$0=10
$1=25
$2=0
$3=4
$4=0
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=7
$24=200.000
$25=3000.000
$26=250.000
$27=2.000
$30=1000.000
$31=0.000
$32=1
$100=80.000
$101=80.000
$102=250.000
$103=100.000
$104=100.000
$105=100.000
$110=6000.000
$111=6000.000
$112=1000.000
$113=1000.000
$114=1000.000
$115=1000.000
$120=1000.000
$121=1000.000
$122=1000.000
$123=200.000
$124=200.000
$125=200.000
$130=400.000
$131=410.000
$132=200.000
$133=300.000
$134=300.000
$135=300.000
ok
9

May be that I have found a source of a problem - within serial port terminal.

First G0 command after device is powered up returns ok.
Next G0 command produces error 2.

After passing innocent command $i the device seems to answer ok after one G0 again.

I am novice to grbl language. This seems to me to be strange. Could a device accept G0 twice? If this is a problem, a Lightburn should not silly flood a device with G0 and expect anything to work. May be that FreeGRBL causes similar effect another way. It is clear that device sometimes falls into a state in which it resuses to respond to G0 command.

10

@JohnJohn I can say that I experienced the same behavior and could reproduce it on multiple PCs. So far I suspected the firmware being the reason, but it happened on different versions as well. (But all were Sculpfun firmwares)
Here is what I experienced:

  • Laser powered up fresh (power + USB disconnect before)
  • You can connect with either LightBurn or LaserGRBL
  • If you connected once using LaserGRBL, LightBurn can’t connect to the laser anymore
  • LaserGRBL can be closed and opened as much as you like, it always connects successfully
  • LightBurn does not work anymore until the laser is power cycled again.
2 Likes
11

Does enabling DTR signal affect the behavior at all?

12

It seems to have nothing to do with DTR. I have found a remedy of this as wrritten above. Send some command like $i through serial line from serial terminal.

13

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.

1 Like
14

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

15

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 :slight_smile: 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 :slight_smile: )

16

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.

17

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.

18

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 :slight_smile:

1 Like
19

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.

20

Thank you for this reminder. I’ll confirm that this is in motion. Ctrl+x was requested on another thread as well.

21

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).