P2S: Non-optimised time-consuming gcode?

I switched from P1S to P2S because I wanted a “more modern” printer, with improvements and convenient refinements based on several years of observations of its predecessor.

Above all, it was supposed to be FASTER, more efficient, quieter, more accurate, more “interactive” – thinking for the user, forgiving mistakes. In some areas, this is indeed the case, while in others, it turns out that it is not as refined as advertised.

After just a few days of use, I was surprised to find that practically every model I wanted to print, after calculations in Bambu Studio, took longer to print on the P2S than on the P1S. Sometimes by a few minutes, sometimes by almost an hour, depending on the complexity of the model. So, a newer, better, more powerful and faster printer prints slower than its predecessor? Why?

But I would mainly like to draw attention to the printer’s features not directly related to printing. What I noticed…

In P1S
When you select the LOAD/UNLOAD option (when you want to load filament from outside the AMS system) The nozzle heating process begins IMMEDIATELY, WHILE the toolhead moves from above the purge bin to the end positions on the X and Y axes at the front of the printer - it does this ONCE for each of them, repeating a “short confirmation movement” once to confirm the end of a given axis. It returns to the purge bin and, after reaching the required temperature, moves to the front of the printer to cut the filament and returns to the purge bin again.

What I would like to point out is that the heating and positioning of the head occurs SIMULTANEOUSLY and happens at the same time.

In P2S, on the other hand
The entire process is much slower and, in addition, much noisier = even irritating. After selecting the LOAD/UNLOAD option, the first thing that happens is that the toolhead starts to home. Nothing else. The upside is that the home point has been moved closer to the toolhead parking point (purge bin) and is now located at the rear of the printer on the right. However, the toolhead still does this THREE TIMES for EACH axis, repeating a “short confirmation movement” at the end of each axis each time. In addition, DURING EACH of these cycles of moving to the end stops, a metal rod swings out to help the toolhead cut the filament. It does not participate in this operation, but deflects automatically due to the design of the printer. The “opening” of this rod generates a very loud, distinct click. Listening to this entire long cycle of reaching the end stops accompanied by loud clicks undermines the description of the printer as being quieter - and therefore more user-friendly. As if that were not enough, ONLY AFTER this entire “clicking dance” of the toolhead and its parking over the purge bin does the nozzle heating process begin.

I roll my eyes to the sky and ask: WHYYYYY??!!
What is stopping the nozzle heating process from starting immediately, so that it heats up during this crazy “dance”?
Why does the print head need to be calibrated so many times when its predecessor only needed to be calibrated once to produce correct prints?

Are these programming shortcomings, where this was neglected in order to focus on improving the main printing functions? And is this feasible, and will we perhaps see improvements to these functions someday? Or is this just the way it has to be, because this model cannot be improved upon?

8 Likes

I have witnessed similar lacks of minor functions on my P2S, and thought no one would care but at least you do! I have some more to share:

-During homing and nozzle wiping operations, the motor noise cancellation is turned off, given by how loud the steppers are.

-The Z axis doesn’t have motor noise cancellation, and is really loud when there are Z hops (I just printed a huge piece of chainmail and that noise is really obvious during that)

-The nozzle wiping process is slower and more complex than it needs to be. The A1 Mini is a good example of how it should be.

-It homes WAY to much. Seriously, it seems like it homes before every step of the print preparation, at least 3 times. I have a feeling this was implemented because they were struggling with keeping the tool head movements accurate, given some weird artifacts on my prints.

-This is more of a slicer and possibly to-user thing, but the part cooling fan is WAY overpowered. Under a thermal camera, it makes the bed cooler in that spot. This might not sound like an issue, but I had to turn it off for chainmail to prevent pieces popping off. And also having it so overpowered makes prints really weak. The default speed should be 60-80% like the A1 Mini.

Now the printer is still a really good printer, but not as optimized as the A1 Mini. The software development clearly seems to have some bugs and oversights, like how they totally realized after the release that an update was needed for the VFAs. I have a suspicion that they were rushing the development a bit to get it out for the holidays which isn’t unheard of for any brand.

I would just let the updates keep rolling in and assuming they don’t have any bricking/proprietary stuff in there it should help mainly everything I complained about.

3 Likes

Thank you for your reply. Yes, there is indeed more to it, I agree with you. I guess what you are referring to in your first point is the moment of preparation for printing, when the printer emits two strange buzzing sounds of different frequencies. However, they are much louder than those known from the P1S. When I run a print job in the evening, I feel like my neighbours behind the wall can hear it every time, especially the first, very low-frequency vibrations.

I actually was talking about the stepper noise, not the vibration compensation thing it does. Just the sound of the stepper motors is loud, and how they would sound if you skipped the motor noise cancellation. Similar to like a Ender 3 Pro, with it’s loud steppers. It is just weird that it turns it off for print prep and then turns it on for the print.
Also, if you haven’t updated to the latest firmware version on the P2S, the stepper control is messed up in the first version. The steppers make almost like booming noises on accelerations and make it sound like the printer is gonna fall apart. The latest firmware version fixed that, though.
I did want to mention that the vibration compensation on the P2S is a huge upgrade over the A1 Mini. The A1 Mini does I think a 6 frequency thing for EACH AXIS, while the P2S does 2 for each axis. And the A1 Mini is LOUD when it does it too. Now I do have both of these printers sitting on the same, very solid sturdy table so that might change results of any loudness aspect.

2 minute print, 8 minutes of mechanical masturbation to get ready. I’ve followed the wiki for disabling filament change and purging before/between prints, it still purges more than twice the weight of my prototypes. and sounds like two dumpsters bumping junk while it does it. Instead of printing, I’m googling gcode line by line like I’m ordering dinner from the local martian restaurant to figure out what is going on. You give my ADHD riddled brain 8 minutes of downtime and I will start 9 more projects and forget that I have a printer.

4 Likes

Pleased this has been raised, it does my head in too! It spoils what I think is a good machine that has so far done all I ask of it. Hopefully someone at BL take notice and do something.

1 Like

Can you send me a link to the Wiki page about what you’re talking about?

I believe this is the wiki they’re referring to, saves me the pain of watching the filament I just used be unloaded / reloaded and then purged into oblivion.

I’m convinced the g-code settings for the P2S had the ‘ship now, fix later’ treatment given the teething issues and feature ‘optimisations’ pushed since launch. My personal P2S headache: the thing LOVES a fat poop.

I followed the wiki in my reply to create a preset that removes the ungodly filament unload/reload + purge sequence if using one filament across prints. This user has also shared their modified start g-code which looks promising, though I’ve yet to test it.

As a new user, troubleshooting and trying to learn g-code in the hopes of a band-aid solution has sent my sanity places. I’m left waiting for someone else to share a fix for the ‘Change filament G-code’ in the printer settings that forces my printer to poop on every filament change, despite flushing volumes being set to ‘0’. I mean… how does ‘0’ just… not mean ‘0’…

1 Like

Sure thing, @Cancel-sky. I couldn’t get it to work consistently for me, but maybe it’ll work for you.

There are a lot of places in Bambu Studio where if you enter zero it actually sets to default. I’m pretty sure that flushing volume is one of those, but I won’t swear to it. I can’t check Studio just now. Generally, there will be some kind of indication either when hovering over the “?” or the description of the setting that will tell you if 0 sets to default. I’ve made that particular mistake only once ever and you can’t prove otherwise.

My understanding is Bambu’s algorithm sets default volumes for loaded filament, which can be modified manually or via a multiplier. I have seen those settings you mention where ‘0’ = a default value, though the flushing settings note ‘0’ as a valid multiplier/parameter i.e. the default being ‘1’. Once sliced, the filament scheme reflects this in grams, with mm³ = ‘0’ (or multiplier = ‘0’) resulting in no filament purge.

Since the printer still purges some filament irrespective of this, these volumes are somewhat misleading from an optimisation standpoint. All things point to a process change in the P2S filament change g-code vs the P1S. Without documentation, a solution would require familiarity with g-code to test and pinpoint the executable responsible :confused:

This G-Code stuff is beyond me. All I know is when it shows a g-code error in the slicer and says 0-3, I add #1 and continue. I’m sure this is not at all what you guys are talking about. What I can say is that I’ve printed over 100 items since receiving my P2S printer (yes, my first 3d printer) and I’ve printed many in multicolor and have only filled half the poop bin so far. I was expecting lots more poop :laughing: –yeah, I’m old :folded_hands: . Not sure if this helps, but thought I’d add my experience as this topic looks interesting. GL friends.

Hey !

I modified mine to fix the poorly optimized starting gcode of the P2S. It’s available on my github : Scoofz/P2S-start-gcode

It doesn’t fix the fact that each X & Y homing does it 4 times every time, but it does move up the motor noise reduction up the chain and removes one unnecessary homing in the gcode. The rest depends on Bambu to fix their homing macro.

Bambu, do please do something…

3 Likes

You are my hero of the freaking year so far. The sweet release from the GD noise. I had forgotten what printing without banging was like. Now, Bambu, would you kindly get your sh*t together?

1 Like

Well, I’m truly glad you like it. If at least one user uses it and likes it, I’m happy :slight_smile: