Laser keeps stopping halfway through engraving. The letter k in grbl code

[stormbruce]

Hello to all, i am having many problems getting a normal image file to engrave. Part way through the engraving the machine just stops engraving with the letter k showing in the grbl console. I have attached an image of when it stops, and when i try to disconnect it comes up with a box saying file transfer in progress. I have already tried many things to try to fix the problem but being new to lasergrbl i dont know where to turn next. I am using a Maker Shield and grbl 1.1h. Windows ten fully updated and have 8gb ram.

[gmmanonymus111]

Judging by the screenshot you provided, I suspect a communication issue between your PC and engraver. As you can see, the buffer is full (according to LaserGRBL), so new command can't be sent. Buffer is freed when GRBL sends an ok message (in your case, the received message was just a k). Until a full ok is received, the last command remains in LaserGRBL's buffer.
Try ro set $10 Status report mask to 2, this enables GRBL to send back the actual buffer status, so LaserGRBL can correct itself.
Note: this is only a workaround, please make sure the connection between your PC and engraver is solid (with a new/better quality/shorter cable, other USB port, less electronic equipments around the cable/machine etc.)

[stormbruce]

Hello Alex and thanks for your advice. I did as you said and the machines still stopped engraving but it would then start again where it left off with no input from me, i guess it emptied the buffer? I am using a non genuine Arduino Uno and the Maker Shield. Do you think a genuine Arduino Uno would help? I already have a very short usb cable . But perhaps i should purchase a shielded cable. What are your thoughts on this if you dont mind me asking. I have also tried on Laserburn and the same problem. thanks. Bruce

[gmmanonymus111]

Well, I also have a non genuine Uno, when I used that, I had an 'older' Sony data cable (bundled with my Xperia Z2), which never gave me issues (PC USB port was 3.0 I think, but might be irrelevant; Higher quailty cable helps a lot). Now I'm using telnet, because wireless is much easier for me. When I first set up my Uno+WiFi with a telnet bridge, I came accross that data loss (thus the workaround), but managed to fix it by replacing the telnet firmware later.
You could also take a look here, it's a different issue, but explains further on data loss/quality at the end of the discussion, better than me xD)

[codechangerr]

I have the same problem what would happen if I set $10 to 3

[stormbruce]

Hello codechangerr i ended up getting a genuine Arduino board and a new USB cable and it uses a different driver. I was originally using a Chinese board and the ch340 driver. It was a buffer issue and the Chinese board just couldn't handle it. That was quite awhile ago and it has not done it since the new board and driver.

[stormbruce]

Thanks very much Alex and i checked out the link you gave me. Very interesting reading, i was also thinking that it could be a driver issue as my non genuine Arduino Uno uses the Ch340 driver. I checked in device manager on windows and it seems to set the port to 9600 baud by default with this driver. I reset in properties just to make sure it wasnt a driver issue. I then changed $10 to 2 as you suggested and it still stops but at least it now restarts . So i am experimenting with different settings in Lasergrbl to get the least amount of stops! I have ordered a high speed usb shielded cable and i will let you know if that helps the problem. Obviously the buffer is getting full and thanks to your help at least it can now be cleared and carry on engraving. I will also test in Lightburn. Thanks again. Bruce P.S i also moved all excess electronics from near laser.

[stormbruce]

Hi Alex, sorry has been awhile as i have been awaiting another board. I ordered an italian Arduino UNO R3 with ATMEL ATMega 328P & Mega 16U2 and it appears to have solved the buffering issue. But after changing the board i can no longer get the Z table to work in the homing cycle and i am not sure if it is a board problem or the grbl coded. The new Arduino board also does not use the ch340 driver. Any ideas why the Z axis has been left out of the homing cycle (homing worked on all three axis with old Arduino) I can still move the z table up and down manually it just doesnt want to go in the homing cycle Thanks Bruce Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

…

On Saturday, August 7th, 2021 at 10:06 PM, Alex ***@***.***> wrote: Well, I also have a non genuine Uno, when I used that, I had an 'older' Sony data cable (bundled with my Xperia Z2), which never gave me issues (PC USB port was 3.0 I think, but might be irrelevant; Higher quailty cable helps a lot). Now I'm using telnet, because wireless is much easier for me. When I first set up my Uno+WiFi with a telnet bridge, I came accross that data loss (thus the workaround), but managed to fix it by replacing the telnet firmware later. You could also take a look [here](#378), it's a different issue, but explains further on data loss/quality at the end of the discussion, better than me xD) — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#1549 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVDXWSRB3XJ557DLY2VD4J3T3UOUXANCNFSM5BXAWUAA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email).

[gmmanonymus111]

Well, I suspect a GRBL firmware issue there. The flashed firmware might contain only X/Y axis homing. If you've compiled & uploaded it yourself, you can take a look at config.h at around line 105 (for Z homing, you should have this):

#define HOMING_CYCLE_0 (1<<Z_AXIS)                // REQUIRED: First move Z to clear workspace.
#define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.

instead, you might have something like this:

#define HOMING_CYCLE_0 ((1<<X_AXIS)|(1<<Y_AXIS)) 

In case you just uploaded a pre-compiled .hex file, you can flash another one using LaserGRBL. To do so, click Tools -> Flash Grbl Firmware -> Chose Uno -> Chose 1.1h original -> Select COM port -> Select Baud rate (usually the default is ok) -> Click OK

[stormbruce]

Hi Alex thanks for your reply i know you must be a busy man. I have been using Laser grbl and doing some engraving. More experimenting than anything. I will check all the code as you suggested. But i was surprised in the difference between the two Arduinos. Not really surprising i suppose as one was a cheap Chinese clone using a different chipset and driver. The new board does not stop engraving or filling the buffer. And the thing is the new board was only $5 extra. I am using shielded Usb cable and the only problem is the z axis. But i can still move it manually My initial idea with the z table was to have it controlled by grbl to move so the laser is always focused when cutting. So if it cuts for instance 3mm then the z table will move to account for the laser being not as focused. This way i could cut knowing it was constantly adjusting and keeping it focused, thus getting less burning and deeper cuts. not sure how i can get grbl to do that yet but first i have to get the z table to be a part of the homing cycle. I really appreciate your help Thanks so much Bruce Sent with [ProtonMail](https://protonmail.com/) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

…

On Friday, August 27th, 2021 at 7:02 AM, Alex ***@***.***> wrote: Well, I suspect a GRBL firmware issue there. The flashed firmware might contain only X/Y axis homing. If you've compiled & uploaded it yourself, you can take a look at config.h at around line 105 (for Z homing, you should have this): # define HOMING_CYCLE_0 ( 1 <<Z_AXIS) // REQUIRED: First move Z to clear workspace. # define HOMING_CYCLE_1 (( 1 <<X_AXIS)|( 1 <<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time. instead, you might have something like this: # define HOMING_CYCLE_0 (( 1 <<X_AXIS)|( 1 <<Y_AXIS)) In case you just uploaded a pre-compiled .hex file, you can flash another one using LaserGRBL. To do so, click Tools -> Flash Grbl Firmware -> Chose Uno -> Chose 1.1h original -> Select COM port -> Select Baud rate (usually the default is ok) -> Click OK — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#1549 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVDXWSTFCG2BS33W5PQRFY3T62TURANCNFSM5BXAWUAA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).