Just me, or could there be major efficiency improvements in the code?

I’m sitting here listening to my H2D print out a multicolor print, and it is currently on a segment that is all the same color. That doesn’t keep it from stopping after every layer and parking the head over the purge hole like it does on a filament swap, even though there is no swap to be made. Probably adds seconds to each layer, but this is a thin/tall model and there’s hundreds of layers. Adds up. Not to mention, have to listen to those plastic lever things bang every time the head goes back to the parking area. Just printed a spool spindle last night and it completed in twenty-something minutes for close to the same size of print.

Also, noticed that on the start of any print, it switches to the left nozzle and heats it up for… something. I do 90% of my prints on the right nozzle because that’s what the AMS 2 is connected to, and I’m pretty sure Bambu Studio knows that it’s only using the right nozzle before sending the job, yet it seems it goes through all these additional and unnecessary checks every time. Meant that when I nuked my left hotend heater, the printer was down completely until I got a new one, too. That was a week of waiting.

All that said, it’s a good printer and I’m enjoying the heck out of it. I guess these are more slicer issues than printer issues, since the slicer is creating the G-code that produces these artifacts?

Hi, for the first issue with parking, do you happen to have “smooth” timelapse mode enabled in the slicer settings (Others → Special Mode → Timelapse)? For the “smooth” setting it says the head will move to the chute after each layer so it can take a picture. You can also disable timelapse recording entirely when you send the print (from what I can tell even “traditional” timelapse mode generates some pauses so I just disable it).

As for engaging the left nozzle when it will never be used in a print, I noticed that also, though it seems very brief. No idea why it would need to move that nozzle at all though.

The slicer does produce the bulk of the g-code of course, but there is also a considerable amount in the “machine g-code” settings for the printer, including the timelapse handling, if you want to take a look.

Cheers,
-Max

Do you have smooth timelapse active? That will do that.

One thing I thought could always be changed was if there is no color change and the height of the part is not that tall why dosent the bed raise its self with with the head and the back and start the first purge tower layer as the first purge hasn’t the xl Already done this?

Because that would have the same requirements of the “print by object” scenario, with the same limitations.

Could be implemented as an optional toggle if the print allows it / user wishes to use it.

That’s right - it’s almost entirely down to the slicer that produces the G-code. In rare cases, the printer itself may override certain parameters. You can even have fun opening the file and reading the code. There are many areas where the G-code could be optimised. So why isn’t this done? Because Bambu follows the ‘one size fits all’ strategy.

Although the code improves with each update, the G-code will never be as optimised as it would be if you adjusted it manually. Considering who the customers for these devices are, it makes sense that Bambu prefers to take one extra step and double up on safety features and perform one extra check.

Bambu, try to strike a balance between time and safety. As I said, you could theoretically program lots of safety features and ‘detours’ out of the G-code. This is not recommended, but if I had a print farm and always printing the same thing, I would adjust the G-code for all objects once.

However, if someone only prints occasionally, it must be acknowledged that the time saved is not significant enough to justify the risk.

1 Like

Yeah, that makes sense. Basically programming for the least tech savvy user. Definitely different from business CNC equipment which will straight up let you crash the tool right into the bed and destroy everything.

I actually found the “machine startup” gcode and removed the “vibrate machine really loudly” code so it wouldn’t get me murdered by my wife when starting a print at 11pm. :slight_smile: I could probably optimize away a bunch of other stuff too, with the caveat that the nozzle might dig a trough through the build plate afterwards. I do really like that the ability to create machine profiles exists in Bambu Studio.

Now I think about it, I bet someone out there has created fast YOLO machine profiles that cut out a bunch of checks. I’ll have to investigate. I could see the use for such a profile when producing multiples of something, where literally one prints only to have the job immediately started again after the plate is cleared.

I guess the other-other choice is to use a different slicer, but I’m resistant to that since I started with Studio and actually quite like it. I won’t lie: its warnings have saved me a couple times.

1 Like

I was thinking this same thing the other day. I had a few different versions of my X1c for things like heat soaking chamber before print, keeping it warm after print and slow cooling. I dont know code enough to really mess with it, but will be looking forward to watching it progress. Its just a matter of time.

As for another slicer, dont think its going to happen. Orca Slicer was are only other option until bambu started their security stuff. Ocer has no plans to support H2c with very little on the H2 series.