When I start a print, everything goes fine until right after the initial test line. Right after, Octoprint disconnects from the printer and the print stops. I can immediately connect back to it and start prints and they will work as intended with no problems. Once everything goes off and back on, the same thing happens to the first print again. It worked fine for nearly a year but the past couple months has been problematic with it
What did you already try to solve it?
Completely redid my Gcode, added a whole new printer profile in Cura, changed from 5Ghz band on my router to the 2.4Ghz SSID (its very close to the router regardless).
Good point. Is there a recommended amount of plugins or something? I always assumed if it started freezing up or lagging, that that would be the indicator for too many. I def can removed a bunch though, but I will try the safe mode first for sure
Disabled a bunch of plugins yesterday and tried printing, it was working fine even after a restart though it did disconnect on the first print as usual. Tried a safe mode print and it also happened here, did the initial test line and then disconnected. But for some reason all prints are disconnecting now.
octoprint-systeminfo-20220307105930.zip (100.8 KB)
I included this 2nd zip just in case, but it might have all the same info as the 1st one. This was after about 3 or 4 disconnects in a row, and then even one after a reboot.
Edit:
So safe mode = 3 or 4 disconnects in a row (then I rebooted it)
Normal boot = 1 disconnect and then printed fine, but the working print isn't in the zip because I replied assuming it just wasn't working altogether.
2022-03-07 10:25:07,663 - octoprint.util.comm - INFO - Changing monitoring state from "Starting" to "Printing"
2022-03-07 10:25:10,362 - octoprint.util.comm - INFO - Externally triggered heatup detected
2022-03-07 10:28:42,154 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2022-03-07 10:36:15,080 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:36:45,273 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:36:57,624 - octoprint.util.comm - INFO - Externally triggered heatup detected
2022-03-07 10:41:49,997 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:41:52,001 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:41:54,006 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:41:56,010 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:41:58,015 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2022-03-07 10:42:00,020 - octoprint.util.comm - INFO - No response from printer after 6 consecutive communication timeouts, considering it dead.
Where is this externally triggered heatup coming from?
I don't even know what that means honestly, I haven't changed anything regarding temps besides within my slicer (Cura). There is nothing plugged into my printers motherboard, that isn't stock. Could it be something in my Gcode or Cura?
Send: N61 T0*13
Communication timeout while printing, 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: N62 M105*19
Communication timeout while printing, 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: N63 M105*18
Communication timeout while printing, 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: N64 M105*21
Communication timeout while printing, 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: N65 M105*20
Communication timeout while printing, 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: N66 M105*23
No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Your firmware stops responding after a select of the first extruder happens briefly after start of the print job. OctoPrint never gets an ok back in response to this command, and the printer also refuses to respond to its desperate attempts to get a temperature report, so after a while OctoPrint has to give up and call it a loss.
So, this is something that's your printers' doing. I've also never seen this firmware before:
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6383cef0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: JumpToApp0
Recv: JumpToApp1
Recv: MACHINE_TYPE:A30T UUID:ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ FIRMWARE_NAME:V1.xx.03
Recv: PROTOCOL_VERSION:V1.0 EXTRUDER_COUNT:3
Recv: BOARD_INFOR:Smartto MB V1.2
Recv: echo:SD init fail
Recv: echo:Unknown command:
Recv: ok
Send: N0 M110 N0*125
Changing monitoring state from "Connecting" to "Operational"
Recv: ok
Recv: ok
Send: N0 M110 N0*125
Recv: ok T:0.0 /0.0 B:0.0 /0.0 T0:0.0 /0.0 T1:0.0 /0.0 T2:0.0 /0.0 F:0 R:0 @:0 B@:0
Send: M115
Recv: ok
and our experience here with "whatever the printer came with" hasn't been too great all in all here (frankly, binary garbage in the firmware identification strings and non-standard M115 response already feel like red flags).
What I would suggest it to first of all get rid of any tool select commands you don't need (T0 if there's only one extruder) in your GCODE short term and see if this helps, and long term see if you can't flash a mainline Marlin build on this thing before you run into the next weird behaviour.
I thought that was weird too seeing that, but figured there might be a good explanation for it since I never looked in the sysinfo zip before. It might just be due to it being a Chinese printer and it might not be able to show Chinese characters . But yeah I agree, I would much prefer a stock Marlin build and would move onto it asap once it is confirmed safe/working. I know there is one on Github that is experimental, but haven't decided if I want to try it since I am worried about getting stuck on it or bricking the motherboard.
However one thing I am confused about, is the printer used to just work fine some months ago. So this problem didn't always exist, it might have started around 3 months ago or so, but the firmware has always stayed the same on the printer (I never updated it and it is the latest version from the website).
My Gcode does have the T0 command for sure, and I could def remove it. Though some way I did want to mess with multi-color prints. However I didn't add/remove the T0 when it was working. I used the same Cura profile, kept getting the problem, then basically started from scratch using the internet.
Could it simply be due to my Start Gcode blocking M105? I blocked it since my previous working one (which now also errors only on first print) so I assumed the new one doesn't need it. But I see in this error it has the M105 code. This is my start Gcode :
;M105 ;Report Temperatures
G28 ;home all axes
G29 ;auto bed leveling
G1 Z30 F300 ;move extruder up 30mm at 5mm/s
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
;M163 S0 P0.33 ;color mix extruder #1
;M163 S1 P0.33 ;color mix extruder #2
;M163 S2 P0.33 ;color mix extruder #3
;M164 S4 ;save color mix
;M104 S{print_temperature} ;Set extruder temperature
;M190 S{print_bed_temperature} ;Set bed temperature
M109 S{print_temperature} ;Set extruder temperature and wait
G92 E0 ;Reset extruder position(zero the extruded length)
G0 X1.5 Y20 F2100 ;Move nozzle at 35mm/s
G1 Z0.8 F300 ;Move Z Axis up little to prevent scratching of Heat Bed
G1 X180 E60 F300 ;Move nozzle at 5mm/s and extrude filament 60mm
G1 Z5 Y5 F300 ;Move Z Axis up 5mm at 5mm/s
G92 E0 ;Reset extruder position(zero the extruded length)
T0 ;Switch to the first extruder
If by "blocking M105" you mean the commented out first line there, no, that cannot cause this. M105 is a request that will generate a response immediately, not something like a settings modification or anything like this. And it's one of the most fundamental commands, so if this misbehaves, get rid of the firmware.
Apart from that I don't know what's up here either, all I can tell you is, the printer stops responding altogether after receiving that T0 there.
I blocked out the T0, and still had the problem. So I then wanted to do a clean install of OctoPi, which it still happened even while having T0 blocked. I guess my two options are to ask Geeetech support about it or go to a stock Marlin build right? I don't have a new systeminfo bundle cuz I was kinda hoping it just worked. But I can get another one today or tomorrow
octoprint-systeminfo-20220323121626.zip (32.5 KB)
I hope this has everything needed. I feel like in the past the services file would stay enabled throughout shutdowns and restarts, but now I feel like whenever Octoprint turns on it disables itself. Haven't been printing much lately but I went to print today and remembered how much this annoyed me lol.
I guess a worst case scenario I can probably do some kind of "fake" print to just start the "printing" process, but without the extruders and nozzle doing anything soon after startup to get the error and disconnect out of the way if there are no alternatives
Hi just curious, do you think a dummy gcode file like this would cause any problems for a printer? Basically I removed all temperatures and extruding, to hopefully, get the disconnect out right at the start and not have to pull away some filament oozing and so it saves me time.
M82 ;absolute extrusion mode
G28 ;home all axes
G29 ;auto bed leveling
G90 ;absolute positioning
M82 ;set extruder to absolute mode
G92 E0 ;Reset extruder position(zero the extruded length)
G91 ;relative positioning
G90 ;absolute positioning
G92 E0 ;Reset extruder position(zero the extruded length)
M84 ;disable motors
M104 S0 ;turn off extruder
M107 ;off fan
T0 ;Switch to the first extruder
M84 ;disable motors
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
. But yeah I agree, I would much prefer a stock Marlin build and would move onto it asap once it is confirmed safe/working. I know there is one on Github that is experimental, but haven't decided if I want to try it since I am worried about getting stuck on it or bricking the motherboard.