There is a random (i.e. not always at the same z-height) failure when printing this model - you can see below the results of two trials next each other. The failure is a clear shift in y-direction of the print. The orange took longer before being detected, while the yellow one has been immediately stopped.
For the latter (yellow), here the octoprint.log (110.7 KB). The job was running fine earlier in the morning (you can see I connected from my iPad around 8am to check it), while shortly before noon I had to stop it since I observed the shift.
The model was well attached to the plate.
I am running Octoprint version 1.5.3 on OctoPi version 0.17.0, running on Raspberry Pi 3 Model B Plus Rev 1.3.
The Ender 3 Pro (purchased in Jan 2020) is running the Creality Silent Board v1.1.5 with marlin 2.0.x.
My next steps could be
Running in safe mode
Tape the 5V line on the USB to avoid back powering the board from the Pi.
Before doing that, I would love to hear if the community has an idea about the issue, each model is around 200g filament and I would like to limit the trials as much as possible
Is the shift exclusively in the Y plane, with no X? I ask because the part may just have moved on the bed. That would sorta explain the varying Z. Just a guess, probably wrong.
@towlerg I wish you were right, unfortunately both models were well attached to the plate when I stopped the build. The second trial (yellow) was also provided with a brim, and it was quite hard to remove it
@b-morgan do you mean when it failed or the whole period after the failure? In the latter case I would say there was not noticeable noise, I have a silent board...
I mean audio at the exact time of the failure, one layer before and one layer after the shift is all that is needed. If the shift is a result of something mechanical like a belt slipping or the stepper motor stalling, I believe you would hear that.
Sometimes I will "print" an object without filament loaded. This saves wasting filament but unfortunately, still takes the same amount of time to print, and I'm guessing the timing of this failure is probably measured in hours.
Between this problem and the previous thread's related problem, I think I'd change the controller board.
A quick update: I started the very same build job with Octoprint in safe mode and with serial.log enabled.
The job still fails, (around 9am, after 20h print) at a similar height. This time the failure has been more spectacular, I found my model "ejected" from the plate and lying on the floor a meter away from the printer
I have uploaded the octoprint and linked the serial.log (too large to be uploaded here even when compressed). I cannot see anything strange, but I would like to have your educated opinion on them. I can only notice that in the serial.log there are repeated "busy" messages at particular times.
It seems that after the warm up such messages are clustered at the beginning of the build and towards the end, while there is a very large time interval (between 5pm and 4am) with no busy messages at all.
Is this perhaps a hint of a communication or controller problem?
I'll echo b-morgan's earlier thought... Because I've had that same problem before, and it was an overheating stepper driver. If your board enclosure has a fan, make sure it's running at proper speed and inlet/outlet aren't restricted. You might also consider adding some small heat-sinks to the stepper chips.
You are very much right, indeed! I am not sure how it could have worked up to now (over three months)
I checked now and the fan does not run at all - the board does not provide any voltage at the connector. I am wondering if I have missed something in the firmware configuration
Once fixed the problem I will run again the job and I am sure I will be able to mark this as solved
:
