1
$\begingroup$

I am converting an old Makerbot Replicator 2 to Marlin Firmware and everything works. The printer heats up, auto bed levels, and starts the print. However, after a couple minutes (usually after the 1st or 2nd layer), the printer crashes and stops. It does not continue printing and I have to restart it again. It crashed for every single print, I have not had any successful prints yet.

Here is a video showing the issue:

The camera was started right when the print started. After about 1.5 minutes, the printer crashes, and the lcd screen freezes.

Here are photos of a couple of prints that crashed: Photos of sample prints

I have all of my code here: https://github.com/RosalieWessels/Marlin_MakerbotReplicator2

My models are sliced with Cura and printed in PLA.

I tried hotend temperatures of 200, 210, and 220 degrees. My print speed is around 50 or 60 mm/s.

Here is a sample sliced file that was used: https://filebin.net/df33a3jjwgemz0m8

Thank you!

| improve this question | |
$\endgroup$
  • $\begingroup$ I want cake too! youtu.be/MzcrX3wcA-Q?t=32 $\endgroup$ – 0scar♦ Aug 3 at 6:38
  • 1
    $\begingroup$ One thing you should fix is the attachment of the belts to the carriage; the belt (tensioned with a tie wrap is quite original) has a lot of play. This causes the layer shifts in your prints. But, I don't think this is related to the crashing. $\endgroup$ – 0scar♦ Aug 3 at 6:44
  • $\begingroup$ Can you measure the voltage draw of heater and bed? $\endgroup$ – Trish Aug 3 at 8:15
  • $\begingroup$ Hello Rosalie, I noticed your question has been up for a while now. Have any of the answers below been able to solve your question? If so, would you mind accepting the appropriate answer. If not, what is missing so that we may help you further? Also, if you have figured it out on your own, you can always answer and accept your own solution after 48 hours. Thank you! $\endgroup$ – 0scar♦ Sep 2 at 18:35
1
$\begingroup$

I see a couple likely culprits for a hardcrash like this

  • problems with the power supply. If the power supply does not provide enough voltage an/or current to the board, this can lead to a lockup of the board.
  • temperature issues of the board. If the board overheats, it could fail to execute properly, leading to abort. make sure that the board is not overheating.
  • faulty firmware. recompile your firmware and reflash it.
  • faulty board.
| improve this answer | |
$\endgroup$
0
$\begingroup$

Few things to try,

Check G-Code - Verify that the slicer is not the problem, slice using some other program / make a new default profile and re-slice.

3D File - Also In parallel with the above point, I would get a standard test cube STL to start with. This will be a simple quick print to get a solid reference.

Voltages - Get a Multi-meter on the Regulated Voltage rails, 5V Rail, 12V rail / 24V rail. See if at the moment of crash a voltage rail collapse, the most likely one would be the microcontroller rail, but you may be able to see the problem somewhere else.

Current - If possible, measure the current draw of the printer either from the mains or after the AC/DC regulator. Its possible something is going horribly wrong and current limiting.

Serial Port - Possibly connect the printer to a PC via its serial port and open a com port. See if the printer spits out an error code at the time of crash?

End Stops - Double check that none of the End Stops are accidently being triggered (Although this should not crash the system, it might be part of the problem)

Verify Sensor Readings - Check all end stops, check the bed temperature readings, check the nozzle temperature reading. Maybe a sensor has failed and is causing the controller to crash out.

| improve this answer | |
$\endgroup$
  • $\begingroup$ of your suggestions, only the voltage and current could be relevant, because the rest would have resulted not in a crash like that, it's a print from SD-card afaict, making Serial port a no-issue, the file wouldn't result in a hangup, the G-code does not result in a self-reset/bluescreen, endstops are ignored during actual printing (printers use software endstops only then) $\endgroup$ – Trish Aug 3 at 16:57
  • $\begingroup$ @Trish: While the serial port isn't being used for printing, it could spill useful debug output indicating the cause of the crash at the moment it happens. $\endgroup$ – R.. GitHub STOP HELPING ICE Aug 4 at 4:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.