Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot Copy Files to the SD Card on an Anet A6 #1882

Closed
RodneyMcKay715 opened this issue Apr 22, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@RodneyMcKay715
Copy link

commented Apr 22, 2017

What were you doing?

I wanted to move some Files from my Desktop to the SD-Card of my Printer over OctoPrint.
I clicked on Upload to SD and selected the File and clicked on OK.

What did you expect to happen?

I expected the File to be moved over to my Printers SD card.

What happened instead?

Depending on the File i get different Errors. I have 4 Files : a Fan duct, a LED Bar holder for the extruder ,a Dust Cap for the Z Axis and a Tablet Stand.

The Fan Duct File can be copied over and over again without any issues.

The LED Bar holder causes this Error:

Upload failed
Konnte die Datei nicht hochladen. Bitte stelle sicher, dass es sich um eine valide Datei mit einer dieser Erweiterungen ist: .g, .gco, .gcode, .stl

(btw. theres a grammatical Error there : "ist" should be "handelt")
The File is a .gcode File. This Error occurs with all slicers i tried. (simplify 3d, cura, repetier host and slic3r)

The Dust Cap causes following behaviour:
It disconnects the Printer and the Status is Stuck on Streaming... and the button copy to SD is greyed out, but clickable. On top of that it says following:

Error:Line Number is not Last Line Number+1, Last Line: 0

The Tablet Stand is greying out upload files to SD and makes the SD-Card unaccessible even from the printer itself. After a OctoPrint Reboot it shows a corrupt file in the directory. To access the SD card from the Printer again i have to eject and reinitialize it.

Copying to the Pi is not an issue at all.

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.2 (master branch)

Operating System running OctoPrint

OctoPi 0.13

Printer model & used firmware incl. version

Anet 3D A6 , Marlin Skynet 2.3.1 Autolevel for Anet A6

Browser and Version of Browser, Operating System running Browser

Firefox 53.0 , Windows 7 64x

Link to octoprint.log

https://gist.github.com/RodneyMcKay715/a4472109ee90283eb22b2668041a2fac

Link to contents of terminal tab or serial.log

https://gist.github.com/RodneyMcKay715/d1b42caacf3011de62bc2165e309bfd9

Link to contents of Javascript console in the browser

Nothing there

Video

In the Video i could not reproduce all Issues i listed before but still needed a OctoPrint Reboot and also the SD-Card was corrupt.

https://www.youtube.com/watch?v=IGlDt9zFpYc

I have read the FAQ.

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 24, 2017

I cant provide more since the serial log freezes my browser [...]

The serial.log has nothing to do with your browser, it is written to disk if you enable it in Settings > Serial Connection > Log communication to serial.log (the checkbox with the red warning label about performance). Once you do that you can reconnect to your printer, reproduce the problem and then provide the serial.log as downloadable from Settings > Logs.

And in order to further look into this issue it's absolutely crucial to have this log. Your provided terminal output sadly does not even contain the error and your octoprint.log indicates some serious problems with regards to line number tracking being the root cause, but to narrow down on that the full serial.log is needed. It might be something simple caused by how your printer's firmware behaves that needs some special handling, but for that the full log is needed.

You might also have more success by disabling Settings > Features > Enable automatic firmware detection and then in the options that appear then to select "Always" for "Send a checksum with the command". That might only be covering up the real problem though, so even if that solves the problem for you, still provide the serial.log as described above please.

@RodneyMcKay715

This comment has been minimized.

Copy link
Author

commented May 3, 2017

I added the Serial Log and also a Video showing my issue

@foosel

This comment has been minimized.

Copy link
Owner

commented May 3, 2017

Have you tried what I suggested?

You might also have more success by disabling Settings > Features > Enable automatic firmware detection and then in the options that appear then to select "Always" for "Send a checksum with the command".

It looks like there might be a bug in a specific combination of enabled firmware detection and M110 commands going on here, but until I have found the cause for that, the above settings might be able to get you going.

@foosel foosel added this to the 1.3.3 milestone May 3, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented May 3, 2017

Hah, found it! Race condition, caused by just the right delay of printer acknowledgements on streaming start. I pushed a fix to maintenance, soon devel and this will be part of the upcoming 1.3.3 release!

@RodneyMcKay715

This comment has been minimized.

Copy link
Author

commented May 10, 2017

Now the upload to the Pi is also broken. If i move a file over to the Pi i get the error: "Konnte die Datei nicht hochladen. Bitte stelle sicher, dass es (sich um) eine valide Datei mit einer dieser Erweiterungen ist: .g, .gco, .gcode, .stl."
If i refresh the File list the File is there.

@foosel

This comment has been minimized.

Copy link
Owner

commented May 10, 2017

This sounds like a completely unrelated issue, please provide a log file for that.

@RodneyMcKay715

This comment has been minimized.

Copy link
Author

commented May 10, 2017

The log has thiese 2 lines which seem strange to me:
2017-05-10 15:03:46,372 - octoprint.filemanager.storage - INFO - Initializing the file metadata for /media/usb0/uploads...
2017-05-10 15:03:46,410 - octoprint.filemanager.storage - ERROR - Error while writing .metadata.yaml to /media/usb0/uploads

/media/usb0/ is the mountpoint of my USB Stick on the Pi.

@foosel

This comment has been minimized.

Copy link
Owner

commented May 10, 2017

OctoPrint's default upload folder is ~/.octoprint/uploads, not a USB stick. And from the looks of it something's wrong with that stick, because it's not (or no longer) writable by the user OctoPrint is running under. A full log might provide more insight (I'd be expecting to see a stack trace when you attempt to upload a file), but based on the information you already provided please try resetting OctoPrint to store its uploads on a location that is proven to be writable by it (e.g. the default one) and if that fixes it your USB stick is at fault.

@foosel foosel closed this in 844494a May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.