Open petervanderwalt opened 1 year ago
grblHAL has a 10%-200% range:
https://github.com/grblHAL/core/blob/e2ba6db69cda9d7ab664c3d4bbce0c1737b81768/grbl.h#L166-L167
Removing the limits completely is IMO not a good idea, at least 0% may have side effects. Increasing beyond 999% may cause problems for senders that has allocated 3 digits in the UI? I can change the limits and make the settings overridable via compile time #defines, but have to change the variables/parameters from 8bits to 16 or 32 first (16 should be enough).
1-999% works for us (:
Thanks for considering! (:
I have added overrides for the override definitions for the BlackBox X32 in the latest commit. I think I will add an option to select some ranges for builds created by the Web Builder and leave the current default values as-is.
Thank you! I like the Web Builder idea too!
When grbl introduced realtime commands, the Feed Override was established with that 50-200% range Would it be possible to remove that limitation - at the end of the day the Max Rate will still limit someone doing something stupid, but sometimes if you CAM up too conservatively, even a 200% override is not enough. Especially for newer users just learning the hobby, they tend to CAM work up too slowly and as they learn to listen out the cut and use overrides to develop a feel, that 200% upper limit sometimes gets in the way. On the Laser side we often see users setting feedrates too high though, and the 50% limit stop them from dialing it back slow enough. etc Removing the limits (even if as a configuratble option) would allow for a little more freedom to explore feedrate overrides to the extreme.