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.
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
GrblHAL/Teensy4.1/ShapeOKO-3/Rotary-A
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.
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.
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.
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
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.
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.
Homing, file loading, jogging around (now with continuous), homing rotary etc all good.
