OCTOPRINT / OCTOPI issue with ELEGOO Neptune Printer

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)

Can you clarify?

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 N0
125
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 M115
39
Recv: Resend:1
Recv: ok
Recv: Error:Wrong checksum
Send: N1 M11539
Recv:
Recv: Resend:1
Recv: ok
Recv: ok
Send: N1 M115
39
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.