Newb question: Got some Xtension Limit switches installed on my two axis machine and have been trying to figure out homing. When I press the homing button nothing happens (or moves) and an alert flashes about 20 seconds later (see below). A few folks have made references (in other posts) to firmware settings that I can't seem to access through the Control software. The closest I get is the troubleshooting tab and in the UI where it says "OFF" next to each parameter kinda behave like buttons but when I press them (presumably because they toggle to "ON") nothing happens. Is this the designed behavior? or is there somewhere else I can modify firmware settings? Thanks.
that reads the output of the in-compiled parameters from the firmware (cant be changed) Refer to gnea/grbl about two thirds down: To change those you have to recompile grbl, for example, the first one "V Variable spindle enabled" to disable it you have to go to gnea/grbl and comment out "#define VARIABLE_SPINDLE // Default enabled. Comment to disable." Then recompile and upload
The "not doing anything" is grbl moving the non existant Z axis first to clear the workpiece before doing XY moves... Refer to gnea/grbl (which we already did for you see below, but do read it so you understand it - Grbl wiki holds all the answers (; you could ever want) Luckily you dont need to recompile, we already did that one for you (2 axes machines = our Acros): Wizards and Tools > Grbl Flashing tool > 2 Axes
@Peter Van Der Walt It's Homing! Super helpful thank you. As an entry level user (that happens to have 2 decades of professional UI/UX Design experience) I can't help but to pass on a couple pieces of subtle feedback in case they haven't been considered: Most of the status indicators on the troubleshooting tab have a hover state which is an interaction paradigm that is misleading (since they aren't intended to be click on). I would recommend simply removing the hover state so it does not imply that they can be interacted with. The UI is so clean which makes clutter more obvious. If the firmware is configured by the user for 1 or 2 axes why not remove the UI features for the unused axis? This would also be good visual reinforcement of the active configuration especially if a user interfaces with different machines regularly. Thanks again. The journey continues.
Three reasons: 1. a very strict "User doesnt have to configure anything" policy - so we show/react/automate only from information we CAN retrieve without asking the user anything (feedback from Grbl mostly - see gnea/grbl) and 2. You'll notice Grbl doesnt have any feedback on whether z axis homing is enabled or not (; - nothing to react to. - flash the 2 axes plus RC Servo image and notice how the Pen/Up down buttons suddenly get added - refer to gnea/grbl to see what is available in the feedback for us to work with 2a (And sure we can add our own to our own fork of Grbl, but we highly prefer STOCK grbl as far as possible) and 3. There's all kinds of folks in the community - building all kinds of machines. We actually have users who disable Z homing (relying on probe, and avoiding G53 moves in Z) - still using G53 in XY (for offsets to plate out a job into fixtures) and yet, still have a working Z axis, even though they dont Home Z - Got to cater for them too Default behaviour of Metro 4 Components Library
Could use something like this... a bit heavy handed compared to what you're using but this more semantic (at least to the degree that metro enables). Code: <span class="px-1 py-1 bg-red fg-white rounded d-inline-block" id="enVariableSpindle">OFF</span>