Hi community,

I've got a problem here. I print from a SD-card and my printer just stops somewhere in the print. This happens all 2 to 4 prints. "It stops" means, that the printer stops moving, the display tells me "ready", the heated bed and the extruder-heater stay on. I'm almost sure that the controller does not reset itself because the heaters stay on and the displayed position is correct. It fails randomly which means it could happen at 20 minutes in the print or after 1,5 or 2 hours.

I couldn't find anything suspicious in my g-code. If I start the same print again and it stops again, it stops at a different place. Nevertheless here the part where it stopped last time:

G1 X32.838 Y-59.779 E8.85428
G1 X33.038 Y-60.112 E8.87207
G1 X31.935 Y-61.215 E8.94353
G1 X32.467 Y-61.215 E8.96794
G1 X33.038 Y-60.645 E9.00489
G1 X33.038 Y-61.177 E9.02929   <---------------FAIL
G1 X33.000 Y-61.215 E9.03173
G1 F5400.000 E3.03173
G1 Z45.310 F7800.000
G92 E0
G1 X14.820 Y-61.215 F7800.000
G1 Z45.010 F7800.000
G1 E6.00000 F5400.000
G1 X14.858 Y-61.177 E6.00246 F2400.000
G1 X14.858 Y-60.642 E6.02706
G1 X14.285 Y-61.215 E6.06431
G1 X13.750 Y-61.215 E6.08891
G1 X14.858 Y-60.108 E6.16095

My printer is a:

• Delta, my own constuction
• Ramps 1.4
• Ultimate Kit from reprapdiscount with a full graphic smart LCD
• Repetier 0.91 Rev4, downloaded from the homepage and uploaded to the controller several times
• every motor and ramps have an own fan, overheating is impossible
• ramps is at 24V, the power supply has plenty power
• heated bed is at 230V

I looked around and I found this: HERE
(its half german, the interesting part starts at the bottom of the first page)

They believe, that the problem is the display/the card reader (on the same board) or the cables. On this particular printer, these cables are placed near the heated bed which is bad because of the current and electromagnetic radiation. In my case the cables do not cross any other cables.

I read this thread an tried this:

• separate the two cables as far as possible
• placed a ferrite-core around the cables
• formatted my sd-card (every time)
• put just one folder with one file on the sd-card

Any ideas?

Edited 3 time(s). Last edit at 02/22/2014 04:43AM by Darki.

First you should find out what kind of hang you have. As you know th eline where it happened, you were not printing from sd card. In that case it might wait for a "ok" to receive so buffers get empty. That should only happen if you have communication errors happening.
If th elcd is still responsive, try changing speed multiplier and see if it changes in host. That means the back channel is still working and we have to find out why it refuses to take new commands.

First get 0.91 Rev 5 (contains new delta fixes) and then add
#define DEBUG_PRINT
to your configuration.h

That gives you a new menu entry in lcd in quick settings writing important debug informations to the log (if backchannel is working). Post them here. They might help to find the place or reason why it happens.

---

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!

Quote
repetier
First you should find out what kind of hang you have. As you know th eline where it happened, you were not printing from sd card. In that case it might wait for a "ok" to receive so buffers get empty. That should only happen if you have communication errors happening.

Surely I was printing from SD-Card. I started the print through the menu on the lcd! And the controller isn't even connected to a PC.
I know the line where it failed because I took note of the coordinates (displayed on the lcd) and then looked up the line in the g-code to continue the print (because it was an 3 hour print at ~80%).

Quote
repetier
If th elcd is still responsive, try changing speed multiplier and see if it changes in host. That means the back channel is still working and we have to find out why it refuses to take new commands.

Yes, i can change values, even start a new print without a reset. As i mentioned above, not connected to PC.

Quote
repetier
First get 0.91 Rev 5 (contains new delta fixes) and then add
#define DEBUG_PRINT
to your configuration.h

That gives you a new menu entry in lcd in quick settings writing important debug informations to the log (if backchannel is working). Post them here. They might help to find the place or reason why it happens.

Ok, I'll try that. Where will it save the log? WIll it be on the SD-card or will it be sent to the PC?
I'll try to get a video of the fail.

It will write it to serial output so you need a host connected.

---

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!

Well, I just finished a 3 hour print with no complications. (It failed last time) I downloaded the new Firmware with my settings, changed nothing except for the "debug_print". I was logging and recording all the time. :-/
I wouldn't say that the problem is gone... I've got another 5 or 6 hour print for tomorrow!
Is there any way I can log something on sd-card? (for the case that the usb connection smoothes out problems with the power supply)

No you can't log to sd card. We can only handle one sd file at once and we left it for sd printing.

---

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!

Had a very similar problem here, 94% into a 5 hour print.

Also on a custom built Delta with RAMPS 1.4, using a Reprap discount LCD (non graphical), also started from SD card and not connected to PC, using firmware v0.91 rev5
I noticed "Buffers" on the LCD displayed 0, not sure if that indicates something.

Will post if I can get a log of this on the host computer on another print.

Hi Brekel,

try to connect a USB-cable from the microcontroller to a USB-charger. I think it could have sth to do with power supply.

Thanks for the tip, will give that a try.
I had it connected to a USB hub connected to the computer when it stopped.

Hi!

Tried it myself because I thought it had something to do with the power supply. Still stopping.

@repetier:

I tried to log it as I told you above. Had a 2 hour and a 6 hour print from SD-card with logging to my PC. Guess what, no error/stopping. The camera was recording all the time. Hab another short print in the night with no connection to the PC (not logging, not recording) as I did before and it stopped after ~1 hour which was ~90%. For that print, I connected the USB-cable to a USB-charger, because I thought it would stabilize the power supply of the board, but it looks like the problem is somewhere else.

Edited 1 time(s). Last edit at 02/24/2014 08:46AM by Darki.

That is really a complicated error. First, because it does not happen to every one, so it is already difficult to reproduce. And second, because it happens at different positions, so no nice tests can be developed to provoke it and make it localizable.

It might be a read error confusing the firmware, which would explain why everything works except that the print does not continue.

One thing you could try if it happens when not connected. In printer settings you can set reset on connect to disabled, so it will not reset the board (which would void the error state). But perhaps it still allows to output the log debug message.

---

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 didn't get your last point. Could you explain it a little further?

I can randomly reproduce it, but I can't log it, therefore I asked if it is possible to write a log to the SD-card. If I do a large print (4 hours above), I think its almost sure that there will be an error.

The only things I can try now is:
- shorten the cables to the display
- try another sd-card
- separate the cables even more
- move the display(+cardreader) to a different place, even if there is nothing nearby

BTW HERE is a link to my LCD-panel.

EDIT:

The question is: What changes, if I connect it to PC and if I start logging as described above!?

I checked my sd-card and there seems to be no error.

Edited 2 time(s). Last edit at 02/24/2014 10:04AM by Darki.

The GCD uses software I2C for communication, which can block on communication errors. Bus you said your display is working, so it is not the display part.

The sd card is always a possible source of errors. If cables are too long you get reflections of signals so a read error might be a reason for the stop. That is one of the things the debug might show.

You see a read error also in the log as it writes a sd read error message. It does this also for the ui but I guess it would be replaced by the idle message very fast.

My last point was a possible way to show log messages when the error happened when not connected. Normally it will reset the printer on connect, so all state variables are gone. If you connect with reset disabled you might be able to output the log message.

So far it sounds like the error only happens when NOT connected to the computer, which would make it more a hardware problem. The firmware always sends it's message to serial output even if not connected. It simply does not care. So connecting makes only two changes - requesting temperatures with M105 from host and better stabilized 5V source. I think if it is one then the 5V source. If you have ever connected a 12V led to the printer you will see how it flickers when heaters go on and off. WIth bad luck this influences other parts as well. But I'm no electronics expert, just happy it does not happen with my printer.

---

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!

Ok! If there is a message on the display, I'll do another print with my camera.
So your advice is to print from sd card and if it stops, I have to connect it to repetier-host without reset, right!? How do I get the last messages? I guess the message will be sent only once!? How can I see the state?

Edited 2 time(s). Last edit at 02/24/2014 01:13PM by Darki.

Would it be an option to print the amount of SD red&write messages to a debug line (or page) on the LCD?
Just count them and display a number, and maybe the last error message for example.

Or detect when the buffers are 0 and print hasn't finished yet and print the last error for example.

The sd read error will be lost. What still should be possible is the debug message from the quick menu. That can be repeated any time.

You could go into motion.cpp and search and uncomment all 4 occurences of

if(linesCount == 0) UI_STATUS(UI_TEXT_IDLE)

That way the message on the lcd gets not lost so fast. The only negative effect is that you will not see any idle message any more.

---

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, will give that a try just in case it stops again.

I'm suspecting it may have more to do with the ribbon cables and not so much the power.
I'll try and see if I can setup a worst case scenario, crossing them, having them close to one of the motors, see if I can swap them with longer ones.

So far a 10 hour print is at 85% without issues so it seems it's not a reproducable on my machine as on Darki's.

You are giving me an idea. The status line is a debug line, but the problem is that once the buffer is run empty, the message gets overwritten. I will make a new message mode UI_ERROR_STATUS which sets a flag and as long as the flag is set, new messages can not overwrite the message assuming an error message is more important. A click will remove the error state then, so normal messages appear. That way everyone has enough time to read the message.

---

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!

Sounds like a good idea indeed!

Just checked motion.cpp and those 4 lines are already uncommented btw.

@repetier
Sorry, but what do I have to do to get the debug message?

Your idea is great! Errors should be displayed until the user does something.

@ brekel
I'll also try to make it even worse by twisting the cables!

@Brekel I meant comment or delete, not uncomment. I always us ethe wrong term for it :-(

when you have #define DEBUG_PRINT in your config you go in the quick settings menu and select the last point. It will then print some internal data to the serial console.

---

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!

Interesting, it just failed on the 10h print, just a few minutes before I saw 96% on the display. (27.4mb file)
My first fail yesterday was on a 5h print somewhere around 95%. (14.9mb file)

So it doesn't seem to be related to filesize or print duration, peculiar that both are at about the same percentage mark though.


This was using the USB charger, I'll try a quick print next and log on the PC.

I'm now printing with (improved) bad :-) cable routing, camera and I'll try to get that debug-message.
For me, the error is definately not related to printing-time, printing-steps or size.
Also no luck with usb-charger.

@Darki: note there's also a similar discussion on GitHub on this:
[github.com]

I was able to get the error again! Same part as yesterday. Stopped 2 or 3 layers under that one from yesterday.

Debug gave me:

02:58:52.203 : Buf. Read Idx:1 Buf. Write Idx:1 Comment:0 Buf. Len:0 Wait resend:-1 Recv. Write Pos:0
02:58:52.203 : Min. XY Speed:4.74 Min. Z Speed:4.74 Buffer:0 Lines pos:15 Write Pos:15
02:58:52.203 : Wait loop:1

I was recording and standing enarby, but I couldn't see any message, have to check the video in a few minutes! (Didn't make the changes in the motion.cpp yet)

EDIT: Can still change the speed multiplier on the lcd and it is changed in the host too!

EDIT2: Looked at the video frame per frame, can see the pixel changing. Well, it went straight from printing to idle! Buffer was at 16! Will now make the changes to the motion.cpp and start it again.

Edited 3 time(s). Last edit at 02/24/2014 03:26PM by Darki.

I just updated github master tree with some changes, which hopefully work.

1. As discussed the error message should stay on screen.
2. Added sd infos to log message, after seeing it happened indeed in the main loop.
3. Added a fix for read errors. After I get a read error I reposition again at that position and try to read the file again. With some luck the error does not happen twice in a row, so we can continue normally. You see this in the lcd display.
"SD Read Error" means unrecovered error.
"SD error fixed" means the error could be fixed by rereading the byte causing the error.

@Darki That you wen directly to idle means nothing. There is no forced update and if the 16 moves are executed faster then 1s which is the update frequency of the display, it might miss the message completely. Hopyfully my changes work as expected so we have more infos next time.

---

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!

Can I use the online configurator to download this?

No it's not online after it is tested a bit more. But you can use the Configration.h from the online configurator.

---

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!

Ok! Thanks again, will try that now!

You could also try using a laptop to monitor, that will eliminate the ground loop problem. (two pin power cord or run on battery)