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 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

  • Looks like your timeout i set to 4 seconds. So after each timeout server sends 2 lines and waits firmware to send "ok" but this seems to not happen. If you enable ack in log you would see the "ok" at least as long as it works. Communication is synced with these responses so they are essential. If firmware stops sending them you get that pattern.
  • edited September 2020
    Can it be a problem with the usb cable?
    Can it be fixed in any way when that happens?

  • Do you have the firmware sources and are able to compile and upload them? I have a theory what it is, but that needs to recompile firmware with second serial for the display disabled.
  • Repetier said:
    Do you have the firmware sources and are able to compile and upload them? I have a theory what it is, but that needs to recompile firmware with second serial for the display disabled.

    Printer is new and creality don't release source file for this printer yet.
  • Ok see on https://www.creality.com/download the V3 is missing here.
    When you send M115 what firmware does it show? Did they show marlin 2 as firmware?
  • edited October 2020
    Repetier said:
    Do you have the firmware sources and are able to compile and upload them? I have a theory what it is, but that needs to recompile firmware with second serial for the display disabled.
    Now it's happening to me on my two Artillery X1s Stock Firmware.

    Fast disconnect and reconnect cable solve the problem until the next time it happens.
    printing resumes immediately.




  • Repetier said:
    Ok see on https://www.creality.com/download the V3 is missing here.
    When you send M115 what firmware does it show? Did they show marlin 2 as firmware?

    CR-10 V2 is the same firmware than V3 except that it has direct drive.

    See that:
    22 Jul, 2020
    CR-10 V2_1.1.6V_Source Code.zip


  • >Fast disconnect and reconnect cable solve the problem until the next time it happens.
    printing resumes immediately.

    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.
  • edited October 2020
    The problem keeps happening.

    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

    This happens on my Raspberry Pi 3B and on Pi4.
    None indicate power problems.
    USB cables have the VCC pin capped to avoid draining power to the printers.

    I have a farm and I print 24 hours.

    Problems happen every day.

    COMANDS LOG:

    Mesg:15:38:22.292: Warning: Communication timeout - resetting communication buffer.
    Mesg:15:38:22.292: Connection status: Buffered:85, Manual Commands: 1, Job Commands: 5000
    Mesg:15:38:22.292: Buffer used:85 Enforced free byte:43 lines stored:2
    Mesg:15:38:26.303: Warning: Communication timeout - resetting communication buffer.
    Mesg:15:38:26.303: Connection status: Buffered:68, Manual Commands: 0, Job Commands: 5000
    Mesg:15:38:26.303: Buffer used:68 Enforced free byte:43 lines stored:2
    Mesg:15:38:29.309: Reconnecting usb port to fix serial driver problems ...
    Mesg:15:38:29.362: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    Mesg:15:38:30.069: Dtr: true Rts: true
    Mesg:15:38:30.072: Connection continued
    Recv:15:38:31.579: start
    Recv:15:38:31.579: echo: External Reset
    Recv:15:38:31.579: Marlin 1.1.6.0
    Recv:15:38:31.579: echo: Last Updated: 2020-04-29 | Author: CR-10 V3
    Recv:15:38:31.579: echo:Compiled: Apr 29 2020
    Recv:15:38:31.579: echo: Free Memory: 2002 PlannerBufferBytes: 1232
    Recv:15:38:31.579: echo:EEPROM version mismatch (EEPROM=? Marlin=V41)
    Recv:15:38:31.579: echo:Hardcoded Default Settings Loaded
    Recv:15:38:31.579: echo: G21 ; Units in mm
    Recv:15:38:31.579: echo: M149 C ; Units in Celsius
    Recv:15:38:31.580: echo:Filament settings: Disabled
    Recv:15:38:31.580: echo: M200 D1.75
    Recv:15:38:31.580: echo: M200 D0
    Recv:15:38:31.580: echo:Steps per unit:
    Recv:15:38:31.580: echo: M92 X80.00 Y80.00 Z400.00 E382.14
    Recv:15:38:31.580: echo:Maximum feedrates (units/s):
    Recv:15:38:31.580: echo: M203 X500.00 Y500.00 Z5.00 E25.00
    Recv:15:38:31.580: echo:Maximum Acceleration (units/s2):
    Recv:15:38:31.580: echo: M201 X500 Y500 Z100 E1000
    Recv:15:38:31.580: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    Recv:15:38:31.580: echo: M204 P500.00 R500.00 T1000.00
    Recv:15:38:31.580: echo:Advanced: S<min_feedrate> T<min_travel_feedrate> B<min_segment_time_ms> X<max_xy_jerk> Z<max_z_jerk> E<max_e_jerk>
    Recv:15:38:31.581: echo: M205 S0.00 T0.00 B20000 X10.00 Y10.00 Z0.40 E5.00
    Recv:15:38:31.581: echo:Home offset:
    Recv:15:38:31.581: echo: M206 X0.00 Y0.00 Z0.00
    Recv:15:38:31.581: echo:Material heatup parameters:
    Recv:15:38:31.581: echo: M145 S0 H185 B45 F255
    Recv:15:38:31.581: M145 S1 H240 B70 F255
    Recv:15:38:31.581: echo:PID settings:
    Recv:15:38:31.581: echo: M301 P19.47 I1.59 D59.40
    Recv:15:38:31.581: echo: M304 P201.86 I10.67 D954.96
    Mesg:15:38:35.594: Warning: Communication timeout - resetting communication buffer.
    Mesg:15:38:35.594: Connection status: Buffered:100, Manual Commands: 2, Job Commands: 1
    Mesg:15:38:35.594: Buffer used:100 Enforced free byte:10 lines stored:8
    Recv:15:38:38.314: echo:TF init fail (2)
    Recv:15:38:38.364: FIRMWARE_NAME:Marlin Creality 3D SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:CR-10 V3 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
    Recv:15:38:38.366: Cap:EEPROM:1
    Recv:15:38:38.369: Cap:AUTOREPORT_TEMP:1
    Recv:15:38:38.370: Cap:PROGRESS:0
    Recv:15:38:38.372: Cap:PRINT_JOB:1
    Recv:15:38:38.372: Cap:AUTOLEVEL:0
    Recv:15:38:38.372: Cap:Z_PROBE:0
    Recv:15:38:38.375: Cap:LEVELING_DATA:0
    Recv:15:38:38.377: Cap:SOFTWARE_POWER:0
    Recv:15:38:38.378: Cap:TOGGLE_LIGHTS:0
    Recv:15:38:38.380: Cap:CASE_LIGHT_BRIGHTNESS:0
    Recv:15:38:38.384: Cap:EMERGENCY_PARSER:0
    Recv:15:38:38.417: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
    Recv:15:38:38.423: Error:No Line Number with checksum, Last Line: 9
    Mesg:17:50:28.209: Connection closed by os.

    SERVER LOG:

    2020-10-14 08:19:42: Websocket opened
    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

    SYSLOG:

    Oct 14 15:53:16 Repetier-Server systemd[1]: Started Time & Date Service.
    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 ")





  • I see they use the ch341 driver which is so far the only one I know causing that problem.

    Mesg:15:38:29.309: Reconnecting usb port to fix serial driver problems ...
    Mesg:15:38:29.362: Connection closed by os during print ... trying reconnect for 10 seconds to continue ...
    Mesg:15:38:30.069: Dtr: true Rts: true
    Mesg:15:38:30.072: Connection continued
    Recv:15:38:31.579: start
    Recv:15:38:31.579: echo: External Reset

    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?
  • edited October 2020
    So are these 2 different pi?
    No. I have both running with different groups of printers. Both with the latest version. Logs you see are from Pi 4 with 3 printers. I have tried aggressive and conservative reconnection mode. The problem happened several times in two days, maybe I was wrong on the day or the problem happened several times but the Artillery X1 tend to be less prone to cut the work I think. Sometimes some printers hang and others follow. And if I restart some, they cut my prints on the other printers that are working fine. Or sometimes they all fail too, but some do it first and others fail hours later. I'll run more tests and keep you posted.

    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



  • The usb reset script searches the latest usb device we can disconnect to affect least possible number of devices. That solution is linux only. No idea if that problem is on windows as well. Windows uses different drivers so it may behave differently. But I have no printer with that driver chip. Just identical reports from other Artillery/Sidewinder users. I wonder if they have some hardware error that sometimes comes through or if it is a software problem in driver.

    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.
  • Good news!

    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.
  • Just saw something similar to this on 0.93.1 and a Creality CR-10S (v2.1 mainboard, using FTDI). I noted that it always continued with a status update (layer number, ETE, ETA, etc) sent to the printer, then a batch of a few G commands (each one followed quickly by an OK), then a pause for several seconds, then a new status update.

    Disabled status updates for the printer, and the print runs perfectly fine.
  • edited April 2021
    Noting that it was printing a spiralized, smoothed (progressive Z) print from Cura. It seems like it's only printing one layers worth of commands between LCD status updates (which, for cura spiralized prints, could be between 1 and 10 G1 commands or so, very few.)


    > 22:35:21.009:  T:209.96 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:22.017:  T:209.96 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:23.009:  T:209.92 /210.00 B:55.00 /55.00 @:97 B@:41
    < 22:35:23.860: M117 Layer 203/29273
    > 22:35:23.872: ok
    < 22:35:23.873: N1477273 G1 X131.731 Y131.731 Z1.644 E1001.25111
    > 22:35:23.888: ok
    < 22:35:23.889: N1477274 G1 X133.5 Y130.566 Z1.645 E1001.29338
    > 22:35:23.904: ok
    < 22:35:23.905: N1477275 G1 X136.224 Y129.382 Z1.647 E1001.35266
    > 22:35:23.920: ok
    < 22:35:23.921: N1477276 G1 X138.358 Y127.318 Z1.65 E1001.4119
    > 22:35:23.936: ok
    < 22:35:23.937: N1477277 G1 X140.112 Y126.128 Z1.651 E1001.4542
    > 22:35:23.952: ok
    > 22:35:24.017:  T:209.84 /210.00 B:55.00 /55.00 @:98 B@:41
    > 22:35:25.024:  T:209.92 /210.00 B:55.00 /55.00 @:97 B@:41
    > 22:35:26.015:  T:209.96 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:27.023:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:28.015:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:29.023:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:30.015:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:31.023:  T:209.96 /210.00 B:55.00 /55.00 @:97 B@:41
    > 22:35:32.013:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:33.021:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    < 22:35:33.861: M117 ETA 23:25:13 day 13
    > 22:35:33.869: ok
    < 22:35:33.869: N1477278 G1 X142.189 Y125.729 Z1.653 E1001.49641
    > 22:35:33.885: ok
    > 22:35:34.029:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:35.021:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:36.029:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:37.021:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:38.028:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:39.019:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:40.027:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:41.019:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:42.027:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:43.018:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    < 22:35:43.867: M117 ETE 00:49:40
    > 22:35:43.881: ok
    < 22:35:43.882: N1477279 G1 X145.163 Y125.68 Z1.655 E1001.55577
    > 22:35:43.897: ok
    > 22:35:44.026:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:45.017:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:46.025:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:47.017:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:48.025:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:49.032:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:50.024:  T:210.04 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:51.032:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:52.023:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:53.031:  T:210.04 /210.00 B:55.00 /55.00 @:96 B@:41
    < 22:35:53.873: M117 Layer 210/29273
    > 22:35:53.879: ok
    < 22:35:53.879: N1477280 G1 X147.924 Y124.586 Z1.657 E1001.61503
    > 22:35:53.895: ok
    < 22:35:53.895: N1477281 G1 X150 Y124.159 Z1.659 E1001.65733
    > 22:35:53.911: ok
    < 22:35:53.911: N1477282 G1 X152.074 Y124.583 Z1.66 E1001.69957
    > 22:35:53.927: ok
    < 22:35:53.927: N1477283 G1 X154.837 Y125.68 Z1.662 E1001.7589
    > 22:35:53.943: ok
    < 22:35:53.943: N1477284 G1 X157.81 Y125.723 Z1.665 E1001.81823
    > 22:35:53.959: ok
    < 22:35:53.959: N1477285 G1 X159.89 Y126.123 Z1.666 E1001.8605
    > 22:35:53.975: ok
    < 22:35:53.975: N1477286 G1 X161.644 Y127.311 Z1.668 E1001.90278
    > 22:35:53.991: ok
    < 22:35:53.991: N1477287 G1 X163.776 Y129.382 Z1.67 E1001.96209
    > 22:35:54.007: ok
    < 22:35:54.007: N1477288 G1 X166.504 Y130.556 Z1.672 E1002.02136
    > 22:35:54.023: ok
    > 22:35:54.023:  T:210.08 /210.00 B:55.00 /55.00 @:95 B@:41
    > 22:35:55.030:  T:210.08 /210.00 B:55.00 /55.00 @:95 B@:41
    > 22:35:56.022:  T:210.04 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:57.030:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
  • The LCD status updates via M117 are time triggered to switch every 10 seconds and you see they do switch every 10 seconds. You also see communication is ok
    < 22:35:23.921: N1477276 G1 X138.358 Y127.318 Z1.65 E1001.4119
    > 22:35:23.936: ok
    < 22:35:23.937: N1477277 G1 X140.112 Y126.128 Z1.651 E1001.4542
    > 22:35:23.952: ok
    > 22:35:24.017:  T:209.84 /210.00 B:55.00 /55.00 @:98 B@:41
    > 22:35:25.024:  T:209.92 /210.00 B:55.00 /55.00 @:97 B@:41
    > 22:35:26.015:  T:209.96 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:27.023:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:28.015:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:29.023:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:30.015:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:31.023:  T:209.96 /210.00 B:55.00 /55.00 @:97 B@:41
    > 22:35:32.013:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    > 22:35:33.021:  T:210.00 /210.00 B:55.00 /55.00 @:96 B@:41
    < 22:35:33.861: M117 ETA 23:25:13 day 13
    > 22:35:33.869: ok

    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.
  • Hi all, i found something on one other forum.
    One friend has an Anycubic, if he let th pi on turn the printer off all on the printer is off.
    Not so on my Ender 5 Plus, if i turn the printer off and let the pi on, the touch display, bl touch and temparature still working. So i try to put a litle tape over my usb pin 1 (+) from the connection from my pi4 to the printer.(+5V)


  • I think I have a similar problem, but no idea what's causing it. I have a pretty simple setup, a PC running Linux (Mint) and an Anet A8 printer. Several times over the last few days the printer has stopped mid print. I tried all sorts of things to try to get it going again (like pausing and continuing) but nothing worked. Today I noticed it hadn't stopped, it was just taking a long time between commands, roughly 30 seconds each time. As @Repetier ; mentioned above, it seems the device stops sending an OK after the command is complete, so the timeout is hit (30 seconds in my case) and the next command is sent.
    In the log there are several warnings about communication timeout - ressetting communication buffer,
    then finally a message saying "too many timeouts without response - disabling timeout message"
    I don't know much about Repetier, so I have no idea what has happened, nor how to solve the problem.
    Is it a hardware/software fault in the printer?
    Thanks.

  • I think it is a bug in one of the serial drivers. Please try activating "USB Reconnect on timeout" and also make sure to have "Continue print after fast reconnect" is activated. This simulates unplugging usb cable for a short time, so driver reloads/reinits and hopefully puts firmware responses through again.
Sign In or Register to comment.