[GH-ISSUE #422 ] [Feature]: Add Auto-Print GCODE Injections #264

Owner

Originally created by @piatho-1 on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/422

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

There are various 3rd party solutions on the market that allow to automate printing by adding certain G-Code that 1) allow the print bed to be loosen
2) cool down
2) allow the print head to act as a pushed
3) blocks zones of the print bed that have to stay clear.

Providers known are: Farmloop, Swapmod, AutoClear, Printflow 3d

Proposed Solution

When uploading a file or when assigning to a queue, i would propose to add a setting to activate/deactivate autoprint. If activated, some further settings shall become available. Eg Auto-Restart: yes/no, Cooldown yes/no, Type of print automatization.

Based on the settings some templates shall be shown to the user in a Code editor UI. Users shall be allowed to edit

Finally, GCODE of the file shall be updated with the additional G-CODE

Alternatives Considered

No response

Feature Category

File Manager

Priority

Would improve my workflow

Mockups or Examples

See https://simplyprint.io/features/autoprint for some inspiration

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 @piatho-1 on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/422 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case There are various 3rd party solutions on the market that allow to automate printing by adding certain G-Code that 1) allow the print bed to be loosen 2) cool down 2) allow the print head to act as a pushed 3) blocks zones of the print bed that have to stay clear. Providers known are: Farmloop, Swapmod, AutoClear, Printflow 3d ### Proposed Solution When uploading a file or when assigning to a queue, i would propose to add a setting to activate/deactivate autoprint. If activated, some further settings shall become available. Eg Auto-Restart: yes/no, Cooldown yes/no, Type of print automatization. Based on the settings some templates shall be shown to the user in a Code editor UI. Users shall be allowed to edit Finally, GCODE of the file shall be updated with the additional G-CODE ### Alternatives Considered _No response_ ### Feature Category File Manager ### Priority Would improve my workflow ### Mockups or Examples See https://simplyprint.io/features/autoprint for some inspiration ### 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

BreizhHardware

closed this issue
added the
enhancement
label

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Feb 20, 2026):

Before we commit to building this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

@maziggy commented on GitHub (Feb 20, 2026): Before we commit to building this, I'd like to gauge community interest. If you'd find this feature useful, please give this issue a thumbs up (👍) reaction so we can prioritize accordingly.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 16, 2026):

From my point of view, the GCODE injections should be done on the queue and not the printers page. It's dealing with automated printing and not with manual prints.

What's about:

Adding the required settings to settings page
Add a toggle to the print and schedule modal to enable/disable the GCODE injection

Does that makes sense?

@maziggy commented on GitHub (Mar 16, 2026): From my point of view, the GCODE injections should be done on the queue and not the printers page. It's dealing with automated printing and not with manual prints. What's about: - Adding the required settings to settings page - Add a toggle to the print and schedule modal to enable/disable the GCODE injection Does that makes sense?

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Mar 19, 2026):

I lost a bit focus here, but i do agree that this feature makes sense on the queue since it helps automating the process of auto-starting new prints if previous prints are completed.

If we add the feature to the print queue it should allow the following

allowing to configure machine code for various "plate swap/plate clean" concepts to be maintained in the settings. If you have multiple printers, multiple snippets need to be maitainable per printer model
Add a toggle to the popup for queue assignment - this needs to be printer specific
- toggle 1: Add auto-print machine code
- toggle 2: Activate lights-out automatisation (if toggled off, i would expect the operator to confirm that plate is empty for testing purpose)
Optional preview of the adjusted maschine code

Bonus:

to ease the usage, we might want to include features to the settings to allow the user to customize the maschine code snippets eg to set a specific timeout before the plate clear should happen or a specific bed temperature

@piatho commented on GitHub (Mar 19, 2026): I lost a bit focus here, but i do agree that this feature makes sense on the queue since it helps automating the process of auto-starting new prints if previous prints are completed. If we add the feature to the print queue it should allow the following - allowing to configure machine code for various "plate swap/plate clean" concepts to be maintained in the settings. If you have multiple printers, multiple snippets need to be maitainable per printer model - Add a toggle to the popup for queue assignment - this needs to be printer specific - toggle 1: Add auto-print machine code - toggle 2: Activate lights-out automatisation (if toggled off, i would expect the operator to confirm that plate is empty for testing purpose) - Optional preview of the adjusted maschine code Bonus: - to ease the usage, we might want to include features to the settings to allow the user to customize the maschine code snippets eg to set a specific timeout before the plate clear should happen or a specific bed temperature

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Mar 19, 2026):

Got it.

@maziggy commented on GitHub (Mar 19, 2026): Got it.

BreizhHardware commented

Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=g+code#auto-print-g-code-injection

Author

Owner

@maziggy commented on GitHub (Apr 5, 2026):

Available/Fixed in branch dev and available with the next release or daily build.

Unfortunately I'm currently not able to test. May I ask you please to give it a try and let me know if it's working for you?

@maziggy commented on GitHub (Apr 5, 2026): Available/Fixed in branch dev and available with the next release or daily build. Docs -> https://wiki.bambuddy.cool/features/print-queue/?h=g+code#auto-print-g-code-injection Unfortunately I'm currently not able to test. May I ask you please to give it a try and let me know if it's working for you?

BreizhHardware commented

Author

Owner

@pleite commented on GitHub (Apr 5, 2026):

I can test and let you know in a couple of days.

There is a caveat, most injection code should not be at the start and end of the original gcode, there is a specific location after print initialization that would make sense and in the end of print it's quite dependent on the code intention.

As most systems allow the code to be injected by the slicer, validation of the code presence would also be required.

I couldn't read on the docs what happens to make the next print be started without manual intervention, what is the expectation of the feature?

On queuing, the injection usually needs to be at all plates, for example the start code may load a plate if not yet loaded, can't start only on second print. For the choice of plates allowing to select quantities of each would also make sense, being able to reorder or cancel later.

I'm not a fan of the injection here, as the tool has no slicer, but rather have the proper machine code on the gcode file.

In order to solve remotely problems that may rise when cancelling prints, executing the start or end code on demand would be beneficial. As such, having the code snippets as part of a library and choosing those and allowing separate execution would be very helpful. For example allowing a Z screw movement pattern to lube

@pleite commented on GitHub (Apr 5, 2026): I can test and let you know in a couple of days. There is a caveat, most injection code should not be at the start and end of the original gcode, there is a specific location after print initialization that would make sense and in the end of print it's quite dependent on the code intention. As most systems allow the code to be injected by the slicer, validation of the code presence would also be required. I couldn't read on the docs what happens to make the next print be started without manual intervention, what is the expectation of the feature? On queuing, the injection usually needs to be at all plates, for example the start code may load a plate if not yet loaded, can't start only on second print. For the choice of plates allowing to select quantities of each would also make sense, being able to reorder or cancel later. I'm not a fan of the injection here, as the tool has no slicer, but rather have the proper machine code on the gcode file. In order to solve remotely problems that may rise when cancelling prints, executing the start or end code on demand would be beneficial. As such, having the code snippets as part of a library and choosing those and allowing separate execution would be very helpful. For example allowing a Z screw movement pattern to lube

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 15, 2026):

Still waiting for feedback from you guys.

@maziggy commented on GitHub (Apr 15, 2026): Still waiting for feedback from you guys.

BreizhHardware commented

Author

Owner

@pleite commented on GitHub (Apr 15, 2026):

It's not easy testing and checking the output.
The end code works for my Swapmod. Combined with the not asking to clear the plate. The start code on my case is not working correctly as it's placed before the printer startup.
Technically your code is correct.

@pleite commented on GitHub (Apr 15, 2026): It's not easy testing and checking the output. The end code works for my Swapmod. Combined with the not asking to clear the plate. The start code on my case is not working correctly as it's placed before the printer startup. Technically your code is correct.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 16, 2026):

The start code on my case is not working correctly as it's placed before the printer startup.

What's the correct position?

@maziggy commented on GitHub (Apr 16, 2026): > The start code on my case is not working correctly as it's placed before the printer startup. What's the correct position?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 19, 2026):

?

@maziggy commented on GitHub (Apr 19, 2026): ?

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 22, 2026):

@piatho-1 ?

@maziggy commented on GitHub (Apr 22, 2026): @piatho-1 ?

BreizhHardware commented

Author

Owner

@piatho commented on GitHub (Apr 22, 2026):

@piatho-1 ?

I am currently not using autoprint on my farm since my current print models do not reliable loosen from the plate. I thus cannot test at the moment

@piatho commented on GitHub (Apr 22, 2026): > [@piatho-1](https://github.com/piatho-1) ? I am currently not using autoprint on my farm since my current print models do not reliable loosen from the plate. I thus cannot test at the moment

BreizhHardware commented

Author

Owner

@DevScarabyte commented on GitHub (Apr 27, 2026):

I have been playing around and doing some testing with my gcode that sets the ending height based off the z layer of the print. In the slicer it sets this value once exporting the sliced file. When using the injected gcode it does not seem to use the max_layer_z or max_print_height values.

Using this snippet at the end code to see how its handled then printed a 30mm and 60mm tall cube. Both ended up at Z1 at the top. Setting a printer end code for the same printer that could be printing different heights can cause issues with the print either being directly at the bottom or top for cooling the plate or pushing the top glass+AMS up due to it being to high up. The sweeping to push the print off the bed can also cause damage as the print will be at Z1 instead of whatever Z you set it for.

max_layer_z can be found in the header section of the gcode file being edited could be used to modify the injected gcode before committing to the 3mf. Example of mine included at the bottom.

Prusa has a list of some that can be used.

; Slicer custom variable with plate max z layer
G1 Z{max_layer_z} F600 ; Set Z to max layer height

; HEADER_BLOCK_START
; BambuStudio 02.06.00.51
; model printing time: 1h 24m 30s; total estimated time: 1h 26m 18s
; total layer number: 80
; total filament length [mm] : 12155.34
; total filament volume [cm^3] : 29237.03
; total filament weight [g] : 36.55
; model label id: 109,120
; object max height: 16.00,13.00
; filament_density: 1.25
; filament_diameter: 1.75
; max_z_height: 16.00
; filament: 1
; HEADER_BLOCK_END

@DevScarabyte commented on GitHub (Apr 27, 2026): I have been playing around and doing some testing with my gcode that sets the ending height based off the z layer of the print. In the slicer it sets this value once exporting the sliced file. When using the injected gcode it does not seem to use the max_layer_z or max_print_height values. Using this snippet at the end code to see how its handled then printed a 30mm and 60mm tall cube. Both ended up at Z1 at the top. Setting a printer end code for the same printer that could be printing different heights can cause issues with the print either being directly at the bottom or top for cooling the plate or pushing the top glass+AMS up due to it being to high up. The sweeping to push the print off the bed can also cause damage as the print will be at Z1 instead of whatever Z you set it for. max_layer_z can be found in the header section of the gcode file being edited could be used to modify the injected gcode before committing to the 3mf. Example of mine included at the bottom. [Prusa](https://help.prusa3d.com/article/list-of-placeholders_205643) has a list of some that can be used. ``` ; Slicer custom variable with plate max z layer G1 Z{max_layer_z} F600 ; Set Z to max layer height ``` ``` ; HEADER_BLOCK_START ; BambuStudio 02.06.00.51 ; model printing time: 1h 24m 30s; total estimated time: 1h 26m 18s ; total layer number: 80 ; total filament length [mm] : 12155.34 ; total filament volume [cm^3] : 29237.03 ; total filament weight [g] : 36.55 ; model label id: 109,120 ; object max height: 16.00,13.00 ; filament_density: 1.25 ; filament_diameter: 1.75 ; max_z_height: 16.00 ; filament: 1 ; HEADER_BLOCK_END ```

BreizhHardware commented

Author

Owner

@DevScarabyte commented on GitHub (Apr 27, 2026):

The start code on my case is not working correctly as it's placed before the printer startup.

What's the correct position?

In my gcode after slicing this is the line directly after the printer start code.

; MACHINE_START_GCODE_END

Would probably inject the code right before this as this starts the filament gcode then printing gcode from what I can tell.

@DevScarabyte commented on GitHub (Apr 27, 2026): > > The start code on my case is not working correctly as it's placed before the printer startup. > > What's the correct position? In my gcode after slicing this is the line directly after the printer start code. `; MACHINE_START_GCODE_END` Would probably inject the code right before this as this starts the filament gcode then printing gcode from what I can tell.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 27, 2026):

Start g-code was injected in the wrong place

You were right — it was being prepended to the whole plate_X.gcode, so it ran before the printer's own bed heat / homing / nozzle prime. It now anchors at ; MACHINE_START_GCODE_END (exactly the line @DevScarabyte called out), so the snippet lands where a slicer-side custom-start-gcode would. Older files without that marker keep the prepend behaviour as a fallback with a warning log.

{max_layer_z} and friends now actually substitute

This was the safety-relevant one — G1 Z{max_layer_z} was being sent verbatim, the firmware parsed it as Z1, and the head crashed into tall prints. Snippets now go through a placeholder pass that reads the values from the 3MF's ; HEADER_BLOCK_START..END block before injection. Supported placeholders:

{max_layer_z} / {max_print_height} — top-layer Z, in mm
{total_layer_number} / {total_layers}
{total_filament_weight}, {total_filament_length}
Any other key from the 3MF header is also addressable directly (lowercased, spaces -> underscores, [units] stripped)

Unknown placeholders are left in the snippet verbatim with a warning log — a typo never silently expands to an empty string.

Wiki page updated with the placeholder list and a safety callout for {max_layer_z}: https://wiki.bambuddy.cool/features/print-queue/#placeholders

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now.

@maziggy commented on GitHub (Apr 27, 2026): 1. Start g-code was injected in the wrong place You were right — it was being prepended to the whole plate_X.gcode, so it ran before the printer's own bed heat / homing / nozzle prime. It now anchors at ; MACHINE_START_GCODE_END (exactly the line @DevScarabyte called out), so the snippet lands where a slicer-side custom-start-gcode would. Older files without that marker keep the prepend behaviour as a fallback with a warning log. 2. {max_layer_z} and friends now actually substitute This was the safety-relevant one — G1 Z{max_layer_z} was being sent verbatim, the firmware parsed it as Z1, and the head crashed into tall prints. Snippets now go through a placeholder pass that reads the values from the 3MF's ; HEADER_BLOCK_START..END block before injection. Supported placeholders: - {max_layer_z} / {max_print_height} — top-layer Z, in mm - {total_layer_number} / {total_layers} - {total_filament_weight}, {total_filament_length} - Any other key from the 3MF header is also addressable directly (lowercased, spaces -> underscores, [units] stripped) Unknown placeholders are left in the snippet verbatim with a warning log — a typo never silently expands to an empty string. Wiki page updated with the placeholder list and a safety callout for {max_layer_z}: https://wiki.bambuddy.cool/features/print-queue/#placeholders Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you now.

BreizhHardware commented

Author

Owner

@DevScarabyte commented on GitHub (Apr 29, 2026):

Tested the end code and it worked perfectly. Don't currently have anything for the custom start code to test.

@DevScarabyte commented on GitHub (Apr 29, 2026): Tested the end code and it worked perfectly. Don't currently have anything for the custom start code to test.

BreizhHardware commented