Printer simply stops, DC42 v104e

Hi Dave
This now the second time it happens, I loaded a gcode file onto the SD card, this time the small robot that comes with CURA
Then it prints around 40% and stops.... no reason, the pronterface screen shows SD printing... but nothing anymore, pause resume nothing
The printer simply stops, I can then enter new commands and it responds to them, G1 x0 y0 z5
So the printer is not faulty...I also checked the Gcode in Slic3r and it is complete..
Any ideas
Tx Ben

Can you post the gcode? If you zip it up then it should be small enough to attach to a post.

---

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].

I canfirm it is not the gcode. I reset everything and reloaded the files. 1.2Mb... then printed again and this time it printed all the way as expected... I was just wondering if someone else found it as well. It was printing from the sd card. Not the pc. I always print from the sd card. Tx Ben

have you checked, that the gcode was transfered completely to the sd card? i had a similar problem where the file was not completely transfered and so it kind of finished beacause it ran out of things to do...

How did you transfer the file to the SD card? Via Ethernet, USB or did you unplug the card and transfer on your PC? It certainly sound like an incomplete file transfer.

Dave

Hi Dave
I make use of Pronterface, I first load the file, then upload to the SD card, then Print from SD by selecting the uploaded file... I will keep an eye in it, it hasn`t happened, it could be some of the above... it is always hard to fault find if things happen randomly, and not regularly
Tx Ben

Hi Dave
OK I think I found the issue, yes indeed it is a combination of Slic3r then pronterface
Slick3r exports the file to a Gcode file, but now I see that sometimes it takes a while to export to Gcode then it seems while it is still exporting and I load the file in Pronterface it only loads partially
Hence only part of the file is loaded and hence uploaded to the SD card
Then it only prints the part that was loaded....
So it seems with big file one MUST HAVE PATIENCE ! to upload via Pronterface
Tx Ben

Quote
BenBB
Hi Dave
OK I think I found the issue, yes indeed it is a combination of Slic3r then pronterface
Slick3r exports the file to a Gcode file, but now I see that sometimes it takes a while to export to Gcode then it seems while it is still exporting and I load the file in Pronterface it only loads partially
Hence only part of the file is loaded and hence uploaded to the SD card
Then it only prints the part that was loaded....
So it seems with big file one MUST HAVE PATIENCE ! to upload via Pronterface
Tx Ben

I have made that mistake as well. Slic3r can take a long time to export the file. In fact if you have "Do not cross perimeters" checked, some STLs can take many hours to export the file (unless that has been fixed in later releases). It is a good idea to check the print file with a text editor to ensure it has the expected ending (your custom end code etc.)

Dave

Quote
dmould

Quote
BenBB
Hi Dave
OK I think I found the issue, yes indeed it is a combination of Slic3r then pronterface
Slick3r exports the file to a Gcode file, but now I see that sometimes it takes a while to export to Gcode then it seems while it is still exporting and I load the file in Pronterface it only loads partially
Hence only part of the file is loaded and hence uploaded to the SD card
Then it only prints the part that was loaded....
So it seems with big file one MUST HAVE PATIENCE ! to upload via Pronterface
Tx Ben

I have made that mistake as well. Slic3r can take a long time to export the file. In fact if you have "Do not cross perimeters" checked, some STLs can take many hours to export the file (unless that has been fixed in later releases). It is a good idea to check the print file with a text editor to ensure it has the expected ending (your custom end code etc.)

Dave

Another option is to open your gcode in something that can preveiw gcodes, personaly I use Repeater-Host [www.repetier.com] solely for the purpose of looking at the gcode and visualizing non-print moves

Quote
shadow651

Quote
dmould

Quote
BenBB
Hi Dave
OK I think I found the issue, yes indeed it is a combination of Slic3r then pronterface
Slick3r exports the file to a Gcode file, but now I see that sometimes it takes a while to export to Gcode then it seems while it is still exporting and I load the file in Pronterface it only loads partially
Hence only part of the file is loaded and hence uploaded to the SD card
Then it only prints the part that was loaded....
So it seems with big file one MUST HAVE PATIENCE ! to upload via Pronterface
Tx Ben

I have made that mistake as well. Slic3r can take a long time to export the file. In fact if you have "Do not cross perimeters" checked, some STLs can take many hours to export the file (unless that has been fixed in later releases). It is a good idea to check the print file with a text editor to ensure it has the expected ending (your custom end code etc.)

Dave

Another option is to open your gcode in something that can preveiw gcodes, personaly I use Repeater-Host [www.repetier.com] solely for the purpose of looking at the gcode and visualizing non-print moves

The latest Slic3r release has a preview option. One issue with the repetier preview is that it does not correctly display the extrusion width. This can result in the preview incorrectly showing the infill not reaching the perimeter, when in fact it will print OK.

Dave

Quote
dmould

Quote
shadow651

Quote
dmould

Quote
BenBB
Hi Dave
OK I think I found the issue, yes indeed it is a combination of Slic3r then pronterface
Slick3r exports the file to a Gcode file, but now I see that sometimes it takes a while to export to Gcode then it seems while it is still exporting and I load the file in Pronterface it only loads partially
Hence only part of the file is loaded and hence uploaded to the SD card
Then it only prints the part that was loaded....
So it seems with big file one MUST HAVE PATIENCE ! to upload via Pronterface
Tx Ben

I have made that mistake as well. Slic3r can take a long time to export the file. In fact if you have "Do not cross perimeters" checked, some STLs can take many hours to export the file (unless that has been fixed in later releases). It is a good idea to check the print file with a text editor to ensure it has the expected ending (your custom end code etc.)

Dave

Another option is to open your gcode in something that can preveiw gcodes, personaly I use Repeater-Host [www.repetier.com] solely for the purpose of looking at the gcode and visualizing non-print moves

The latest Slic3r release has a preview option. One issue with the repetier preview is that it does not correctly display the extrusion width. This can result in the preview incorrectly showing the infill not reaching the perimeter, when in fact it will print OK.

Dave

I know the current experiment will show you a 3D preview, and a layer by layer 2D map. But I'm not sure if slic3r will let you open a generated gcode file to see this, I've only seen it before I export the gcode which doesn't really tell if the final file contains everything. I also haven't seen slic3r show non-print moves in these previews, but maybe there's a way to turn it on.... and these features could be added in the future, as slic3r is always improving.

Admittedly repetier has some issues, but it can at least confirm that the entire code is there, and show you any realy funky errors....

Edited 1 time(s). Last edit at 04/20/2015 01:35PM by shadow651.

Thinking about it, it would be impossible to display the extrusion width given only a G code file, because the width cannot be calculated without knowing the volume of plastic extruded during each move, and the volume cannot be calculated without knowing the filament diameter, which is not given by the print file.

Dave

I thought filament width was something given in all the info slic3r dumps into comments, but maybe I'm mistaken.

I was thinking....

when say google chrome is downloading a large file, it starts saving it as filename.download (or something like that) and only when it's done does it change the file to filename.ext
Slic3r could probably be programed to do something similar (i.e. filename.slic3r or something), this might prevent the mistake above. I have no idea how complex that might be to do, or how receptive the developer would be to it though.

Quote
shadow651
I thought filament width was something given in all the info slic3r dumps into comments, but maybe I'm mistaken.

Yes, many slicing programs put parameters in comment fields, but they are not consistent in format and an application could not rely on such a comment being present (though it could search for comments made by known programs and use them if present, as indeed the web interface does).

Dave