Communication timeout while printing

What is the problem?
Getting an error while printing that leads to Octoprint disconnecting from printer mid-print.

Error:
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
several of these and then it leads to:
Closing down send loopChanging monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"Connection closed, closing down monitor

What did you already try to solve it?
Nothing yet. Not sure how to proceed.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
OctoPi 0.16
16GB SD Card IIRC.
Setup was saved from a working 0.15 and restored to a 0.16 build.

I had a working 0.15 build. I bought a new Pi 3b+, same as the one I had before, but installed it into a iUniker case with a pwr+ usb charger. I set this up by installing the 0.16 OctoPi image and restoring from a saved Octoprint backup. It worked well for a few days but the last 2 days I've had 3 failures like this. Not sure where to start since the setup was working fine before and the new setup worked well for a few days.

The differences between this setup and the previous 0.15: New Pi board though they are the same version, Different camera (C270 previously, C920 now), and different memory card, different Pi enclosure. Also both were connected via wired ethernet cable.

Octoprint log
Serial log was not enabled. Enabling now and retrying.

You might want to fall back to your earlier power adapter to test. A switching power supply offers a nice horizontal 5V signal to your devices since it includes a final voltage regular in its design. A charging power supply is absent that final stage so if you looked at the output power it's described as pulsing DC voltage and some calculation of power is 5V. That could be the peak voltage at the top of the humps, the RMS voltage of those humps, it's difficult to say. If those humps fall below 4.64VDC then your Raspi will register this as a problem and start to make some adjustments. There is a point below this where the expected high/low signals on your serial line aren't right and cause confusion.

1 Like

Interesting. I didn't change PSU though. That's the same as the one on the previous pi. I will order switching power supply though to prevent future issue in case that's the instigator. Kinda sucks since I have 3 for various pi's though.

Any unit in particular you recommend on Amazon?

I you were here, we'd put this on an oscilloscope to find out. Your adapter could be fine. The part which worries me is the broad claims of "2A, 2.5A, 3A..." in marketing terms, making me think that they just want to sell them and they're using promiscuous sales hyperbole.

What is difficult is that the marketing people try to cast a wide net with respect to, say, an Amazon ad. For example, this might be what you want. Unfortunately, it's got the word "charger" right in the title as well as adapter. You can see from the photo of the model, it has the word "adapter". But then I worry when they also suggest that it's "super mini". The smaller it is, usually the less power it can send through it. In this business, bigger is better not the reverse. It's clear when they've got a stylized picture of a Raspberry Pi plugged into the wall with the words "Charger" next to it, they don't know what they're saying—you charge things with batteries and the Pi has none.

The product symbol for pulsing DC is supposed to look like this. They're supposed to put that on the input/output label of the device if it's a charger. But I'm seeing a lot of products now from overseas which don't have what is expected.

Tedder suggests this one and it just solved an undervoltage indication on another thread, for what it's worth.

Just note that if your Raspi has a hat (Sense Hat) or if you've plugged lots of things into it or if your controller board is sinking power from your Raspi then the requirements might be slightly more. A bonafide 3A adapter might actually be what we all need for our setups.

1 Like

Good info. Thanks.

I actually have that CanaKit 5V 2.5A adapter. I went with the pwr+ because it claimed a max 3.5A output. If I'm not mistaken the max amperage rating doesn't matter too much as the device will draw the amperage it needs. So I get the 2A, 2.5A, 3A... marketing nonsense. A 3.5A power adapter will work for 3.5A and lower requirements and typical Amazon consumers may not know that.

As for devices connected I only have that dual fan plugged into the GPIO pins, the Logitech C920, and the printer. I would like to eventually add a temp/humidity sensor to the GPIO.

In the Air Force, I actually went away for training that involved some pretty intense design work for electronics in a case like this. Yes, the "load" will determine the power consumed (voltage times current). But it's the internal components of the power adapter mostly which determine the maximum current on both sides of that big transformer.

The input voltage is somewhat static at say, 115VAC or sometimes 120VAC here in the states. That's fed into the big transformer which might then have a 20:1 ratio of wrappings so you're getting alternating +/-6V on the opposite side. That goes into a rectifier and now it's positive/pulsing 6V down to 0V. That goes into a section which then uses a capacitor plus resistor or coil to smooth it out to 5.4+ volts +/- a bit. That then goes to something like a zener diode in the cheapest case which clips it to exactly 5V, say.

All that said, if the load has low resistance it will accept more current. All the circuitry before this then tries to give both 5V AND the current, as requested by the math. It either can do this or not. If it can't, then the voltage will drop off to something less than 5V. So it might technically deliver 3A but at 4.5V. :facepalm:

Almost anything inside the adapter and its cable can limit the current: gauge of wiring, amount of heat sinking on transistors and diodes, length of the plug cable, size/rating of the capacitors, size of the transformer and even weird things like physical spacing between diodes in parallel.

1 Like

With the fans running off the GPIO, and you have 2 of them, you need a larger supply. Fans draw 0.2A each, so now you have the 2.5A the 3B+ needs plus another 0.4A. the only supply that works properly on my 3B+ is rated 5.2V at 3.5A. i got ot from either Mouser electronics or Newark/Element 14.

1 Like

You guys think this will work?
Terasic 3.5a Adapter +2.1mm to micro usb adapter + 2.5mm to 2.1mm converter

I couldn't find a 3.5a power adapter with a micro USB plug OR one with a 2.1mm end. My concern here is resistance added by all the converters. I don't know it I need to be concerned about that. I could also just unhook the fans and run the pi until it happens again ruling out power issues too no? As long as it doesn't overheat.

That part has 12V. It will blow up your Pi...

1 Like

crap. i searched 12v instead of 5. thanks.
This one should work then:

Yep. That 5v one should work... It would be better if you could find a 5.2v adapter, because as the pi draws more current, the voltage will drop slightly. When I get home from work, I'll get the make and model of the one I have, as it came with a heavy 2 conductor cord to the micro USB plug as well

2 Likes

So I'm having this same issue, I'm new to Octoprint, so I've never had a 'working' setup. Works fine On short prints, but anything over 2-3mb i get communication errors at about 50%, and print 'pauses' and then resumes numerous times until the end.

2019-11-21 03:44:25,938 - Send: N38984 G1 X112.732 Y104.151 E413.68037*100
2019-11-21 03:44:26,133 - Recv: ok
2019-11-21 03:44:26,139 - Send: N38985 G1 X113.116 Y104.345 E413.69468*108
2019-11-21 03:44:26,335 - Recv: ok
2019-11-21 03:44:26,340 - Send: N38986 G1 X113.46 Y104.548 E413.70796*90
2019-11-21 03:44:26,713 - Recv:  T:204.86 /205.00 B:51.58 /50.00 @:60 B@:0
2019-11-21 03:44:28,713 - Recv:  T:204.90 /205.00 B:51.82 /50.00 @:59 B@:0
2019-11-21 03:44:30,713 - Recv:  T:205.00 /205.00 B:51.34 /50.00 @:57 B@:0
2019-11-21 03:44:30,716 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-11-21 03:44:30,736 - Send: N38987 M105*42
2019-11-21 03:44:30,753 - Recv: ok T:205.00 /205.00 B:51.34 /50.00 @:57 B@:0
2019-11-21 03:44:30,767 - Send: N38988 G1 X113.794 Y104.774 E413.72137*110
2019-11-21 03:44:30,794 - Recv: ok
2019-11-21 03:44:30,800 - Send: N38989 G1 X114.111 Y105.02 E413.73472*81
2019-11-21 03:44:30,816 - Recv: ok

I'm running a Ender 3 Pro, with the Bigtree SKR Mini E3, and a Raspberry 3B+
I'm tapping power off the the main ender 3 power, and running it through a buck converter at 5.2volts. I'm using a shielded usb cable, that is about 6 in in length.
Everything prints fine when I go direct to the printer usb and print from there.

.

For everyone looking for a solution to this problem, I found it:

Since I upgraded my Ender-5 to a SKR Mini E3 V1.2 i wan't able to print without "stuttering" ("freezing" or whatever you want to call it) using Octoprint via USB. The problem wasn't the USB-Cable or Octoprint, nether the Pi itself, it's the Serial Port configuration which BTT provides for the SKR Mini E3 V1.2, in their official github in the Configuration.h file it says:

#define SERIAL_PORT 2
#define SERIAL_PORT_2 -1

which prioritizes the LCD connector over the USB port (-1 beeing the USB port and 2 beeing the LCD connector for the SKR LCD touch screen)

#define SERIAL_PORT -1
#define SERIAL_PORT_2 2

So I switched those ports around and haven't had any issues since.

At first I was a bit concerned if this would only move the problem to the other port, so I verified it by printing from the LCDs SD card slot directly, no stuttering either.

Hope it helps some of you guys out there :blush:

6 Likes

thats awesome, I will try that and see if that sorts it out!

1 Like

I wonder if this is essentially the who-gets-the-good-UART issue in disguise?

2 Likes

So i just wanted to weigh in here, that the above fix from tsndr did fix my issue with the random pauses during printing, and now everything seems to be working just fine. Thanks so much for the info, life is good now!

1 Like

Thank you it helped me! I had the same problem with the version 2 of this board.

2 Likes

How do I go about making that change?

You need to recompile your fw using vscode and make those changes for marlin