Printer pauses a lot

Hi everyone,
I just finished my printer, and I have worked out a majority of the major issues, but I just have one issue remaining. The printer stops randomly every 5 minutes or so (sometimes shorter, sometimes longer. It really just seems random). I know there is a similar post already, but I feel this is probably a different issue because I can continue the print by clicking Pause then Continue in RepSnapper. Can anyone advise on what might be causing this issue?

My printer specs:
Prusa Mendel
MakerGear hotend w/Wades extruder
RAMPS (Arduino Mega 1280)
PCB Heated Bed
12 volt/20 AMP power supply
Sprinter firmware
RepSnapper

Found a terribly hacky "solution" to the problem. Every time I start a print, I set up xAutoClick (Linux, I know there are similar programs for other platforms) to click on "Kick" once a second.
From what I gather, the pauses are due to the firmware not understanding a gcode it receives. Whether it is repsnapper's fault for generating non-standard gcodes or sprinter's fault for not understanding them is not really my concern. This does have a far better solution though: repsnapper should detect the pauses and auto-kick the printer

I use skeinforge 41 to generate g-codes and I'm able to send it with repsnapper (MacOS 10.5.8) without pauses. I printed a 5.5 hr part succesfully with it before I started using Kliment Printrun. From reading this forum, I don't think a lot of people actually use repsnapper to generate g-code.

BTW, it also helps to tell people what OS you're running.

Interesting, I sent gcodes generated by skeinforge 33 with repsnapper and I still experienced the pauses. I'll try 41 and/or pronterface and see if that helps. That's funny about generating g-code with repsnapper, because I got some really decent prints with it.
Sorry I forgot to mention that I was using Linux, I knew I would forget one of the variables, there are so many. I will report back with my skeinforge/pronterface experience.

Do you have an alterations file (replace.csv) to remove invalid g-codes in Skeinforge?

No, I didn't know about that. It looks like I have export enabled, but set to "Do Not Change Output". Which option do I need to select to make it use replace.csv and does it come with a replace.csv with good default content?

I've attached my replace.csv file. Just put it into the Skeinforge folder under the subfolder skeinforge_application/alterations. You'll see some example files in the same folder. I think Skeinforge is set to use the alterations file by default.

Thanks brnrd. I will give that a try today or tomorrow, when I have my RepRap put back together.

Disclaimer: my inexperience with skeinforge may invalidate these results

I tried to print with Printrun but it still paused.
The print started out by running the extruder in reverse for quite a while (?), then eventually it started (and I had to push the filament back in) but it was extruding way too fast (3-5 times too fast). I thought I got the e_steps_per_mm right: 3200 * (30/10) / (6.7 * 3.14) = 456
Anyway, these problems are neither here nor there. The problem of this topic is that the print paused. It seems different though, because I could hit Pause/UnPause and the print did not continue. I should have tried jogging the axes or something to see if the printer was responding, but I didn't think of it. I'll try it next time.
I did confirm that the replace.csv is working by looking at the gcode and seeing that the specified commands are commented out so thanks, that's a great tip.
I'll have to try it in RepSnapper to see if it still pauses as well. Is there an easy way to determine what gcode the printer stops on when it pauses?

Btw, if solutions to the other problems I encountered seem obvious to you I would certainly appreciate any advice.

It seems like you calculated E steps per mm in terms of feed. SF 33 uses the value in terms of extuded plastic. So you have to divide it by the (feed diam/extruded diam)^2 which is around 36 for 3 mm feed.

As far as reversing in the beginning of the print, you might have a problem with your start.gcode file.

Did you get any messages in the console when running printrun? When you run in repsnapper, take a look in the log for errors.

Sorry, forgot to mention that I upgraded to SF 41 for these tests (and removed my ~/.skeinforge folder so I could start from scratch). Did I get the formula right for SF 41? I'll take a look at those other things when I get home.

Took a look and I don't have a start.gcode. My settings are almost completely default. Why on earth does it reverse at the beginning by default?

My hotend blew out when I was stuffing the filament back in, so I've got probably another couple days before printing again while I rebuild. Actually, testing this while my hotend is not there sounds like a great idea to me...

Found this in the reprap wiki, hopefully it fixes my problem:

Quote
RepRap Wiki
Extruder running backwards at start of print
Technically this is not a problem with Skeinforge, but you can make a simple change in Skeinforge to work around it. The issue is caused by manual extrusion (through RepRapHost, RepSnapper) prior to a print changing the E value calculated by your firmware.
To fix, in your start.gcode file add the command 'G92 E0' which resets the E count to 0.

I always run the extruder manually before a print, so that would seem to explain it.

While your hot end is out of commission, this would be a good time to measure the actual extruded filament so that you can adjust the filament packing density ratio parameter in SF. This would give you a good starting point and should get you very close to getting that perfect print once your hot end is fixed.

I had been avoiding calculations and measurements because Repsnapper was giving me pretty great prints without the need for that. However, when trying to print tall skinny tower-like objects it just breaks down. I'm hoping the cooling module can help by slowing it down on the tower parts.
Anyway, long story short, I haven't done any measurements yet. By "measure the actual extruded filament", do you mean putting a mark on the filament, telling the extruder to run 50mm, and then measure how far it actual did go? And what is the "filament packing density ratio" parameter? Can you recommend a tutorial for this?

There's a long discussion in the skeinforge forum on the adjusting extruder parameters in Skeinforge 40 and later: [forums.reprap.org].

Do you mean that Repsnapper is generating the g-codes or are you generating g-codes with Skeinforge 41 and then sending it to the printer using Repsnapper? In my experience, repsnapper doesn't generate good g-code files.

The Filament Packing Density ratio is a correction to account for the actual extruded length. It primarily accounts for how far the filament drive teeth sinks into the feed which changes the effective circumference of the drive. Start with it set to 1 and do as you wrote. Then divide the actual extruded length by the amount you told it to do to get the parameter.

I have been using Repsnapper for printing and generating g-codes. Perhaps it's because I'm not spoiled by the great g-codes that skeinforge generates, but I think my prints have turned out pretty well.
They aren't perfect, the main problem is they are a little globby around the edges.
Another problem is if you don't have full infill, your top and bottom layers will be printed the same as all the other layers (ie, with space in between the strands)
And it just fails big time on tower-like structures, which is the only reason I'm moving to skeinforge. I've printed usable z-motor couplings and would've printed usable bushings and x-end idlers if it hadn't skipped steps in the middle of the print. Maybe I need to post some pictures...

I have my hotend working again and I've figured out how to use skeinforge to generate gcode. Unfortunately, the printer is still pausing all the time, with both pronterface and repsnapper (always using gcode from skeinforge). The difference is that when pronterface pauses, it seems to lose it's connection to the printer or something and it seems that it's impossible to continue the print at that point. I didn't see any output to the terminal from pronterface, so here are some example logs from Repsnapper when it pauses (these snippets are the last few lines in the log when a pause occurs):

10:40:40 Send >>SendData: N4259 G1 F798.0 *92
10:40:40 Send >>SendData: N4260 G1 E0.663 *80
10:40:40 Send >>SendData: N4261 G1 F3000.0 *98
10:40:40 Send >>SendData: N4262 G92 E0 *117
10:40:40 Send >>SendData: N4263 G1 X71.03 Y83.63 Z1.88 F3000.0 E0.0028 *126
10:40:40 Send >>SendData: N4264 G1 X70.79 Y83.37 Z1.88 F3000.0 E0.0096 *113
10:40:40 Send >>SendData: N4265 G1 X70.69 Y83.47 Z1.88 F3000.0 E0.0124 *126
10:40:40 Send >>SendData: N4266 G1 X70.49 Y83.18 Z1.88 F3000.0 E0.0193 *121
10:40:40 Send >>SendData: N4267 G1 X70.59 Y83.07 Z1.88 F3000.0 E0.0222 *126
10:40:40 Send >>SendData: N4268 G1 X70.31 Y82.87

(I also saw this in the error logs at this point, although the time is off so I'm not sure if it's related)
10:44:46 Send >>Received:Error:checksum mismatch, Last Line:6
10:44:46 Send >>Received:Resend:7 with parameter 7

-----------------------

10:47:39 Send >>SendData: N5393 G1 X69.27 Y91.83 Z2.38 F3000.0 E0.0071 *119
10:47:39 Send >>SendData: N5394 G1 X69.98 Y92.1 Z2.38 F3000.0 E0.0219 *65
10:47:39 Send >>SendData: N5395 G1 X73.66 Y88.42 Z2.38 F3000.0 E0.1226 *123
10:47:39 Send >>SendData: N5396 G1 X69.94 Y88.19 Z2.38 F3000.0 E0.1949 *114
10:47:39 Send >>SendData: N5397 G1 X68.58 Y91.52 Z2.38 F3000.0 E0.2646 *118
10:47:39 Send >>SendData: N5398 G1 X66.7 Y90.92 Z2.38 F3000.0 E0.3027 *64
10:47:39 Send >>SendData: N5399 G1 X69.25 Y88.38 Z2.38 F3000.0 E0.3724 *115
10:47:39 Send >>SendData: N5400 G1 X68.54 Y88.6 Z2.38 F3000.0 E0.3868 *73
10:47:39 Send >>SendData: N5401 G1 X66.35 Y90.78 Z2.38 F3000.0 E0.4466 *116
10:47:39 Send >>SendData: N5402 G1

-------------------------

10:49:19 Send >>SendData: N7239 G1 X89.36 Y91.44 Z3.13 F3000.0 E0.3728 *113
10:49:19 Send >>SendData: N7240 G1 X87.03 Y89.12 Z3.13 F3000.0 E0.4365 *119
10:49:19 Send >>SendData: N7241 G1 X86.54 Y89.12 Z3.13 F3000.0 E0.446 *71
10:49:19 Send >>SendData: N7242 G1 X89.01 Y91.59 Z3.13 F3000.0 E0.5137 *123
10:49:19 Send >>SendData: N7243 G1 X87.98 Y92.04 Z3.13 F3000.0 E0.5355 *121
10:49:19 Send >>SendData: N7244 G1 X86.05 Y89.12 Z3.13 F3000.0 E0.6032 *119
10:49:19 Send >>SendData: N7245 G1 X83.6 Y89.15 Z3.13 F3000.0 E0.6507 *68
10:49:19 Send >>SendData: N7246 G1 X87.63 Y92.19 Z3.13 F3000.0 E0.7486 *127
10:49:19 Send >>SendData: N7247 G1 X84.87 Y93.39 Z3.13 F3000.0 E0.8068 *127
10:49:19 Send >>SendData: N7248 G1 X83.15 Y89.19

----------------------

10:51:59 Send >>SendData: N1770 G1 X81.17 Y65.45 Z0.88 F3000.0 E1.1725 *113
10:51:59 Send >>SendData: N1771 G1 X78.83 Y65.45 Z0.88 F3000.0 E1.2177 *121
10:51:59 Send >>SendData: N1772 G1 X76.55 Y65.94 Z0.88 F3000.0 E1.2629 *127
10:51:59 Send >>SendData: N1773 G1 X74.42 Y66.89 Z0.88 F3000.0 E1.3081 *112
10:51:59 Send >>SendData: N1774 G1 X72.77 Y68.08 Z0.88 F3000.0 E1.3475 *127
10:51:59 Send >>SendData: N1775 G1 F798.0 *82
10:51:59 Send >>SendData: N1776 G1 E1.3475 *96
10:51:59 Send >>SendData: N1777 G1 F3000.0 *101
10:51:59 Send >>SendData: N1778 G1 X72.15 Y67.62 Z0.88 F3000.0 *11
10:51:59 Send >>SendData: N1779 G1 F798.0 *94
10:51:59 Send >>SendData: N1780

It looks pretty normal to me, what do you think?

Did you get this fixed?

I had the same problem with random pauses due to a 'checksum mismatch'.

The solution for me was to change the transfer rate in the firmware to 57200 baud (and of course setup Repsnapper to the same value before connecting; you can change it in the settings file).

I use Gen 3 electronics.

-Eriksen

Hi guys,

I had a similar problem on with my gen 3 electronics, in which the print would have random pauses and blob plastics deposited in the print. I narrowed it down to a communications problem as I could see temperature readings drop out once in a while.At the time, I was running everything off of my laptop (the mb was powered via USB from the laptop), which wasn't the highest quality. So I decided to switch it over to my desktop and it solved it 100%.

From what I figured from some of my classes (I'm a recent Electrical Engineer graduate) and talking with my boss, it sounds like my laptop has some noise ground being introduced in the ground, which can severely mess with communications. I might bring it into work some time and check it on our O-scope to confirm it. But if you are having this problem try running your machine from a different power supply or computer (desktops will probably be more likely to have cleaner power) if you are having this problem, worked wonders for me.

I've tried different baud rates and nothing has worked for me. The best solution I have found so far is to hack Printrun to detect a pause and kick the printer back to action. You can find it here:
[github.com]

It works pretty well for me, there is a slight pause (a few seconds) every once in a while, but at least the print will continue automatically.
I was warned by Kliment that this would not work well with long running commands like M109 so let that be a warning to you if you decide to try it.
I sure wish there was a better solution, but that's it for me right now.

Honestly, I got rid of my pausing problem by using Replicatorg to send gcode. Happened all the time with Pronterface, never happens with Replicatorg.

Hi Unicoder,

I think I'm having a similar problem as you. I too recently finished my printer and worked out all the bugs except for this frustrating problem of it freezing/pausing often. It appears to be random which I think rules out a problem with the gcode, as opposed to it happening at a certain line every time. I also have intermittent trouble uploading firmware in the arduino software. About half the time I get an error that says "programmer out of sync", but cycling power fixes it and it uploads ok the next time, this may or may not be related.

My Setup:
Prusa Mendel
MakerGear hotend w/Wades Extruder
Sanguinololu 1.3a
12V ATX 400W power supply
Ubuntu 10.04 on an Asus EeePC

I get this error in the pronterface console when a print freezes, which may be different than you:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/tim/Dropbox/aa_Prusa/kliment-Printrun-2a1ef25/printcore.py", line 79, in _listen
    line=self.printer.readline()
  File "/usr/lib/python2.6/dist-packages/serial/serialutil.py", line 60, in readline
    c = self.read(1)
  File "/usr/lib/python2.6/dist-packages/serial/serialposix.py", line 320, in read
    buf = os.read(self.fd, size-len(read))
OSError: [Errno 11] Resource temporarily unavailable

Repsnapper doesn't echo any errors except for sometimes returning a strange command like "**ook"

Things I've tried without success:
1. Marlin and Sprinter firmware
2. Repsnapper and Pronterface to send gcode (like you mentioned, repsnapper will recover and continue to print with the kick button, pronterface freezes, won't send any signals to the printer, and won't recover)
3. Skeinforge44 and SFACT
4. 2 different USB cables
5. Slowing the baud rate to 57600, 19200, or 9600
6. Slowing print speeds down to 20mm/s
7. No printer monitoring in the host software
8. different .stl calibration models (mostly the 20mm cube)

The one way I have seemed to slow the amount of pausing is by changing from Rectangular Fill in skeinforge to Line Fill. I think that just may be related to the number of commands sent though as line fill is a fraction of the number sent as opposed to rectangular fill.

I'd like to try printing from SD, but don't have that capability yet.

Brick_Man's possible solution of printing from a desktop instead of a laptop is interesting as I've only used my netbook to print.
I haven't been able to get Replicatorg to work correctly for me to try Pointedstick's solution.

My next step is to try printing from windows and see if that solves it.

Thanks for any other ideas people can offer as I've scoured other posts trying to find solutions. I am unfamiliar with how to use debugging in the firmware, would that help?

-Tim

I have had similar problems to you (the error you posted). But I am not getting to the point where the print will simply stall at random points, with no error at all. Just crashes pronterface with it.

My set up:

SL 1.3a electronics
Marlin v1 beta FW
Ubuntu 10.10 via VM
Pronterface with SF

I have tried printing this via the windows distribution and it has worked perfectly. It seems something in Ubuntu's set up is causing Marlin to crash... or at least that is what it has been narrowed down to.

Going to keep looking for a fix in ubuntu. If you find another fix round this let me know!

Cheers,

Iain

After trying the windows xp distribution of pronterface, I can report the same experience as you. I have not seen the error posted above since switching. It would appear that it's an Ubuntu specific problem, but whether it's the OS, or pronterface, or something else I can't say. But since Repsnapper in ubuntu seems to freeze just as much, it's peculiar.

Have you tried other control software lain?

Also, it appears there has been some recent work to eliminate trouble with sanguinololu and marlin interactions.
http://techpaladin.com/2011/11/21/getting-all-the-pieces-to-fit-together/

The above links to this issue thread as well: https://github.com/ErikZalm/Marlin-non-gen6/issues/7

I'll try the latest beta of marlin next.

-Tim

It´s probably the firmware thing. i had a problem like that and i downloaded an "fan" firmware taht fixed it.or you can edit some things on your own

---

If you need an awesome resume try free resume builder[]

Hi there, I haven't tried different control software (yet) I am going to try to get everything (Python et al) working again on Win7 along with Slic3r and try using the latest Printrun and see if it works as it should.

Failing this... I am going to try RepG in my Ubuntu VM (I have never used or set up RepG so this might be a while before it's working).

I can't understand what the issue is, sometimes I get the OSerror spam in terminal, most times the print stops and nothing out of the ordinary shows up in the pronterface terminal window. Just a pure crash.

I'll let you know if anything fixes this, as I was hoping to get a netbook with linux on it to run my printers, but if Marlin refuses to work with Ubuntu etc, then I need to find another solution!