Printer Stops in the middle of the print

I printed multiple medium prints over the last days. Never a problem and everything worked well. Since today, all prints stop at least once mid-print. The App said that there is no connection to the device. I did not got any notification that the printer has problems. Or is not responding. It just stops, and the nozzle is melting everything around it. I searched around and saw the tip with the power outage. I tried it and it worked. So just turning the printer off and on, and then use the recover procedure continued the print. But since it’s currently happening with every print (the last one had this issue twice just 1 minute after the recovery) I am interested if this also happens to others.

Ok now it happened again three times during the same print. At the end I had to abort since it could not recover. The base was on the wrong level and it continued midair.

After resetting the printer to factory settings and removing the camera i did not had any issues any more.

So you think its the camera? probably enaugh to deactivate timelapse in the app?

I have the same problem and i will try to deactivate record setting in the app. I will update you soon if i have the problems again

I remember reading elsewhere this can happen when a low-spec or cheap MicroSD is used with the printer. I personally use a Samsung Evo MicroSD and have yet to have any issues with prints pausing, but I also have an X1C so your results may be different on the P1P.

Oh also good idea! I will try it!

I am running a bigger print over 2 hours now, and dont have any stuck or stops in my print!
I think its the timelapse, after i deactivate the record in the app, it doesnt show the bug again.

But probably it can be a the reason of a bad SD Card… dont writing fast enaugh or so, and than it stucks. So i will buy a better SD Card and try again

Okay Update :slight_smile:

I had a 6hours print now, no stops, laggings and its not stopped in midprint.
I am sure its the SD Card Quality… If you stop records in the app its also working, cause he dont write to much to the sd card, but if you have a bad sd card, it stucks

I have had my printer just over a week and had my first incident where the print stopped 6 hours into an 18 hour print. This is the 2nd time I have used a Micro SD as I normally just wifi it. So yes there maybe is something in the cheap micro SD card causing the problem.

I had the SD card switched. But still had the issue. I think in my case it was the camera.

Not contradicting you, but as another data point, in order to improve P1P performance, I replaced the stock (no name) card with a Samsung EVO 128GB and since doing that, my P1P has had three prints fail by just stopping moving/extruding. This last time, I got a simple “Print failed” notification from the Bambu Handy app, but no additional details.

If getting a new MicroSD card will fix this, I’ll go shopping, but I’m not sure what I’d want to look for in a replacement.

I pulled the card from my P1P and ran First Aid (fsck) on it. Interesting results are below. I wonder whether filesystem corruption is leading to P1P misbehavior.

Running First Aid on “NO NAME” (disk8s1)

Checking file system and repairing if necessary and if possible.
Volume was successfully unmounted.
Performing fsck_msdos -y /dev/rdisk8s1
** /dev/rdisk8s1

** Phase 1 - Preparing FAT

** Phase 2 - Checking Directories

/RECORDER/CMN_01S09A2B0600052_01-19_14_51_26.318_idx_0.bin has too many clusters allocated (logical=868352, physical=966656)

Drop superfluous clusters? yes

/RECORDER/CMN_01S09A2B0600052_01-19_15_22_46.619_idx_10.bin has too many clusters allocated (logical=155648, physical=180224)

Drop superfluous clusters? yes

/LOGGER/01S09A2B0600052_01-18_16_14_18.305_idx_2.log has too many clusters allocated (logical=3111936, physical=3162112)

Drop superfluous clusters? yes

/LOGGER/01S09A2B0600052_01-19_16_59_56.690_idx_7.log has too many clusters allocated (logical=17051648, physical=17104896)

Drop superfluous clusters? yes

/LOGGER/01S09A2B0600052_01-01_08_00_02.379_idx_8.log has too many clusters allocated (logical=979072, physical=1048576)

Drop superfluous clusters? yes

/LOGGER/01S09A2B0600052_01-19_13_33_58.087_idx_10.log has too many clusters allocated (logical=6123520, physical=6193152)

Drop superfluous clusters? yes

/LOGGER/01S09A2B0600052_01-19_12_59_47.350_idx_11.log has too many clusters allocated (logical=2225280, physical=2277376)

Drop superfluous clusters? yes

** Phase 3 - Checking for Orphan Clusters

Found orphan cluster(s)

Fix? yes

Marked 56 clusters as free

Free space in FSInfo block (7801652) not correct (7801732)

Fix? yes

62 files, 124827712 KiB free (7801732 clusters)


File system check exit code is 0.
Restoring the original state found as mounted.

Operation successful.

Since my post about the SD card I have had prints fail 2 nights in a row. Both times using the wifi and not an SD card.

I dont have the camera installed so its not that either.

Last nights was a little worrying as it must have happened between 1 and 2 hours after starting and wasn’t noticed until 6 hours later. So the printer was sat at printing temperatures for all that time.

If it fails again tonight then I may have to consider not printing when I cant check on it every couple of hours which isnt ideal.

I think the SD card is the internal storage. If there were a problem with the SD card, it’d still show up with printing from the cloud.

After completing the fsck of my SD card, I tried a print which had previously failed. It finished just fine. So, I’ve got a rough hypothesis to start from:

  1. This card was formatted in the printer itself just a few days ago, so let’s assume it was “good” to begin with.
  2. I ran into a lot of issues with prints failing due to the random K value in the latest firmware update. Thus, lots of prints were aborted using the :black_medium_square: (stop) button on the control panel.
  3. Since I had those files corrupted, I think that canceling a print causes some files not to be closed properly, leading to filesystem corruption.
  4. Subsequent prints, if they run into a glitch with the filesystem, simply pause the print while they get hung waiting on whatever is wrong with the filesystem (and are unable to self-resolve).


Edited to add…

I had to cancel a print just now for unrelated reasons. I figured I’d check the card. Sure enough, two files don’t seem to have been closed properly upon stopping the print.

/RECORDER/CMN_01S09A2B0600052_01-20_08_30_04.818_idx_35.bin has too many clusters allocated (logical=221184, physical=360448)
/LOGGER/01S09A2B0600052_01-20_03_46_23.900_idx_14.log has too many clusters allocated (logical=21520384, physical=21577728)