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)
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
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 M11035
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor
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.
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.
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.