Plugging USB destructively restarts printer
gsedej opened this issue · comments
Hello,
I am very happy new user of MK3. Printer is fantastic.
But I am having issues with printing from computer via USB.
Before attacking me, a bit of background.
For the past 8 years I have been in charge of printing from old RepRap Pro (at uni), around ~200hours of printing.
All the printing has been done trough laptop running linux (Ubuntu) and pronterface.
I CAN'T REMEMBER SINGLE FAILURE DUE TO COMPUTER. The printing from computer has been very reliable.
It has been very useful for:
- pronterface has progress indicator in 3D and final preview (for everyone asking what is printing)
- pronterface with controls: head movement, printing speed acceleration, etc...
- use of USB camera looking directly at hotend nozzle, having nice picture of extrusion on part of sceeen
- use of remote control (e.g. VNC or teamviwer)
All combined give me much flexibility to control the printing process, even e.g. when I gone home.
note: the printer was always connected to laptop
So the MK3 does work via the described method (linux+pronterface+USB), but I the printer always resets when connecting (and sometimes disconnecting) the printer. If printing from SD card, the print is failed, no recovery.
Even though the printer would be always connected, I still have bad feeling of possible restarts.
Is there a possible fix to handle USB connection/disconnection without resetting printer?
I am aware that this is hard due to voltage fluctuation and 8 bit controller complexity.
actual behavior:
Printer resets if USB Connection is established.
wanted behavior:
Printer does NOT reset if an USB Connection is established.
USB resets are standard Arduino behaviour.
USB reset behaviour exists in order to allow access to the ATmega2560 boot-loader to perform a firmware upgrade. There is often a very-short period after reset when the boot-loader is accessible (duration depends on boot-loader, typically one second or less).
WARNING! Dangerous technical info ahead! Feel free to skip. Proceed at your own risk!
USB device attachment causes the ATmega32u2 to toggle the Data Terminal Ready (DTR) pin, that is mapped by software to the Clear To Send (CTS) pin on the package (for historical reasons), which resets the ATmega2560.
It is possible to disable USB resets by cutting a solder-jumper (JP1-SJ) on the board (typically located near the ATmega2560, marked 'reset' or 'USB boot en') , but then firmware upgrades over USB with the 'avrdude' flashing program will be problematic or impossible, because of the difficulty in getting into the boot-loader. The trace can be re-soldered though (it was designed to be), or it can be cut and a switch can be added across it.
On most other Arduino boards .... there is usually a second solder-jumper for the same pin (typically on the bottom, near the ATmega32u2 / 16u2 / 8u2, but not always marked as 'boot') that can be modified (either cut, or a 10k resistor to ground added - on the Einsy-Rambo test-point TP24 is handy) to gain access to the ATmega32u2 / 16u2 / 8u2 boot-loader, instead of the ATmega2560 boot-loader. HOWEVER, on the Einsy-Rambo I think the ICSP header may have to be used instead (depends on the boot-loader).
When all else fails, the ICSP headers can always be used for flashing firmware if you have an interface adaptor, or another Arduino. Just make sure to connect to the right ICSP header! For most firmware upgrades, the ATmega2560 is the one you want.
Options:
- Live with it.
- Cut JP1 and solder a switch across it, so you can still upgrade firmware over USB.
- Cut JP1 and upgrade firmware via the ATmega2560 ICSP header with a USBASP or another Arduino.
Thank you very much for such a detailed answer.
We replaced laptop with an actual PC (the (already "abused") laptop fan failed due to constant usage). The printer and PC are now always connected and there is no problem with restarting.
Even though in the more than 1 month we had ZERO problems with printing USB. Everything is super stable. I am wondering why it's so nu-recommended to print over USB. You have so many benefits over SD.
(It even survives if PC suspends)
About scheme - the option "2" that includes switch would be optimal, if we ever had problems with USB.
I am closing issue as "WON'T FIX" with workaround provided.
I just released a new plugin for OctoPrint that might help solve this problem. Prusa Reset Mode adds a tab to Octoprint, with buttons that allow you to send serial commands directly from the OctoPrint interface to enable and disable this "automatic reset feature".