The first layer is put down fine, but before the second layer every time, the extruder winds itself backwards for at least 6 or 7 seconds until the filament is almost completely out! Then when the second layer starts obviously there is no filament to print with. I can't find the setting which deals with this in the host software of firmware? Has anyone had this problem and how do you reduce the back winding between each layer?

I thought it could be the Extruder0_Reverse but it is set to only 400ms.

Thanks.

Can't say I've ever seen this. It's probably more likely to be related to the GCode you've created.

Can you indicate which electronics and firmware version and which tool-chain you are using to convert the STL. Also, post the GCode you are having problems with, it might be useful to see what's going on.

JB

Using Gen 6 electronics with the latest firmware, just using reprap host software to convert the STL. To be honest it hadn't occurred to me that it might be the GCode causing the problem, perhaps I should use repsnapper next time (and is repsnapper better)? The GCode is below showing from layer 1 to layer 2 (minus the repetitive bit in the middle)

; GCode generated by RepRap Java Host Software
G21 ;metric is good!
G90 ;absolute positioning
M140 S55.0 ;set bed temperature and return
T0; select new extruder
M113; set extruder to use pot for PWM
G92 E0 ;zero the extruded length
G28; go home
G92 E0 ;zero the extruded length
G1 F5.0; feed for start of next move
G1 Z0.4125 F50.0 ;z move
G1 Z0.5875 ;z move
G1 Z1.0 F5.0 ;z move
G1 F1500.0; feed for start of next move
G1 X2.8 F3000.0 ;horizontal move
G1 X127.2 ;horizontal move
G1 X130.0 F1500.0 ;horizontal move
G28 Z0 ;set z 0
M109 S220.0 ;set temperature and wait
G1 F3000.0; feed for start of next move
G1 E500.0; extruder dwell
G1 F1500.0; feed for start of next move
G1 F8000.0; feed for start of next move
G1 E480.0; extruder retraction
G1 F1500.0; feed for start of next move
G92 E0 ;zero the extruded length
;#!LAYER: 1/66
M107 ;cooler off
G1 F5.0; feed for start of next move
G1 Z0.05 F30.4 ;z move
G1 Z0.2 F5.0 ;z move
T0; select new extruder
M113; set extruder to use pot for PWM
G1 F1500.0; feed for start of next move
G1 X65.9 Y47.1 F3000.0 ;horizontal move
..................etc
G1 X67.5 Y30.7 E2588.5 F1500.0 ;horizontal move
G1 F8000.0; feed for start of next move
G1 E2568.5; extruder retraction
G1 F1500.0; feed for start of next move
;#!LAYER: 2/66
M107 ;cooler off
G4 P20 ;delay
G1 F5.0; feed for start of next move
G1 Z0.35 F30.4 ;z move
G1 Z0.5 F5.0 ;z move
T0; select new extruder
M113; set extruder to use pot for PWM
G1 F1500.0; feed for start of next move
G1 X2.0 Y2.0 F3000.0 ;horizontal move
...............etc

I've never been able to use RepRap Host with my Gen6, perhaps there is a newer version that handles the echo's now. Anywho, the bit of interest appears to be at the end of the first layer, it requests an extruder retraction:

G1 E2568.5

the previous command using the extruder put it at:


G1 X67.5 Y30.7 E2588.5 F1500.0 ;horizontal move

So it looks like it is requesting the extruder to retract 20mm of extruded filament (to stop the ooze). Seems like a lot to me, it possibly still thinks it has a PWM d.c. motor driven extruder rather than a stepper extruder. 20mm would probably translate to a few mm's of filament at the top of your extruder. Probably somewhere in the RepRap host configuration is a setting for controlling how much it retracts.

I'd suggest switching to Skeinforge to generate GCode (you'll have to wrestle with learning all the in's and out's of this tool, but there are some good forum posts on it now) and RepSnapper for controlling the printer. You'll get much better prints in the long run.

Regards,

James

---

--
Check out my blog: AdventuresIn3-DPrinting

This problem is probably caused by a mismatch between the expected E values.

For various reasons, mostly firmware limitations with tracking the total number of steps that the E axis (the extruder stepper) takes over the course of a print, the E axis's virtual "position" has historically been periodically reset to zero. There where two approaches to doing that.

One approach was to use "relative movement mode" on just the E axis. This means the E axis's position is reset to zero every time, and the gcode has the amount to be extruded (distance to be moved) with this move, rather than the cummulative total to be extruded by the time this move is finished (distance from the start to move to).

The other approach is to reset the position of the E axis to zero after every layer. This works (IMHO) a bit better as the small segments are all going to be rounded off, and have a slightly inaccurate amount of plastic. Over the course of a layer it could theoretically result in less plastic.

G-code already has a mechanism to reset the axis's position, called "G92" In practice, this is followed by the axis to reset, and what position to reset it to. "G92 E0" would reset the position of the E axis without actually moving the extruder's mechanism.

It sounds like what's happening is that your g-code is (correctly) reseting the E axis position to zero after each layer, but the firmware is not. You may be able to get a bit more information by searching for G92 commands in your g-code file. If you find "G92 E0" at the start of every layer, then the g-code is correct and your firmware is for some reason ignoring that command. If you do not, your g-code was not correctly generated and there's a bug in whatever you're using to generate the g-code. So there's a bug somewhere, please find it let us know where it is (firmware or skienforge or repsnapper or reprap host or ?) so that we can get it fixed.

There are two ways to fix it.

First, you can fix the bug (probably it's a firmware bug)

Second, if you're using skienforge you can change some stuff in the "dimension" tab to fix it.

---

--
I'm building it with Baling Wire

I've discovered the problem!

Jgilmore is right about the GCode file not containing G92 commands, but strangely they are only missing for the first three layers. So the extruder basically goes all the way back to E0 after a layer but without it actually being reset! But then after layer 3, the G92 E0 lines exist for the rest of the print?

Why would it only be missing for the first 3 layers?? I've been using the reprap host to generate the code and can't find anywhere in the firmware that relates to the equivalent of G92.

Any clue how to correct this bug in the reprap host software?

Nope! I hate and despise Java, and refuse to have anything to do with the reprap host software as a result. The best I can suggest is send your config files & probably some java-specific machine information to the maintainers.

Since this g-code has G92 E0 on some layers and not on others, it's most definitely a bug in the g-code generation software, in this case the reprap host software.

There are two possible solutions:

First, you could switch to a different generation software. You could use either skienforge or repsnapper to generate the g-code and still use the host software to send it (if you like the host software for some reason)

Second, you could wait for the bug to be fixed - send in the report, communicate well, keep your current setup available for further testing when the bug is fixed, etc. You could argue that this is the responsible thing to do even if you solve the actual problem some other way - helping open source software get better by fixing bugs is generally a good thing. (see rant about java for a counter-argument)

Third, you could fiddle around with the existing reprap host software and see if you can convince it to do things right. This may be a good idea in conjunction with saving existing configurations to try to help narrow down the bug.

Fourth, you could go code diving and fix it yourself. I wouldn't, but that's mopstly because I'm prejudiced against java. It's also because slicing and generating g-code is a complex problem, so the code is complex and surely somewhat opaque.

---

--
I'm building it with Baling Wire

Are you using Skeinforge if so it's the retract settings under dimension see attachment

Edited 1 time(s). Last edit at 05/17/2011 01:55AM by NelsonRap.

---

__________________________________________________________________________
Experimenting in 3D in New Zealand