Printer moves unexpectedly when stopping SD-card copy

Hi,

What is the problem?
I'm new to 3d-printing and to octoprint, playing around a little bit.
printer: Anycubic i3 mega (seems to be an older hardware version, since I get a thermal runaway protection - warning)

I just wanted to upload a file to SD-card and cause it was very slow (I know USB won't be faster on such devices) I decided to cancel copying.
After that it said cancelling print and x-axis went to it's end and didn't really stop, it went some mm further and back all the time, didn't sound really good, I had to switch off the printer.

I don't know where this came from, I have copied the commands which where sent, I hope you can tell me what this is and how I prevent it in future:

Recv: ok
Changing monitoring state from "Printing" to "Operational"
Send: G1 X113.777 Y109.818 E166.31314
Send: G1 X113.512 Y109.129 E166.32475
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: ok
Send: G1 X113.342 Y108.616 E166.33325
Recv: echo: cold extrusion prevented
Recv: echo: cold extrusion prevented
Recv: ok
Send: M20
Recv: echo: cold extrusion prevented
Recv: ok
Send: M30 /karott~1.gco
Recv: Begin file list
Recv: End file list
Recv: ok
Recv: ok

What did you already try to solve it?
Not trying to reproduce as it sounded like a malfunction

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
firmware:

Recv: FIRMWARE_NAME:Marlin 1.1.0-RC8 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:1 UUID:xxxxxxxxxxxxxxxx
Recv: ok
I know not really safe for thermal runaway, I'll update this soon

Setup everything with https://discourse.octoprint.org/t/setting-up-octoprint-on-a-raspberry-pi-running-raspbian/2337

  • newest raspbian, Octoprint 1.3.9

If you need more logs feel free to ask.

Thanks for your help!

Can you provide a full serial.log please?

I don't think this is what you expected:

2018-08-16 17:48:28,485 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log

I've turned it on for now, perhaps I can reproduce it
Any other ideas for now?

I couldn't reproduce it by now, I tried to remember the exakt I think I did the following steps yesterday:

  • Load an stl to SD-Card
  • Was annoyed it lasted so long and so I removed SD-card (thought upload would also stop, but it didnd't), that was not the best idea I know, but I didn't mind first place.
  • Lateron (I was sitting in front of my computer next to the printer) I was seeing in octoprint that it was in print state. I didn't intend to print so this is somehow mysterious to me, perhaps I've accidentially clicked print while changing tabs in my browser. Or are there any keyboard shortcuts?
  • But it didn't print at that time, so I decided to press cancel.
  • After that the problem happened

I tried to replay it, but everything normal: heating - when pressing print and cooling down when canceling.
Tried it with canceling while printing and cancelling before printing

Forget my last post, as I looked in octoprint.log I could recreate what I've done more or less, but unfortunately not reproduce the issue:

  • Uploaded a gcode-file to SD, first it seems to get uploaded to raspberry, then via USB to SD-card.
  • It seemed like the connection got closed and restarted some minutes later
  • The sent lines like "G1 X113.777 Y109.818 E166.31314" I have found somewhere in the middle of the sent gcode file.

I've tested with SD-card pulled out in between, detatching octoprint while uploading, cancel the upload in between, but everything was working fine.

These are the relevant lines of octoprint.log (at the end I've switched off the printer).
Is it possible that only part of the file got uploaded and started printing? Any other ideas? I'm giving up at this point ...

2018-08-16 16:29:18,390 - octoprint.filemanager.analysis - INFO - Starting analysis of local:karottebrille.gcode
2018-08-16 16:29:18,393 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/OctoPrint/venv/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/karottebrille.gcode
2018-08-16 16:29:18,456 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2018-08-16 16:29:18,487 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Sending file to SD"
2018-08-16 16:32:58,584 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-08-16 16:47:58,587 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-08-16 17:02:58,591 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2018-08-16 17:06:36,848 - octoprint.server.util.sockjs - INFO - Client connection closed: 192.168.11.108
2018-08-16 17:11:40,462 - octoprint.server.util.sockjs - INFO - New connection from client: 192.168.11.108
2018-08-16 17:11:41,626 - octoprint.plugins.announcements - INFO - Loaded channel _important from xxx in 0.26s
2018-08-16 17:11:42,165 - octoprint.plugins.announcements - INFO - Loaded channel _releases from xxx in 0.21s
2018-08-16 17:11:42,468 - octoprint.plugins.announcements - INFO - Loaded channel _blog from xxx in 0.21s
2018-08-16 17:11:42,812 - octoprint.plugins.announcements - INFO - Loaded channel _plugins from xxx in 0.26s
2018-08-16 17:11:43,156 - octoprint.plugins.announcements - INFO - Loaded channel _octopi from xxx in 0.22s
2018-08-16 17:11:53,832 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Operational"
2018-08-16 17:12:00,800 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port

FWIW this happened to me recently:

  1. Clicked Upload to SD
  2. Selected a file
  3. Realised it didn't just upload but actually priming for printing too
  4. Clicked cancel
  5. After a delay X Axis when to max and on, scary grinding sound as it did. It stopped itself before I had a chance to act.
  6. Print status was cancelled

My questions (apart from what I assume is a bug somewhere in the malfunctioning x-axis behaviour):

  1. Why does Upload to SD immediately start a print? I don't see that behaviour in the normal Upload feature.
  2. How can the printer go out of its safe bounds when my (own rolled) Marlin specifies the max bed?

Both the above lead me to suspect that the firmware is involved here.