Printer Disconnects Partway Through First Layer
I've been working to get Repetier Server setup to monitor prints on a gCreate gMax 2 Pro and have had an issue where the print will fail after getting partway through the first layer. After a couple minutes the printer might or might not reconnect but I would like to avoid having to wonder if the print will finish or not. I'm running off of a Windows laptop and have tried all the USB ports and have assigned the printer to different COM ports to see if that was an issue.
Connection Settings:
Ping-Pong Mode - On
BAUD Rate - 115200
Continue Print After Fast Reconnect - On
Buffer Size - 63
Communication Timeout - 25s
Here's a copy of the log from the most recent failure:
If you have any ideas, that would be great!
Connection Settings:
Ping-Pong Mode - On
BAUD Rate - 115200
Continue Print After Fast Reconnect - On
Buffer Size - 63
Communication Timeout - 25s
Here's a copy of the log from the most recent failure:
Recv:16:47:56.324: X:29.1990 Y:290.5460 Z:0.3600 E:3372.7017 Count X:3759 Y:24667 Z:582
Recv:16:47:58.330: X:29.1990 Y:290.5460 Z:0.3600 E:3372.7017 Count X:9738 Y:30645 Z:800
Recv:16:48:00.335: X:154.8790 Y:415.0950 Z:0.3600 E:3393.5029 Count X:9230 Y:30048 Z:781
Recv:16:48:02.324: X:154.8790 Y:415.0950 Z:0.3600 E:3393.5029 Count X:3198 Y:24015 Z:542
Recv:16:48:04.330: X:29.1990 Y:288.2830 Z:0.3600 E:3414.4919 Count X:6845 Y:27572 Z:705
Mesg:16:48:32.122: Warning: Communication timeout - resetting communication buffer.
Mesg:16:48:32.122: Connection status: Buffered:41, Manual Commands: 2, Job Commands: 5000
Mesg:16:48:32.122: Buffer used:41 Enforced free byte:0 lines stored:1
Mesg:16:48:58.131: Warning: Communication timeout - resetting communication buffer.
Mesg:16:48:58.131: Connection status: Buffered:17, Manual Commands: 2, Job Commands: 5000
Mesg:16:48:58.131: Buffer used:17 Enforced free byte:0 lines stored:1
Mesg:16:49:24.142: Warning: Communication timeout - resetting communication buffer.
Mesg:16:49:24.142: Connection status: Buffered:25, Manual Commands: 2, Job Commands: 5000
Mesg:16:49:24.142: Buffer used:25 Enforced free byte:0 lines stored:1
Mesg:16:49:24.142: Warning: Too many timeouts without response - disabling timeout message!
Mesg:16:52:26.192: Looks like printer is not powered any more. Closing connection.
Mesg:16:52:29.939: Printer reset requested false
Mesg:16:52:29.939: Dtr: false Rts: false
Mesg:16:52:29.970: Dtr: true Rts: true
Recv:16:52:31.883: Response while unconnected://action:notification M117 Finished
Recv:16:52:31.883: Connection verified by:ok
Recv:16:52:31.913: FIRMWARE_NAME:Marlin 2.0.9.3 (Mar 8 2022 11:23:16) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:gMax 2 PRO Copperhead EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv:16:52:31.913: Cap:QUOTED_STRINGS:1
Recv:16:52:31.913: Cap:SERIAL_XON_XOFF:0
Recv:16:52:31.913: Cap:BINARY_FILE_TRANSFER:0
Recv:16:52:31.913: Cap:EEPROM:1
Recv:16:52:31.913: Cap:VOLUMETRIC:1
Recv:16:52:31.913: Cap:AUTOREPORT_POS:1
Recv:16:52:31.913: Cap:AUTOREPORT_TEMP:1
Recv:16:52:31.913: Cap:PROGRESS:0
Recv:16:52:31.913: Cap:PRINT_JOB:1
Recv:16:52:31.913: Cap:AUTOLEVEL:1
Recv:16:52:31.913: Cap:RUNOUT:1
Recv:16:52:31.913: Cap:Z_PROBE:1
Recv:16:52:31.913: Cap:LEVELING_DATA:1
Recv:16:52:31.913: Cap:BUILD_PERCENT:1
Recv:16:52:31.913: Cap:SOFTWARE_POWER:0
Recv:16:52:31.913: Cap:TOGGLE_LIGHTS:0
Recv:16:52:31.913: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv:16:52:31.913: Cap:EMERGENCY_PARSER:1
Recv:16:52:31.913: Cap:HOST_ACTION_COMMANDS:1
Recv:16:52:31.913: Cap:PROMPT_SUPPORT:1
Recv:16:52:31.913: Cap:SDCARD:1
Recv:16:52:31.913: Cap:REPEAT:1
Recv:16:52:31.913: Cap:SD_WRITE:1
Recv:16:52:31.913: Cap:AUTOREPORT_SD_STATUS:1
Recv:16:52:31.913: Cap:LONG_FILENAME:1
Recv:16:52:31.913: Cap:EXTENDED_M20:1
Recv:16:52:31.913: Cap:THERMAL_PROTECTION:1
Recv:16:52:31.913: Cap:MOTION_MODES:0
Recv:16:52:31.913: Cap:ARCS:1
Recv:16:52:31.913: Cap:BABYSTEPPING:1
Recv:16:52:31.913: Cap:CHAMBER_TEMPERATURE:0
Recv:16:52:31.913: Cap:COOLER_TEMPERATURE:0
Recv:16:52:31.913: Cap:MEATPACK:0
Recv:16:52:31.913: Cap:CONFIG_EXPORT:0
Recv:16:52:31.913: area:{full:{min:{x:-40.0000,y:-3.0000,z:0.0000},max:{x:458.0000,y:458.0000,z:610.0000}},work:{min:{x:0.0000,y:0.0000,z:0.0000},max:{x:458.0000,y:458.0000,z:610.0000}}}
Recv:16:52:31.913: X:157.1420 Y:415.0950 Z:50.3600 E:0.0000 Count X:12571 Y:33208 Z:40288 (2)
Recv:16:52:40.832: X:-40.0000 Y:458.0000 Z:50.3600 E:0.0000 Count X:-3200 Y:36640 Z:40288 (2)
Recv:16:55:44.848: echo:M112 Shutdown
Mesg:16:55:44.880: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer. Eventually running print is stopped.
Mesg:16:55:44.880: Error:Printer halted. kill() called!
Mesg:16:55:44.880: Firmware stopped! You can only send host and shell commands until you hit emergency stop or restart the printer. Eventually running print is stopped.
Mesg:16:55:44.880: //action:poweroff
Mesg:16:56:48.269: Connection closed by os.
If you have any ideas, that would be great!
Comments
Other reason might be electrical nature disturbing communication. If that is always on first layer it might be when heated bed stops heating. You might try a print without heating to see if heaters disturb communication. You get lots of cild extrusion prevented I guess but that is ok then.
And last on reconnect it gets "M112" from the reconnect that was meant for before. It does not reset as it did in the past so in server setup you might want to change "Emergency Solution" to only try to reset.
I have tried prints with and without the heated bed to no avail.
Changed "Emergency Solution" to reconnect only and that didn't help.
The model I have been trying to print is very large (18in x 18in x 4in) and has very long moves on the first layer. I've upped the Communication Timeout to 45s to see if that was the issue. I was able to get a much smaller print to fully complete using these settings but no such luck on two different larger prints. I waited a bit this time for the printer to reconnect 5ish minutes later and attempted to resume the print. The printer again disconnected a couple lines later. I've included this log below.
You also seem to have the checkbox "Port is visible when firmware is not running" checked. This is for printers using e.g. RAMBO board where the serial is always visible even if no communication is possible. Normally Prusa MKS. Should be disabled normally as it closes connection after 10 sequential errors. On the other hand this causes the restart after some minutes, also it was not meant for that:-)
What you clearly see is that after every g-code send you get an "ok" as answer. When you see " echo:busy: processing" it means firmware is busy with a longer move and "ok" will come a bit later. Valid for timeout seconds. When you have this you set timeout normally to 3 seconds. Longer delays are communicated by firmware by busy every 2s. At the point where it starts hanging you get no busy and no ok any more. It is just like firmware stopped sending anything, which is the cause of the problem. Log is not 100% complete as you have filters enabled for temperature responses/commands. What I miss is that after each timeout you should see firmware sending a command - but I assume it is a M105 that you filtered. Starting 17:33:30.900 I also see other commands getting send.
Haven't seen microsoft chips for serial so far - guess it is the microsoft driver. Device manager sounds correct. There are several tabs and in one you can see many attributes that show the device. But since it is not FTDI driver that is not that relevant.
You can try a different/shorter/better protected usb cable or other usb ports. Try usb 2 not 3. Normally it works all the time if communication is up to standard, but with noise etc it seems they do not always recover from errors. Not the first one I observer stopping to send data until reconnect. On linux systems we have a usb reconnect on timeout for such issues where we disconnect usb port software side to reset driver. Unfortunately not on windows.