Valid point.
The Job Bounds box doesn’t provide much extra information, I do like the blue boundary around the graphic depiction however.
Another thing which would be useful is a progress indication when cutting, so you can see how far through a job you are.
Why not both? Make an option so the user can pick between none, a boundary trace, or a rectangular bounding box.
I really appreciate this trace boundary feature. My precision area is the center of the board, and I always have to reposition it. Seeing where the cut will go has helped me a lot in locating the cut between already cut pieces. It would also be very useful if it followed the perimeter accurately to optimize material usage, although this would also slow down the process. I don’t know when they changed it, but I miss being able to pause the manual movement. This new version has saved me because it no longer falls off the work area. Sometimes I make a mistake and press the manual move arrow too many times and can’t stop, unlike in version .88.
The constant battle of building software is to not let bloat in. Every feature is individually a good idea, but if we add every possible feature it all gets too bloated to be easy to use. Simplicity is the key.
tryon wrote:
Why not both? Make an option so the user can pick between none, a boundary
trace, or a rectangular bounding box.
very much this.
David Lang
Bar wrote:
Do we want to visualize the blue bounding box at all? I love being able to
trace it, but I don’t know that the blue visualization is giving us much other
than making the UI a little harder to understand
I can see arguments in both directions here. I know you don’t like options, but
I think this is a reasonable thing to be able to turn on and off. (showing or
turning off g0 moves would also be useful)
A future thing that would make this especially useful is the ability to
integrate with a camera for workpiece positioning.
David Lang
What is the problem with G0 commands? Just want to know for interests sake.
I really like that you can now restrict the area the Maslow can reach (by changing values in maslow.yaml). This allows us to restrict the boundaries the Maslow can access, especially useful when cutting on a smaller work area rather than the full 2400x1200.
Ian Abbott wrote:
What is the problem with G0 commands? Just want to know for interests sake.
sorry, I should have clarified, turning off the display of G0 moves (just like
turning off the blue outline)
the advantage is better seeing what is being cut.
David Lang
Here is a test release for hopefully 1.17:
The changes are:
Lots of good changes in there! Let me know if you find anything that we broke along the way 
firmware.bin (1.9 MB)
index.html.gz (130.1 KB)
Setup screen is just wrong. Initially comes up with no status. Maslow was in retracted mode prior to loading test files. Appears the button still work, I will continue to mount Maslow and report. Debug level is info.
Loaded on another computer and now responds as usual on both computers!!! That’s just weird!
Worked it out, Debug was set to Error initially which caused the data loss (went from Debug to Error instead of Info by mistake)
I don’t quite understand 
Is it a bug?
No Bug Well only an “id 10 t” one. I had accidently set the Flash settings Debug level to Error instead of Info, and you are using this info to generate the messages for display and generally report status etc. hence the lack of info on the screens.
Minor bug, here. If you set Debug to check for Motor Currents, when you set it back to False it doesn’t remove Debug menu until a power reset, although it no longer reports motor currents.when set to False.
I’ve seen that behavior too
@bar I put in a request to display progress when cutting (#688). Co-pilot generated: * Add real-time progress display to tablet view during file execution #689
This faciality already exists in the GRBL display. The change puts the percentage complete next to the Run message on Tablet view in addition to the GRBL display as a percentage to 1 decimal point.
Files here:
README.txt (524 Bytes)
firmware.bin (1.9 MB)
index.html.gz (130.1 KB)
I love this idea! I might hold off on merging it for a little bit because I have been planning to make a video on how to use the AI to make changes and I was thinking about using exactly this as a demo project
I have tried another (you may have let loose a monster). My idea was too let me go to precisely to any position within the cuttable range by entering the XY co-ordinates, instead of jogging. My first attempt (#690, #691) worked by popping up an input window which then uses the Number pad to accept X and Y values. What I wanted was to be able put an absolute XY values in and it would move Maslow accordingly e.g. If I entered 0,0 it should take the Maslow to the bottom left of the cuttable area, ignoring what was set for the home position.
I then asked it to do the same with absolute XY co-ordinates (#692, #693), and it added the following, which lets you add X & Y values via the popup number pad, and then go to XY
Ian Abbott wrote:
Is this possible? My understanding is that the underlying co-ordinate system
is based on X=0 and Y=0 is at the BL point.
No, internally 0,0 is the center (it doesn’t currently know the dimensions of
the work area, Bar has done some work around that, but I don’t think it’s been
integrated yet)
David Lang
Can we get a test version of the latest changes please
