Apparent coms. failing betwen octopi and printer

Hello all,

I'm having a weird issue, I'm trying to print a camera holder for a 3.6mm Pi camera and the printer freeze right at the second round of the Brim extrusion, then after some seconds it startas again to print and after some minutes it freezes again (other 7n times).

What is happening? the printer worked fine till my last print wo days ago, then I turn it on this morning and this happens.

This is what I see in the terminal when it happens:

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.
Send: N24 M10517
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.
Send: N25 M105
Recv: o-�ok T:239.7 /240.0 B:41.1 /40.0 T0:239.7 /240.0 @:49 B@:0�ok T:240.4 /240.0 B:40.2 /40.0 T0:240.4 /240.0 @:43 B@:0
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.
Send: N26 M10519
Recv: ok T:240.0 /240.0 B:40.6 /40.0 T0:240.0 /240.0 @:45 B@:0
Send: N27 M105
Recv: ok T:240.0 /240.0 B:40.6 /40.0 T0:240.0 /240.0 @:45 B@:0
Send: N24 M10517
Send: N28 G1 X89.739 Y74.566 E0.13991
Recv: Error:Line Number is not Last Line Number+1, Last Line: 27
Recv: Resend: 28
Recv: ok

Send: N622 G1 F2400 X82.214 Y77.115 E14.84798*51
--- too many lines to buffer, cut off ---

it's weird because the holder is 40x30x8mm and it is not very complex.

Additional information about your setup
Raspberry Pi 3 B

OctoPrint 1.3.9 running on OctoPi 0.15.1

octoprint.log (61.8 KB)

Printer: Geeetech i3 Pro W

Check the serial cable. Make sure that it's plugged in completely and that it either has: 1) internal metallic shielding or 2) one or two ferrite cores.

Remote into your Raspberry Pi and see if it's throttling at all (due to undervoltage): vcgencmd get_throttled

A value other than 0x0 means that it doesn't have enough voltage (or it's too hot).

The cable it's ok, is a brand new usb cable with diuble shielding... can't be undervoltage since I'm using an original raspberry pi power suply... also, it worked perfectly till two days ago.

1 Like

Does it do the same running in Safe Mode?

1 Like

Yes -.-", it's frustrating...
it worked perfectly till 4 days ago

Not sure if this is only on the M105 commands but if it is, I think I'd let everything cool down and check the connections in the hotend/thermistor area.

Obviously, something changed.

Try to print something else. See if the problem follows that particular file. Try to print a file that you sliced a long time ago. Maybe this is related to a Cura upgrade or similar.

1 Like

I've printed some stuff this morning directly from SD without Octoprint, and it printed well with no pauses nor interruptions (except for the power outage due to the consistent rain here in italy the last two days... fall in italy sucks)... as was saying... no interruptions... I've the Rasp Pi has a 40x40mm fan on top to keep it cool but I've ordered some alluminum heatsinks to put on the chips... I'll try also to re install the cura engine on it... maybe is that

1 Like

Sorry, I was assuming that you slice and then upload to OctoPrint. I never slice within OctoPrint. I love the control I get by slicing with the brand-new, stand-alone version of Cura. It's got relative extrusion which I prefer, among other things.

1 Like

Sorry to hijack the thread but I've seen relative extrusion been talked about largely in terms of disadvantages so I'd be interested to hear your experience with it as it of course makes mixing gcode a lot easier

I write a number of CLI type of programs which post-process GCODE. The math is much easier with relative extrusion. If you want to reorder two adjacent layers in a file, go for it. It's now simple. I can't think of any reason why you'd want to do that, but at least you don't have to recalculate each line's extrusion from an audit standpoint and rewrite everything.

So the heat sink for the rasp pi 3 finally arrived... even thou it already had a fan blowing on it everytime, I'll try one last time to see if it was a geating issue.
If it repeats again I'll post the log.
Cross fingers and toes...

I doubt if that's it. I know that I run my Raspis quite hot and they're happy as clams. But I'll cross my fingers for you.

Nope, you are right... not a cooling issue, and still freezes... is there another way to make the raspberry comunicate with my printer? Only the usb?

Have you tried another/new power supply?

It's a brand new and origibal raspberry power supply of 5v 2.5A psu... also I repeat... it worked perfectly for the first 25 prints...

Even a brand new power supply can fail... from now to then...

... things work... Until they fail... New, old... It don't matter anymore. ALL MADE IN CHINA.

I was doing well, printing this and that, then one day I started getting comms failures. It's a horrible mess to troubleshoot. I swapped the cord for a much smaller, heavier shielded one, moved my buck converters away from everything else, replaced the power supply, RESEARCH RESEARCH RESEARCH... Months went by and I finally realized it's the code. Either Marlin or Octo had changed. Scraping at the walls, looking for ANYTHING that would help alleviate these comms issues Outsourced mentioned klipper. So I made the jump to klipper. I have never had a comms issue with klipper. It's a bit of a change from Marlin but very nice. GL

1 Like

Ok... wow klipper! Nice klipper!... wait.. what is Klipper... you have a link? I'm Using a very chinese Geeetech i3 pro w, the control board is a GT2560... how can I upload new firmware? I do have an Arduino Mega 2560 with ramps 1.4 on it could it work?...

Klipper moves much of the logistics math (if you will) from the Arduino board up to the host (Raspberry Pi in this case). The printer is then relegated to just moves, mostly. So you end up with less processor-stalling on the Arduino board, in theory anyway. In fact, you might get smoother surfaces in some cases.


I haven't installed it yet myself but I'll likely first build a test rig to print cappuccino foam art first to get a feel for it before introducing it to my own 3D printer. Robo 3D tested it and they thought it was worthwhile.

Once I got Notepad++ configured correctly I was able to make firmware changes VERY quickly with only a few buttons to press. I am very happy with Klipper using RAMPS 1.4/RE-ARM... and another 2560/RAMPS 1.4 sandwich for the LCD. The ability to use multiple MCUs to overcome pin issues or conflicts associated with TMC drivers was very handy, and surprisingly easy. I don't know what the difference is between how Marlin/octoprint communicate with the MCU vs how klipper/octoprint does but it completely wiped out all my issues. Perhaps the virtualSD feature?? Dunno. It doesn't have every bell and whistle Marlin does but it's getting there. BTW thanks again OutsourcedGuru. You rock.