Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Inputfields for undefined GRBL IDs #39

Closed
ImagineerNL opened this issue Oct 16, 2021 · 9 comments
Closed

Feature: Inputfields for undefined GRBL IDs #39

ImagineerNL opened this issue Oct 16, 2021 · 9 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Milestone

Comments

@ImagineerNL
Copy link

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
Copy link
Owner

synman commented Dec 7, 2021

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

@synman synman added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Dec 7, 2021
@ImagineerNL
Copy link
Author

Works for me :)
thx

@synman
Copy link
Owner

synman commented Dec 13, 2021

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
Copy link
Author

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

@synman
Copy link
Owner

synman commented Dec 13, 2021

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
Copy link
Owner

synman commented Jan 20, 2022

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
Copy link
Author

So that means you will implement this feature? :)

@synman
Copy link
Owner

synman commented Feb 1, 2022

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
Copy link
Owner

synman commented Dec 27, 2022

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.

@synman synman closed this as completed Dec 27, 2022
@synman synman added this to the 2.3.0 milestone Dec 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants