Repetier v. 0.82 stops job execution from SD card

Dear fellow repetier users,

I have just migrated from Marlin to Repetier version 0.82 (07-03-2013). My hardware is a Rostock Mini delta bot, and my electronics are RAMPS 1.4 with a G3D LCD+SD reader. Marlin ran flawless on my setup, but lacked proper delta bot integration, which gave me headache.

Now, with Repetier installed, I am blessed with a much better delta bot firmware, but a strange problem.

My prints run fine... but only for a while... I normally leave the bot to attend to itself, but ever since the firmware upgrade, when I come back, I find a machine that has stopped in the mindst of printing. Heat is still on and regulated for both extruder and heat bed. The firmware is not frozen. I can manually move the axis of the machine using the LCD user interface. I can also home the bot. However, trying to stop/restart/resume print jobs from the SD card, nothing happens. The status line in the display just show the following line: "Printing...41%" (or whatever percentage the machine managed to finish before mysteriously stopping)

I have tried to reduce delta line segments and buffer sizes to check if it was a memory problem, but that did not fix the problem. Any ideas of what could be the cause?

I have attached a photo showing the stalled print jobs. The two prints has been sliced with different parameters, so I still need to test whether the problem is systematic (whether the machine stalls at the same spot each time) or whether it is random.

I have also attached my configuration.h file. Other than that I have only altered the beeper-pin for the G3D LCD display in the pins.h file .

Lastly, I use slicer 0.99 as job generator.

Update:

The stalling appear to be systematic. I ran the same job twice, and the bot stalled the same spot at the same percentage executed. Next up is to try to isolate whether one specific code line makes the bot stall. That, unfortunately I will not have time to do before the weekend.

I am having the same problem with my Leapfrog Creatr. I can resume the print by pressing the "fake" ok button in the debug window, but it does not solve the problem. At some times it seems to be systematically stopping at high acceleration print moves, but even lowering the acceleration to as small a value as 250 mm/s/s does not solve the problem.

However, I am using a USB to control the printer, but I have tried several different configurations of computer and USB cable that have improved the frequency of the freezes, but not completely eliminate them.

If you find the code part causing the pause post it here, so i can test what might be the problem. You could try dry run to find the problem so you do not need to waste plastic.

jdyverga: If fake ok helps ts means that the firmware has send the ok but lost the o or k, so it is not recogniced by the host. If you are not using ping pong you need more occurences then to get a stall. So you can even hit fake ok a few times to prevent a stop at the next missing char.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Update:

Assuming that the error was systematic since I had the same print stall at 41% at the exact same spot, I decided to do a test. I noticed the z height, took the SD card to my computer, and copied that one layer in which the printer stalled to a new file. I ran the modified job from the SD card, and the build completed without stalling. This leaves me even more puzzled.

Now I'm printing the original print a third time to ensure that it was not just random chance that the printer stalled the same spot twice. Chances are minimal, but hey. Murphey might be playing tricks on me.

Please keep posting if you guys experience similar behavior or if you have any suggestions.

/David

Edited 1 time(s). Last edit at 05/29/2013 05:35AM by volunteerlabrat.

Okay. Stalled the same spot again. This time I'm doing a dry run, with echoing enabled, hoping to pinpoint the line that cause the job to stall.

Oh wow! Now for some interresting news!

I sat down and surveyed the print-job as it neared the stalling point. Here is what I found out:

Up till 37% job execution, my buffer was full (with 16 lines) only dipping to 15 buffered lines whenever a circular movement was made.
From 38% and up, the buffer went down more and more, at times dipping down to 3-5 lines.
From 39% the fast moves became jerky, with small halts of the movement in-between delta segments. The buffer went from time to time as low as 1 line.
From 40% the slow moves also became jerky.
At 41% the bot stopped completely. Pausing/resuming the job did nothing.

That leaves me thinking. -Could this be a problem related to reading the job file from the SD card? The job is around 16mb in size. The SD card works perfectly fine in an ultimaker standing next to my machine. The SD card has been formatted recently, and no errors were detected on the card.

Back on the Marlin firmware now, testing the same job. Everything looks cool this far.

That is indeed very strange. Buffer can run empty when you have many very short moves in a row.

But that is no reason for the hanging problem. Have you also tried writing the file in binary format (Save Job in host offers that). What is the longest line in your code? Lines linger 95 chars could cause trouble, also I do not see how it could create a stall.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks for the fast reply.

I'll give it a look on friday and get back. Maybe I'll record a video of the phenomena as well.

All the best!
David

Dear Repetier,

I never got around to try any further debugging. I've spent time printing some 500mm tubular sections over the weekend. I've probably stuffed more than 300 megabytes of G-code through Marlin without any issues. So strange with what cause Repetier to crash.

If I don't get around debugging anytime soon, I could upload my firmware and the job file, if that is of interrest for debugging purposes. Then again, if it is only me experiencing thee problems, maybe I should just wait a few months for a newer build of Repetier and try again by then.

All the best
David

I'm getting a delta the next days. Will try to run some prints from sd card and see if it happens to me.

Only to make sure I get your scenario right:
- Which slicer did you use
- How did you copy code to sd card (source from slicer, save gcode from host, binary or ascii)
- Did it happen wich every print or only one special g-code

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

I used the Mac-build of Slic3r version 0.9.9.

The code exported in ASCII format to a file, and then manually copied to the SD card.

It has happened with several prints

You can find your firmware with the alterations I made to get my G3D LCD and SD to work here I have compiled the firmware with Arduino 1.0.1:

[volunteerlabrat.com]

You can find the crashing job here:

[volunteerlabrat.com]

I ran the job at 40% of normal speed. This seemed for me to affect when the print would crash, yet at the same speed, the job would consistently crash the same place.

Maybe you can replicate the crash behavior by just disabling steppers, and run a "completely dry run" including movement?

All the best
David

Dear all,

I never resolved my issues with the repetier firmware. I am still using a very barebone marlin delta implementation, that does not allow me to use the LCD display for much else than selecting a jb file from the SD card. By chance anyone outhere have any suggestions or news when it comes to delta robot firmwares?

All the best
David