Possible gSender issue after stopping, rehoming and re-starting job on GRBL 1.1h

gSender 🐛 Bug
1

Hi,

I am trying to diagnose a strange and potentially unsafe issue I experienced with gSender. Because I am a new user I cannot attach my diagnostics exports, firmware settings, gSender settings, and the G-code file used. Please let me know if there is an email address I can sent it to

Machine / setup

  • Machine: FoxAlien XE-Ultra CNC
  • Controller firmware shown in diagnostics: GRBL 1.1h
  • Sender: gSender v1.6.1
  • OS: Linux x86_64 / X11
  • Connection: /dev/ttyUSB0, 115200 baud
  • Homing enabled
  • Hard limits enabled
  • Test was run with the spindle switched off

What happened

I homed the machine in gSender and started the job. The job initially appeared to run correctly.

I then stopped the job, rehomed the machine, returned to my work zero position at X0/Y0, and restarted the same job.

On the restarted run, the first plunge looked correct. However, when the pocketing operation began, the machine started moving in the wrong direction / not following the expected pocket path.

Why I suspect a restart/resume/modal-state issue

The later diagnostics export shows that gSender was connected to GRBL 1.1h and the machine was reported as homed at the time of the diagnostics.

However, the diagnostics also show fresh errors around the time of the failed restarted run:

G-code words consist of a letter and a value. Letter was not found.

Example input shown in diagnostics:

X160.784 Y121.162 Z1.267

That line exists in the uploaded G-code file as part of a modal cutting/ramping sequence. The G-code relies on normal modal motion behaviour: after a G1 command, following lines may contain only coordinates, for example:

X160.784 Y121.162 Z1.267

That should be valid if the controller is still in the correct modal motion state, for example G1, with the required modes already active.

My concern is that after stopping and restarting the job, gSender may be sending coordinate-only lines from the middle of a modal G-code sequence without first re-establishing the required modal state, such as G1, G90, G21, G17, etc.

I am not sure whether gSender is:

  1. starting the file from the true beginning,
  2. resuming from a previous line,
  3. restoring modal state incorrectly,
  4. or sending coordinate-only motion lines without first restoring the previous motion command.

Steps that seemed to lead to the issue

  1. Home machine in gSender.
  2. Start job from uploaded Side - 6mm.nc.
  3. Run with spindle off for testing.
  4. Stop the job after it appears to run correctly.
  5. Rehome the machine.
  6. Return to X0/Y0.
  7. Restart the same job.
  8. Initial plunge appears correct.
  9. Pocketing then moves in the wrong direction / unexpected path.
  10. Diagnostics show errors for coordinate-only G-code lines such as X160.784 Y121.162 Z1.267.

Attachments (Unfortunately new users cannot upload new attachments, please let me know where i can send them to)

  • gSenderSettings_6-8-2026_09-51-20.json
  • gSender-firmware-settings-6-8-2026-09-51-20.json
  • diagnostics_6-8-2026_10-10-54.pdf
  • gSenderSettings_6-8-2026_10-10-54.json
  • gSender-firmware-settings-6-8-2026-10-10-54.json
  • Side - 6mm.nc

Could you advise whether this looks like a gSender restart/resume/modal-state issue, or whether there is another explanation in the diagnostics?