Extruder starts too early leaves blobs

Hi,
I recently got a Mendel and got it running the other day. I've been adjusting the settings to get my print cleaner, but can't seem to change the delay of when the etruder starts extruding before the extruder starts moving. I am getting these blobs of plastic around the piece that look like warts on the outside of the finished piece because of this.
It prints the shell, then starts on the infill of a layer. When the infill first starts it's layer, it starts in the middle and doesn't affect the shell. It then finishes that polygon and continues the infill for the layer, but before it starts moving again, the head starts extruding in one spot (usually at the edge) for a fraction of a second, causing a blob to form and bleed out over the shell. This happens multiple times per layer, causing an appearance of bumpy warts all over the piece. I have adjusted the preferences with little to no change. I see that there is a ExtruderDelayForLayers and ExtruderDelayForPolygons, but when I try a value of say 600, it lays down even more of a blob. It seems like this is a delay in the opposite direction, ie. delays the movement not the extrusion. A negative value of -600 does nothing. A value of 0 or -1 still leaves blobs.
Thanks in advance.

Running Windows 7 Home 64bit with the 64 bit version of reprap 0719 and 64bit version of Java 6 update 22.
Using the Wade Extruder, pololu board, and external thermocouple controller.

Edited 1 time(s). Last edit at 11/05/2010 01:17AM by arasb.

Some pics of the globs.
On Venus, one side looks ok, but the other has these blobs where it starts the infill at the shell and sits there and extrudes before moving.
The Hand has more of these because I increased the amount of infill compared to venus.

It seems that changes in the preferences are not affecting the persistence of the blobs.

I can PM the links to the gcodes if it helps.

Thanks for looking,
Aras

I had similar problems with the RepRap Host generated gcode and gave up and switched to Skeinforge.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

It looks like too much material being extruded? - Have you adjusted your E_Steps_per_MM in the Firmware? - if so what value did you use?

And maybe you are not reversing the stepper motor enough - in the hand picture you should not be getting all that string everywhere when using a WADE stepper.

RRHost seems a little odd on the start delay and it changes when you switch shield on or off (for some reason). I needed to reduce my Delayfor layers and delayfor poly by 100ms each to stop blobs after switching off Shield. My delays are set to to 170ms and 50ms and I reverse 400ms but I am printing ABS.

And that looks like PLA? so how hot do you have it set?

---

[richrap.blogspot.com]

Hi Richrap,

Thanks for your reply. I am using PLA. I was able to get slightly better prints with less noticable blobs. This was achived by changing the E_STEPS_PER_MM in the firmware from 40 to 32. Since I have a 1/16 stepping Pololu stepper controller, this is a much higher number than the standard 1/2 stepping controllers. This helped by putting down a little less PLA in general.

I also ran a bunch of tests while only changing the Delay on Layers and Polygons, then looking at the results in the gcode. I found that the least amount of PLA was extruded when the nunmber was closest to zero, and that negative numbers extruded the same as positive numbers. For example, when I input -300, I got the same amount of plastic as 300, but the code was slightly different. I noticed that having it set to zero put out a similar amount of extrusion as 0.00000001, but when set to zero, the code looked different.
When I say the code looked different for negative numbers and zero, I mean that the placement of the commands on the line were not identical, though the amount of extrusion was similar. and the print looked more messy.
So I now have my Delays set at 1ms each.

So, even though it looks better, I still have the extruder dewlling at the beginning of infill segments (polygons) dumping a blob, usually at the edge. which pushes out the outer layer causing a distortion. I think there is something wrong with the 'middle start' feature of the infill because on any given infill layer, it will start in the middle on the first segment, then the next section, it will go to an edge and start there instead of starting each segment in the middle on the same layer. This adds to my problem, but would not fix it, since, if printing something small, it will stop and start a new segment within the same layer, dumping a lot of unneeded plastic in a small space.

Sometimes, in small areas, it will have multiple segments that are only 1mm long, but will dwell before starting each segment, leaving a huge mess, just dumping extrudient over and over.

Sometimes, it will over shoot during a run of infill and go past the outer layer printing in thin air about 3 mm away from the outer layer.

Strange.

Thanks again for looking,
Aras

I'm having the same problem, where each time the extruder starts for infill it extrudes too much before starting motion.

I think the problem may be in the reversing algorithm that Reprap Host uses. There are three tunables involved, Reverse, DelayForLayer, and DelayForPolygon. Even with all but Reverse zeroed, I still get too much ABS laid down. The algorithm Reprap Host uses is to run the extruder in reverse at the end of a polygon, move, then "make up" by running the extruder forward at fast speed for Reverse time. The assumption seems to be that moving the extruder back X time then forward X time will result in no extrusion.

I'm not sure that assumption is valid. Since before the reverse we are extruding ABS at a certain rate, at the end of that reverse we will be extruding ABS at an equal rate. However, since it takes the ABS some time to accelerate, the extruder will leave some ABS in place before the extrusion reaches speed.

A better algorithm might be this: reverse the extruder by Reverse time, then move the extruder forward by Reverse/2 time. If this is not enough to get a clean line, it can be increased with DelayForPolygon. The problem with the current algorithm is that if Reverse is too much, there's no way to reduce it. Another option would be to allow negative values for DelayForPolygon.

I will experiment with the above and report back.