›

USB Random Disconnections

FabrizioFabrizio
in Repetier-Server
Hello! 2 days ago I updated the firmware of my Repetier Server to 1.3.0 and after that I have had random disconnections of the USB of my printers I find some of my printers stopped, in the RepetierInformer app it tells me "Print Grogu for printer magnaSE5 was stopped before it was finished due to lost connection" The printers are stopped in the middle of printing but they are connected and ready to send the file again, that is, they reconnected by themselves. I am using 6 printers on a RaspberryPi 3b+ Any advice? reinstall the RepetierServer firmware maybe?

Comments

  • Repetier_SupportRepetier_Support
    Hello. Do you have any undervoltage warnings? What kind of hub do you use? 
  • RepetierRepetier
    In that combination I have to first assume linux did disconnect USB due to power/EMF issues. It normally reconnects a few seconds later. Make sure the option "Continue print after fast reconnect" is enabled. If reconnect does not reset printer that is a good help, also it does not fix the problem, just the symptom.

    Check /var/log/syslog at the time of disconnect for more information why linux did it. And also server.log in case we did because you said to reset usb on timeouts.
  • FabrizioFabrizio
    1) No, I did not have any alerts for undervolting or throtting
    2) I am using a common hub with external power, I have noticed that the 3 printers that have stopped at some point, are always the ones connected to the HUB, could a hub connected directly to the GPIO of the RPi work better? for example this https://articulo.mercadolibre.com.ar/MLA-932958892-modulo-raspberry-waveshare-usb-hub-hat-4-puertos-hdm-gpio-_JM

    3) the option "Continue print after fast reconnect" is ON

    4) Excuse me, could you tell me how to see sys.log? I have no experience in Linux but with a little more information and google I can do it.
  • luis84luis84
    @Fabrizio Just my .02 as a fellow user, I run a small print farm and use Repetier on RPIs (2/3 mix) with hubs.  I noticed the behavior you mentioned in some scenarios and one of the biggest causes for me was dirty power issues.  

    The USB cables supply power to the printer on a single line and 99% of printers absolutely do not need this now.  You can check if you just turn off the printer but leave the Pi on, if any of the lights, LCD, etc on the printer are on even dim then power is being exchanged.

    Anyway this causes all types of issues with RPIs and hubs for me.  I had to eliminate this on every USB cable, you can modify the USB cable or less aggressive, just tape over the line. 

    If you check the "Solutions" section here it details it, not hard, just need some Electrical Tape and Tweezers:
    https://www.repetier-server.com/knowledgebase/undervoltage-and-throtteling-of-pi/
  • RepetierRepetier
    The syslog is /var/log/syslog and can be downloaded if you selects logs when you are in regular gui. There is a download option to make it easier to get it. Already saw that linux closed complete hub due to EMF. So no Underpower is not the only criteria, just a frequent one. 
  • FabrizioFabrizio
    luis84 said:
    @Fabrizio Just my .02 as a fellow user, I run a small print farm and use Repetier on RPIs (2/3 mix) with hubs.  I noticed the behavior you mentioned in some scenarios and one of the biggest causes for me was dirty power issues.  

    The USB cables supply power to the printer on a single line and 99% of printers absolutely do not need this now.  You can check if you just turn off the printer but leave the Pi on, if any of the lights, LCD, etc on the printer are on even dim then power is being exchanged.

    Anyway this causes all types of issues with RPIs and hubs for me.  I had to eliminate this on every USB cable, you can modify the USB cable or less aggressive, just tape over the line. 

    If you check the "Solutions" section here it details it, not hard, just need some Electrical Tape and Tweezers:
    https://www.repetier-server.com/knowledgebase/undervoltage-and-throtteling-of-pi/
    Thank you very much Luis84!
    I have one of my printers with that "solution", the screen stayed on when the power switch was off but the USB was connected.
    I will implement that in the rest of the printers. Thanks


  • FabrizioFabrizio
    Repetier said:
    The syslog is /var/log/syslog and can be downloaded if you selects logs when you are in regular gui. There is a download option to make it easier to get it. Already saw that linux closed complete hub due to EMF. So no Underpower is not the only criteria, just a frequent one. 
    I think it is this, the log is very large, copy a part where I found that it was disconnected, do you prefer that I attach the complete log in some way? Thanks you very much!

    Mar 23 12:01:14 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 23 12:01:49 RepetierServer dbus-daemon[363]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.4808' (uid=0 pid=20788 comm="timedatectl ")
    Mar 23 12:01:49 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 23 12:01:49 RepetierServer dbus-daemon[363]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 23 12:01:49 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 23 12:02:02 RepetierServer kernel: [154055.185784] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:02:02 RepetierServer kernel: [154055.185902] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:02:03 RepetierServer kernel: [154055.320388] usb 1-1.1.2: USB disconnect, device number 5
    Mar 23 12:02:03 RepetierServer kernel: [154055.321104] ch341-uart ttyUSB1: ch341-uart converter now disconnected from ttyUSB1
    Mar 23 12:02:03 RepetierServer kernel: [154055.321198] ch341 1-1.1.2:1.0: device disconnected
    Mar 23 12:02:19 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 23 12:02:53 RepetierServer dbus-daemon[363]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.4810' (uid=0 pid=20929 comm="timedatectl ")
    Mar 23 12:02:53 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 23 12:02:53 RepetierServer dbus-daemon[363]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 23 12:02:53 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 23 12:03:23 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.
    Mar 23 12:03:58 RepetierServer dbus-daemon[363]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.4812' (uid=0 pid=21054 comm="timedatectl ")
    Mar 23 12:03:58 RepetierServer systemd[1]: Starting Time & Date Service...
    Mar 23 12:03:58 RepetierServer dbus-daemon[363]: [system] Successfully activated service 'org.freedesktop.timedate1'
    Mar 23 12:03:58 RepetierServer systemd[1]: Started Time & Date Service.
    Mar 23 12:04:04 RepetierServer kernel: [154176.854801] ch341-uart ttyUSB5: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:04:04 RepetierServer kernel: [154176.854912] ch341-uart ttyUSB5: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:04:04 RepetierServer kernel: [154176.856325] ch341-uart ttyUSB4: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:04:04 RepetierServer kernel: [154176.856440] ch341-uart ttyUSB4: usb_serial_generic_read_bulk_callback - urb stopped: -32
    Mar 23 12:04:04 RepetierServer kernel: [154177.014800] usb 1-1.3.2: USB disconnect, device number 20
    Mar 23 12:04:04 RepetierServer kernel: [154177.015423] ch341-uart ttyUSB4: ch341-uart converter now disconnected from ttyUSB4
    Mar 23 12:04:04 RepetierServer kernel: [154177.015472] ch341 1-1.3.2:1.0: device disconnected
    Mar 23 12:04:04 RepetierServer kernel: [154177.211845] usb 1-1.3.3: USB disconnect, device number 21
    Mar 23 12:04:04 RepetierServer kernel: [154177.212073] usb 1-1.3.3: ch341_read_int_callback - usb_submit_urb failed: -19
    Mar 23 12:04:04 RepetierServer kernel: [154177.212554] ch341-uart ttyUSB5: ch341-uart converter now disconnected from ttyUSB5
    Mar 23 12:04:04 RepetierServer kernel: [154177.212600] ch341 1-1.3.3:1.0: device disconnected
    Mar 23 12:04:28 RepetierServer systemd[1]: systemd-timedated.service: Succeeded.






  • RepetierRepetier
    Mar 23 12:02:02 RepetierServer kernel: [154055.185784] ch341-uart ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32

    That is the problem. Every time this driver gets that error code it disconnects. So has nothing to do with Repetier-Server. I'm not author of the linux driver so I can not really say what is causing this error, just have seen this happening.

    You said:  the option "Continue print after fast reconnect" is ON

    So next question is why it idid not continue. Please check the next seconds in syslog until you see that the drivers reconnect. The open question is how long. If they reconnect within 10 seconds server would try to continue print. You said they were ready to print again after that so must have reconnected just when. 

    You might also want to try if that works at all - do s simple test print and during print unplug usb cable and reconnect within a few seconds. If it continues the option might work. If it resets the firmware it will not continue and about on reconnect anyway. Reason is after a firmware reset temperature and position in firmware is lost. Then only the rescue system would help. Good thing is that it is not from power outage so it can send start commands early to move extruder to the side and last logge dposition is more or less last executed so you just continue with rescue from last position if z can move without homing.

    Possible solution to prevent the driver error which I think come from communication problems somehow would be to try directly connecting printer to pi. Without hub it is one device less that can interfere and with isolated plus cable it will not draw current so no power issue here. On a pi 4 use best usb 2 plug for this. usb 3 is no speed gain and I they might be more sensitive.
Sign In or Register to comment.