Unexpected M5 (Spindle Off) After Resume in gSender 1.4.11

Hi everyone,

I’m experiencing an issue with gSender 1.4.11 when resuming a job after a pause or restart. My setup includes a GRBL controller and a spindle (M3 S1000).

Issue Description:

When I restart or resume my job (after a feed rate correction), the following happens:

  1. The spindle starts correctly with M3 S1000.
  2. The job resumes and moves to the correct position.
  3. Unexpectedly, an M5 command (spindle off) is executed, even though M5 is NOT in my G-code.
  4. The machine continues moving, but the spindle remains off unless I manually restart it with M3 S1000.

What I’ve Tried:

  • Verified my G-code: No M5 is present after the tool change.
  • Checked event handling in gSender: I added M3 S1000 to stop, start, pause, and restart. Still, M5 appears in the console.
  • Ran $$ to check GRBL settings: $32=0 (not in laser mode). $30/$31 are correctly set.
  • Tested with another sender (UGS): No unexpected M5, only happens in gSender.
  • Looked for macros or scripts that might trigger M5, but found nothing.

Question:

Where does this unexpected M5 come from, and how can I prevent gSender from sending it?

Has anyone else encountered this issue? Any insights would be greatly appreciated!

Thanks! :blush:

1 Like

Hey Arne,

Welcome to the forum. I did a topic search on yout problem and found one with the same problem you have.

@KGN did post in this tread stating that it was indeed something that gsender did and that it would be fixed in a newer version.

If there’s a newer version available, or if it slipped under the radar again, I don’t know.

1 Like

Dasarne,

I submitted this issue as an official bug and I received the response below from Kelly Zhu from Sienci Labs.

Thanks for your patience in the matter, one of our engineers Johann was able to replicate the issue and here is his response:
We have replicated the issue and it’s being actively investigated by the team as a potential bug.
To elaborate, gSender’s “Resume from line” feature only respects restarting the spindle when spindle commands (M3/M4 SXXXXX) are included inside the gCode file and will stop the spindle with an M5 when no spindle command is detected in the .nc file. This logic runs after any programmed events gCode which is why the spindle starts up and stops almost immediately.
At this time, there is no workaround for this issue and the only resolution is to include spindle command in your gcode, this can be easily accomplished manually by opening the file in notepad and adding in an M3S18000, or by asking your CAM program to include such a command when exporting the code. We understand that this may not be the workflow that you are looking for. Our software team will work to rectify the issue.
Thank you for bringing this to our attention.

I changed the formatting for this thread but this was as of January 2nd, 2025. Since the latest version of gSender is from December I am hopeful this will be resolved in the next release of gSender.

2 Likes

Hello everyone,
this is an extremely quick answer, which has helped me a lot.
Thank you to everyone involved. :+1:
I am very curious to see if the next version addresses the problem.

Yours
Arne