M4 ESP32 UI for stop vs abort

The way the layout on this page works, the button sizes do not change differently based on the size of the content, but the content shrinks or gets cut off. I tried it on desktop, tablet and phone and although phone is not fully “good” (and it wasn’t before I started either) it is usable.

2 Likes

I’m not a fan of icons where they add to the cognitive load. At a minimum, they need words to go along with it. The Jog Arrows are an example of relatively universally understood pictographic representations of action/direction. However, with something like Maslow, it’s tricky coming up with easily parsed icons that are faster to decode than a word(s).

Even looking at the button bar above the text I’m writing, most are familiar, but the upload is one I haven’t seen before. (vs. Mac/iOS/Windows standards that have been around for years). The gear we could use for “Settings”, but the popup is really “Setup” - actions you take, not just things you specify.

I’ve been working on the setup popup to work on mobile, and will follow that with the 'Settings" popup from there. I think there is some short-term simplification / clean up and maybe a bit of a longer term path to solving the problem of trying to explain the steps to take to get a machine up and going.

Longer term, there is a 3.0 version of the Fluid UI under development - no idea what state it’s in, but might be worth looking into. UI Consistency at least for the maslow portion would be useful to work towards.

I have more thoughts on this, would be fun to get consensus on! As of this point, I’ve spent more time looking into the Maslow code than assembling mine or using it!

1 Like

Derek Graham wrote:

Longer term, there is a 3.0 version of the Fluid UI under development - no
idea what state it’s in, but might be worth looking into. UI Consistency at
least for the maslow portion would be useful to work towards.

one thing we do not seem to be doing well right now is keeping up with changes
upstream (let alone having something ready to integrate with upstream)

David Lang

That’s usually best managed as something like a regular monthly pull and merge during the major development phase, and then quarterly during maintenance times. But you only tend to figure that out after doing things for a few years.

1 Like

Curious, are you thinking maybe a wizard / sequence for calibration and then a wizard/sequence for “things you have to do to hang a calibrated maslow”? Most of the rest of the buttons in the current dialog seem to be for diagnostic use, which I’m thinking about more features in this area so might be their own dialog, maybe off the top dropdown menu, as they don’t really need their own launch button on the maslow tab.

1 Like

Yes - I’m only getting started exploring all the different layers of UI and software, but there is a simple setup wizard in in the upper right hamburger menu - for setting up wifi and some other basic settings.

The setup process seems like it could include more instructional information than will fit on a single screen with all the controls. A wizard / paging control is one way to do that. And maybe some hope of it fitting on a mobile screen. Another way would be to have clear instructions on-line, in a printable sheet (1-page) with clear directions as to the step-by-step and corresponding buttons/actions.

Step 0 - welcome / overview of setup/calibration process
Step 1 - Retract All - info if all belts don’t retract fully, etc.
Step 2 - Extend All - how to release them, attaching to frame
Step 3 - Calibrate - frame sizes, etc. (not sure where that gets called out in process…)
Not sure what comes next - is it Test? Apply Tension? Sort of depends. So at some point, I think you want access to most of these things together? If you’re using it every day may be different than 1x a month, etc.

I could see a checkbox “Skip Setup Wizard” or similar that skips the steps and just shows all the controls.

Bar just mentioned an another topic that the buttons aren’t supposed to be active until the previous ‘steps’ are completed, but I don’t know how much that is button press aware or actual machine state. i.e. you can set your motor current low enough that the belts don’t fully retract - are you prevented from extending/calibrating/etc. I don’t have mine on a frame yet so I haven’t checked out that behavior. If the ‘state’ is somewhat available to the UI, things like checkmarks could be updated (Retract All completed) etc. in wizard or other step-wise presentation.

Anyway, here’s a screenshot of my branch working on mobile. I’d like to be able to do these operations at least from my phone vs. laptop balancing, etc. Providing some idea of the essential sequencing, and grouping similar functions together. I’m assuming this is paired with a clear set of instructions for this part of the UI (hence removing the arrows…)

I could probably put the arrows back in if the calibrate/test stack was on left and Apply/Release was on right.

2 Likes

The ‘Stop’ in this menu is confusing to me. Is it different than the stop in the main interface? I tend to click/tap out of the setup dialog to see the machine log …

Separately, getting back to the earlier discussion of pause/stop/emergency stop.

On woodworking tools/other industrial machinery in the U.S., these seem to be the go to: woodworking emergency stop at DuckDuckGo

What about:
[PLAY/PAUSE]: Begins action/Pauses action with ability to restart from paused state. Manual options/jog disabled.
[RESET]: Stops action and brings machine home or center without option to restart from paused state.
[EMERGENCY]: Kill all. Requires machine hard power reset.

I agree. I think the thought on that is that if the user needs to stop during calibration its two clicks/taps to get back to hit stop. I wonder if, since the main area on the page is not used for calibration, it might be better to just swap it out for the “setup” controls (vs a dialog). then stop is still available on the side (or under it on a phone/small width device).

1 Like

I’ve assumed that the STOP button is here because this popup is representative of the distinct nature of the setup / deployment process being different than normal operation.

While you are running calibrate, or I suppose any of the other operations, you will want to be able to stop it if something goes awry.

If the settings/config/calibration were fairly sticky - i.e. once done only rarely needing to be done again - it would make sense to show and require the setup process before the ‘main’ UI is displayed. But you still need access to retract/extend/tension on a regular basis even if you aren’t doing calibrate/config/test every day.

However, I think I’ve heard @bar mention that a desired outcome of the calibration process is that it is easy and quick enough that you can do it every time.

I’m new to this, but it seems we are in this era of rich, responsive programmable UI and the default is to emulate front panel controls of CNC machines from decades ago. Things like Cricut and Glowforge are CNC machines that try to distill everything down to a “Design and Go” sort of idea. However they have the luxury of being more self contained for calibration (run to the limit stops, camera, etc.) but still have the Load Material / Close Lid / Go levels of interaction. Maslow is a bit more interactive because you are loading the tool as well as the material.

It seems possible to get to a place where the UI and process is as accessible to someone who hasn’t used it before as it needs to be for someone who uses it every day.

regarding the Play/Pause/Stop/E-Stop/Reset options…

I don’t know enough about what’s possible in the software with respect to the original question up top, but something like [RESET] stopping a current action and then moving to home is not a good idea. If the belts are jammed you don’t want to start the motors again. If the bit is still extended you don’t want to move to home, etc.

If something is going wrong, you want to STOP.

  • stop calibrating, stop retracting, stop extending, stop tensioning/releasing, stop spindle/etc.
  • You need and want 1 click/touch access to STOP during those setup operations as well as cutting / moving operations.

PLAY / PAUSE - implies the ability to resume operation. STOP does not (i.e. CD Player).

I’m not sure the differences between “!” And Maslow_Estop, but it seems there are the following actions being discussed:

START (Play) - begins processing G-Code
PAUSE(Pause) - pauses processing G-Code
RESUME - continues processing g-code. Is this pressing pause a 2nd time, or pressing play after pausing? Both?

STOP - stop processing G-code. Should you be able to resume after stopping?

E-STOP - Stops everything - loses current state info, etc.
RESET (George) - this sounds like Stop, retract, go home?

Do any of these auto-retract Z-axis?

2 Likes

The way I’m currently doing it the play button becomes pause when gcode is running and the pause button becomes play again when clicked to allow the user to resume. This does not mean it has to or even should be that way, that is just what I thought should happen. Unlike physical buttons on a device, in software we can have the icon change based on state and I think this is a case where that makes sense.

I think stop should be “abandon the job” (or maybe not, I don’t have a strong opinion on this) but the biggest key is to NOT have to restart the machine. “soft stop”.

“auto-retract Z” meaning? go to z=0? That said, if we have a command to do this, the code can certainly invoke it on any of these operations.

1 Like

the command ! in fluidnc (when its accepted) stops motion immediately. It does not panic or alarm just stops. you can “resume” with “~” which is what I have my play/pause button doing “!” and “~”

1 Like

Ron Lawrence wrote:

the command ! in fluidnc (when its accepted) stops motion immediately. It does not panic or alarm just stops. you can “resume” with “~” which is what I have my play/pause button doing “!” and “~”

Ron is working to clean up the code and make sure ! works properly for the
maslow, at which point Maslow_Estop may be able to go away.

David Lang

1 Like