Model stops printing after a few layers

[goldbeezie]

Hi guys,

I'm new to 3D printing, and I'm trying to print an iPhone case. I designed it with autodesk inventor and used meshmixer to put supports on it. When it prints, it only prints the first few layers and then stops before printing the sides of the case. The printer is a makerbot replicator 2x and it was able to print another piece, just not this one. I also downloaded netfabb and repaired it with that, but it still wouldn't print. I've attached a version with the supports and a version without. Does anyone know a solution to this problem?

Thanks in advance.

[3dkarma]

Try putting it through the cloud repair service at https://netfabb.azurewebsites.net/ - the cloud service does a better job of repair than the free download.

[goldbeezie]

Thanks, I didn't realize there was a difference. I'll give it a try and see if it prints.

[MysteryAlabaster]

One thing I noticed about Makerbot printers is that they CAN NOT handle system time changing if you are printing from a computer.

[GameProps]

I don't think that system time would be causing an issue with the printer stopping after a few layers. If it's still doing this after running the model through the Netfabb Cloud I would recommend contacting Makerbot. Also is it doing this with other models as well or is it just this model in particular?

[RobH2]

I've having the same issue with my Makerfarm. I have a new power supply that can deliver 24A. I have a 60mm fan on ramps. I've reset my thermistors so I know they are not shorting. I wiggle everything around just to test that and nothing fails or faults.

I get about 5-minutes into a print and it just....stops and sits. The target temps all flip to zero and everything starts to cool down. I go to my slicer and the gcode is still running away, line by line, like everything is normal. I'm using Simplify3d as my slicer. I don't think it's a slicer malfunction.

Anyone else have this issue with Ramps and Makerfarm?

[old man emu]

Yeah. My Makerfarm Prusa i3 (without the v) has done it to me. I'm slicing with Slic3r and running through Pronterface. I seem to remember once this happened so I printed the same Gcode from an SD card without problems.

I have a bad time with my Pronterface not recognising the printer via the COMM port. I think the problem resides somewhere in drivers since the Pronterface drivers are unsigned and the Windows O/S doesn't like unsigned drivers. Probably part of the built in anti-virus protection in the later versions of Windows.

I know that when I was installing Pronterface, I had to deal with the Python files a lot.

Old Man Emu

[RobH2]

Thanks OME. That's a good test, to try with an SD card. I should have thought of that myself. I just never print from a card so I kind of forgot I could. I'll report back if it helped or not. I have the same printer as you FYI.

[Roxy]

Thanks OME. That's a good test, to try with an SD card. I should have thought of that myself. I just never print from a card so I kind of forgot I could. I'll report back if it helped or not. I have the same printer as you FYI.

The communication link is a weak component of the design. It is across USB, but that USB port is pretending to be an RS-232 communication port. And the protocol for detecting errors in transmission of a line of GCode is pretty lame. I think it is fairly possible the communications to the printer is at fault as opposed to the actual printing being to blame. So, I'm in agreement with printing from and SD-Card for a while. If that goes OK and you switch back to using an USB cable and things start locking up again... You might have your answer.

[RobH2]

I think I've found it. I have two brand new Hexagon hot end kits that came with thermistors, fans, heaters, etc. One of the thermistors had a bad connection to the lead wire, a short. Goes to show, just because it's new doesn't mean it's flawless. One lead had just the smallest bit of solder holding it to the lead wire and it came loose. I've now used crimps instead of solder and I think I'll be OK now.