When I connect the printer USB to the OCTOPI, the Neptune printer ceases to know where HOME is. Especially the Z controls. I have to reset the printer completely to get it back home.
The only solution at the moment is to leave it unplugged from Octoprint.
octoprint.log (123.3 KB)
Sure
I get the printing bed leveled using the method the manufacture states. I can print using the USB card and the prints come out perfect. (Well as perfect as they can using melted plastic...)
When I tie in the OCTOPI and print using it, the Z-axis goes off. (See picture for one of them.)
It's like whenever I start the OCTOPRINT, wherever the head is, it assumes as HOME.
I had the head halfway up and tried using it... The Z-axis home was where I started it, not where the limit switches tell it to be.
I am assuming this is something in setup that I need to change... Perhaps it's sending a code to the printer when I connect that is wrong?
Hello @James_McDowell!
Can you share the start Gcode of the slicer and, if you have, the start code in OctoPrint?
Usually you have a homing sequence in the very start of the print.
What happens if you run G28 Z
in the OctoPrint terminal?
This is the gcode file that the Cura program creates for this printer.
Not sure where startup would be for Octoprint.
;FLAVOR:Marlin
;TIME:8018
;Filament used: 5.98411m
;Layer height: 0.2
;Generated with Cura_SteamEngine master
M140 S65
M105
M190 S65
M104 S205
M105
M109 S205
M82 ;absolute extrusion mode
G28 ;home
G1 Z15.0 F6000 ;Move the platform down 15 mm
;Prime the extruder
G92 E0
G1 F200 E3
G92 E0
G92 E0
G1 F4200 E-7
;LAYER_COUNT:111
;LAYER:-6
M107
G0 F7200 X94.065 Y71.07 Z0.36
This is what the printer says when it starts...
Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: [u'/dev/ttyUSB0']
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x70cd69d0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Send: N0 M110 N0125
Recv:
Baudrate test retry #1
Recv: Resend:1
Send: N0 M110 N0125
Recv: ok
Changing monitoring state from "Detecting baudrate" to "Operational"
Recv: Error:Wrong checksum
Send: N0 M110 N0125
Recv:
Recv: Resend:1
Recv: ok
Recv:
Send: N1 M11539
Recv: Resend:1
Recv: ok
Recv: Error:Wrong checksum
Send: N1 M11539
Recv:
Recv: Resend:1
Recv: ok
Recv: ok
Send: N1 M11539
Recv: wait
Recv: ok 1
Recv: FIRMWARE_NAME:Robin
Send: N2 M21*18
Recv: Printed filament:243.77m Printing time:2 days 17 hours 19 min
Recv: PrinterMode:FFF
Recv: skip 1
Recv: ok
Recv: skip 1
Recv: ok
Recv: ok 2
Recv: wait
Recv: wait
Send: M105
Recv: T:28.37 /0 B:26.63 /0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Communication timeout while idle, 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: M105
Recv: ok T:28.37 /0 B:26.51 /0 B@:0 @:0
Send: M105
Recv: ok T:28.37 /0 B:26.51 /0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: M105
Recv: ok T:28.37 /0 B:26.63 /0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: M105
Recv: ok T:28.37 /0 B:26.74 /0 B@:0 @:0
Recv: wait
Recv: wait
Recv: wait
Recv: wait
Send: M105
Recv: ok T:28.26 /0 B:26.74 /0 B@:0 @:0
That's a bit weird:
OctoPrint starts to communicate and and the printer reacts with nothing.
And then the printer requires line 1 again. Line 1 has not been send yet, just line 0.
OctoPrint resends line 0 and the printer says: ok.
And the the printer immediately replies with Error: Wrong checksum.
And this goes on and on. Either there is a bug in the firmware or the printer receives crap (that's interesting because the line to OctoPrint seems to be ok)
You may check the USB cable, maybe try this: Put tape on the 5V pin - Why and how , you also may have a look on your firmware.
There maybe could be a slight possibility, that there is a fault on the printer board.
1 Like
I think the issue IS the printer itself. I have tried with Astroprint as well. As soon as it's connected to any terminal, it gets stupid.