Run up a (very) simple job and all is good so far 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.
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 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.
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.
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
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.
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.