Octoprint | firmware buffer overflow problem? | Communication timeout while printing

Get Help
1

What is the problem?

Hello,

I recently finished creating my I3-RS. I am very satisfied with it. https://www.makerfr.com/en/imprimante-3d/i3-rs-2018/

Being an automation / home automation fan, I wanted to integrate a RPI (Model B Rev 2) with octoprint into my printer.

All of my prints going through SD / USB drives worked perfectly fine. However, by going through octoprint, it prints well, until at some point (random: Because never the same layer) the printer starts to jerk, then stops dead.

I went to see the octoprint terminal which is the following:

Send: N47700 G1 X117.444 Y105.35 E776.61995*83
Recv: Error:Line Number is not Last Line Number+1, Last Line: 47699
Recv: Resend: 47700
Recv: ok
Send: N47700 G1 X117.444 Y105.35 E776.61995*83
Recv: Error:Line Number is not Last Line Number+1, Last Line: 47699
Recv: Resend: 47700
Recv: ok
Send: N47700 G1 X117.444 Y105.35 E776.61995*83
Recv: Error:Line Number is not Last Line Number+1, Last Line: 47699
Recv: Resend: 47700
Recv: ok
Send: N47700 G1 X117.444 Y105.35 E776.61995*83
Recv: Error:Line Number is not Last Line Number+1, Last Line: 47699
Recv: Resend: 47700
Printer keeps requesting line 47700 again and again, communication stuck
Changing monitoring state from "Printing" to "Error: Printer keeps requesting line 47700 again and again, communication stuck"
Send: M112
Send: N47701 M112*36
Send: N47702 M104 T0 S0*39
Send: N47703 M140 S0*98
Changing monitoring state from "Error: Printer keeps requesting line 47700 again and again, communication stuck" to "Offline (Error: Printer keeps requesting line 47700 again and again, communication stuck)"
Connection closed, closing down monitor

It can be seen that the printer is not receiving the 47700 line and create a loopback. (It never hangs on the same line but here I will continue to talk about this line).

What did you already try to solve it?

I did a little research on the net and found a python plugin that I added in the plugin folder of my RPI.

The plugin is as follows:

# coding=utf-8
from __future__ import absolute_import

def Fix_Bad_Resend(comm, line, *args, **kwargs):
    if "Error:Line Number is not Last Line Number+1" not in line:
        return line
    goodline = line.replace(".*Resend:","Resend:")
    return goodline

__plugin_name__ = "Fix Bad Resend"
__plugin_version__ = "1.0.0"
__plugin_description__ = "Fix Bad Resend in printer responses (add newline)"
__plugin_hooks__ = {
    "octoprint.comm.protocol.gcode.received": Fix_Bad_Resend
}

It comes from this topic on the octoprint forum:https://community.octoprint.org/t/problem-error-line-number-is-not-last-line-number-1-last-line-23resend-24/10420/5

I checked that it was in my list of plugins on my dashboard and relaunched a print .... unfortunately, the problem persists.

So I continued my research and found that someone had changed the buffer size in the " Configuration_adv.h " file for the marlin serial link.

 #define BLOCK_BUFFER_SIZE 16 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
  #define BLOCK_BUFFER_SIZE 16 // maximize block buffer
#endif

// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
#define BUFSIZE 4

... became ... :

  //before 32->16
  #define BLOCK_BUFFER_SIZE 32 // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
  //before 32->16
  #define BLOCK_BUFFER_SIZE 32 // maximize block buffer
#endif

// @section serial

// The ASCII buffer for serial input
#define MAX_CMD_SIZE 96
//before 32 -> 4
#define BUFSIZE 32

Unfortunately, again without success.

I tried to print the same way but from my PC and Simplify3D and that way it worked.

I wonder if the problem is the baud rate to my printer of the gcode in octoprint?
Can we change this setting somewhere?

So I come here to find out if anyone has the solution to my problem or a lead that allowed me to move forward.

thank you in advancesmileys with beer

Additional information about your setup

octoprint.log (420.7 KB) serial.log (296 Bytes)

OctoPrint 1.4.2
Python 2.7.16
OctoPi 0.17.0

Printer:
MakerFr I3-RS
Modified version of Marlin 1.1.8
Motherboard: MKS Base 1.5
Screen: TFT MKS 3.2"

RPI model B rev2 (2 USB ports)

2

Hello @MrEtho53!

Sadly, as you deleted the template that appears when you open a Get Help thread, some handy informations are missing: OctoPi version, OctoPrint version, and the logs.

1 Like
3

Hello @Ewald_Ikemann , Thank you for reporting my mistake. I made the correction on the initial topic, if you need more information let me know.

4

If tou mean an original Raspberry Pi B (not even a B+, ie with 2 USB ports and a yellow composite video output), then that Pi is quite limited in the amount of RAM it has (512 Kb) and by its single core CPU, and not recommended to use. If you mean a Raspberry Pi 3 or 4 model B rev 2, then carry on.

1 Like
5

Hello @fieldOfView, thanks for your help.

Indeed it's an old model RPI 1 b rev 2 which was at home (2 USB ports) I will try with another more recent RPI and will tell you if the problem is solved.

But it seems strange to me, does it take so many resources to just send gcode lines over a serial interface? I know the server may need some resources, but the server is working fine. Only the printer control has a problem.

I'll keep you informed.

6

People want features. Even if those features are often in the form of plugins, OctoPrint has to have hooks for these plugins to hook into. This takes a bit of CPU load. But the most problematic part is the protocol between the Raspberry Pi and the printer firmware, where each line is checksummed and acknowledged line-by-line, so the process is much more involved than just sending a file over a serial port.

1 Like
7

Thank you for your explanation which helps me to understand better. I actually thought that it simply corresponded to sending a file on a serial interface

8

Hello @fieldOfView,

I only have a Raspberry Pi 2 Model B Rev 1.1 at home. So I flashed an SD card again and put back the same versions as before. My prints seem to have worked well. Thanks a lot.

However, sometimes the printer hangs and the following message appears:

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.

Usually this error is followed by a "send" and 2 "receive" including a checksume error

Send: N119704 G1 X105.33 Y101.298 E1321.08073*82
Recv: Error:checksum mismatch, Last Line: 119702
Recv: Resend: 119703

Fortunately, it does'nt block all printing and the printer continues. But this problem can cause problems on my prints, maybe you have seen this problem before? Is it better to buy an RPI3 / 4? Do you want me to upload the logs?

9

You could try a different USB cable between the printer and the pi; not too long and with ferrite beads at both ends.

1 Like