Slic3r GCode Print via USB Card stops after a while

Hi,

I'm using Slic3r 1.2.9.

I rather would like to use Slic3r over Cura cause it seems to deliver better print result and other settings.

Unfortunately I'm not able to use the Slic3r GCode with my Prusa i3 Setup successfully. The print stops after a not defineable time / state. It simply stops. SD Card and smart controller cannot be the problem, cause a.) I tried a different SD Card and b.) the same object with Cura 10.54 GCode prints until the end.

Attached you'll find the both GCodes from Cura and Slic3r.

This is the object I try to print. But the problem occurs with other objects as well.
[www.thingiverse.com]

I've searched the Internet for this issue but I'm only hitting problems with stopped prints directly via USB which in my case is not the issue.

I also imported the profile bundle from a friend (who is not having any issues) to verify, that there aren't any settings in Slic3r wrong but the problem remains. The printer simply stops, somethimes after 5% and sometime at 40%

Does somebody have a hint what I can do? It would be greatly appreciated ;-)

Both G-code files you have attached show the final layer to be 9.6mm, so they should both print up to that height. If the Slic3r file stops before that height it is probably a firmware or file transfer issue.

Are you certain that Slic3r has finished slicing before you copied or used the G-code file? I had a similar issue, and discovered that Slic3r was taking a long time to complete slicing, and I was copying the file to SD card before it had completed. Look at the end of the file in a text editor to ensure it has your end code and other ending lines before you copy or use the file.

Dave

Edited 1 time(s). Last edit at 08/26/2015 12:18PM by dmould.

I found that Slic3r takes a REALLY long time to transfer the G-Code file to the SD card on my printer. It is much quicker to save the G-Code file to my PC's hard drive, insert the memory card into the PC's card reader slot and copy the file across, and then move the memory card back to the printer.

Hope this helps!

---

Follow my Mendel Prusa build here: [julianh72.blogspot.com]

Quote
julianh72
I found that Slic3r takes a REALLY long time to transfer the G-Code file to the SD card on my printer. It is much quicker to save the G-Code file to my PC's hard drive, insert the memory card into the PC's card reader slot and copy the file across, and then move the memory card back to the printer.

Hope this helps!

I suspect (BICBW) that Slic3r opens the output file, appends a small chunk of data, then closes the file while computing the next chunk. Or maybe the chunks are sufficiently slow that they exceed the time that determines when pending file data is flushed to the disk. If so it would have minimal impact on a traditional HDD which can append data to a file with little overhead, but would cause a Flash card significant overheads, because appending data to a Flash file usually entails creating a completely new file, copying across the previous file with the new data appended, then changing the file pointers to the new file (which can also entail cloning the old allocation table with amendments). If the flash card runs out of erased sectors, it will need to perform a block erase operation to reclaim disused sectors, which is pretty time consuming.

Dave

Quote
julianh72
I found that Slic3r takes a REALLY long time to transfer the G-Code file to the SD card on my printer. It is much quicker to save the G-Code file to my PC's hard drive, insert the memory card into the PC's card reader slot and copy the file across, and then move the memory card back to the printer.

Hope this helps!

I am not surprised. Data transfer over the USB connection to RAMPS and similar atmega2560-based electronics is slow. These boards use a USB-over-serial connection that is limited to about 25kbytes/sec and has no flow control. There are other electronics that can do faster file upload to SD card, using either a native USB port or an Ethernet port.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I am not surprised. Data transfer over the USB connection to RAMPS and similar atmega2560-based electronics is slow. These boards use a USB-over-serial connection that is limited to about 25kbytes/sec and has no flow control. There are other electronics that can do faster file upload to SD card, using either a native USB port or an Ethernet port.

I misunderstood the PP, and was thinking that he was writing the file from Slicer directly to a location on an SD card that was plugged into the PC USB port via an SD-USB adaptor (such as the Ormerod was originally supplied with). I now see that your understanding is likely to be correct, and transferring via USB to the printer's controller which then writes to SD card is certainly going to be abysmally slow for the reasons you give.

Dave