Feature: Inputfields for undefined GRBL IDs about octoprint-bettergrblsupport

[synman]

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

[ImagineerNL]

Works for me :)
thx

[synman]

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.

[ImagineerNL]

well, by making it an inputfield for the 'none' values :)

[synman]

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.

[synman]

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.

[ImagineerNL]

So that means you will implement this feature? :)

[synman]

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.

[synman]

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.