Printing just stop in middle of part!


I got octopi working well
the problem is on large parts, printer just stop working in middle of print and only button working is pause ,but i can not continue at all
I cannot move head, temps nozzle and bed are up but , no move happens, head just rock on it's position
all i know is I see on raspberry pi somtimes low voltage ,and maybe i think connection to RAMPS is too hi (250000) also with log i got some like

log tell me i got error checksums and try to skip some lines


This happened to me for the first time yesterday as well. There was a Serial error in the middle of a print and the print failed.

Been reading up on it but as long as it doesnt happen again im going to call it a fluke.

I got official canakit power supply on the pi so I do not think it is that..but I wasnt at the office when it happened. It could have been a brown out to the building. too many factors to try and narrow it down from. Hence "fluke"


When you're working with a power supply that doesn't give enough wattage, you're really gambling in a way. You're saying "I know I might finish this part or not".

Stop gambling and buy the correct power adapter. It will pay for itself in the cost of lost filament.


I just fix problem with power more low voltage
I change cables usb with strong cables
After 10 hours printing I got error connection serial
now I swap usb with another one in RPI to see if is something wrong
one more problem
arduino have 5 volt to be powered
I power that with 5 volt but I'm not sure if is necessary how much time I got 12 volt from RAMPS
any advice ?


I'm not exactly sure what you're trying to say here in this sentence.

  • What's the model/brand of the printer?
  • If this is a do-it-yourself printer, what is the model/brand of the RAMPS board itself?
  • You have OctoPi/OctoPrint running on the Raspberry Pi and you mention an Arduino. Can we assume that the Arduino is or is on the RAMPS board?

In my printer, a large 24V adapter goes into the RAMPS board. This board creates 24V, 12V, 5V and 3.3V (presumably) and provides these voltages as necessary to the stepper motors, heating elements and to power the Raspberry Pi itself on a pair of pins which are marked "5V".

In other cases, people might power their Raspberry Pi using other means like a 2.5A 5V adapter.

In still other cases, the RAMPS board receives 24V or 12V as inputs but this is only for the stepper motors and heating elements; it's necessary to power the Arduino using a 5V adapter of some kind.

It really depends upon the brand and model which you have.


I just wanna add that I completed the print and am officially calling my issue a fluke. 33+ hour print with no issues! yay

split this topic #7

2 posts were split to a new topic: Questions about powering Pi/RAMPS/Arduino/


I just got this the last few days as well.....I was printing fine for a week. The last 3 days, it'll print normal, get to 30-80% done, then just freeze. No major errors in the logs. It just decides to stop. The entire rasp pi service seems to stop, as the "OctoPrint server is currently not running" message is up and I can SSH into it. Also got the cannakit, Rasp Pi 3 b+, and my printer is the Prusa MK3


RPI 3b+, core xy
The real problem I got is RPI is freeze in time printing
a simple login and logout from octopi make all system inaccessible and freeze
the only solution i have is to put a real computer instead of this RPI
I cannot login in ssh and nothing to do
I lost few hundred meters filament just looking on mjpgstream from internet (at work) to see if my printer is active and arriving home computer was with problems
I think RPI can not manage octopi on long prints like 2, 3, 4, 5 days and it crash itself
I don't say is not good , just is not stable on long time
Is my opinion.


It may be the plus version of the Raspberry Pi 3B that's responsible for these freezes and possible a manufacturing problem. The non-plus version of the Raspberry Pi 3B doesn't seem to have this.

Google: raspberry pi 3 b+ freezing


Exactly, I had a original B and that worked perfect. Wanted to get a bit faster so did B+ and it started happening then. But I wasnt sure if it was a bad image, bad cable, or the rasp pi itself. So I replaced the cable, didnt work. I reflashed the image so ill know tomorrow if it crashed. And if that still crashes, ill test the old rasp pi again and see if it was the pi model all along


You know... in the troubleshooting thread, someone was suggesting that the speed increase to 1.4GHz is causing the problems with respect to either unchecked heat, throttling-gone-bad or some sort of inability to read/write to the RAM at that speed.


I ran two test prints so far, smaller ones (2-3 hrs), and both have not crashed. Still using the B+ model, but had no other plugins added after flashing a full clean image. Perhaps it's a certain plugin, or if there are too many, it overloads and crashes? I'm doing a longer test now, with only octolapse installed, so a little more power/time, which may push it


Get ready for a very technical response...

You probably want to remember this command so that you can run it when it's happy and during/after a longer print: Checking for throttling.

If vcgencmd is returning a non-zero value for that then your Raspi is in panic mode and it's making adjustments to the CPU speed to compensate. One reason is power and another is heat.

This method won't tell you if attempts to read/write from memory are failing. This is more of a catastrophic thing in processing terms. These are categorized as kernel messages. You could look for things in your logs related to this. Sometimes it's that the memory isn't available fast enough (think "overclocked too fast").

It might look like: octopi kernel: <1-1.1:1.0: eth0: kevent 2 may have been dropped

cat /var/log/messages|grep kernel or also pipe that to grep kevent

I'm guessing that this is the same as grep'ing for kernel above:
cat /var/log/kern.log

If you wanted to play with this theory: sudo nano /etc/sysctl.conf and edit/append (from Debian man page and sysctl):

vm.min_free_kbytes = 16384

...or bump that to 32768.

Additionally, sudo nano /boot/cmdline.txt in the kernel command line options to "disable the wired networking driver turbo mode" (noting that this suggests it only affects a wired Ethernet—related connection problem):


The kernel includes an on-demand governor which will bump up the processor's speed when it's under load. You might be able to slow down the processor's default speed with a /boot/config.txt edit/append of arm_freq=700 or whatever is lower than your Raspi's default. I just put the default for the non-plus version of the Raspberry Pi 3. Check out this page for inspiration, noting that you intend to limit rather than to overclock.

It is rumored that some of these problems are related to the double-powering of a Raspberry Pi and goes something like this:

  1. Power comes in on the standard micro USB port in the corner, as expected
  2. One or more of the USB connections also contains a 5V power line and that's also somehow being felt, creating a surging 5V feedback loop between both upstream/downstream power providers

Not that I love this solution, but some people are applying tape to the superfluous 5V USB pin.

I note that the vm.swappiness value in Raspbian has changed since sometime in 2016. If I now run sysctl vm.swappiness I get vm.swappiness = 60. From what I understand, it used to be 1 before this, which meant "almost always avoid using swap". So now presumably, it uses swap significantly more than what it did earlier. What does this really mean to us?

If the speed of the micro SD card is low (typical of the bargain basement cards I buy) then this means that if Raspbian is swapping memory to disk more frequently, that becomes a bottleneck.

You can use free -h to see how much swap is being used.

              total        used        free      shared  buff/cache   available
Mem:           875M        131M        500M        6.6M        243M        686M
Swap:           99M          0B         99M

But if I've got a cheap/slow microSD then that's not necessarily a good thing.

Try also watch vmstat to get a feel for this in realtime, especially while a print job is running. Compare with what this looks like while you're streaming video back to your browser, etc.

Shorter version of this section: replace your microSD with a really expensive one or adjust the vm.swappiness back to 1 with sudo nano /etc/sysctl.conf.


Awesome response. Let me do some testing with the notes you gave me and I'll update when I can. Ty for the detailed response, really appreciate it.


Thank you very much for theory
for me make sens all you say there
i will save this for later use of raspberry pi
i am in way to change RPI with computer like INTEL NUC
Is not about i don't trust RPI, is about after I invest 2000 ÂŁ in my printer mechanics is pointless to be stopped by a simple computer who is not sure it will working or not
for all i write is very important to have a real 5.1v on RPI because:

  1. if is less than 5.1v the processor fo in under voltage detect and will work slow and in steps
  2. if you have a more than (let say you put a power source with adjust voltage by a resistor and let say adjust to 5.25 v ) the RPI it will work , will be fast and very responsive but by the other side RPI have a regulated voltage inside who do a short if detect is more voltage, and this, to protect processor by over voltage
    i search deep on internet about this and i don't have technical language to explain this situation.
    so in this case your power source will be in short and will become boiled on long time used
    it happens to me and to be onest after 30 hours my source was closer to 60 degree and machine stop because wires from source to RPI was boiled and melt my switch

Many thanks for all guide me
My opinion is RPI is very good for printers 20 cm squarer but if you print long time is necessary something more stable.
There to many thinks must take care to have a stable RPI


The under-volt threshold is 4.64V, by the way.

Ah... so you're saying that the power supply itself got very hot. This tends to happen if the "load" (the resistance internal to the Raspberry Pi in this case) is too high or the internal resistance is too low (like a short). I'm very good with electronics and electricity and yet I'm not entirely following you.

Keep in mind that the Raspberry Pi 3B (no "+") is an excellent version which does not suffer from what you describe.