Print stops randomly

For a number of weeks now I have been plagued by my prints randomly stopping before the end of the print. Sometimes I can print many times with no problem, other times prints fail quite frequently. I first noticed this in Repsnapper, where for no apparent reason Repsnapper issues an N-1 M110 command mid print, as if it has reached the end of the gcode file. This issue has in fact been reported as an official issue in the Repsnapper github repo (github/timschmidt/repsnapper), but no definitive solution has yet been found.

I am sure the firmware in my RAMPS board has not reset since when this unexpected stop occurs, the firmware is still controlling the nozzle temperature and a manual move to X5 Y5 executes as expected (so even the absolute position is retained).

Not sure how to get to the cause of this fault, I decided to try using ReplicatorG-0024 as the host software, to see if the issue was with Repsnapper itself. Unfortunately the problem occurs with this software too. With RepG, there is no N-1 M110 command, the print just stops mid print. And again the software is still functional and the machine is just sat apparently waiting for the next command.

The Repsnapper log files do not offer any insights, and I have not figured out how to get any log files from RepG. I can also confirm this occurs on 2 different Dell laptops, one running Ubuntu 10.04 32bit, and one running the 64bit version.

I also tried running prints with only an Arduino Mega connected (without the RAMPS shield and therefore no 19v power anywhere near the Arduino). So far this has not failed, but this doesn't necessarily mean it never will.

So my questions are:
1. has anyone else had similar issues with their prints?
2. can anyone offer any advice as to how I can troubleshoot, or even fix this problem?

Thanks,
Jean-Marc.

---

[emaker.io]

[emaker.limited]

I've had this problem too. I get both the occasional pause between loops of perimeter or infill. These last from 2-3 seconds. And also very rarely an almost indefinite stop that ends up with me cancelling the print. I thought I had solved the latter issue with a shorter USB cable, but it might resurface, given what you have stated.

I use Repsnapper v352 to send gcode.

Woodsmoke

@jmgiacalone and Woodsmoke: How fast is your feed rate?
@Woodsmoke: Are you also using RAMPS?

I've found that you can get the printer unstuck if you enable temperature update in repsnapper. A good compromise would be to set it to 10 sec updates so it doesn't interfere with the print too much. At least, it won't ruin your whole print if it gets stuck while you're not looking.

I've been having this problem on and off with Techzone Gen 3 remix. After switching the stepper controllers to Pololu 1201's, I started seeing this more. Printing at 30 mm/s feed rate, I can see a lot of checksum and other errors with X and Y at 1/16 steps and the Z and extruder at 1/4 steps. At slow speeds, the errors coincide with extruder retract and restart which is set at 15 mm/s (based on feed). I think this step rate is too fast for the Sanguino and it keeps it too busy to receive commands. This results in erratic head movement and bad print. I saw a large improvement on the print it slowed down to 15 mm/s. I'm going to try to back down the Z and extruder down to 1/2 steps and see if that helps. Perhaps I'll also need to go to 1/8 steps on X and Y.

But I thought that the RAMPS uses a faster processor and can handle microstepping much better than the Gen 3 electronics.

brnrd,

Thanks for the temperature update suggestion. I will try that later.

I actually print at 50mm/s, and usually get only one comms error around line 15 during a print, even one that is 30,000 lines long. My serial baud rate is set to 115200, and I don't get any pauses during a print (other than the frustrating error described in this topic), even when doing multi faceted circles (which I am pleased to say are coming out very round).

All my axes run at 1/16th microstepping (even my Z, which I know is unnecessary for that axis).

In fact overall I am very pleased with the performance of the RAMPS/MEGA combination.

---

[emaker.io]

[emaker.limited]

I had a few problems with switching electrical noise (Lights / electric drill etc.) causing Gen 3 electronics to stop. Fixed it by using a better PSU , sorting out wiring and boxing the electronics.

---

[richrap.blogspot.com]

richrap,

Can you describe how the noise caused your electronics to stop?
Did the firmware reset?
Did the serial link go down?
Did it cause comms errors?

I use a Toshiba laptop PSU, which gives 120W at 19v. Not sure if that's good or bad really.

Thanks.

I spotted the problem quite quickly as it started to go wrong when I switched the lighting in the room.
I didn't need to investigate the exact point of failure, but basically the firmware was running on the mainboard but all the axis had stopped moving, communication to the extruder controller was still working and temperature was being controlled.

My setup at the time had extra long cables to the stepper controllers and a bit of a wiring mess on the ATX psu after this was all tidied up and I switched to a 180W Atx with just a simple 12V cable to the boards the problems didn't happen again.

I think my issue was conducted noise down the Mains, through the ATX and onto the mainboard.


The Toshiba Laptop PSU should be giving you a nice supply, so that should be a good thing.

I'm also just switching from Gen3 to RAMPS and have not seen any problems yet, so maybe it's something else.

Have you tried running the Steppers at 1/8th stepping?

Rich

---

[richrap.blogspot.com]

I was also having issues with my print stopping randomly. It turned out to be something reprap-host was doing. I switched to replicatorG and haven't had problems since.

I'm using techzone gen3 electronics.

you can also make sure that comments are being stripped from the gcode. I know my prints would pause to go through those.

I think I've identified my problem to be due to a bad connection in the 6-pin ribbon cable between the FTDI usb-serial board and the motherboard. I was getting a lot of checksum errors and resend requests and then random freeze every few minutes. At which point, enabling the temperature update always got it unstuck. So, I pulled out the cable and soldered the the wires to the pins on both ends. After this, all the errors went away. So far, it has been printing for almost 2 hours after changing the firmware to use 57000 baud and it hasn't stopped yet.

My machine has been running fairly reliably but I have been moving the usb-serial board between the motherboard and the extruder controller when I was working on the extruder firmware. The repeated handling might have loosened the connections.

Edited 1 time(s). Last edit at 03/25/2011 12:27AM by brnrd.

Hmph... mine has done this twice on me. Both times when I'm not watching... 1st time was on a 25mm cube. I had been printing continuously all day... 2nd time was during a 3 hour print. I came back to it half done and a giant blob of PLA under the head. No signs of problems, heater still on.

My setup:
>> Prusa Mendel with RAMPS electronics - I bought it assembled
>> Skeinforge 11.04.26
>> RepSnapper Beta (with self proclaimed "version unknown") that is on GitHub as of May 21, 2011
>> host: Dell D630 with WinXP home SP3

I am unable to get replicatorG to run in XP... everything I've downloaded seems to be for ubuntu. Else I'd try that. It feels to me like XP is "going idle". The first time it died on me was a 25mm cube. Then I noticed XP would turn off hard disks so I disabled all power saving settings. I did make a big print while I was on the host computer surfing the web and reading reprap forums, etc. It completed no problem. I changed some settings and started another big print and went to dinner but the fault came again. XP was there, not sleeping nor having rebooted (defaults to ubuntu, so rebooting is impossible) and repsnapper said the print was done. The half completed job on the mendel begged to differ...

I can't find anything specific enough about making this setup work in ubuntu, else I'd try all this with ubuntu 10.04 that this Dell dual boots with...

Let's hope this doesn't happen too much more to me... I'm trying to prototype a product that involves me piecing together 5 "large prints" and I need to test this drawing before going to mold.

Chris

Well, it did it to me again. I'm going to need a solution for this... otherwise the whole point of having a reprap is null and void...

It was going along well enough... until 7 minutes after I went to dinner.
From RepSnapper.log:

19:13:58 Send >>SendData: N16236 G1 X121.3 Y73.32 Z14.4 F960.0 E507.8614 *125
19:13:58 Send >>SendData: N16237 G1 X120.86 Y73.09 Z14.4 F960.0 E508.3409 *66
19:13:58 Send >>SendData: N16238 G1 X119.51 Y72.86 Z14.4 F960.0 E509.6666 *68
19:13:58 Send >>SendData: N16239 G1 X119.26 Y72.99 Z14.4 F960.0 E509.9383 *74
19:13:58 Send >>SendData: N-1 M110 *15

Following this in the RepSnapper log were only entries about temperature...

---

There is no M110 in the source gcode file... here are the entries:

G1 X120.86 Y73.09 Z14.4 F960.0 E508.3409
G1 X119.51 Y72.86 Z14.4 F960.0 E509.6666
G1 X119.26 Y72.99 Z14.4 F960.0 E509.9383
G1 X117.56 Y72.56 Z14.4 F960.0 E511.6374

The bold line is line number 16240 in the gcode file generated by skienforge and loaded into RepSnapper.

---

Any thoughts on a solution or alternative?

Thanks,
Chris

PS - I made it so temperature is updated every 2 seconds AND I used a program that prevents windows from becoming idle called Timeout Preventer. Using ATX 12V power supply and nothing substantial was switched on the power lines...

Edited 2 time(s). Last edit at 05/25/2011 11:33PM by unexpectedly.

You might want to look at the error log in RepSnapper. M110 is the command it sends at the beginning of a print to set the line numbers up correctly. It appears that it thinks something went wrong and its trying to restart.

I've seen this happen on my Gen6 Mendel once when the firmware crashed.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

Hmmm, I recall there wasn't an error file in the repsnapper directory. Will check again tomorrow when I get back to work. I'll also try to learn more about the RAMPS firmware I have...

Thanks! -Chris

In the print tab in RepSnapper, next to the Interactive Control tab (in the middle of the screen) there is another tab for communications, if you click on that one you can see three different levels of comms between RepSnapper and the printer. One is just echos, one is errors and one is everything. It should give you more insight into what is going on.

Failing that you could always download port-mon and use that to capture the communication between the two devices. I often use it if I don't trust the RepSnapper logs.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

... look at the line-number count - instead of "N16240 ..." it's printing "N-1 ...", what's seems to be a sort of overflow or restart with wrong parameters.

Especially the "-1" points to a wrong calculation of the next line number ...

Edited 1 time(s). Last edit at 05/26/2011 01:41AM by VDX.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Chris,

That's the same issue I was getting and have reported here. My current solution to this is to run every print from the microSD card. You can get one of these for the RAMPS boards from Kliment in the reprap irc channel.

The M110 N-1 is repsnapper's way of starting a print. It sets the line number to -1 so the first line of Gcode sent has line number N0. So in this failure mode, repsnapper sends the start of print command randomly during a print, then stops.
Interesting that you are getting this on XP as well. I wonder if the issue is in the fw?

---

[emaker.io]

[emaker.limited]

... a restart without reset?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Indeed. and the fw is still running because it accepts new commands and heaters are still managed.

I was having the same issue on my RAMPS setup on a machine with a heated bed that consisted of a 1600W clothes iron. I had the iron and the 12v brick driving the RAMPS plugged into the same powerboard. I found that when it happened, I had to unplug the RAMPS and the 12v before I could get it to communicate again (but like you said, the firmware was still running managing the heater). Somehow I became suspicious of the iron and I moved it to another power point and the problems went away. Perhaps this was some sort of power spike caused by the iron switching that then caused the comms chip on the RAMPS to shutdown? Could you be seeing something similar? Try isolating the RAMPS power supply.

Another thing someone suggested to me is to remove the diode on the RAMPS so that the arduino is not connected to the 12V power line. I never tried that option.

Greg,

Thanks for the suggestions. I actually don't have the diode fitted as I run my RAMPS from a 19v laptop power supply. So the 5v for the arduino is provided by the USB cable when I get this problem.

... as the GND of the USB cable is connected with the laptop shield, you can receive heavy noise here ... with long unshielded wires to the steppers and heaters too ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

jmgiacalone Wrote:
-------------------------------------------------------
> Interesting that you are getting this on XP as
> well. I wonder if the issue is in the fw?

I grep'd the arduino firmware folder for 110 and saw this in Tonokip_Firmware.pde:

if(gcode_N != gcode_LastN+1) && (strstr(cmdbuffer[bufindw], "M110") == NULL) ) {
      Serial.print("Serial Error: Line Number is not Last Line Number+1, Last Line:");
      Serial.println(gcode_LastN);
      //Serial.println(gcode_N);
      FlushSerialRequestResend();
      serial_count = 0;
      return;
    }

See, it appears to me to mean if the line numbers mismatch AND the command is not M110 then we ask for another copy of the last line. So if we do get a M110, we just keep going down that function... and there are no handlers for M110. The file does have a big select:case to handle M codes and 110 is not present in it! So M110 ends up being an undefined condition. The firmware I'm using is kliment-Sprinter-01d5fbf.

So I changed that if to:

if(gcode_N != gcode_LastN+1) {   
      Serial.print("Serial Error: Line Number is not Last Line Number+1, Last Line:");
      ...

Which means that instead of the M110 getting the firmware into an unknown state, it is treated the same as a line number mismatch, which hopefully means RepSnapper will re-send. Looks like the PDE file is written in C, which I can speak, so if needed, I can add a handler to specifically catch (and ignore) the M110 in the select:case.

I'm 1/2 hour into this print...

Yaay,
Chris

PS - the gentleman who supplied the parts for the reprap I'm using said the diode is not installed, so the arduino is running from my laptop's usb.

Edited 2 time(s). Last edit at 05/26/2011 02:34PM by unexpectedly.

You need to look at the line preceding that code segment:
gcode_N = (strtol(&cmdbuffer[bufindw][strchr_pointer - cmdbuffer[bufindw] + 1], NULL, 10));
This sets the current line number in the fw. So if the fw sees:
N-1 M110 *15
it will expect the next command to be at line N0.

So far so good... just finished that print without issues. I did see some comm errors with request for resends... but it got through the part.

Now I've started on the next one. RepSnapper said it was 44:04 (yes 44 hours) to print... and now it says 46 hours. So, we'll see how this goes!

download notepad+++ here [notepad-plus-plus.org] it is a free open source editor.


use this program to open up and look at your gcode.then select edit->eol conversion ->unix. this ensures that the end of line type is correct for firmware gcode interpreter.

Is this the problem?, gee i don't know.

but it may help with other issues.
with notepad++
just select view->show symbols->show all characters and you will see even invisible characters. I wish i fully understood why but windows likes to and a whole bunch of those whenever you edit a file manually. (i know you say you tried ubuntu as well, but was the gcode regenerated?

CRLF for line feeds, and some garble goo in word or write with the RTF font, even when saved as txt file type....

Just a thought. it sounds like rep snapper is choking on something visible, or not visible.

lines with no data, invalid characters, characters in wrong place,and invisible characters all will cause halted prints. there may be some fixes in place, or in the works, so take all the above with that in mind...



good luck.

Edited 1 time(s). Last edit at 05/27/2011 01:20AM by jamesdanielv.

Yeah I use pspad. Pretty sure that's not my issue though...

It happened again at 2am... 5 hours into the part I'm trying now. So I reworked my printing area. It's a plastic cart... I moved all the AC power cords to the bottom shelf, bent up 1/2" rigid conduit for the USB cable to my laptop. The ATX power supply is still on the top shelf 2" away from the RAMPS board. And I ran a grounding strap from the conduit to the case of the power supply.

The usb cable I was using before did say it was shielded. But it wouldn't fit in the conduit, so I'm using another cable, which is somewhat thicker than the first one.

I read someone using a slower baud rate (56000?), so I went looking around the net. I found the data sheet for the usb communication chip which then says to see FTDi spec an232 b-05. I found a document about setting baud rates. I'll set the firmware and repsnapper to 57692 and see how that works...

From AN232B-05_BaudRates.pdf :
divisor = 52, rate = 57,692
divisor = 26, rate = 115,384

My printer stopped twice today. Both times the machine was running from the SD card, but with the USB cable still plugged in. And the second time (not sure about the first, I can't remember) the machine stopped when I used my bench grinder.

So I am starting to believe it is noise getting in to the RAMPS board.

If I run from the SD card, with USB cable unplugged and don't use any power tools plugged into the same extension reel, then I don't get any issues.

---

[emaker.io]

[emaker.limited]

Hmmmm, yours is some of the best data I have seen yet. In my case of the 2 am stoppage, no one was at work and all the lights were off. I'm not beyond putting the ramps into a metal enclosure. If the failure happens again, I probably will do just that... I've got an o'scope somewhere, too. I can see how the 12VDC looks going in to the card as well as what's riding on my conduit. I guess the next step could be to run the individual stepper wires in shielding??

I am curious how the SD card talks to the Ramps. Is it via the UART? Is there a baud rate setting?

Here's my current setup: