Octoprint Errors at end of Job

Simplify3D sliced on a Windows 10 computer and transferred to Octoprint.

When running the print through Octoprint, it works fine up until the very end. Once the last layer has printed a communication error pops up indicating the the printer keeps requesting line XXXXXX again and again, and communication is stuck. It then disconnects but leaves the print head where it was last positioned. This results in the hot head melting the material in the immediate area, and if I don't catch it in time, not only does it create a localize blob, but it also becomes stuck to the head.

A newbie, so haven't done too much. Did search for possible fixes in the forum and online, swapped out USB cables, reloaded the program and even subscribed to the developer Octoprint 1.4.0 rc4

Logs (octoprint.log, serial.log or output on terminal tab, ... no logs, no support)

Example GCODE file
[Octoprint Log.log|attachment](upload://vrcLec11DJQrfjg5KMN_3DBenchy.gcode (2.6 MB) eHKqtoPJ.log) (9.7 KB)
OctoPrint version - Octoprint 1.4.0 rc4
OctoPi version - Version 0.17.0, running on Raspberry Pi 3 Model B Rev 1.2
Simplifiy#D Version 4.1.2
printer - QIDI X-one2
firmware - RepRap (Marlin/Repetier/Sprinter)

Hello @SafetyWiz!

Can you also share the logs (serial.log may be activated) and also the firmware response of M115 ?

Sorry, I did not have the serial log turned on. I do have the lSerial.log (8.8 KB) last bit of information from the Benchy print I did if that helps. If not I'll rerun it with the serial log turned on.
Send: M115
Recv: ok CBD make it.Date:Mar 5 2018 Time:14:46:07

serial.log.2020-02-12_21-36-46.log (3.1 MB)

This is the log for another print I did this evening that also closed the connection do to a "communication error" . Let me know if this helps.

Ok, the errors already start about 2.5 minutes after start printing.

2020-02-12 20:37:56,221 - Changing monitoring state from "Starting" to "Printing"
...
2020-02-12 20:40:15,308 - Recv: Resend:81
2020-02-12 20:40:15,322 - Recv: //last:80 curr:85 rcv:N85 M105*26

You may consider to check the USB connection: OctoPrint randomly loses connection to the printer with a "SerialException"
(The responses from Repetier are quite different than from Marlin)

Could you also please share the octoprint.log?

Also make sure you have these two plugins installed

because this looks like yet another case of this horribly broken firmware making the rounds and that might very well be the core issue here.

Swapped out serial cables, tried four different ones and installed both plugins which upon reboot, broke my ability to connect with the printer. Have been getting the following errors....

hanging monitoring state from "Detecting baudrate" to "Error: No more baudrates to test, and no suitable baudrate found."
Changing monitoring state from "Error: No more baudrates to test, and no suitable baudrate found." to "Offline (Error: No more baudrates to test, and no suitable baudrate found.)"
Connection closed, closing down monitor

I then checked the baudrate on the pi which indicated it is set at 9600. Changed the baudrate from auto to 9600 and attempted to reconnect, which then gave me the error...

Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x669c4bb0, open=True>(port='/dev/ttyUSB0', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M11035
No answer from the printer within the connection timeout, trying another hello
Send: N0 M110
35
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

I am now going to try reloading the pi server.

I ended up having to reinstall Octopi, can't say for sure what caused it, but it did happen after I installed those two plug ins, so...... I will try it again though just in case it had issues with the RC version. Also note that I did not re-install the RC version and have Version 1.3.12 installed at this time.

Anyway, It is now connecting and I have swapped out a new usb cable, one that is newer and I use with my Arduino. I reran benchy with the same results. It printed right up to the very last line. I have the logs and they are as follows.

_3DBenchy.gcode (2.6 MB)
Terminal text.log (9.6 KB)
seriallog-benchy.zip (2.8 MB)

The resend requests from the firmware still persist. That's bad.
So could you please share the complete octoprint.log. It contains much more information than the terminal text.

I did get the two plugins installed and it worked on Version 1.3.12. Re-ran the Bench print and still had the same problem. Below are the files from that print.

serial 2.zip (2.0 MB)
octoprint 2.zip (211.6 KB)

Following is the Octiprint log from the first run. Sorry about not having it the first time, didn't see it was to big to upload and didn't compress it.
octoprint-benchy.zip (202.4 KB)

As @foosel already wrote before, this firmware is really chaotic and does not stick to the most important conventions of RepRep firmware.
It's hard to find a solution.
You may have a look on this thread: Commands lost while waiting to warm up (Qidi X-ONE2) that deals with the problems of such firmware.

I am guessing then that this is not an issue that can be fixed with this machine.