synman
Feature: Inputfields for undefined GRBL IDs
See enclosed picture; GRBL setting ID 33 is in my case the triggervalue for the G-shock. However, in other systems, this can be a different value, thats why it is uncommented by default.
It would be a great feature if it was an inputfield, so people can manually document these exceptions for their setup
you can override this today if you'd like by a simple edit to grbl_settings.txt
https://github.com/synman/Octoprint-Bettergrblsupport/blob/master/octoprint_bettergrblsupport/static/txt/grbl_settings.txt
just keep in mind every time I push a new release any customization you've applied to ./oprint/lib/pythonX.X/site-packages/octoprint_bettergrblsupport/static/txt/grbl_settings.txt will be overwritten.
I'm thinking through how to manage this better.
lol.... yeah, that covers it functionally... I still have to figure out how to actually manage it behind the scenes. I keep grbl_settings.txt in sync with GRBL. Allowing it to be editable deviates from the protocol (purist perspective). So yeah, it's a bit of refactoring for something I never expected to pop up as an enhancement request.
GRBL is so loosely implemented though, I have to say at this point I'm not all that surprised.
and wouldn't you know it, with a recent controller board upgrade I performed on my laser engraver (32 bit Black-n-Blue) I am now faced with a similar challenge myself.
Apparently, the BnB has a ton of undocumented settings.
For me, these additional $ settings are pure gibberish and incoherent. I honestly have no idea what the firmware author was thinking and he will not provide any explanations as to what he was thinking / trying to accomplish.
there should no longer be ANY grbl flavor errors, alarms, and/or settings that are not captured by the plugin. At this point I have synced up all known variations across core Grbl 1.1, Grbl_Esp32, GrblHAL, and FluidNC.