LOOOONG Pauses (Stops) in prints. (SOLVED)

Sometimes on my medium or large prints the machine just stops. Long, long pauses. So long it melts the lower layers. Sometimes I have to click on the repsnapper window and it re-starts. Other times I have to hit the kick button on the print page. I've tried using the unpause feature in Skeinforge 40 and it's still happening. I have recorded several videos of it on Ustream (http://www.ustream.tv/channel/pink-prusa-mendel-reprap-printing). What is the fix for this?

Edited 1 time(s). Last edit at 05/07/2011 06:37PM by MrJohn.

what electronics are you using?

Gen6 with firmware from mendel-parts. Repsnapper by Kulitorum and a Windows 7 machine. Slicing with SF40.

Is your ooze bane unchecked in skein forge? In repsnapper are you using a queue buffer of 1 or 4? And what baud rate are you using? Thx.

the video actually looks quite good excluding your issues.

Oozebane is off, I haven't messed with repsnappers settings since I've started using SF40. Baud rate is 19200. I've tried 115200 as suggested in the IRC wouldn't connect to the printer. Played with it some more to negative results. So I just went back to the default.

MrJohn

What are the last few gcode commands in the debug window when it pauses?

I have this problem with Techzone Gen 3 Remix. I've tried different Five-D firmware-host (reprap and repsnapper) combination and they all have the issue. The latest version of reprap host/sw from Dec 2010 seems to still take long pauses and then continue on it's own after what seems like half a minute or more. I've seen it do it at random places in a print and I've also seen it pause at the same point. The others would just get stuck forever although repsnapper would continue if I "kick" it or if I issue an M105 command. I can't figure it out so I'm switching to RAMPS when I have some time in a couple of weeks for this reason in addition to speed.

I didn't think that the newer electronics suffered from the same issues.

I've seen this a couple of times with my Gen6. I have one piece where it happens consistently in the same spot (even after re-slicing with different settings). After about a minute it begins printing again. There was nothing interesting about the GCode at that point it stopped, it was a series of G1 moves.I thought the firmware had crashed as it wouldn't respond to unbuffered GCodes during this time, but then it started again. Kicking it from repsnapper didn't help.

One thought was the extruder temperature had dropped so low that it was pausing to allow it to heat back-up, but I can't see why it would take so long.

Not sure what caused it.

JB

PrusaJr helped me from the IRC. He suggested turning retract speed down from 27 to 15 and retract distance from 3 to 1mm. Set extra restart distance from -0.5 to 0.0. It didn't completely stop the pausing, still had several but the print looked much better. I'm considering swtiching my firmware to Sprinter if I can figure out how to install it correctly.

This is the gcode I get when it stops.

Send >>Received: Serial Error:Recieved a LineNr code without a Checksum code or Checksum without LineNr
Send >>Received: Resend:1356 with parameter 1356

Interesting. I get similar error messages so it seems that your Gen 6 and my Gen 3 are having the same problem. Are you using the reprap firmware?

No, I'm using the mendel-parts.com firmware.

I think I've fixed it. I tried all these with test prints of a rod clamp in between.

I removed my USB cable from my cable bundle to see if it was interference from them. No.

Swapped out cables. No.

Lowered the buffer size from the Repsnapper settings. No.

Increased the buffer size. No.

Changed the firmware to increase the "Speed" or baud rate to 115200 and connected Repsnapper at the same rate. No. (Just locked it up.)

Reverted the firmware back.

Slowed down the print to 30/30mm per sec. Unchecked a lot of the plugins I was using. NO.

Uploaded the new Sprinter firmware, entered my know steps per mm for all the settings. Selected my board (Gen6) and NO. In fact this screwed everything up. Z would only go up when up or down was commanded. X and Y barely moved if at all.

Quickly reverted BACK to my OG software.

Looked at the USB port properties on my Win7 Computer. Updated the drivers, increased the USB port baud to 19200, to match Repsnapper and my firmware. Restarted my computer. NO.

Reverted my USB baud back to its' OG 9600 baud rate and lowered my firmware and Repsnapper baud's to match my PC's USB baud. Uploaded that firmware change. And.....








Yes.

So far I've printed two Non-footed vertex pieces without one stop.

Now that I've said that, it's bound to happen as soon as I press "post message" on this. Let you all know in the morning what happens.

I was having pauses and dropped commands in my prints as well. It turned out to be a loose wire in the cable to one of my opto-endstops. Have you looked at this?

with 19200baud or lower , you may want to reduce repsnappers queue buffer. the reason is because it is so much slower than 115200, that all of your bandwidth is used recieving data. the arduino has very little time left to send data, and process without the input buffer filling up completely. this would be different if the arduino was running in a duplex mode where it sent and recieved data at the same time.

what you want to have is some of the time available for the processor to catch up, and send data without the input buffer overfilling.
thx


james

If you have acceleration turned on in software on RepSnapper, you will get what seems like a slowdown in small rounded corners, due to the large number of straight line segments (short ones) in the arcs. Try with acceleration turned off.

I believed this problem has been fixed by lowering my firmware and repsnapper's baud speed to 9600. Since then I have seen zero pauses. In the gcode I still see the error of serial error but the print keeps moving, so I'm happy.

I have an Orcabot 0.42 by Mendelparts and getting the same loooong pauses.
Changed baud rate to 9600 from the recommended 250000 and it worked on one print I was having a problem with.
I thought I was onto a winner but I threw the bot an even bigger challenge and it started pausing again.
Does anyone have a full proof solution to this?
SD card only?
Faster computer?
Any suggestions would be gratefully rewarded.

---

3D Printing never sleeps
MAGICMODEL

An SDcard has been a foolproof solution for me. Printing directly from host is more prone to issues if you're using the host at the same time or if it's a laptop and it goes to sleep mode.

I used to print from a laptop with 512mb ram. Pronterface uses ginormous quantities of ram, about 10x the gcode file size, so printing 20MB files slowed the computer to a crawl. I changed to 1GB and it was all fine

Thanks for the advice guys.

Just found this:

"I think until there is larger buffering on the arduino platform for communications, there will be issued with pausing. This is one reason 5d code is good for arduino, E only moves at a rate to the x and y axis. x and y pause, e will wait.

The way communications has handled the delay issues is with error correction and to add data into the signal that allows data to be rebuilt from errors and corrected without redelivery. there are limitations with sending data and waiting for a response from host.

The main reason pauses occur is because data is received, then if it is good it is acknowledged to host, then host sends the next data, clearing out its send buffer each time.


one way to fix this a little bit is to reduce latency time down to 4ms, from the default (16ms on my machine) in windows. go into systems settings, and open up usb comm port driver for FTDI chipset.
Right click on it, and select Properties from the pop up menu. Next, click the Port Settings tab, and click the Advanced... button. and change latency from its default down to 4ms or even less if your computer is fast enough. this will reduce time it takes for signaling back and forth between comm port and pc. it should reduce pauses.

there are tools for reducing usb comm latency as well.

Ideally we would want to have communication fix errors without resending of data, but since we error check and verify data it would be nice to reduce that delay significantly."

I am going to try it, but I think it's time for a morepowerful laptop.
Also looking into ditching the gen6 deluxe board for a Printrboard Electronics REV D with SD support.

---

3D Printing never sleeps
MAGICMODEL

brnrd Wrote:
-------------------------------------------------------
> An SDcard has been a foolproof solution for me.
> Printing directly from host is more prone to
> issues if you're using the host at the same time
> or if it's a laptop and it goes to sleep mode.

What electronics are you using to get the SD card support?
Would it be able to replace gen6 board from Mendelparts?

I had the same problem and it seems to be fixed!
I have RAMPS 1.4, with arduino mega 2560 R3 and I use Repetier host.
In complex parts my printer had loooong pauses and after a while it stopped!

HOW I FIXED IT :

Open "Repetier host" --> Config. --> Printer settings --> Enable the option "Use Ping-Pong Communication (Send only after ok)"

That's it!

It worked to me, I hope to you as well!

what does the ping pong setting do? i would think that would slow the heck out of it.