synman / Octoprint-Bettergrblsupport

Better Grbl Support Plugin for Octoprint based (loosely) on the original Grbl Support plugin developed by mic159
https://github.com/synman/Octoprint-Bettergrblsupport/wiki
64 stars 19 forks source link

Feature: Inputfields for undefined GRBL IDs #39

Closed ImagineerNL closed 1 year ago

ImagineerNL commented 2 years ago

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

image

synman commented 2 years ago

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 commented 2 years ago

Works for me :) thx

synman commented 2 years ago

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 commented 2 years ago

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

synman commented 2 years ago

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 commented 2 years ago

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.

Screen Shot 2022-01-19 at 9 33 58 PM Screen Shot 2022-01-19 at 9 34 14 PM Screen Shot 2022-01-19 at 9 34 22 PM
ImagineerNL commented 2 years ago

So that means you will implement this feature? :)

synman commented 2 years ago

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 commented 1 year ago

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.