I have used Mach 3 on 3 other mills/routers. It represents the standard screen configurations that a mill/router would provide the user. Although the maslow is different than a conventional machine(in that it does the x-y calculation in terms of the chain lengths) many of the operation are identical to other machines.
I have posted this pic to illustrate. Is there any discussion or value in considering making the display migrate towards this kind of screen?
The advantages are standard milling operation and cnc look and feel.
Large position readouts(visible from farther away ie when your at the maslow and not at the control)
Step and repeat of entered short sequences of gcode. Re-positioning of cutter quickly with direct gcode entry on the screen
Resetting of x, y, and z zero positions so that specific cut lengths will be with respect to current position (you don’t have to figure out gcode delta x and y)
Just thought I would introduce the concept. As I understand the code better, this would not be an operational change, but more a reworking of the UIElements chosen to display/activate certain component controls, and their size and placement on the screen.
The gcode editor built-in might be some work, but all that is really need is a text entry box and a button that appends to local default file with save and load by name functions.
Maybe there is a discussion on look and feel, but I bring it up for discussion.
The current screen of GC was deliberatly NOT like other CNC machines as those
are intimidating to new users.
The thing we have been talking about it making it so that any g-code sender can
control the maslow.
This would allow everyone to pick the display type they like rather than trying
to make GC satisfy everyone.
Currently, the Maslow is pretty much grbl compatible, but the calibration
currently relies on calculations done in GC. Once it’s calibrated, it’s possible
to run it with a generic g-code sender
GroundControl is constrained by its Kivy roots, but that also makes supporting many platforms using open source tools possible. @madgrizzle has done some interesting exploring with a web-based add-on here.
If you’re looking for a project to make a contribution, look through the issues with the ‘Enhancement’ tag. Nothing as dazzling as a complete user interface remodel there, but several opportunities to make a valuable difference.
Thank you for the feedback. I appreciate your comments. I especially like the idea of any g-code sender being able to interface with different look and feel styles. So the idea would be that setup is done in generic GC, and then after that, other g-code senders would be compatible. That is a great idea!!
Thanks blurfl for the link to the beginners tips page. I will come up to speed on how the guts work.
I think your group has come up with a tremendous tool. Can’t say enough good things about the Maslow concept.
To expand on that, if someone we’re to pick up from @madgrizzle’s web interface and add a web version of the ‘Automatic Chain Calibration’ tool, the generic GC really wouldn’t be needed except for initial setup or a major reconfiguration.
All of the work in the Actions/AutomaticChainCalibration is done through G codes and B codes that are already present. The web page needs to fill in the distances (constants) to move into the gcodes for the different sprocket-rotate buttons and send them, then send the closing B codes when the ‘Set zero’ is clicked.
Doing the full calibration on a web page is a much bigger task, would require R/W access to GroundControl.ini as well. Little steps…
All of the work in the Actions/AutomaticChainCalibration is done through G
codes and B codes that are already present. The web page needs to fill in the
distances (constants) to move into the gcodes for the different
sprocket-rotate buttons and send them, then send the closing B codes when the
‘Set zero’ is clicked.
the actual measurements are entered into GC, then GC does a bunch of
calculations and sends the resulting settings to the firmware.
a new B code (or a couple) would be needed to allow the actual measurements to
be sent to the firmware and to have the firmware do the calculations.
Doing the full calibration on a web page is a much bigger task, would require R/W access to GroundControl.ini as well. Little steps…
doing it in firmware would also require that we not override the firmware if the
firmware and groundcontrol.ini don’t agree.
I see, you’re talking about the full initial calibration, I’m talking about re-calibrating the chains by setting the sprockets and extending the chains - it’s a subset of the whole but much more frequently used one.
we’re to pick up from