Print stops

I may be posting in the wrong place. If so, please redirect me. I am running Slic3r, Marlin, and Repetier. All incredible pieces of work. Trouble is, I get about 80% of the way thru one print and it stops right in the middle of some part of the model. This is without my touching anything or changing any parameters in Repetier. I did this twice and the stopping occurs at the same place. Could it be firmware, software, the part, watching it too much? Help. Thanx in advance.

Unless you have a reason to think it's to do with Slic3r's gcode, then probably more appropriate in the Printing or General forum.
It could be many things, from overheating stepper drivers to intermittent wiring connections, although stopping at the same place reduces the likelihood of the more random ones.

Repetier host shows what the solid form of the gcode will look like - does it show the whole part?
Does the slice phase run without warnings or errors?

If you are using Repetier host to send the Gcode to marlin, it shows outgoing gcodes in the log subwindow - when the print stops, is it still showing gcodes continuing to be sent?

If you do suspect the gcode, attach the gcode file. And describe about where in the part it has been stopping.

nb99, thanks for the heads up and sorry for incorrectly posting. I will move this to Printing, if necessary, after this note. I want to try a few more tests to check connections. To answer your questions: Repetier shows the whole whole part and the slicing works without any errors. As it prints, the gcode is running by on the window and it stops completely when the printer freezes(although I have had instances where the code would keep scrolling). Unfortunately, I didn't save the exact place in the gcode where it stops. Descriptively, it prints until it close to or at the top of the box portion, before the tabs begin. Gcode won't attach. File is 3.1 Meg. Is there another way I could make it availlable? Thanks for your help. And I will move over to Printing now.

If repetier shows the whole model, then probably not the gcode.
When you re-add the question to (probably General actually, Printing I guess is more for problems with the appearance of completed objects rather than a technical issue like stopping)
include teh above detail plus a photo of the object, and mention if you have printed anything as large or larger successfully. (I'm wondering about het effects)

Edited 1 time(s). Last edit at 03/05/2012 08:47PM by nb99.

I may be in the right place after all(at least in part). I tried running the model thru Netfabb some more and sliced in Repetier using the internal and external slicers. For the external slicer I have Slic3r 070. In both, the slicing went fine. Just for the sake of interest I tried loading each of the gcode files into Pronterface because I have had problems with other parts doing this. The Internal slicing went in beautifully. The External slicing jammed up at estimating time to print. I printed with Pronterface and the Internal one went all the way nicely. When I sliced and printed this file yesterday I was using Slic3r 0.7.0 . Is there possibly a bug in 0.7.0 ? I am attaching the .stl file because the gcode files are way too big. If I'm still not in the right place, I will repost.

1 Marlin Firmware

I had Marlin Firmware since 5 month, and i check after all Versions, the RC2 have Bugs, all Version before works normal

Take NOT a version RC2 from Marlin this Version have Bugs an the Firmware crashs , only RC1 from Marlin is 99% big bugfree and crash not, RC2 have Bugs, when i whis RC2 print holt at the Print !!, and i have
a connection from the Host and not an answer from the Firmware, teh Firmware runns in a loop, and on my LCD can i see the Firmware crashs !!!
I have many Time testet and i say it is better you take an RC1 Marlin !

2 Slic3r
I have many Objekts testet
Whis Version 0.6.0 can slice many Objekts correctly
Whis Version 0.7.0 NOT
Version 0.6.0 rocks better than Version 0.7.0 !

Zb.[www.thingiverse.com]

Whis Version 0.6.0 100% OK
Whis Version 0.7.0 not OK


Hardwarekiller

If you are using a max6675 TC, search through the issues for a fix I posted. I was having all sorts of firmware lockups until I removed an unnecessary delay from read_max6675(). read_max6675() is called from an interrupt and having an extra 1msec delay every 250msec can cause all sorts of problems that are difficult to identify. Once, I fixed this issue I have successfully completed over 50 prints.