Selecting print causes Repetier Server disconnect
Hi,
I am using Repetier Server Pro 0.93.1 and my printer uses an SKRv1.4 controller with Marlin 2.0.5.3 firmware.
Often when I select the print icon next to the item I wish to print on the print tab, the server disconnects from my device temporarily and the print job is put in the queue and not sent to the printer. Selecting print for the queued job causes the temporary disconnect each time it is selected. Using the LCD/knob (firmware controller) before selecting print from Repetier Server seems to contribute to the issue, but I am not certain. Let me know if you need any logs (and how to turn them on).
Thanks.
I am using Repetier Server Pro 0.93.1 and my printer uses an SKRv1.4 controller with Marlin 2.0.5.3 firmware.
Often when I select the print icon next to the item I wish to print on the print tab, the server disconnects from my device temporarily and the print job is put in the queue and not sent to the printer. Selecting print for the queued job causes the temporary disconnect each time it is selected. Using the LCD/knob (firmware controller) before selecting print from Repetier Server seems to contribute to the issue, but I am not certain. Let me know if you need any logs (and how to turn them on).
Thanks.
Comments
Especially run
and check if it returns 0x0. You can also check /var/lib/Repetier-Server/logs/server.log if you see printer disconnects which is what can happen on undervoltage.
/var/lib/Repetier-Server/logs/server.log hasn't been updated since 2019 with the last entry: "2019-06-18 15:29:34: error:WifiManager::scanMode:Syntax error", not sure if this is because its logging somewhere else, or because of another issue. Ran vcgencmd get_throttled and got 0x0. My Pi is actively cooled and rarely exceeds 50degC on CPU and GPU and I use the recommended genuine 5.1V power supply. The only time I get the disconnect is on pressing the print icon, I can do everything else from Repetier-Server Webapp, set temps, home, move, extrude, etc with no problems. The SKRv1.4 is configured to get power from the power supply not USB port so that should not contribute either.
Thanks.
Your power situation sounds very good.
Since it happens always on print start you should enable logging and see which commands got send to printer until disconnect. Also enable regular logging and see messages from firmware on next connect. At least old marlin showed reset reason on start. One guess is that one of the commands you send causes a reset on firmware side. Especially now that server side is more likely. Never the less also check /var/log/syslog at the time of disconnect. Linux also disconnects usb on back EMF from printer.
Once you see last 20 commands being send you can replay them manually and see if any of these would cause the disconnect. Typical candidates are enabling bed and extruder. Here also the timing between them might be important. So enabling one at a time with delay could work and both same time would cause a brown out if printer cpu and reset for example.
Ok captured server.log.0 below:
I also enabled logging, and the log file is 0 byte, so nothing appears to be going to the printer.
connected.log contains:
...
> 16:05:41.559: T:200.00 /200.00 B:60.05 /60.00 @:33 B@:25
...
Thanks.
For comparison when selecting print does work, server.log.0 contains:
Seems to be more reliable if I start Repetier-Server before I power on the printer.
Thanks.
ps aux | grep ssh
you would see it just started and das a differed pid then before the print start.
If it is a crash please follow https://www.repetier-server.com/knowledgebase/debugging-crashes-hangs-on-linux/ and send me the backtrace after the crash. There I can see exactly where it crashed and might also find our why. All just in case it is a crash.
Repetier-Server is definitely crashing the instant I select a print. I can make it crash easily. However if I start Repetier-Server first then power on the printer and perform all actions from within Repetier-Server webapp it does not crash. I have sent the crash logs to repetierdev@gmail.com as requested in the debugging page.
Thanks.