Request to add “Lathe Keyway Cycle (M800)” to Third‑Party Plugins (plugins_init.h)

[ennio64]

Hello,

I have developed a new third‑party plugin for grblHAL named Lathe Keyway Cycle (M800).

The plugin provides a parametric keyway machining cycle for lathes, including multi‑pass logic, safe return modes, validation, and planner integration.
It follows the official plugin guidelines and requires only a minimal planner patch (documented in the repository).

Repository
https://github.com/ennio64/grblHAL-plugin-M800

Request
Since third‑party plugins must be added to plugins_init.h by the core maintainer, I kindly request evaluation and, if appropriate, inclusion of:

c
#if LATHE_KEYWAY_CYCLE_ENABLE
extern void lathe_keyway_cycle_init (void);
lathe_keyway_cycle_init();
#endif
Notes
The plugin is self‑contained and documented.

Pre‑patched GRBLHAL files (version VER:1.1f.20251207) are included for convenience.

No core modifications are required except the optional planner extension (fully backward‑compatible).

Thank you for your consideration.

Best regards,
Ennio SESANA

[terjeio]

There are some issues that should be addressed/fixed:

1. Call plan_data_init() to set default values for your plan_line_data_t structs. If not your code may cause a crash.
2. Do not use the N-word, it is a single-meaning word and is reserved for line numbers. The L-word is usually used for repeats.
3. The F-word is also a single-meaning word, used to set the modal feed rate. Trapping it to set a local feed rate may confuse users. Let the core set the feed rate and use that (gc_state.feed_rate) instead.
4. Return the appropriate status code when relevant instead of a message followed by Status_InvalidStatement.
5. Select parameter words so that the routine can optionally be added as a macro to be run from a SD card? These are allowed for macros. And take a look at G76 for which to use?
6. I do not understand the reason for patching the core. Did the rapid_motion condition flag fail when set in the plugin?
7. The src directory is not generally available, the plugin should be placed in a directory at the same level as grbl.
8. Provide a CMakeLists.txt file like for other plugins, this is needed for the RP2040 driver and the Web Builder.

[ennio64]

Thank you for the detailed feedback.
I will work on the required changes.
Happy New Year.

[ennio64]

Thank you for the review and guidance.
The plugin has now been fully refactored to comply with all GRBLHAL requirements.

All plan_line_data_t structures are initialized with plan_data_init().
The N‑word is not used, L is used only for repetitions, and the F‑word is handled by the core (gc_state.feed_rate).
Validation returns only status codes, without mixed messages.
The parameter set should be compatible with macro/SD execution, as it avoids reserved letters and follows the allowed word set for user‑defined macros. In any case, I needed to assign meaningful letters to the cycle parameters, so the chosen mapping balances clarity, availability, and GRBLHAL conventions.
All planner patches have been removed; rapid_motion works correctly through standard GRBLHAL mechanisms.
The plugin is placed at the same level as the grbl directory, and a proper CMakeLists.txt is provided following the style of official plugins.

The build is clean, and the plugin works correctly on the hardware I tested (STM32F4xx driver, environment blackpill_f411ce_alt2).

[terjeio]

Happy New Year.

FYI I will add the plugin to plugins_init.h in the next commit - likely at the end of January.