gSender Edge 1.3.1

Hey folks

Edge is progressing with both some new features for Rotary/Vortex support along with some quality of life changes for other features.

This build is current with main changes as of 1.2.2, along with some cool new additions:

Go To location

  • Easier movement to specific coordinates (either relative or absolute), available with a button press in the location widget

Warn on Zero

  • New safety option that will always prompt when interacting with the Zero buttons to make sure you don’t accidentally set your workspace offset without meaning to

Remote mode improvements

  • QR Code now viewable with remote mode enable for easier navigation to the remote interface on your phone
  • Workflow controls are now available on remote interface - if a file is loaded, you are now able to start, stop and pause jobs on your phone.

Toolchanging improvements

  • Added pass through option that will not comment out M6 commands if you’re connected to a firmware that supports real tool change procedures
  • Return of the codeblock - due to popular demand, pre-and post- codeblocks are now returned as a tool changing strategy.

The full list of patch notes is available below.


  • Updated build with changes from Main as of 1.2.2
  • Added workflow controls to remote mode view - now possible to start, pause and stop jobs on your phone
  • Added QR code in remote mode modal for easier access on phone or tablets - scan on your phone camera and instantly navigate to the interface
  • Added Go To location button, to allow easy movements either relative or absolute to exact positions
  • Added preference to prompt on axis zero, to prevent accidentally rezeroing when not intended.
  • Visualizer performance improvements - smoother panning and visualization on lower power hardware
  • Added passthrough option to toolchanges to allow M6 to be sent and handled by the firmware
  • Return of the code block - Code option re-added to toolchanging with pre- and post- hooks
  • Fixed issue with continuous jogging on non-Sienci firmware
  • PRB values now available as macro variables for all axes in Grbl and grblHAL controllers
  • TLO for each axis available as variables in HAL controllers
  • Updater ping will more consistently show when a new version is available
  • Fixed aliasing issue on visualizer when resizing window
  • Macro variables that look like numbers are now treated like numbers for the sake of addition (instead of concatenating as strings)
  • Fixed issue with firmware selection updating list of devices too frequently
  • Fixed issue with DRO precision in some situations
  • Dependency updates


  • Fixed physical rotary unit setup not outputting correct file in some instances
  • Added y-axis and z-axis probing
  • Updates to rotary mode toggle, will now prompt you with what actions will be performed
  • Added rotary tab in preferences to allow changes to firmware values
  • Minor fixes to stock turning

As always, binaries can be found at the release link:


Run up a (very) simple job and all is good so far :slight_smile: Homing, file loading, jogging around (now with continuous), homing rotary etc all good.

Apple 2013 MacBook Air x64

Converted my corner and centre finding macros to use PRB variables, which are all working correctly and the Number() workaround no longer seems necessary. First assessment is that PRB along with my contact probe is delivering ±0.03mm repeatability, which is the same as the step-movement resolution on the machine. I suspect any limitations are now the machine, not Grbl/Probe/gSender.

One slight anomaly is the console window. It seems to scroll ‘backwards’ for about 10 lines until clicked in the keyboard down-arrow is pressed. Scrolling down with the mouse scroll doesn’t remedy the loss of visibility on the last line - but once down-arrow is pressed, scroll then successfully shows everything. I suspect this is a scroll-bar ‘number of lines’ it knows of issue. Minor, but it is there.

Can someone tell me if the Workspaces gets reset to G54 (P1) after every job run? We got this to be sticky at some point, but 1.1.7 reverted to having it reset after every job.

It needs to be sticky if a job is re-run in the same Workspace ad nauseam. A job can be ruined if you do it in P2, it resets and it has a different XYZ than P1.

Does your PP put an M2 command at the end of the file?

According to LinuxCNC M2 does the following:

  • Change from Auto mode to MDI mode.
  • Origin offsets are set to the default (like G54).
  • Selected plane is set to XY plane (like G17).
  • Distance mode is set to absolute mode (like G90).
  • Feed rate mode is set to units per minute (like G94).
  • Feed and speed overrides are set to ON (like M48).
  • Cutter compensation is turned off (like G40).
  • The spindle is stopped (like M5).
  • The current motion mode is set to feed (like G1).
  • Coolant is turned off (like M9).

So as you can see M2 sets a bunch of stuff, one of which is G54 (P1).

To answer your question, yes, M2 is at the end of every gcode file.

It has been awhile, but I think that @KGN said that gSender would be able to have the offsets set to the new default e.g. G55 if it was manually changed from G54. I’m sure that some version before 1.1.7 did this.

Maybe it did, I’m not sure as I tend to do all my work in G54. I have a couple of spots saved to other workspaces. For example I have the center of my spoil board set to zero in G59. Then if I want to use the center I switch to G59, go to XY zero then switch to G54 and set the zeroes there. Not sure if that method would work for you because I don’t know how you prefer to use workspaces.

I’m also unsure of how Sienci feels about altering the way a M code behaves. It seems like a big line to cross because some other people may rely on the way M2 works now. So I think if they alter the way M2 works it should be an option in the settings.

I’m afraid that you’ve slipped off the path of the question. I know how to use the Workspaces, and generally use 2 to 3 of them where I keep fixtures mounted.

The problem is not how to zero, etc. The problem is that every time the gcode for a job is finished executing, the Workspace is reset to P1 / G54 even if I started the job in a different Workspace.

Michael, you described the reason it happens (gcode M2). Yes, that’s right.

I’m wondering why we can’t get gsender to respect the current Workspace choice when it encounters an M2 in gcode.

Then I’m saying that I’m purty sure that gsender did that in a previous version after some discussion with @KGN previously.

The real question is to someone that can test this in Edge 1.3.1 since I’m unable to do that.

1 Like

I only mentioned the way I use workspaces because it explained why I don’t know how gSender handled M2 in past versions. Because I always do my actual work in G54 I never had the problem of it switching workspaces on me.

I’m sure they can get it to remain in the workspace if that’s what they want to do but it’s altering what a GRBL code does which I feel is a slippery slope. But it’s their software and they can do what they want. I just feel it should be optional to change what a code means.

Lastly I just tested Edge 1.3.1 on my test Arduino and it still changes back to G54 on M2.

1 Like

We reset workspace to what you had selected on job stop since 1.1.7, but M2 is supposed to reset modals and we have always kept that behaviour in. We have a workaround in the start/stop job if you want that’s documented in resources (Problems / Bugs? - gSender Docs) - a way to save your current workspace on job start and reset it to that workspace on job end.

Generally, if a gcode is supposed to do a specific behaviour we try our best to keep it doing that behaviour. M2 is supposed to reset workspace - that is core gcode/GRBL behaviour.


Since Edge 1.3.1 is maintaining the stickiness of the Workspace unless it sees an M2, is the solution to eliminate the M2 in the post-processor?

With the quote from LinuxCNC by Michael in mind, what are the ramifications of removing M2 from every gcode file? I have seen it included in every post-processor I’ve used.

You should be ok as long as you have everything you need at the start of the next file. It just won’t reset the modals as @_Michael quoted. Feed and speed overrides will not be reset, units will not be reset, spindle won’t turn off, etc… I would think that the biggest issue on your machine would be with feedrate override if you use it. There may be weird issues with the plane modal and arcs, but I only see that with Fusion.
You could replace M2 with explicit commands like:
G0 G90 G94 G17


I have been preparing a ‘try it out’ rotary job to cut a ‘barley twist’ and encountered the following warning;

Given that I have a permanent XYZA setup, this seems curious. My gcode contains two tool paths output together, the first rotates A to A0 then cuts 16,000 lines, the second then rotates A to A180 and cuts a further 16,000 lines. Solid model created in Fusion 360 (no Manuf Extension), tool paths created and output with a rotary-aware Post Processor.

An excerpt from the gcode file

(T2 D=6.35 CR=3.175 - ball end mill)
(Safe Retract Z set: -3.)
G53 G0 Z-3.
(Parallel Z-up (1))
T2 M6 (ball end mill D=6.35 6.35mm Ball Endmill)
S20000 M3
G0 A0.
G0 X67.108 Y-15.563
G1 Z-25.5 F842.1
X67.1 Z-25.599 F2526.4
X67.077 Z-25.696

X66.417 Z-27.696
X66.44 Z-27.599
X66.448 Z-27.5
G0 Z15.
G53 G0 Z-3.
(Parallel Z-down (1))
G0 A180.
G0 X67.108 Y-15.563
G1 Z4.5 F842.1
X67.1 Z4.401 F2526.4
X67.077 Z4.304

Is this warning, before I go and waste a piece of stock and my time, an alert to ‘temporary A-Axis’ users, or does this apply to any setup, including permanent XYZA?

I ran up gSender Edge 1.3.1 against a spare Arduino board with GRBL MEGA-5X loaded as XYYZA, and although gSender complained at the ‘G0 A0.’ and ‘G0 A180.’ lines, the simulator ran seemingly successfully. The visualiser was also correct, which is really nice to see.

So it appears that the ‘cannot be run’ is a warning for hijacked A-axis machines where Y-axis is not available during A-axis use. Clicking on ‘Continue’ in the JOB would appear to be all that is required.

Perhaps an option (sorry, another one) in gSender config could be to enable or disable warnings for simultaneous A and Y-axis use. For those with current generation Long Mills and the new Vortex, switch on (and on by default, I would suggest) for the warning, for those with MEGA-5X or GrblHAL who have permanent A axis (permanent 4 axis in fact), they have the option to switch off the warning.

Food for thought…