Printing stops and continues to print EXTREMELY slow.
I have encountered this problem 2 times in the same day.
I have 2 CR-10 V3 and 2 Artillery Sidewinder X1 + 1 webcam connected to a Raspberry Pi and a USB hub.
Generally shortly after starting one of the CR-10 V3s it begins to print extremely slowly, as if the commands take a loooong time to arrive.
I have 2 CR-10 V3 and 2 Artillery Sidewinder X1 + 1 webcam connected to a Raspberry Pi and a USB hub.
Generally shortly after starting one of the CR-10 V3s it begins to print extremely slowly, as if the commands take a loooong time to arrive.
I leave an example with the date stamp so you can see what I'm talking about.
Send:16:11:52.302: M117 ETA 18:43:43 day 1
Send:16:11:52.302: N1199673 G1 X89.854 Y96.556 E1196.66928
Send:16:11:56.303: N1199674 G1 X90.028 Y96.342 E1196.6968
Send:16:11:56.304: N1199675 G1 X90.2 Y96.152 E1196.72237
Send:16:12:00.306: N1199676 G1 X90.369 Y95.991 E1196.74566
Send:16:12:00.306: N1199677 G1 X90.62 Y95.783 E1196.77819
Send:16:12:04.307: M117 ETE 02:31:51
Send:16:12:04.307: N1199678 G1 X90.743 Y95.695 E1196.79328
Send:16:12:08.308: N1199679 G1 X91.03 Y95.517 E1196.82698
Send:16:12:08.309: N1199680 G1 X91.282 Y95.391 E1196.85509
Send:16:12:12.317: M117 Layer 12/388
Send:16:12:12.317: N1199681 G1 X91.466 Y95.316 E1196.87492
Send:16:12:16.327: N1199682 G1 X91.667 Y95.247 E1196.89612
Send:16:12:16.327: N1199683 G1 X91.863 Y95.192 E1196.91643
Send:16:12:20.334: N1199684 G1 X92.081 Y95.144 E1196.93871
Send:16:12:20.335: N1199685 G1 X92.222 Y95.122 E1196.95295
Send:16:12:24.345: M117 ETA 18:44:13 day 1
Comments
Printer is new and creality don't release source file for this printer yet.
When you send M115 what firmware does it show? Did they show marlin 2 as firmware?
Since that helps in last server version for linux we have added the option to reset usb connection on timeouts in serial communication definition. That is nearly the same just you do not need to watch the print constantly.
Now sometimes it manages to get the print back and continue but other times it fails and the print appears as finished on the printer when it is not true.
In this case, the prints on X3 and X4 (Artillery X1) continued but on V3 (Cr-10 V3) it failed to continue.
I leave the V3 command console log, the syslog.log and server.log
None indicate power problems.
USB cables have the VCC pin capped to avoid draining power to the printers.
Problems happen every day.
2020-10-14 08:19:46: start printjob 9h44m232g-_B-Acostadox6 on printer X4
2020-10-14 08:19:49: Websocket opened
2020-10-14 08:19:51: start printjob 9h44m232g-_B-Acostadox6 on printer X3
2020-10-14 08:19:58: Websocket opened
2020-10-14 08:20:00: start printjob 8h58m184g-_D-Colgandox4 on printer V3
2020-10-14 15:54:11: usbreset: /usr/bin/sudo /usr/local/Repetier-Server/bin/usbreset /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-port0
2020-10-14 15:54:11: usbreset: /usr/bin/sudo /usr/local/Repetier-Server/bin/usbreset /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0-port0
2020-10-14 15:54:11: usbreset: /usr/bin/sudo /usr/local/Repetier-Server/bin/usbreset /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0
2020-10-14 15:54:11: error: Reading serial conection failed: End of file. Closing connection.
2020-10-14 15:54:11: error: Reading serial conection failed: End of file. Closing connection.
2020-10-14 15:54:11: error: Reading serial conection failed: End of file. Closing connection.
2020-10-14 15:54:11: Connection closed during print ... trying reconnect for 10 seconds to continue ...
2020-10-14 15:54:11: Port closed for X3
2020-10-14 15:54:11: Connection closed during print ... trying reconnect for 10 seconds to continue ...
2020-10-14 15:54:11: Connection closed during print ... trying reconnect for 10 seconds to continue ...
2020-10-14 15:54:11: Port closed for V3
2020-10-14 15:54:11: Port closed for X4
2020-10-14 15:54:11: Connection closed: V3
2020-10-14 15:54:11: Connection closed: X4
2020-10-14 15:54:11: Connection closed: X3
2020-10-14 15:54:12: Connection continued: V3
2020-10-14 15:54:12: Connection continued: X3
2020-10-14 15:54:12: Connection continued: X4
2020-10-14 17:17:21: Websocket opened
2020-10-14 17:21:40: error fetchTextFromWeb:Timeout: connect timed out: 85.93.88.136:80
2020-10-14 17:21:40: Websocket opened
2020-10-14 17:23:06: Update webcam list
2020-10-14 17:24:54: error fetchTextFromWeb:Timeout: connect timed out: 85.93.88.136:80
2020-10-14 17:24:54: Closing websocket for missing ping
Oct 14 15:53:46 Repetier-Server systemd[1]: systemd-timedated.service: Succeeded.
Oct 14 15:54:04 Repetier-Server kernel: [28163.815938] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Oct 14 15:54:04 Repetier-Server kernel: [28163.816086] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
Oct 14 15:54:04 Repetier-Server kernel: [28163.816204] ch341-uart ttyUSB2: usb_serial_generic_read_bulk_callback - urb stopped: -32
Oct 14 15:54:11 Repetier-Server kernel: [28170.934299] ch341-uart ttyUSB2: ch341-uart converter now disconnected from ttyUSB2
Oct 14 15:54:11 Repetier-Server kernel: [28170.934340] ch341 1-1.1:1.0: device disconnected
Oct 14 15:54:11 Repetier-Server kernel: [28170.934960] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
Oct 14 15:54:11 Repetier-Server kernel: [28170.935000] ch341 1-1.4:1.0: device disconnected
Oct 14 15:54:11 Repetier-Server kernel: [28170.936389] ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
Oct 14 15:54:11 Repetier-Server kernel: [28170.936458] ch341 1-1.3:1.0: device disconnected
Oct 14 15:54:12 Repetier-Server kernel: [28171.252686] usb 1-1.1: reset full-speed USB device number 6 using xhci_hcd
Oct 14 15:54:12 Repetier-Server kernel: [28171.388031] ch341 1-1.1:1.0: ch341-uart converter detected
Oct 14 15:54:12 Repetier-Server kernel: [28171.393540] usb 1-1.1: ch341-uart converter now attached to ttyUSB0
Oct 14 15:54:12 Repetier-Server kernel: [28171.484619] usb 1-1.4: reset full-speed USB device number 5 using xhci_hcd
Oct 14 15:54:12 Repetier-Server kernel: [28171.618124] ch341 1-1.4:1.0: ch341-uart converter detected
Oct 14 15:54:12 Repetier-Server kernel: [28171.623663] usb 1-1.4: ch341-uart converter now attached to ttyUSB1
Oct 14 15:54:12 Repetier-Server kernel: [28171.712889] usb 1-1.3: reset full-speed USB device number 4 using xhci_hcd
Oct 14 15:54:12 Repetier-Server kernel: [28171.858598] ch341 1-1.3:1.0: ch341-uart converter detected
Oct 14 15:54:12 Repetier-Server kernel: [28171.866141] usb 1-1.3: ch341-uart converter now attached to ttyUSB2
Oct 14 15:54:19 Repetier-Server dbus-daemon[352]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.1893' (uid=0 pid=26788 comm="timedatectl ")
Oct 14 15:54:19 Repetier-Server systemd[1]: Starting Time & Date Service...
Oct 14 15:54:19 Repetier-Server dbus-daemon[352]: [system] Successfully activated service 'org.freedesktop.timedate1'
Oct 14 15:54:19 Repetier-Server systemd[1]: Started Time & Date Service.
Oct 14 15:54:49 Repetier-Server systemd[1]: systemd-timedated.service: Succeeded.
Oct 14 15:55:22 Repetier-Server dbus-daemon[352]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.1897' (uid=0 pid=26913 comm="timedatectl ")
Here I see server detects the hang and reconnects resetting the usb connection. It works in the sense that connection gets reusable afterwards. But it has the side effect of resetting the printer. Are you already using 0.94.3? Older versions had a problem with remembering last state. If you are already on that version try what happens if you set dtr/rts to low on connect (if it is possible to connect that way, not possible with al printers). We need a setting that does not restart on reconnect. As a simple test unplug usb cable and replug immediately during test print. If it does only reconnect and continue the setting is correct. There is always the chance that we have no possibility to solve the reset if the driver toggles the state on initialization for example.
Your logs are all from different times. Server did reconnect
Mesg:15:38:30.069: Dtr: true Rts: true
server.log shows 3 connections being reset at 2020-10-14 15:54:11 but none at that time.
syslog is from same time.
So are these 2 different pi?
Is the problem with ch341 driver a raspberry pi problem? I plan to centralize everything on a Windows or Linux PC. Would that solve the problem for me?
PS: I assume that restarting one printer and interrupting the work of the others may be related to the method of identifying the ports. As I have several of the same model, they all have the same ID so I have to identify them by path, sometimes they exchange profile one to another within the same model but never between different models. That is why I proposed to check this value when connecting to Marlin, it would require modifying the firmware for each machine but it could be worth it if in the future for example you develop a module that allows you to follow the printing times and establish a maintenance schedule based on the hours of use. Or the filament stock module. UUID: cede2a2f-41a2-4748-9b12-c55c62f367ff
So far I know there seem to be several drivers and versions depending on linux kernel version.
First thing I'd do is testing if you can reconnect usb without resetting during print with some dtr/rts settings. Some drivers force a fixed state on connect and if dtr toggles printers reset. So in that case it is important to start with what the driver has on init. Then you would still have the problem but it gets fixed within seconds at least so print is not ruined.
Also what might help is a usb hub and very short usb cables from printer to hub. That way pi gets signals from hub which is maybe less critical. But that is just a test - no idea if that makes it better. After all it works most of the time so my guess is that at some point there is a communication error that makes the hang happen. But that just a guess as I have no test hardware and no idea how the driver is written or works.
This week I changed the parameters you gave me and apparently they have worked. I have had no problems in 4 days in a row.
I have made two changes so I am not sure what the solution was but I changed the dtr / rts values to low and I also bought new 3 meter USB cables which cost triple the old ones.
I am happy.
I have recommended the software to the 3D printing group in Argentina so maybe some sales will come from my beaten country.
Disabled status updates for the printer, and the print runs perfectly fine.
but there is a delay where no moves get send. Question is what is preventing this since we got a ok so are free to send. Do you have timelapse enabled and it comes from there? Also updating to 1.0.4 might be a good idea to have all known problems fixed.