[GH-ISSUE #1139] [Feature]: Macros and Terminal view #819

New issue

Open

opened 2026-05-07 00:14:03 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-07 00:14:03 +02:00

Owner

Originally created by @Keybored02 on GitHub (Apr 26, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1139

Originally assigned to: @Keybored02 on GitHub.

Problem or Use Case

I have been experimenting with ways to include a Klipper-inspired macro support, with a dedicated terminal view. I would like to report back on few aspects and gather some feedback before continuing. I'm going to focus on the workflow aspect more than the technical one.

Proposed Solution

Macros

Currently, macros are implemented on top of the Jinja2 language, similarly to what Klipper does. This allow logic handling that goes beyond simple Gcode commands:

Macros are not all defined in dedicated file, but instead are all saved in DB directly. This is mostly due to the fact that unlike Klipper, Bambuddy does not have a strong file-based flow, but relies mostly on DB instead.
The current UI shows a dedicated item per each macro. Item name is the macro name, which is also the function call name. It has to be unique.

Each Macro can be expanded to show a code editor, specific settings, and a run history of that macro.

A macro that includes sub-macros would need all the child functions to be defined individually. This works fine for small setups with quickly falls off for more complex functions. I would probably rework this aspect

Should definitions be moved to a .cfg file and parsed/handled in the UI like Klipper does? This means:

No per-macro editor: add instead a file explorer and single entry point editor common to all
Parse the file separately, add macros to DB after parsing
Allow a single file to contain multiple macro definitions (after a prefix like [gcode_macro])

Macros can be triggered from multiple points:

Manual trigger
WebHook
Schedule (cron-style)
Embedded in the gcode file (when it archives a print (at print start), it scans the gcode for ; MACRO: name comment lines. Any macros found are triggered after archiving completes)

What other sources would be handy to have?

Terminal

A Terminal page allows to quickly run commands and macros. It allows target machine selection with @printer_name, or global with @ all. When set on a single printer, it shows the progress of macros running for that machine.

A dedicated Terminal page isn't really the best option. It would make sense to relegate it to an icon at the top of Printers to access a global terminal, and a second button on each printer card to launch a terminal aimed at that printer.

Thoughts on this?

Parameters

Commands can be:

Standard G-code (from an approved whitelist)
Built-in system commands (AMS_DRYING, NOTIFY, WAIT, etc.)
Jinja2 template logic (conditionals, loops, variables)
Calls to other macros

The built-in system commands are essentially API wrappers for existing BB functions. This could still use some polishing and a better auto-import flow. I'm still not sure how to integrate this aspect of macro execution with the current backend. This will need a dedicated discussion.

Additional considerations

These are probably the most important questions:

It is not currently possible to hijack gcode execution while printing, as the printer FW blocks any injection request while printing. So any macro aimed at a pause at layer, on tool change (if not slicer-defined) or any similar action is not permitted.
Gcode commands are still not fully mapped. I am currently trying to piece together a reference list, but vendor- and printer-specific commands will still need (dangerous) testing. Some likely across all models. Some functions will remain off limits as they are undiscoverable.
Current gcode sender is not tightly integrated with printer status. This will result in silent command fails, missed error states, and overall no guards on send. I do not have a solution for this.
Allowing macros would be a huge change in the philosophy that BB has towards direct control. Discussion absolutely needed.

I'm glossing over a lot on how commands are parsed, gcodes whitelisted, sent, errors collected, and how everything integrates with the backend for scheduling and execution. This is mostly due to the already huge scope of the feature.

I would like to hear feedbacks on the concept before I move forward.

Alternatives Considered

No response

Feature Category

Other

Priority

Would improve my workflow

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @Keybored02 on GitHub (Apr 26, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1139 Originally assigned to: @Keybored02 on GitHub. ### Problem or Use Case I have been experimenting with ways to include a Klipper-inspired macro support, with a dedicated terminal view. I would like to report back on few aspects and gather some feedback before continuing. I'm going to focus on the workflow aspect more than the technical one. ### Proposed Solution ### Macros Currently, macros are implemented on top of the Jinja2 language, similarly to what Klipper does. This allow logic handling that goes beyond simple Gcode commands: <img width="581" height="311" alt="Image" src="https://github.com/user-attachments/assets/97f883b7-aa01-4aa2-ad5a-587402385c61" /> Macros are not all defined in dedicated file, but instead are all saved in DB directly. This is mostly due to the fact that unlike Klipper, Bambuddy does not have a strong file-based flow, but relies mostly on DB instead. The current UI shows a dedicated item per each macro. Item name is the macro name, which is also the function call name. It has to be unique. <img width="1640" height="517" alt="Image" src="https://github.com/user-attachments/assets/9c12e58e-7aa2-4f0b-a270-1b488475bd39" /> Each Macro can be expanded to show a code editor, specific settings, and a run history of that macro. <img width="1634" height="974" alt="Image" src="https://github.com/user-attachments/assets/a5e4ddce-ada1-4b44-941a-8d17fe32803c" /> A macro that includes sub-macros would need all the child functions to be defined individually. This works fine for small setups with quickly falls off for more complex functions. I would probably rework this aspect **Should definitions be moved to a .cfg file and parsed/handled in the UI like Klipper does?** This means: - No per-macro editor: add instead a file explorer and single entry point editor common to all - Parse the file separately, add macros to DB after parsing - Allow a single file to contain multiple macro definitions (after a prefix like [gcode_macro]) Macros can be triggered from multiple points: - Manual trigger - WebHook - Schedule (cron-style) - Embedded in the gcode file (when it archives a print (at print start), it scans the gcode for `; MACRO: name` comment lines. Any macros found are triggered after archiving completes) **What other sources would be handy to have?** ### Terminal A Terminal page allows to quickly run commands and macros. It allows target machine selection with @printer_name, or global with @ all. When set on a single printer, it shows the progress of macros running for that machine. <img width="1636" height="895" alt="Image" src="https://github.com/user-attachments/assets/15f73564-f9ac-45a1-b45d-dcb5b8b251f0" /> A dedicated Terminal page isn't really the best option. It would make sense to relegate it to an icon at the top of Printers to access a global terminal, and a second button on each printer card to launch a terminal aimed at that printer. **Thoughts on this?** ### Parameters Commands can be: - Standard G-code (from an approved whitelist) - Built-in system commands (`AMS_DRYING`, `NOTIFY`, `WAIT`, etc.) - Jinja2 template logic (conditionals, loops, variables) - Calls to other macros The built-in system commands are essentially API wrappers for existing BB functions. This could still use some polishing and a better auto-import flow. I'm still not sure how to integrate this aspect of macro execution with the current backend. This will need a dedicated discussion. ### Additional considerations These are probably the most important questions: 1. It is not currently possible to hijack gcode execution while printing, as the printer FW blocks any injection request while printing. So any macro aimed at a pause at layer, on tool change (if not slicer-defined) or any similar action is not permitted. 2. Gcode commands are still not fully mapped. I am currently trying to piece together a reference list, but vendor- and printer-specific commands will still need (dangerous) testing. Some likely across all models. Some functions will remain off limits as they are undiscoverable. 3. Current gcode sender is not tightly integrated with printer status. This will result in silent command fails, missed error states, and overall no guards on send. I do not have a solution for this. 4. Allowing macros would be a huge change in the philosophy that BB has towards direct control. Discussion absolutely needed. I'm glossing over _a lot_ on how commands are parsed, gcodes whitelisted, sent, errors collected, and how everything integrates with the backend for scheduling and execution. This is mostly due to the already huge scope of the feature. I would like to hear feedbacks on the concept before I move forward. ### Alternatives Considered _No response_ ### Feature Category Other ### Priority Would improve my workflow ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested