Yes! Absolutely. Here is the latest.
firmware.bin (1.9 MB)
index.html.gz (130.7 KB)
I haven’t found a solution for the bug you found with the math not always finding a good starting point but I have been working on that a lot. I’ve learned a lot about how the math works (not to say that I understand everything), and I have some kind of hacky solutions which I think could work, but I’m still searching to see if I can find something more elegant.
Quick test, all ok. Didn’t try Find Anchor but other functionality working great.
Modified to
Replace Idle button with Apply Tension in Extended state #711 which brings the Apply tension to the main menu while leaving existing Setup menu alone. No extra real estate is used as it replaces the Idle message (which is not current until Maslow is ready to operate). The Apply Tension message is then replaced with Idle message.
firmware.bin (1.9 MB)
index.html.gz (130.8 KB)
I like the idea of moving those buttons to the front page. I was thinking about using this space here for the two most likely to be used calibration buttons for each state:
Like in the “unknown” state that would be “Retract” and “Extend” and then from the “Extended” state that would be “Apply Tension” and “Locate Anchor Points”
What are your thoughts on that?
@ian_ab If you have a chance will you give Replace random calibration retry with systematic aspect ratio sequence by Copilot · Pull Request #709 · MaslowCNC/Maslow_4 · GitHub a test? I’m hoping that it solves your issue of having the starting position be too far off throwing things off, but I haven’t been able to test it well because I can’t get the issue to happen on my setup (although I was able to replicate it with your data)
Edit: I think I spoke to soon, it’s not working right for me at the moment, so don’t waste time testing it yet 
This would mean relocating Trace Boundary function.
How about using the Idle button
How about when Unknown have button with Retract which changes to Extend when status is Retracted then becomes Apply Tension when status is Extended then defaults back to Idle, Home or whatever message is appropriate on Ready to Cut. I think Release Tension and Locate Anchor Points should still be hidden behind Setup as if accidently selected could be annoying.
Ian Abbott wrote:
This would mean relocating Trace Boundary function.
How about using the Idle button
How about when Unknown have button with Retract which changes to Extend when status is Retracted then becomes Apply Tension when status is Extended then defaults back to Idle, Home or whatever message is appropriate. I think Release Tension and Locate Anchor Points should still be hidden behind Setup as if accidently selected could be annoying.
yes, when the state is unknown, play/pause, stop (even alert/idle) do not mean
anything.
David Lang
David Lang wrote:
yes, when the state is unknown, play/pause, stop (even alert/idle) do not
mean anything.
I meant to say, until the status is ready-to-cut alll of the gcode related
buttons (including load file) cannot be used and the space could be used for the
setup functions.
David Lang
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)
README.txt (524 Bytes)
David Lang wrote:
I meant to say, until the status is ready-to-cut alll of the gcode related
buttons (including load file) cannot be used and the space could be used for
the setup functions.
I just started [WIP] Reorganize state changes with new structure by Copilot · Pull Request #715 · MaslowCNC/Maslow_4 · GitHub to implement a
cleanup so that instead of state change limits being set by an if statement at
the start of each state transition, there is instead a data structure that lets
you lookup the current state and see what states you are allowed to transition
to.
I then tell the AI to make this available to the UI and change the logic in the
UI to use this same data structure.
My idea is that once this is done, the next step will be to change the UI to use
this data structure to create a row of buttons that show the state changes
allowed from the current state.
David Lang
firmware-package centralize_state.zip (1.3 MB)
Commit: 416ccee74e0a957484e39b76b4aa29ed0900bbfe
Version: v1.17-39-g416ccee7-dirty
Environment: wifi_s3 (ESP32-S3)
Firmware size: 1.89 MB
Flash usage: 1.89 MB (64.5%)
RAM usage: 135.9 KB (42.5%)
17 commits [WIP] Reorganize state changes with new structure by Copilot · Pull Request #715 · MaslowCNC/Maslow_4 · GitHub
Could I get some people to please test this? it should make ZERO visible or behavioral changes (other than some log messages) but rearranges state management and UI code significantly (+424 lines/-333 lines). It passes my sniff test and extensive analysis by the AI, but additional eyes is always a good thing.
There is now an array stateDefinitions that lists every state, it’s name/background color for the UI, the button label for the UI and what states you can change to. The UI now uses this information to label and color the buttons. This means that if we decide that it is now allowable to go from one state to a different state, all we need to do is change this array and the buttons in the UI will change accordingly
The next step in this path is going to be to
firmware-package dynamic buttons.zip (1.3 MB)
Commit: c213b198428b78af111738403e212866013357a8
Version: v1.17-42-gc213b198-dirty
Environment: wifi_s3 (ESP32-S3)
Firmware size: 1.89 MB
Flash usage: 1.89 MB (64.5%)
RAM usage: 135.9 KB (42.5%)
here is an UNTESTED version that has the buttons change based on the state.
From a UI perspective I’m not super sold on having things totally change their function at different times, I think that is going to confuse people
Tested state was blank, status idle. Setup all fields were purple except Stop
Bar wrote:
From a UI perspective I’m not super sold on having things totally change their
function at different times, I think that is going to confuse people
would it be better to grey them out when they can’t be used and have the new
buttons on a separate row?
With this new infrastructure, it’s easy to add buttons either dynamically (like
I did here) or color changing and not have them get out of sync..
David Lang
I do like the idea of greying them out.
I think that maybe we should have a cohesive design philosophy and come up with a list of what our goal are.
I think that ever growing complexity is the thing that kills open source projects because people get frustrated and just want something simple that works
Bar wrote:
I do like the idea of greying them out.
I think that maybe we should have a cohesive design philosophy and come up with a list of what our goal are.
I think that ever growing complexity is the thing that kills open source projects because people get frustrated and just want something simple that works
bad UI with every feature at the same level can be a barrier to new people
getting started, but I see more projects die because the founder doesn’t accept
features and so potential contributers go away and then the founder gets burnt
out.
IMHO, the normal workflow should be trival, but the abnormal workflow should be
possible (with the recognition that what starts as an abnormal workflow may
become more common in the future)
right now, we have people trying to jog/cut when the machine isn’t able to yet,
so modifying the UI to make it more clear that the parts that can’t be used yet
can’t be used, and what needs to be done to use it would complicate the UI to
some extent, but would also provide more help to people new to the machine if we
can do this right.
greying things out with more info in the tooltips can do this, removing buttons
that can’t function right now can also do this
the trace outline feature is a button that disappears when it can’t be used.
David Lang
@bar in the old UI repo, copilot had a way to run a test version of the UI and take screenshots from it to show that it’s changes were valid.
In the current repo, it does not have that ability.
I didn’t change any settings related to that, but maybe because we are one folder deeper it has a hard time finding the right files?
Bar wrote:
I didn’t change any settings related to that, but maybe because we are one
folder deeper it has a hard time finding the right files?
I’m thinking it was something that was setup in the UI repo that wasn’t set in
the firmware repo
I asked it to show me screenshots after a UI change and it said there was no way
to do that, but when the UI was a separate repo, showing screenshots to confirm
the change was common.
David Lang
