[2.0.x] Random disconnects on Re-Arm

[cdedwards]

I've been running the Re-arm board for a couple of days now and it's been frustrating. I have been getting random disconnect's which require me to diconnect my host and then reconnect again. This doesn't appear to happen during prints as my prints have not stopped. It does occur while doing "other" commands. G29,G33 and M48 are good examples. In fact M48 is pretty consistant in crashing the USB connection. I disabled the WATCHDOG to see if that was a concern, and while it seems to make some differance, I still get these. Sorry I can't provide more information

[p3p]

Can you clarify if the USB cable needs to be removed and reinserted or if a serial disconnect / reconnect from the host is enough. I will test those commands tomorrow but haven't run into the issue myself in normal use.

[cdedwards]

USB cable is not removed at all. Just a serial host disconnect/connect is enough. I'm using simplify 4 for a host. My cable is aprox 4ft long and fully shielded. As I mentioned, when it's printing, the connection is stable and I've done some 12 hour prints without it disconnecting at all. I know when it disconnects as I lose the micro-sd card and it reconnects right away on its own.

[p3p]

Interesting, neither end of the link is crashing then, seems to be a timeout then reconnect of the usb link, the mcu doesn't restart or crash so the watchdog can't be the issue, there is a pretty strict upper limit to the response time in the usb protocol as the usb is low priority its possible that we exceed that during those commands for some reason (it shouldn't). What OS are you running?, could be a difference in the driver's tolerance as to why it doesn't happen to me although I do test on Linux and Windows.

[cdedwards]

I'm running windows 10. this has happened on two different computers both of which are running 10. This same computer had no issues with a 2560. I just recently tore apart one delta to remove the Re-Arm and placed it into another delta.

[p3p]

This same computer had no issues with a 2560.

You wouldn't have this issue on AVR, We run the USB stack on the LPC1768, the AVRs have another chip (usb to serial bridge) that does that for them, I'll see if I can reproduce this tomorrow.

[Bergerac56]

I use a re-arm for a long time now. I confirme this strange behavior. Deconnexion when sending gcodes. Both with repetier or pronterface. I need to disconnect and reconnect to go further.

It seems also that, time to time, the priner receives the codes sent from the host and acts accordingly but pronterface or repetier does not display the "responses".

[cdedwards]

what version of windows are you running?

[p3p]

Have tried to reproduce this on Windows10 and Linux, no luck so far, I did a little research into what can make a USB link disconnect / reconnect, a noisy ground plane or ground loop is the most common issue but I won't say it isn't my fault at this point.

[kAdonis]

Maybe ist related, but reponses from my Rearm are sometimes garbled. The worst behavior shows the output from M503, the mesh with all the M421 is fine, but everything after that is randomly shown or not shown. The Pid-values are never shown. This is only with USB, tested with Octoprint on a Raspberry, Repetier or Pronterface on Windows 10 I tried with a FTDI at the Rearm's serial Port and the M503 output looked perfect!

[cdedwards]

two differant delta's. two differant computers. two differant USB cables. Only thing common between them is the re-arm board. I'll look to see if the delta frame is grounded

[cdedwards]

https://github.com/MarlinFirmware/Marlin/issues/9593

This appears to be happening to others are the post on Feb 11th implies.

[p3p]

I'm aware of that, as I said I wasn't implying there was no problem just that I can not reproduce it, My printers control electronics are isolated from the drivers, steppers and mosfets as I built it modular so I could swap out the control board, An unfortunate side effect of this I noticed, with the ADC issue people were having that I didn't, is that my ground is very clean so I don't get issues related to noise leakage. I was just putting it forward as a possibility.

[ModMike]

I just had this happen on mac printing directly from S3D.

[thinkyhead]

@ModMike — Random disconnects can happen for a myriad of reasons. Is it a recurring problem?

[ModMike]

I don't think so. I did a 20 hour S3D print from my Mac and it looked fine, only issue is fan speed oscillation, even when set to 100%.

[ModMike]

I've been having a hard time with intermittent extrusion and other random failures printing directly from S3D on Mac to Azteeg X5 Mini Wifi via 8' thin USB cable. I switched to Octoprint on a RPi 3+b connected via short USB and everything os PERFECT.

When in doubt, change the cable. There is a reason manufactures provided short, heavily shielded cables. I will test the fan speed issue after my print and update.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.