SD printing stucks randomly.

Hello,

I have a prusa i3 printer and I am always printing using a sd card.I use the newest marlin fw.Sometimes,when I select a file to print,the printer instead of heating up,shows the name of the file on the lcd screen and does nothing as seen in the pictures below.
This problem now occurs every time i try to print.After appearing two months ago, the problem hasn't bothered me ever since except from now.Rarely,the printer can just stop in the middle of a print but without being not responding.I have tried a variety of sd cards,
a variety of gcode files and I have reformatted the sd card several times.At the moment, I have narrowed it down to being a problem in the hardware which is unlikely (either arduino or sd card adaptor) or a bug in the marlin firmware which sounds reasonable.

Here is what happens in the lcd



Here is the "feedback" i am getting



Here is the "feedback" i am getting when it is working properly.



Any help highly is highly appreciated.

Update: FIXED

Both cards I tried were kingston (2gb and 4gb) , but a little ago, I tried with a transcend card and it works just fine (at least for now).
I hope that will help anyone having similar problems.


NOT FIXED

The problem still occurs but what I have observed however is that sometimes, when the arduino boots up, the lcd displays the message "wait till user pressed button on lcd" and when i press the button it says "resuming print'.Later,when I try to print a file, the problem occurs.

I don't why it says resuming print when I haven't given the printer a file to print and i am pretty sure that it doesn't remember the previous file after being turned off
I have read that these messages are a result of the M0 command which I haven't sent to the machine.If I turn the arduino off and on or if i press the reset button,these messages are still being shown.

If I am right,why the marlin firmware acts like I have sent the M0 command when I haven't?

Edited 1 time(s). Last edit at 12/25/2014 04:01AM by gregory21b.

may have been mentioned: sd cards can be come corrupted easily. especially when cached on a pc.

have you tried reformatting sd card , and then placing files on card. renaming files, or copying over files on sd card messes with the sd card file read, the firmware becomes confused with finding file data when it is not all together, such is the case in rewrites, or when sd card is not ejected before removed from pc. not all cases are like this but the over all result is often of a corrupted file length, or so is my best guess, because a format of sd card seems to fix the issue.

There may also be other issues going on here.it is hard to say without more information. can you disconnect the lcd display, and does the issue still occure? it could be inductance on the sd pin of the lcd, or the sd card, and the charge holds to long. you can try to slow down sd card response.

in Sd2Card.h

look for
line 180

bool init(uint8_t sckRateID = SPI_FULL_SPEED


change it to one of the following =SPI_QUARTER_SPEED,,=SPI_HALF_SPEED, and so forth.. any way i think shortening the wires, or slowing down spi clk would help.

// SPI speed is F_CPU/2^(1 + index), 0 <= index <= 6
/** Set SCK to max rate of F_CPU/2. See Sd2Card::setSckRate(). */
uint8_t const SPI_FULL_SPEED = 0;
/** Set SCK rate to F_CPU/4. See Sd2Card::setSckRate(). */
uint8_t const SPI_HALF_SPEED = 1;
/** Set SCK rate to F_CPU/8. See Sd2Card::setSckRate(). */
uint8_t const SPI_QUARTER_SPEED = 2;
/** Set SCK rate to F_CPU/16. See Sd2Card::setSckRate(). */
uint8_t const SPI_EIGHTH_SPEED = 3;
/** Set SCK rate to F_CPU/32. See Sd2Card::setSckRate(). */
uint8_t const SPI_SIXTEENTH_SPEED = 4;

Edited 3 time(s). Last edit at 12/26/2014 01:41AM by jamesdanielv.

thanks for the answer but tried again reformating sd and regenerating the code file but didn't improve.

I have set the spi speed to eighth but that didn't help either.

The lcd panel and sd are separated as shown in the picture below and the wires between the atmega and the sd are practically the shortest possible when using the ramps board.
Sometimes though,the problem might go away for a few days or more but when it occurs,printing using sd is impossible every time I try.

Can this be a grounding issue thus interfering with the serial communication and causing all this mess?





Edited 1 time(s). Last edit at 12/29/2014 09:14AM by gregory21b.

one way to find out. especially because the sd card is near the motor and next to vibrations, and emf noise. un- mount the board, move its location 6 inches away and see if the issue still happens. it looks like your connector has a lot of extra wire on it. i would trim that down. extra capacitance of longer wires and rf energy on wires that go no where can not be ideal.

by un-mount the board i am referring to the entire arduino and ramps setup.

Edited 1 time(s). Last edit at 12/29/2014 03:45PM by jamesdanielv.

I had issues if I used an SD card to print but still had my ramps board connected to my computer via a serial cable. If the computer when to sleep or downloaded an update and did a restart, it would screw up the print. Disconnecting the cable solved that problem.

Best of luck,

Ross

---

You don't need a parachute to skydive. You only need a parachute to skydive twice.