Hi, I would like to manually trigger a toolchange on a layer by adding a toolchange to the exported G-code directly. I looked at a generated toolchange G-code and the reference toolchange G-code in the printer settings in Bambu Studio and came up with the below snippet.
Would anyone be able to please tell me if this toolchange code is correct or if you have manually added a filament change in G-code in the past? Thanks.
I replaced the Z offset movements with relative Z moves through G92. M620 SXXA and TXX and M621 SXXA would have XX replaced with the new filament position.
The purpose of this is to automatically add a specific color change a specific layers of 3D topo map models for Bambu users of the 3D map models here. I have some experience with Marlin and made a script to determine the correct places to insert the toolchange and relocate the prime tower. I would run this myself to test but I don’t have a Bambu printer at the moment.
Oh, I am not using painting. I am using the 2 object dice model at Dual Color Die V2 by RobertW - MakerWorld as a multiobject 3MF and assigned them filament 1 and 2.
I was able to get the change filament enabled when I added a simple primitive cube in one color. I then looked at the exported gcode to see what it added. Seems to look similar to my first gcode above.
The filament index specific gcodes where the same as I observed before:
M620 SXXA and TXX and M621 SXXA would have XX replaced with the new filament position.
Painting each model does not work in this case because I have multiple topo map models with many details and each person printing the map would like elevation lines at different places. For example below from someone who did a manual filament change on my map with their P1S at heights (but they also want to add a third color a X height and higher so that is what my script does in addition to isoline contours).
I’ve been working on some similar things relating to amending gcode and colours.
I managed to write a python script that extracts, processes and alters the gcode within the gcode.3mf files that are created from the ‘export all sliced file’ ‘print plate’ option if is it of any use. I presume you must have done something like that in order to get Bambu Studio to preview your amended gcode.
Other thoughts on possibly simpler ways to achieve your ‘different coloured contours’ without altering the gcode are via creating multiple STLs.
Either a) One STL per colour - which are via a script merged or split as required before being imported,
or b) loads of STLs to cover all of the possible layer options - with a script to go through a Bambu Studio project 3mf file to automatically set the correct colours for each of the individual STLs based on input parameters.
I am working on scripts related to both of these options too if you are interested.
Finally it is probably possible to automate the ‘height range’ painting within Bambu Studio - either via a UI macro running on top of Bambu Studio (such as Keyboard Maestro on a Mac), or again patching the Bambu Studio project 3mf files to add in the layer painting externally.
The main part to keep in mind is that BambuStudio generates gcode with Extruder position set to relative mode while the printhead XYZ is absolute mode. This isn’t super clear until I saw M83 being used to set only the extruder to relative mode. Coming from Cura, I’m used to the extruder using absolution mode.
There is still confusion on what the Bambu proprietary gcodes actually do. A couple that I’m not sure about but have guesses for are. M625 Signals the end of a part and a nonprinting portion of code for some Bambu component. M624 Signals the start of a part and has what may be a base64 encoded data after it but it doesn’t seem to be dynamic or anything meaningful at first glance. T255 Switch to no filament selected. T1000 ??? M620.X ? M621.X ?
Some of these gcode obviously relate to triggering a toolchange in the AMS but I don’t have a Bambu myself.
It would be great if Bambu released a description of their proprietary Gcodes so that users understand what the machine is doing. There isn’t any competitive advantage to having mystery gcodes and Bambu would be able to walk the talk on open source by being more transparent about the gcode. As Bambu already uses an open source slicer to generate the Gcode so the mystery gcode functionality resides in the firmware.
M624/M625 is I think something it uses to separate all of the different objects on the plate that can be individually cancelled if they fail during the print. I would imagine within the encoded part is the object Id (from the comment line above in gcode) - on GitHub it says start_str += ("<mark>M624</mark> " + _encode_label_ids_to_base64({ instance_to_print.label_object_id }));
M620’s are I think commands to the AMS. M620 S255 for example unloads the AMS at the end of the print job (there is another thread about this - and I have just created a little script to post process the gcode and comment this line out).
I got the toolchanges on demand working + cross compatible with PrusaSlicer. See below for a map piece that a friend printed with a X1C.
I’m still doing some more testing with users with Bambu printers. I primarily made this script so that people who download my collection of dual color 3D topo maps can add 2 additional colors through isolines and hi-elevation. If anyone wants to be the first to print a 4 color 3D topo of their state, just send me a message.
The processing ended up being pretty involved since I decided to filter recoloring by feature type such as walls, infill, and top surface and needed to rearrange the features to maintain nozzle pressure and optimize toolchanges.
I hope Bambu’s next printer release has a multi-extruder toolchanger for faster and more consistent toolchanges as each color flush adds to the printing time by a minute.
