Zeroing nuisance - confirmation first?

I don’t know if anyone else has this problem in gSender, but still after months of use I often hit Set to Zero instead of GoTo Zero, which messes up my workflow. I use GoTo more than SetTo, but SetTo is more prominent and has no undo. It would be nice if there was a graceful way to backtrack or to have SetTo require a confirmation. @KGN


I agree, I find myself pausing to think about which to click on, so I don’t screw it up again. The one that still gets me is when I have multiple paths for the same project, and I programmed P2 for the job, the software defaults to P1 after every path is completed.


I’ve had a rant about that before version 1 came out. They said it is common everywhere else. I don’t care about everywhere else.

So, I started taking advantage of that with my default setup, but I still have P2-P6 programmed all over my spoilboard for smaller projects, too. Every time I HOME, I run a macro that initializes the default XYZ zeros for P1-P6.

I, too, am very slow to decide what to click here.

1 Like

What do you mean by " I run a macro that initializes the default XYZ"? I have not worked with macros, don’t really know what that is. Thanks

1 Like

Hey folks, a couple things to address here,

1) RE “Set” being more prominent than "Go to"

We’ll continue to collect feedback about this, but for the time being we’re going to leave it as it is. Way back in the early releases, we actually had these swapped (ie Go To was the bigger button, Set was the smaller one) and the most common piece of feedback we received was that this was backwards and we reversed them. It’s clearly something that maybe a little more subjective as to what the most important/common action to take is (do you set zero more than go to? Do you jog over using Go To? etc).

It might just be that this area as a whole needs a redesign in terms of visual clarity if people are “slow to decide what to click” or consistently press the wrong action. We’ve tried to stay consistent with the colour scheme of “solid blue results in the machine moving” throughout the main UI as a secondary indicator of what each button does, but maybe that doesn’t work in this case.

We also might just end up adding a preference for button order, but I think some redesign might be likely since we’ve had this conversation before internally about the design of that widget. For the time being, however, we’re going to leave the functionality where it is to prevent confusion for the greater number of users.

2) "Software defaults to P1 after every path is completed"

This statement doesn’t 100% track with implementation and I’m going to ask you to follow up on some things here.

“Stopping” a job (with the red stop button) issues a board reset command which results in all modals going back to default (including G54/P1). In the next release, if you stop a job, after the reset it will return you to whatever WCS you were in previously (so if you ran a job in G56 and stopped it using the red button, after the reset gSender will issue a G56 command to get you back into the previous WCS). We’ve had a change of opinion after internal discussions on this and want to remove this as a possible pain point for users who do use different WCS.

“Job completing” (a file runs through to the end) does not reset the board, so your WCS should not change, which is leading to my confusion - I can run multiple jobs in a row in whatever WCS I want and don’t see my WCS changing on Pgm End. Nothing in the codebase resets WCS by itself - relevant events and code below. The gist is that when the Sender determines the program is finished, it emits an ‘end’ Event. The controller, on receiving an ‘end’ event, sets the finishTime, and eventually sends a “stop” command to rewind the program. At no point is the board reset or modals changed.

What may be happening is that you have some code in your “Program Stop” event in settings that is changing modals/WCS, since that code is run a) if you stop using the button as well as b) the program ends naturally. If this is not the case, could you send a video/screenshot of your console output when a toolpath completes so I can have a better idea of what’s going on for you - we can’t recreate it on our end.


1 Like

for zeroing what about a confirmation dialog like there is when you close a gCode file? That would solve my problem by alerting me that I am making this change @KGN

This is also an option we’re considering, but are trying to avoid adding more “clicks” for common actions as a general usability rule.


I would say that the confirmation dialog for closing a file is less useful: the point is that it is an action that is easily recovered from, whereas the change of zero is not. Such confirmations could be a preference, though that adds a different form of complexity

Well, I’ll be a durned horned frog! That’s what I’ve been waiting for, and I’ll still be looking for it.

Now if you can just get Z to raise to a safe height after a “STOP” …

Just to follow up on “Workspace resets on program complete”:

After some back and forth, we found that those reporting their WCS is reset after a program completes was due to having a M2 command (program stop) at the end of their gcode program.

M2 resets GRBL to default state, including WCS.

Potential workarounds/solutions are as follows:

  1. Make sure your program doesn’t contain M2/M30 that would reset GRBL wcs to default, or any G54-59 commands that would change workspace

  2. You can use the start and stop gcode blocks to store and restore your WCS at the start/end of each program.


in the start section will store your current WCS in the workspace variable


in the stop section will issue the WCS command to restore the workspace after the program ends (if you do have M2 that you don’t want to remove).

This + the change for the stop button itself restoring WCS should cover all situations where people were reporting WCS changing on them.



Now if you can just get Z to raise to a safe height after a “STOP” …