Hi all,
For work, I regularly print a wide range of PLA models in series. My usual workflow is to carefully slice all models in advance, upload them to the printer, and then—when I’m in the lab—simply select what I need from the printer’s display (or from Bambu Studio without re-slicing), pick the filament from the connected AMS units, start the print, and walk away. This works perfectly with my X1C machines.
With the H2D, though, this workflow is broken.
There’s no way—neither from Bambu Studio nor directly from the printer screen—to select which nozzle to use, and therefore no way to pick the AMS and filament. As far as I can tell, the machine locks the job to the nozzle used during slicing, and you can’t override it. You must print with that specific nozzle and the materials attached to it. That’s, in my opinion, both a frustrating and counterproductive limitation.
I hope this gets addressed soon, because it really affects my daily work.
Yes, I know I could physically swap AMS units between nozzles, but seriously—that’s incredibly tedious on a high-end, advanced machine that’s supposed to simplify our job, not complicate it.
Just to clarify: I’m running the latest versions – Bambu Studio 2.1.1.52, firmware 01.01.02.08 – so this is not due to outdated software.
Below is an example of how the two nozzles and their associated filaments are not handled properly when printing a model from the printer’s internal memory or from USB.
@insanesoul1978
You can select the nozzle by hovering the “Slice Plate” button and selecting “custom mode”:
Once you hit “Slice Plate” afterwards, it will bring up what’s in the second screenshot. Hitting the middle “<>” button will swap the nozzle being used (or drag and drop as it says). Then you can select the filament you want in the screenshot you posted.
I do find it easier to just change whatever im printing to use the filament I want ahead of time from the filament selection on the right, that way its just tied to the ams I want anyway.
It’s simply impossible by the way a multi tool head machine works. Switching the tool head changes EVERYTHING and it can only be done in the slicer. With simple gcode it’s very hard and pointless to realise what you proposed.
You can still choose between the filaments in the same ams.
There’s no point of buying a car and blaming it cannot follow you home just like your horse did.
What you are doing is send the files sliced to the machine, so the gcode can’t be changed how you want, needs to slice again, you had two options, change the ams like you said (this is how someone managed your same problem ) or upload your proyect to your makerworld account, private mode, and then slice and print from there just changing ams and nozzles while keeping all the parameters of the proyect (from handy or another bambu studio)
And for those saying it’s the G-code’s job to define the nozzle – no, it’s not.
First, the G-code is already on the USB stick.
Second, it doesn’t need to. The printer firmware should decide at the time of printing which nozzle (E0 or E1) to use. Once one is selected, the print starts on that extruder.
I’ve designed many machines myself over the years – including an IDEX with two heads – and trust me, I never had to re-slice a file just to decide which extruder should run it.
This kind of logic belongs to the firmware, not the G-code.
The firmware should allow the user to choose the extruder (E0 or E1) before printing, especially when the G-code is already stored on the machine or USB. Forcing a re-slice just to swap tools is unnecessary and inefficient.
If even a DIY IDEX setup can handle this gracefully, a premium machine like the H2D should do better.
You’re referring to direct printing from Bambu Studio.
I’m talking about G-code files that are already saved in the printer’s memory.
In that case, your reasoning doesn’t apply.
IDEX has no (built in) toolhead offset. It’s completely upon user configuration and firmware settings to calibrate for the offset. Which is fine, but you build your own IDEX=you are fully responsible and knowledgeable enough for your machine. H2D on the otherhand, basically does the same thing except from the automatic vision based offset settings. It has to watch out for its users.
The problem is that, for what the printer has on its tiny AP board (the pathetic CPU and RAM available), making it being able to scan through the entire gcode to scan for out of bound print lines and other tricky things, is really hard. To solve this they have to add an additional gcode (actually, mcode) to tell the machine that the model is completely printing within the dual nozzle area. So that the slicer can do the scan for the printer and save the tiny CPU it has on printer.
However I bet even if they’re going to do it, it’s probably in the lowest possible priority simply because the use case is far too rare. They still have lots of burning issues to resolve before they can do something like this…
Did your dual head IDEX have GCode that was specific for two different offset extruders on the same head? While it seems technically possible that the machine itself could analyze the gcode file and determine if the print file is outside the bounds for a single nozzle it also doesn’t seem like a feature that would be required at launch.
That said your post comes off quite whiney and very entitled sounding. Like you have the option to return the machine if the old machines work better which I think you should. You do not seem happy about this situation.
So… you want to re-code the print without re-coding the print? Obviously, there’s going to be a problem doing that. That slice has a lot of preparation built in, and to just dumb down the slice for the convenience of willy-nilly switching various options seems like a bridge too far to me.
I don’t think it would be impossible to do, but I’m not sure I’d fund that if I were Bambu. Its a fringe case that will likely need 100+ hours of coding, tuning, and testing and it would add a level of complexity to the firmware that is probably not ideal for future releases.
I don’t see how this is possible. (I’ve a X1CC not a H2) but the AREA that each nozzle has to print to makes a HUGE difference depending upon which nozzle you select for that particular ‘color’ which should actually just be stated as MATERIAL. This is because say you are using a PETG on right side as support and pla in 3colors from AMS. But now your PETG support is in the AMS too. If the support is over on the edge of the right side, it is IMPOSSIBLE to print fully from AMS. Your request will NEVER happen.
Just to reply without getting into an argument with those calling me arrogant or telling me to return the machine — which, frankly, is my own business… — I just want to clarify something, because I think there’s some confusion here.
I never said I want to modify the G-code at runtime — and that’s not what this is about.
There are firmwares like Duet and Klipper (unfortunately I don’t know the specifics of how the H2D is built) that manage start and end print scripts (or macros, call them whatever you want) at runtime, using them into the print pipeline right before and after the G-code stream from the file being printed.
So if (and I stress IF) the H2D supports runtime script handling like Klipper or Duet, this would be very easy to solve.
If, on the other hand, we’re talking about old-school (Marlin-style) scripts that get hardcoded before and after the G-code during slicing, then yes — you’d need to modify the G-code manually, update the extruder (or hotend in this case) references inside, and print from there.
But then I ask:
If it’s possible to change the AMS on the fly before starting a print, why should it be so complicated to select the nozzle — and, by extension, the AMS — to use?
After all, when you switch filament, you don’t have to re-slice the file, right?
And please, don’t bring up nozzle offsets — they have nothing to do with this discussion.
Stay calm, my friend — no need to stress yourself out over nothing.
The build area doesn’t matter here: the slicer doesn’t let you place objects in areas dedicated to specific nozzles.
If you don’t have an H2D, maybe get informed before getting worked up.
And as for the material — it’s the same even today with current printers:
if you have a G-code file that was sliced for PLA, it won’t let you select ABS or PETG because they wouldn’t be compatible with the file stored in memory.
Thanks for the clarification, but I believe the previous points still stand. The ability to change the AMS and filament on the fly is really the problem. The slice is built around the filament being used. To do what you want, it would require the machine to be able to effectively re-slice the file (or at least the pre-print slicing). As J.Lifer said, the filament determines the nozzle, and the nozzle is restrained by the build area.
You are allowed to use the left nozzle all the way to the left, and the same with the right, but if you mean, you could choose not to… Ok. But there we have even more complexity and odd limitations to add, which only confuses people. Also, I don’t think we have even touched on all the issues that could be dependent on that initial slice. Ultimately we are saying, what you want isn’t inline with what Bambu generally offers. BBL printers are the “Easy Button”, not the Burger King “have your way” affair.
I’ll be the first to say, there’s nothing wrong with asking… but I wouldn’t expect a whole lot of traction from this one.
This is an interesting point. Since it’s dual nozzle. I’ve been doing a lot of models that make use of the full build volume I can get out of the one nozzle. If I tried switching to the other nozzle, the model would need to be moved over to the other side of the build plate since it runs past the shared middle zone.
By the way the Bambu machines work, it’s very different from most Klipper machines. I would have no doubt to say that the Bambu machines are dumb controllers glued with glorified but actually very limited computer(ap board). Performance wise, most customised Klipper machines are using sbcs that are so much more powerful than what h2d or x1cs ever had. Klipper supports runtime script while Bambus system is much much more simplified (similar to prusa machines instead of Klipper based machines) and hard coded. Bambu’s design is like an octopus while the Klipper machines are more like monkeys or humans.
H2D’s AP board is using a quad core ARM A7 processor. Arm A7 was announced … 14 years ago.
