It seems really short sighted that Bambu locks a sliced gcode file to one nozzle or the other. When reprinting from history, you should be able to select any spool of filament that is the correct type. Having to physically move a spool from one side to the other for a single color print is so unnecessary.
I think you really need to read the gcode of a sliced dual-nozzle print file.
Tens of thousands to hundreds of thousands of lines of code, all of which would have to be dynamically updated to change the nozzle mapping. Simply not something that can be done given the printer’s limited onboard computing capability.
You always have been able to do this, provided the filament is being fed to the right nozzle.
I’m wondering, have you looked into the Filament Track Switch at all? It solves most filament allocation problems, which I think is what you’re trying to solve with your idea.
I wasn’t aware of the track switch. Definitely worth considering. But, currently, it doesn’t work on the H2D.
But, on your point of the gcode, that’s really a non-issue. All the extruder specific code could just be parametric. The extruder parameter would be defined by the filament selection when the print is initiated. The firmware already uses all sorts of parametric variables, so this wouldn’t be anything new from what I can see.
The firmware to use if on the H2D is currently in public beta.
I agree that in theory this could work for the H2D - but keep in mind, Bambu makes three dual nozzle printers, the only one that has the same nozzles and extruder is the H2D. It would be significantly more difficult to do this for the H2C and X2D - there are too many slicer specific variables that would apply to one nozzle side but not the other, so the printing files would likely need to carry a lot of redundant Gcode “just in case”.
Fair, but the gcode files do already carry a ton of redundant code because of model to model differences.
Even though the H2C and X2D don’t have identical hot ends / extruders on each side, I can’t see how those differences would matter as far as the gcode file is concerned. They probably have unique extruder steps and heater PID settings stored in the firmware. But, the gcode just needs to set nozzle temp and extrusion amount. The only difference I can think of is potentially retract distance.
This might have something to do with it.
Left nozzle: 325 Ă— 320 Ă— 320 mm maximum volume
Right nozzle: 325 Ă— 320 Ă— 325 mm maximum volume
The usable area is also different for each printhead because of exclusion zones. So while remapping may be feasible for many smaller single-color prints, it would not be universally safe without the printer or Bambu Studio validating the model against the selected nozzle’s printable area. It makes sense for that validation to occur in a slicer.
This is incorrect. I’m assuming by “model to model differences” you’re talking about printer models.
The whole point of selecting your printer profile in the slicer is so that the print’s Gcode is specific to the printer. That’s why in Bambu Studio you can’t slice a print and then select the printer type you want to send it to - it has to be sliced for that specific printer type.
This is because each printer has unique packages of gcode to start, end, pause, layer change, filament change, etc. based on their specific hardware.
I can say with total certainty that Bambu print files do not contain redundant code to cover model to model differences. The gcode runs from top to bottom and doesn’t skip any lines - the exception being when a subroutine doesn’t get used in a print, for example it won’t use the pause subroutine unless the print is actually paused at some point. The other example would be if skip is used.
I’d invite you to spend some time in the printer profile page, specifically the “extruder” tabs. On the H2C there are 26 extruder-specific parameters. The X2D has 25. Many parameters will be common to both extruders some of the time, but for this to work the print file would have to be structured to that all of those parameters are able to be unique.
That’s a good point.
I think you could still mitigate this with a zone parameter. Ie zone A = left only, zone B = right only, zone C = shared.
You would have to have a zone C only file to switch extruders like that.
You can say it with as much confidence as you want, but there are conditional lines of code which run or don’t run based on print / machine configuration.
I don’t mean to be harsh, but you’re basically just saying that you don’t understand what g-code is. I mean, really understand. Arguing against that now, in a forum where many people practically live and breathe g-code, isn’t a good idea.
Ok, show me. I’ll be happy to update my thinking on this accordingly.
Adding zones and runtime nozzle reassignment seems like a lot of slicer and firmware complexity simply to avoid putting the spool on the nozzle that will print the file or just re-slicing the file.
or
Mine works really well, but it’s not 100% perfect at selecting the best configuration. It’s fine for when I am being lazy…
I better rethink my whole professional life then, because I get paid very well to develop machining strategies on 4 and 5 axis mill turns, swiss machines, wire EDMs, etc. I hand edit g-code every working day of my life, write very complex cutting and probing macros by hand.
You don’t sound harsh. You sound like you assume too much.
Some examples:
Embedded if statements that control Z offset based on build plate type and nozzle diameter:
Using filament type, chamber temp, and nozzle diameter to set up the correct air filtration modes:
I’m just saying that the functionality is all there to consolidate start/end/etc gcode and use conditionals to run the correct code based on machine.
But you do realize that every machine has its own specific g-code, right? Maybe that’s why your perspective is so limited. CNC machines are very different from FDM machines. I’m not questioning your experience, but you also have to be able to apply to adapt to new situations.
Since you’re now equating CNC machines with FDM, I can already see the flaw in your reasoning.
Just because you understand how a CNC machine works doesn’t mean you have the experience to know how filament is handled in g-code for FDM printers. Also, generally speaking: Personal experience doesn’t count for much on the forum, because anyone can make it up; what people here judge is what you write.
Example: Until recently, you didn’t know what a track switch was, and even all your experience with CNC machines didn’t help you.
Keep in mind, this isn’t a personal attack or anything personal, but when it comes to FDM, it seems you still have a lot to learn; you’re expressing a very strong opinion here without the basic knowledge to back it up.
Edit: Also, if you’re an expert when it comes to CNC machines, then you know that every tool has its own designated place that the machine can access. In the case of FDM, that’s the filament. Think about it.
Here’s some additional context - not to contradict or confirm anything, but simply to provide a neutral perspective for putting things into perspective:
You wouldn’t have needed to open the G-code file, as it’s also specified in Bambu Studio. This G-code is inserted as a start code depending on the printer type:
That’s where all the IF conditions are located, such as controlling time-lapses, turning lights on and off, controlling chamber temperatures, and so on. That’s basically what’s placed before the actual G-code, and at the end because every machine is different.
But be careful: The filament / position information is not stored here! These are hard-coded in: CONFIG_BLOCK_START
That’s why it’s true that there are variables / conditionals, but these are defined in the printer’s specific start and end code within the Bambu Studio slicer. The filament / position, on the other hand, is hard-coded.
So yes, APEX86, as you say, there are variables / conditionals, but in a different context: specific startup / end code. Filament, etc., are hard-coded. That’s why this is not possible:
What would actually be correct right now - and that would make this thread meaningful - is that you APEX86, as a CNC G-code expert, should phrase your topic that way:
- “Why can’t the start code - which contains variables and conditions - also include a variable to adjust the filament or its position?”
And Bambu will probably respond by saying: There are too many variables to account for - there would be so many that it’s easier to hard-code them.
But unfortunately, your initial post doesn’t include any of that… but you can always edit your topic. 
Edit: By the way, if you don’t like this default behavior but you say you’re an expert, you can write the desired behavior once in the slicer’s startup G-code, and it will add it to each of the G-code files. Right there:
You are grasping at straws, trying to build up these flimsy claims you are making.
Are you seriously equating my not being aware of an add-on, which isn’t even compatible with my printers and was released a few months ago, with a lack of understanding of g-code or FDM printers? The honestly says everything about your projected “expertise”.
Looking back at it, there is a limitation in the firmware though. Bambu chose to just make a port of ancient Marlin FW (which I have run since I bough my first Ultimaker original). Eventually I moved on to a more modern Duet3D controller which does support true conditional gcode (just like an industrial CNC machine. There is no fundamental difference here like you implied).
It’s easy to look at these modern BL printers with the state of the art features and hardware, and forget they are still running pretty ancient firmware. My mistake. Only the slicer is evaluating conditional statements and that breaks any potential for improvement here.
I’m not grasping at straws; I’m just presenting facts that I can back up. If you’re an expert, you wouldn’t have had to start this thread. On the contrary, you should have posted a tutorial on how to customize the G-code for the community.
If you don’t think that’s possible, you shouldn’t have started this thread in its current form. Consider the content of your initial post and how you wrote it.
If you know of a better way to do it, you could post it on the developers’ official GitHub and get direct access to them to exchange ideas. In addition, link to the GitHub request here, just as others do.
I don’t need to grasp at straws; I just assess whether a post contains the facts or not. Where’s your customized G-code? If that’s not possible: Where’s the proof? Why bring this up? Where’s the GitHub request? Sorry, sir, I don’t need to grasp at straws if you’re the one throwing them around.
Let’s all take a moment to recall: This is all you wrote in your initial post:
If you don’t at least post a link to a GitHub request for the Bambu developers - and yes, we’re looking at the date and time, just like even beginners do when they have a request - then I can’t take this topic seriously anymore.
Edit: And to give you a helping hand: This way, please:
You are a piece of work.
It takes some top-notch mental gymnastics to read a thread with a subject: “… : why?”, literally a question about why they did it this way. I say that it seems short sighted and am asking why… and then somehow in your over-active imagination you have spun this into me “knowing better than the devs” and scoffing that I haven’t posted an issue on Github.
I didn’t post it on Github because I was trying to understand why (in case that wasn’t abundantly clear from the beginning). After some discussion and thought I can now see why (which I posted).
Are you really confused by the trajectory here?
I have plenty of github issues posted, identifying bugs, feature requests, and even pull requests in other repos. I have given BL devs detailed information about ways they can improve things on the printer, like the pressure advance algorithm. What does that have to do with this thread on the discussion board?
All I’m reading are excuses… where’s the GitHub link?
Excellent, I think it’s great that you’re helping the community - and I don’t mean that sarcastically. So where’s the current GitHub link?
You posted it in the “Request” section, but since it’s a programming / coding issue, GitHub is the right place for it. I think you’ll agree with me on that, since it gives you direct access to the developers, right?