If you are running a print from a USB drive and use CuraLE to connect to the machine during a filament run-out on toolhead 2, it sometimes switches to toolhead 1 when connecting. If you then resume the print, it will continue running where it left off in the toolhead 2 code using toolhead 1. Had this happen once when connecting fresh, and once when just opening console while connected after having been in the prepare section of Cura while the print was running.
Description
Description
Related Objects
Related Objects
- Mentioned Here
- T1: Test task
Event Timeline
Comment Actions
@marcio Does 2.0 behave differently than the 1.1.x branches? I believe marlin resets when connecting via USB, and not quite sure how the filament run out sensor pauses/saves location
Comment Actions
It looks like the archim board no longer resets marlin when connecting, will check for a T0 command from cura when first connecting
Comment Actions
FYI, the commands used for pause and resume with the filament detection are M24 and M25, respectively. I have tested and confirmed that sending a T0 or T1 command from Cura during that pause will indeed switch tool heads. I have also tested a little on this exact issue, and found:
Connecting/disconnecting/opening console does NOT do it
Switching from Prepare to Monitor while connected DOES do it
Disconnecting, switching to Prepare, switching to Monitor, opening console, connecting, and then closing console DOES do it
Disconnecting, opening console, connecting, closing console does NOT do it
So, it seems as though a T0 command is sent when activating Prepare, not on connect. But, it only seems to do so when the console history is empty or empty prior to the fresh connection. Switching to Prepare seems to clear that history.
Comment Actions
I don't think cura should send a T0. I'm sure the intent was to make sure the correct nozzle was selected at the start of the print, but the T0 should be added to the start GCODE instead.
Comment Actions
@DaniAO @samantha @marcio I attempted to re-create this on my desk using QuiverAlpha7 with .102 FW and Cura 3.6.5. In short it causes the printer to restart.
Steps used to create issue.
- Start print via USB. Make sure there is no filament in E2 and run the calibration print.
- Once the machine enters the controlled failure state, plug in the serial port and attempt to connect via Cura.
- Observe.
This is the error log that Cura provided:
2019-03-25 13:17:35,372 - DEBUG - [(139986437115520)-MainThread] USBPrinting.USBPrinterOutputDevice._log [54]: Attempting to connect to printer with serial /dev/ttyACM0 on baud rate 250000
Exception in thread Thread-46:
Traceback (most recent call last):
File "/home/aleph/Projects/build-master/build/inst/lib/python3.5/site-packages/serial/serialposix.py", line 523, in write
n = os.write(self.fd, d)
OSError: [Errno 5] Input/output error
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/aleph/Projects/build-master/build/inst/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/home/aleph/Projects/build-master/build/inst/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "/home/aleph/Projects/build-master/build/dist/plugins/plugins/USBPrinting/USBPrinterOutputDevice.py", line 715, in _connect_func
self._parent._serial.write(b"\n")
File "/home/aleph/Projects/build-master/build/inst/lib/python3.5/site-packages/serial/serialposix.py", line 554, in write
raise SerialException('write failed: {}'.format(v))
serial.serialutil.SerialException: write failed: [Errno 5] Input/output error