`Connection lost` errors in the log

MrWorf · March 1, 2021, 11:16pm

When executing some commands on my snapmaker, for example M1010 S3 P255 to turn on the lights as a part of the “Start GCode” section, I always tend to end up with a “Connection lost” error in the console.

This is what I’m seeing:

Starting stream
Layer C00
Eclosure: set LIGHTBAR brightness 255
Eclosure: set FAN speed 255
Connection lost
Stream completed in 0:00

But looking at the code for snapmaker, I don’t see any reason for it to “drop” the connection. So I’m curious if it’s the fact that the machine sends the Eclosure lines which is causing lightburn to say “connection lost”

Bonjour · March 2, 2021, 9:37am

Snapmaker uses its own code base built on top of Marlin.

I’m not sure LB supports it, does it? Did you choose Marlin as your controller type, or is there a snapmaker option?

Grumpy_Old_Man · March 2, 2021, 12:25pm

LightBurn has a SnapMaker profile.

MrWorf · March 2, 2021, 2:51pm

I’m actually using Marlin since I’m using a custom firmware which supports inline laser support. But the question isn’t really about snapmaker I’m just curious about what would make LightBurn say “connection lost” since executing the same commands from console doesn’t generate a connection lost message.

I also used to get connection lost when M7/M8 was used, and again, in those scenarios, snapmaker replied with a text stating “unknown command” which, by it self, didn’t have issues, but when running a program seems to cause a connection lost.

Since it’s open source, I can fix the issue if it’s cause by the text output sent by the custom commands but I’d rather not change that if it’s unrelated to the lighburn behavior.

MrWorf · March 2, 2021, 4:05pm

I found the “Enable Debug Log” option, so I reran my tests, and this is what I found

08:03:41.765  D: "LightBurn 0.9.20"   "Tue Mar 2 2021"
08:03:43.165  D: EnableZ: true Relative: false
08:03:43.167  D: 1  floaters
08:03:43.167  D: PathTree build: 0
08:03:43.201  D: Crossing time: 17 Output time: 15
08:03:43.201  D: Optimize by score: 0 ms
08:03:43.201  D: CutBuilder took: 36 ms
08:03:43.280  D: Protocol::GenerateCuts time: 76
08:03:43.286  D: Got stream - sending asynchronous
08:03:43.286  D: S: 14 TB: 14 LC: 1 OK: 0 RC: 0
08:03:43.286  D: S: 14 TB: 28 LC: 2 OK: 0 RC: 0
08:03:43.286  D: S: 4 TB: 32 LC: 3 OK: 0 RC: 0
08:03:43.286  D: S: 4 TB: 36 LC: 4 OK: 0 RC: 0
08:03:43.286  D: S: 3 TB: 39 LC: 5 OK: 0 RC: 0
08:03:43.286  D: S: 4 TB: 43 LC: 6 OK: 0 RC: 0
08:03:43.286  D: S: 23 TB: 66 LC: 7 OK: 0 RC: 0
08:03:43.286  D: S: 9 TB: 75 LC: 8 OK: 0 RC: 0
08:03:43.286  D: S: 4 TB: 79 LC: 9 OK: 0 RC: 0
08:03:43.286  D: S: 19 TB: 98 LC: 10 OK: 0 RC: 0
08:03:43.286  D: S: 14 TB: 112 LC: 11 OK: 0 RC: 0
08:03:43.286  D: S: 14 TB: 126 LC: 12 OK: 0 RC: 0
08:03:43.297  D: O: "M1010 S3 P255\nM1010 S4 P255\nG21\nG90\nM9\nM05\nG0X113.63 Y87.45 F3000\nG0 Z23.4\nG91\nG1X0.42 F1000 I S0\nG1X0.1 I S0.8\nG1X0.1 I S4.5\n"
08:03:43.306  D:   I: "Eclosure: set LIGHTBAR brightness 255\nok\nEclosure: set FAN speed"
08:03:43.307  D: R: 14 TB: 112 OK: 1 RC: 2
08:03:43.307  D: S: 12 TB: 124 LC: 13 OK: 1 RC: 2
08:03:43.316  D: O: "G1X0.1 I S6\n"
08:03:43.317  D:   I: " 255\nok\nok\nok\nok\nok\nok\nok\nok\nok\nok\nok\n"
08:03:43.318  D: R: 14 TB: 110 OK: 2 RC: 4
08:03:43.318  D: R: 4 TB: 106 OK: 3 RC: 5
08:03:43.318  D: R: 4 TB: 102 OK: 4 RC: 6
08:03:43.318  D: R: 3 TB: 99 OK: 5 RC: 7
08:03:43.318  D: R: 4 TB: 95 OK: 6 RC: 8
08:03:43.318  D: R: 23 TB: 72 OK: 7 RC: 9
08:03:43.318  D: R: 9 TB: 63 OK: 8 RC: 10
08:03:43.318  D: R: 4 TB: 59 OK: 9 RC: 11
08:03:43.318  D: R: 19 TB: 40 OK: 10 RC: 12
08:03:43.318  D: R: 14 TB: 26 OK: 11 RC: 13
08:03:43.318  D: R: 14 TB: 12 OK: 12 RC: 14
08:03:43.318  D: 2374390 bytes in 0.032 seconds, 7.41997e+07 avg bytes per second
08:03:43.318  D: 13 lines @ 406.25 avg lines per second
08:03:43.320  D:   I: "ok\n"
08:03:43.321  D: R: 12 TB: 0 OK: 13 RC: 15

This looks more and more like LightBurn dislikes seeing anything but ok as a response. Is there any prefix I can add to outputs that are informational which LightBurn will ignore?

MrWorf · March 3, 2021, 6:59am

I thought I had found it with prefixing irrelevant messages with echo: but it simply delayed the connection lost message.

Would love to know what criteria that will trigger this message and behavior in LB.

MrWorf · March 3, 2021, 7:08am

Attaching logfile from LB. Has two sessions back-2-back, both simply stating Connection Lost in the console window. The log doesn’t provide much more details. I certainly cannot see anything out of the ordinary.

Edit: Hmm, odd, my logfile isn’t showing on this post.

This is the last part before it shows connection lost:

23:03:53.741  D:   I: "ok\n"
23:03:53.741  D: R: 16 TB: 97 OK: 1967 RC: 1969
23:03:53.741  D: S: 17 TB: 114 LC: 1974 OK: 1967 RC: 1969
23:03:53.751  D: O: "G1X-0.1 I S123.5\n"
23:03:53.752  D:   I: "ok\nok\nok\nok\nok\nok\n"
23:03:53.752  D:   I: "ok\n"
23:03:53.753  D: R: 16 TB: 98 OK: 1968 RC: 1970
23:03:53.753  D: R: 17 TB: 81 OK: 1969 RC: 1971
23:03:53.753  D: R: 17 TB: 64 OK: 1970 RC: 1972
23:03:53.753  D: R: 15 TB: 49 OK: 1971 RC: 1973
23:03:53.753  D: R: 15 TB: 34 OK: 1972 RC: 1974
23:03:53.753  D: R: 17 TB: 17 OK: 1973 RC: 1975
23:03:53.753  D: R: 17 TB: 0 OK: 1974 RC: 1976
23:03:53.753  D: 2374390 bytes in 18.197 seconds, 130482 avg bytes per second
23:03:53.753  D: 1974 lines @ 108.479 avg lines per second

MrWorf · March 3, 2021, 4:05pm

I’ve now installed serial port monitor to see what’s going on. And there’s nothing here showing any kind of errors with serial coms

71 03/03/2021 07:57:03 IRP_MJ_WRITE DOWN  4d 31 30 31 30 20 53 33 20 50 32 35 35 0a 4d 31 30 31 30 20 53 34 20 50 32 35 35 0a 47 32 31 0a 47 39 30 0a 4d 39 0a 4d 30 35 0a 47 30 58 31 31 33 2e 36 33 20 59 38 37 2e 34 35 20 46 33 30 30  M1010 S3 P255.M1010 S4 P255.G21.G90.M9.M05.G0X113.63 Y87.45 F300 126 126 COM7  
72 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
73 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
74 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS 65 63 68 6f 3a 20 45 63 6c 6f 73 75 72 65 3a 20 73 65 74 20 4c 49 47 48 54 42 41 52 20 62 72 69  echo: Eclosure: set LIGHTBAR bri 32  COM7  
75 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
76 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 00 00 00 00 00 00  ............~....... 20  COM7  
77 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
78 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
79 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
80 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
81 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
82 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 7e 00 00 00 00 00 00 00  ............~....... 20  COM7  
83 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
84 03/03/2021 07:57:03 IRP_MJ_WRITE UP STATUS_SUCCESS 4d 31 30 31 30 20 53 33 20 50 32 35 35 0a 4d 31 30 31 30 20 53 34 20 50 32 35 35 0a 47 32 31 0a 47 39 30 0a 4d 39 0a 4d 30 35 0a 47 30 58 31 31 33 2e 36 33 20 59 38 37 2e 34 35 20 46 33 30 30  M1010 S3 P255.M1010 S4 P255.G21.G90.M9.M05.G0X113.63 Y87.45 F300 126  COM7  
85 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
86 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
87 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
88 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .................... 20  COM7  
89 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
90 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
91 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS 67 68 74 6e 65 73 73 20 32 35 35 0a 6f 6b 0a 65 63 68 6f 3a 20 45 63 6c 6f 73 75 72 65 3a 20 73  ghtness 255.ok.echo: Eclosure: s 32  COM7  
92 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
93 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .................... 20  COM7  
94 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
95 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
96 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
97 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
98 03/03/2021 07:57:03 IRP_MJ_WRITE DOWN  47 31 58 30 2e 31 20 49 20 53 36 0a  G1X0.1 I S6. 12 12 COM7  
99 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
100 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  .................... 20  COM7  
101 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
102 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
103 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
104 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS 65 74 20 46 41 4e 20 73 70 65 65 64 20 32 35 35 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a  et FAN speed 255.ok.ok.ok.ok.ok. 32  COM7  
105 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
106 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  .................... 20  COM7  
107 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
108 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
109 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
110 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
111 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
112 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  .................... 20  COM7  
113 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
114 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
115 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
116 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS 6f 6b 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a 6f 6b 0a  ok.ok.ok.ok.ok.ok. 18  COM7  
117 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
118 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  .................... 20  COM7  
119 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
120 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
121 03/03/2021 07:57:03 IRP_MJ_READ DOWN     32768 COM7  
122 03/03/2021 07:57:03 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
123 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
124 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00  .................... 20  COM7  
125 03/03/2021 07:57:03 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
126 03/03/2021 07:57:04 IRP_MJ_WRITE UP STATUS_SUCCESS 47 31 58 30 2e 31 20 49 20 53 36 0a  G1X0.1 I S6. 12  COM7  
127 03/03/2021 07:57:04 IRP_MJ_READ DOWN     32768 COM7  
128 03/03/2021 07:57:04 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
129 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
130 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .................... 20  COM7  
131 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
132 03/03/2021 07:57:04 IRP_MJ_READ DOWN     32768 COM7  
133 03/03/2021 07:57:04 IRP_MJ_READ UP STATUS_SUCCESS 6f 6b 0a  ok. 3  COM7  
134 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
135 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .................... 20  COM7  
136 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN      COM7  
137 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) UP STATUS_SUCCESS 01 00 00 00  .... 4  COM7  
138 03/03/2021 07:57:04 IRP_MJ_READ DOWN     32768 COM7  
139 03/03/2021 07:57:04 IRP_MJ_READ UP STATUS_SUCCESS     COM7  
140 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) DOWN      COM7  
141 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_GET_COMMSTATUS) UP STATUS_SUCCESS 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .................... 20  COM7  
142 03/03/2021 07:57:04 IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK) DOWN STATUS_PENDING     COM7

So I reiterate, what are the criteria for lightburn to say “Connection Lost” when no physical issue exists?

More intreresting is that overnight the issue has become more severe, now I can’t get it to burn at all, and the debug log says:

08:01:27.361  D: "LightBurn 0.9.20"   "Wed Mar 3 2021"
08:01:29.221  D: EnableZ: true Relative: false
08:01:29.222  D: 1  floaters
08:01:29.222  D: PathTree build: 0
08:01:29.254  D: Crossing time: 19 Output time: 10
08:01:29.254  D: Optimize by score: 0 ms
08:01:29.254  D: CutBuilder took: 33 ms
08:01:29.311  D: Protocol::GenerateCuts time: 55
08:01:29.316  D: Got stream - sending asynchronous
08:01:29.316  D: S: 14 TB: 14 LC: 1 OK: 0 RC: 0
08:01:29.316  D: S: 14 TB: 28 LC: 2 OK: 0 RC: 0
08:01:29.316  D: S: 4 TB: 32 LC: 3 OK: 0 RC: 0
08:01:29.316  D: S: 4 TB: 36 LC: 4 OK: 0 RC: 0
08:01:29.316  D: S: 3 TB: 39 LC: 5 OK: 0 RC: 0
08:01:29.316  D: S: 4 TB: 43 LC: 6 OK: 0 RC: 0
08:01:29.316  D: S: 23 TB: 66 LC: 7 OK: 0 RC: 0
08:01:29.316  D: S: 9 TB: 75 LC: 8 OK: 0 RC: 0
08:01:29.316  D: S: 4 TB: 79 LC: 9 OK: 0 RC: 0
08:01:29.316  D: S: 19 TB: 98 LC: 10 OK: 0 RC: 0
08:01:29.316  D: S: 14 TB: 112 LC: 11 OK: 0 RC: 0
08:01:29.316  D: S: 14 TB: 126 LC: 12 OK: 0 RC: 0
08:01:29.328  D: O: "M1010 S3 P255\nM1010 S4 P255\nG21\nG90\nM9\nM05\nG0X113.63 Y87.45 F3000\nG0 Z23.4\nG91\nG1X0.42 F1000 I S0\nG1X0.1 I S0.8\nG1X0.1 I S4.5\n"
08:01:29.329  D:   I: "echo: Eclosure: set LIGHTBAR bri"
08:01:29.345  D:   I: "ghtness 255\nok\necho: Eclosure: set FAN speed 255\nok\nok\nok\nok\nok\nok\nok\nok\nok\nok\nok\n"
08:01:29.346  D: R: 14 TB: 112 OK: 1 RC: 2
08:01:29.346  D: R: 14 TB: 98 OK: 2 RC: 4
08:01:29.346  D: R: 4 TB: 94 OK: 3 RC: 5
08:01:29.346  D: R: 4 TB: 90 OK: 4 RC: 6
08:01:29.346  D: R: 3 TB: 87 OK: 5 RC: 7
08:01:29.346  D: R: 4 TB: 83 OK: 6 RC: 8
08:01:29.346  D: R: 23 TB: 60 OK: 7 RC: 9
08:01:29.346  D: R: 9 TB: 51 OK: 8 RC: 10
08:01:29.346  D: R: 4 TB: 47 OK: 9 RC: 11
08:01:29.346  D: R: 19 TB: 28 OK: 10 RC: 12
08:01:29.346  D: R: 14 TB: 14 OK: 11 RC: 13
08:01:29.346  D: R: 14 TB: 0 OK: 12 RC: 14
08:01:29.346  D: 2374390 bytes in 0.03 seconds, 7.91463e+07 avg bytes per second
08:01:29.346  D: 12 lines @ 400 avg lines per second

And I counted the commands VS responses and there are 12 commands sent and 12 ok received. But looking at the counters shown, it would seem that since there’s the echo: outputs, the RC gets out of sync with the OK and maybe this is the cause for the failures?

@LightBurn any insight in what I’m seeing here?

LightBurn · March 3, 2021, 7:53pm

The reason it’s doing this is that LightBurn isn’t expecting to get additional messages from the controller, so it’s seeing two “responses” for a single command, and assumes something is out of sync. I’ve added 'EClosure:" and ‘echo:’ as recognized prefixes so they won’t bump the receiver count, and that’ll be in the next release.

MrWorf · March 3, 2021, 8:05pm

thank you. I’ll also alter the firmware to prefix it all with echo: since that seems to be a marlin thing for unsolicited messages. Should solve future messages that I didn’t catch on my end.

MrWorf · March 3, 2021, 9:35pm

One thought, does LightBurn have any logic for handling errors from the gcode? What I mean is that it would gracefully stop and perhaps issue M5 to turn off the laser? If so, error: should be something that triggers that.

LightBurn · March 3, 2021, 9:45pm

It doesn’t at this time, no.

system · April 2, 2021, 9:46pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.