Migrating a discussion that was taking place in Interstitial Firmware Releases - #222 by Carson_Barry that grew a bit more than I expected it to and shouldn’t continue to derail that thread.
Just skip all these embeds if you’ve seen the beginning of that conversation.
I love the idea of progressively enabling controls as they become relevant. That would do a lot to make it more clear what buttons are ready to use and when.
Is there a reason why you can’t just hit calibrate and walk through the whole process?
Don’t you have to retract all, extend all, and then do the actual calibration any time you calibrate? I understand the need for the other buttons for other functions, but seems like you should be be able to hit calibrate and have it walk you through the steps. Is this just something that is there for troubleshooting?
This menu is ideal for normal use once calibration is complete.
Those buttons are not calibration specific, but are present because they are required for getting started after a power cycle.
If your machine is on the frame and off with taut belts, and you then turn it on, you will need to give slack, retract all, extend all, and then take slack, before you can jog around and use it, this just puts those ‘need every time’ buttons out in the open.
Give slack may be a bit of an exception, but it would be annoying for that to be the odd one out of these 4 to still be tucked in Setup.
As for calibration
retract all > extend all > Setup > Calibrate
that flow seems both simple and appropriate, especially considering these other buttons would no longer be taking up space and potentially confusing users in the setup menu
I could imagine a second line of text in the gray box at the top which could suggest next steps:
Step 0
Use “Retract All” to find belt ends
Retract All Has Been Used
Use “Extend All” to Extend belts and mount sled
Extend All Has Been Used
Use “Setup” for calibration controls or “Take Slack” to enable XY controls
Last one is way too wordy, but hopefully you get the picture. Alternately these “hints” could be part of the serial log.
I had a code branch that had a “wizard” that would walk you through the setup process but both Bar and I thought it was not very ergonomic so I abandoned it. I like the idea of having the ui elements that are not going to work disabled, but visible. This is super easy in most modern web frameworks, but would take me a bit longer to figure out in the really lightweight version of bootstrap light that the fluid codebase has. I’m sure people that work in this sort of environment more than I do are better/faster at it than I am. Usually I’m writing code for desktop web browsers connected to servers that can serve large libraries like angular or react. That is a no-go on an ESP32.
I’ve been away for a while, and I have some things coming up that will take a large chunk of my free time, but I’m willing to take a crack at starting on this and putting out a fork with it that we can iterate on here… some of the issue of accomplishing the full vision outlined here will be getting the status of things from the m4 which will also likely require some firmware changes too, although I’ve started a command we can extend for getting status already: $MINFO.
From Bar ^^
If it’s that we’re stuck with using a straight grid and can’t subdivide, as well as needing some extra slots for a calibrate button, I’d revise my previous design like this (multiple examples with arbitrary differences):
I think that subdividing is an option, but I’m worried about usability on phone screens because the buttons might get too small to press
I’m still a fan of having the amount it moves in the center of the arrows, but that may be because I very seldom (probably never) move to home once it is set. Maybe someone with more experience in CNC can tell me what I am missing.
To me on both my standard CNC and Maslow I jog to the position where I want the home to be and set it. In this case, I want the amount to move and arrow buttons to be as close together as possible.
If I am making multiple of the same thing I make sure my holding jig is repeatable, set home once and just change out material and click go over and over. Am I just being lazy and not making sure the home didn’t move? What’s the use case for the home button?
For the go home button or for the set home button?
The go home button. It’s more a question of when do people actually use that in practice? Once I set it, I personally don’t ever go back home, but I am fairly new to CNC within the past year.
To be honest I don’t use it very often either. I think that it is nice to have, but maybe not needed?
The time I use it most is after jogging the machine around to make sure that my part will fit on the wood
I’ve used it a few times during multi-bit/multi-cut jobs, jogged it away from where it ends up after the first job to do a bit change, then used set home to send it back.
I also use it right after defining home to make sure that it was properly saved, because I have been trained to never trust hardware without checking things like that. Would be very frustrating to have it hidden in a menu if I’m using it every time I define home.
It’s also a standard user-facing control for this kind of thing, so I would be worried about removing it and having the interface become less intuitive to users of other control software, or for those who would end up having it be a regular part of their workflow in ways we can’t currently foresee.
I use this all the time to get back to what I set as XY zero. This has been very needed when jobs fail as it lets me restart them.
That said, I think we are not adhering to what “home” is on the first tab, which sends “$H” which apparently we don’t have a setting for / use. (don’t ask how I know). Also the movement / jogging on that tab uses different commands and a different feedrate. I think there is work to be done to use more of what is already in grbl/fluidnc in respect to work coordinates, jogging, and homing…
I’m confused, you don’t have to go back home to restart a job do you? Seems like whenever I have had a failure, I just click start and it figures it out for me. But yeah, definitely should stick with what is ‘standard’ in other control software. I guess on my shapeoko I actually do use home when I start up after not having used it for a few days so I can see where the actual home was set, not really relevant here though (yet hopefully).
Well, I guess I learned something new today. I have never not gone back home, having assumed my gcode would start from wherever I was. But now that you point that out I see that is a silly assumption, and have wasted time for years doing this. Thanks 
Bar wrote:
To be honest I don’t use it very often either. I think that it is nice to have, but maybe not needed?
The time I use it most is after jogging the machine around to make sure that my part will fit on the wood
It can be useful when positioning material, but a ‘frame’ button that goes
through the gcode and finds the min/max x/y coordinates and then moves the
router in a box using those coordinates if FAR more useful.
David Lang
Ron Lawrence wrote:
Well, I guess I learned something new today. I have never not gone back home,
having assumed my gcode would start from wherever I was. But now that you
point that out I see that is a silly assumption, and have wasted time for
years doing this. Thanks
It depends on if your CAM software is positioning things in relative or absolute
mode.
If it’s using absolute mode (G90) then you don’t need to go to home
But if it’s using relative mode (G91) it starts from whereever it happens to be
at the time you hit go.
David Lang
Well lookie there, I learned something new too. Haven’t ever seen a relative mode, but I am not a gcode jockey either. Good to know.
