Yeah I remember that too. I’m pretty sure that I’ve had it make screenshots on the new repo too tho. Maybe it is just lying that it can’t do it? 
Bar wrote:
Yeah I remember that too. I’m pretty sure that I’ve had it make screenshots on
the new repo too tho. Maybe it is just lying that it can’t do it?
always possible, can you give it a try and see if you can convince it to give
you a screenshot?
David Lang
1 Like
Yeah, I will try to see if I can get it to generate some
On the UI design front, I pondered it a bit on a drive, and for me, completely abstracting away the internal states, at the beginning of my journey I would have liked it if it was three screens/windows/UI-states:
- Can’t cut
- Could cut
- Cutting
Can’t cut - there’s one or more things that must be fixed. Buttons and outputs that are useful to fix them.
Could cut - setting up everything you want for this particular cut, buttons, outputs and (togglable) Ok/Cancel checks for common things like setting Z-home.
Cutting - pause / resume, etc.
I think now I’d want a ‘Manual’, ‘Power user’, etc mode that shows everything all at once as well potentially, and some other stuff, but those three states would encompass what 99% of users would do.
1 Like
Possibly:
- Can’t cut.
- Prepare to cut.
- Cutting.
Disambiguation is hard.
Dave wrote:
- Can’t cut.
currently this is anything other than ‘ready to cut’
- Prepare to cut.
this is ‘ready to cut’
- Cutting.
this is the maslow state ‘ready to cut’ plus the FluidNC state of !idle
I think there is one more important state
Error, something has gone wrong.
This is different from the ‘can’t cut’ stage above because it’s a ‘reset the
machine’ combined with ‘and figure out how not to have it happen again’ rather
than just ‘follow these steps to be ready to cut’
we added the current state bar to make troubleshooting easier for those of us
helping (not knowing what the state is makes it hard to troubleshoot)
the background colors are supposed to help out 
David Lang
1 Like
I love this I think this is a really interesting take on the issue.
How would we toggle between screens? Would all three be available as tabs along the top or would they all be on one screen and only the functions currently available to the user would be shown?
Maybe the rest of the screen stays the same but just this part is changed between modes?
Seriously. My girlfriend is a UI designer at a big company and the amount of resources that go into disambiguating problems and then testing if that change is being used right is mind boggling.
I agree. I think that we’re having people post logs where the issue is clearly stated in the log, but folks aren’t seeing it. The machine should clearly communicate what is wrong and what the steps are to fix it.
hi,
sorry, I can’t see the whole context, but I saw earlier that the % of the cutting progress will be visible. Could it be calculated based on the set feed rates from G-code and the estimated remaining time? I’ve been cutting quite a lot of grooves to release tension in laminated plywood and it took about 2.5 hours in one axis…so if I could see how much time is left, I would have changed my mind about turning it on at midnight
No. 
At least not right away.
That turns out to be a really tricky problem to compute because we need to take into account both the max federate, but also the maximum acceleration rate. Like a 1000mm straight line will cut a lot faster than a bunch of back and forth little lines with a total length of 1000mm.
I’ve actually never seen a library that can give a good time estimate for a gcode file’s actual run time, but that doesn’t mean it doesn’t exist and I’ll keep an eye out for it.
Currently we are using FluidNC’s built in system which uses the current gcode line number, but that’s also super inaccurate.
Bar wrote:
I love this I think this is a really interesting take on the issue.
How would we toggle between screens? Would all three be available as tabs along the top or would they all be on one screen and only the functions currently available to the user would be shown?
Maybe the rest of the screen stays the same but just this part is changed between modes?
I like the idea, it’s a step further than I am going with my current work.
the x/y jog pads can’t be used until we are in ready-to-cut, so if we are in
other states, rather than obviously blocking them as I have been headed towards,
we just delete that entire section and replace it with the buttons that we
currently hide in the settings popup.
Rather than an error sending us into the state ‘unknown’, have it send us into
the state ‘error’ and make the errors that are logged much more promanent
David Lang
1 Like
even the very expensive commercial CNCs don’t do a decent job of estimating
total run time.
David Lang
2 Likes
I’m not saying it’s the right way to do it, but in my head you work through 2 questions then cut:
- Do I need to fix/adjust/calibrate anything before I prepare my cut?
- Have I set everything for my cut - have I prepared my cut (badly phrased, but ‘normal’ cut setup - setting X/Y/Z homes, loading the file you want to cut, possibly doing the trace outline stuff).
- Cut.
And although there are going to be many more internal states and transitions, from a user perspective, gathering the input/outputs for each of those heading/questions/meta-states makes sense to me.
I’d make the point that for any kind of error state I’d argue it still fits into the first - it’s still something that needs sorting before you can do normal cut prep. 
I definitely don’t know the best answer for this 
Three tabs is a good idea - potentially they could change colour or have the latter stages greyed out if you need to do the previous? I am not sure the level of railroading we want - are there situations where this doesn’t hold:
You must fix issues ->before-> You must prep a cut ->before-> you do the cut.
?
That seems like a good approach
Yep, but do it right and it saves you money compared to the support costs (even ignoring the customer experience)!
I’d argue that’s still the first state - it’s semantics I know, but does a user care whether it’s an error state or not calibrated yet?
‘The Maslow isn’t in a good state to prepare your cut, here are the diagnostic tools / what you need to do to get there’ is what I wanted to know as a user.
Dave wrote:
I’d argue that’s still the first state - it’s semantics I know, but does a
user care whether it’s an error state or not calibrated yet?
the reason I think the answer may be ‘yes’ is that if it’s just not
calibrated/setup yet, there is no troubleshooting to do, just straightforward
‘follow these steps and you will be ready to cut’
This is the ‘extend belts, attach, apply tension’ or ‘extend belts, attach,
calibrate’ workflows
but if you are in an error
state, you have something wrong that you need to diagnose and fix first.
possibly upload logs, ask for help, etc. very diffent tools/steps needed.
David Lang
@ian_ab here is an updated version (found several issues with the prior version) please give this a try. most of the fancy button changes have now been removed, so it’s mostly just making sure that the buttons change colors correctly to represent what’s available in the current state.
firmware-package dynamic buttons.zip (1.3 MB)
Looked OK initially, clicked on release tension, it released tension, fan did not turn off and I lost connection a few seconds later. Had to power cycle to get control again, and it was in the Unknown state. Retracted and tried Release Tension again and the same thing happened, This time it was from the popup menu. Fan kept running and I lost connection. Had to do the dance again.
I don’t think the release tension should be on the front menu, too easy to accidently click on it and it shouldn’t be needed in normal operation.
Did you have a look at the version I put up for revue:
[quote=“ian_ab, post:651, topic:20215”]
This does it, let me what you think:
Replace static “Idle” text with clickable state-dependent action buttons#713
firmware.bin (1.9 MB)
index.html.gz (130.9 KB)
1 Like
Hi all,
Im setting up 1.17 after a long hiatus from Maslow. I was really excited to see something about putting in the workspace size prior to running calibration.
However, i cant seem to find it. When running calibration my Maslow keeps running off the edge. Im not dealing with a full 4x8 area. I am however working on a vertical frame designed to 4x8 “level/size” (the one on setup page)
Any help would be appreciated.
Go to the FluidNC pulldown, then Config Items then go down to
Put in the values, Set and Save (top). Then back To Maslow pulldown,
Retract, Extend and Find anchors.
2 Likes
Solid! Thank you. I was racking my brain and eyes trying to find this. Much appreciated.
I see there is “Work Area Center Offset X” (and Y): Would this be the thing to help me with my centering issues. It appears that maslow now thinks my work area (box) is about 7 or 10 inches low on the Y axis.
Could i just move the at work area box up on the Y axis XXX number of mm using this offset? And would that be okay to do after the fact/calibration?
Also amazing responses and quickness on these forums. Thank you Just as i remember (been a year or two).
Cheers-
Yes and Yes
1 Like
Ok this is looking great!
Then i reset after a “session”. turned it back on later. Retracted. Extended belts. And…disconnects. And keeps disconnecting from wifi.
I have not set a password. Seems to connect initially fine. But then poof. Even during belt extension.
Any ideas?