printer returning "buffer overflow" responses and quitting

[leofaoro]

What were you doing?

Sent a gcode file to print. It goes thorugh the GPX plugin though. Happens with any file I submit.

What did you expect to happen?

terminal showing each command followed by OK.

What happened instead?

Every 10th command or soo it returns Recv: // echo: buffer overflow and eventually the printer just stops responding.

Branch & Commit or Version of OctoPrint

1.2.11 master

Printer model & used firmware incl. version

Qidi Tech I running Sailfish 7.8 (R1234)

Browser and Version of Browser, Operating System running Browser

Windows 7, Chrome 48.

Link to octoprint.log Link to contents of terminal tab or serial.log Link to GPX log all here: https://www.dropbox.com/s/kpehfih3i7859nv/temp.zip?dl=0

Screenshot(s) showing the problem:

I have read the FAQ.

[markwal]

Buffer overflow is normal. In fact, it's desirable because it means that OctoPrint is keeping up with the printer and keeping the movement buffer full. The printer stop responding part however, is not desirable.

[markwal]

The end of serial.log shows a print working fine and then a cancel key pressed by the user, and then a timeout trying to talk to the printer after the cancel (which isn't entirely unexpected since how fast the firmware reacts to a cancel can be variable). Does your gcode script settings in OctoPrint have an "M84" in the cancel box? If so, you should remove that because it was trying to send the M84 that caused the timeout.

Then, it got stuck when trying to connect. It looks like it's able to read temperatures from the printer but the printer is replying "not ready" which is probably state left over from the cancel on the printer.

[markwal]

The plugin_GPX.log also complains about a line in your gpx.ini file "actual_filament_diameter = 0", which I haven't seen before. I thought it should delete that line when you set it back to 0. So that's a bug.

[markwal]

The workaround for that last issue is to go to Settings->GPX, select the 0 in the "Actual filament diameter" box and hit delete so that it is blank rather than 0. Then click save.

The workaround for the lockup after cancel (if deleting the cancel gcode script doesn't work) is to, more than likely, cancel the print from the LCD panel. I'm going to try and reproduce this problem.

[leofaoro]

Hi Mark Thanks for looking into this. For your first question, here's the "cancel" code:

; disable motors
M84

;disable all heaters
{% snippet 'disable_hotends' %}
{% snippet 'disable_bed' %}
;disable fan
M106 S0

I haven't modified it. I will remove the M84 command. Further, I pressed cancel only after a few minutes of the printer not receiving or doing anything, so the procedure stopped hung already before I pressed cancel.

For your second comment regarding the filament width setting, in my settings I have it empty, see screenshot below

[markwal]

Actually nuke everything out of the cancel script. Sailfish when it receives the cancel command turns off the heaters and motors already. I added an M84 to mine and tried to see if that gave me a timeout on cancel, but so far no luck.

I'm not sure what's going on with the filament width. Huh...

[leofaoro]

Ok. I'm using a Raspberry Pi Zero so not sure it has enough computing power to run all this.

[markwal]

I don't think there's anything actionable on this anymore. If I'm wrong, feel free to clarify and I'll reopen.