Extruder running backwards even when E values are increasing in gcode about marlin HOT 6 CLOSED

Hello,

Thanks for testing/trying the advance feature.

It is a very preliminarily feature which needs some tuning / debugging etc.
I get almost no feedback so I am very happy with this feedback.

Can you give me your E-steps / mm ?

Then I can look at this effect and look for a solution/bug fix.

Best regards,

Erik van der Zalm

----- Original Message -----
From: "ttsalo" [email protected]
To: [email protected]
Sent: Friday, August 26, 2011 1:12:03 AM
Subject: [Marlin] Extruder running backwards even when E values are increasing in gcode (#4)

I have a gcode file which appears to cause the extruder to run backwards even when it should not.

Maze box gcode

The problem appears on layers 7-30 when the tight infill pattern is being printed between the walls. I checked that the E values are increasing, but the printer runs the extruder backwards hard when it tries to print the infill. When it goes back to printing the perimeter, the extruder runs perfectly normally forwards again.

I'm using Orca with Marlin 0.9.3 with the advance parameter at k=0.01. I can provide any other details if needed.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4

from marlin.

My E-steps per mm are 80.7, I have verified that this is correct to within
few percent on my setup when extruding manually.

The advance seems to work well in most cases, for example when printing a
perimeter with 90 degree corners at very fast speeds (150mm/s). Honeycomb
infill at various sizes and large 100% filled areas look good too.

I didn't try the same print without the advance on, though. I can do that
later today to see what happens. There was also another pretty similar
infill pattern at higher levels in the print which didn't cause the
backwards motion, but did seem to cause the extruder to run only very very
slowly. Running with the advance on should always extrude the exact same
amount as without it, only with different timing, right?

2011/8/26 ErikZalm <
[email protected]>

Hello,

Thanks for testing/trying the advance feature.

It is a very preliminarily feature which needs some tuning / debugging etc.
I get almost no feedback so I am very happy with this feedback.

Can you give me your E-steps / mm ?

Then I can look at this effect and look for a solution/bug fix.

Best regards,

Erik van der Zalm

----- Original Message -----
From: "ttsalo" [email protected]
To: [email protected]
Sent: Friday, August 26, 2011 1:12:03 AM
Subject: [Marlin] Extruder running backwards even when E values are
increasing in gcode (#4)

I have a gcode file which appears to cause the extruder to run backwards
even when it should not.

Maze box gcode

The problem appears on layers 7-30 when the tight infill pattern is being
printed between the walls. I checked that the E values are increasing, but
the printer runs the extruder backwards hard when it tries to print the
infill. When it goes back to printing the perimeter, the extruder runs
perfectly normally forwards again.

I'm using Orca with Marlin 0.9.3 with the advance parameter at k=0.01. I
can provide any other details if needed.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-1910344

from marlin.

Printing without advance works ok. And the extruder is working the same as for other FW versions.

The advance feature is implemented to limit the effects of acceleration on the extrusion diameter.
With advance (when working correctly, and calibrated) you should have a better print quality.
But is it beta at best.

For more info on the advance feature look at the link in the readme file.

Best regards,

Erik van der Zalm

----- Original Message -----
From: "ttsalo" [email protected]
To: [email protected]
Sent: Friday, August 26, 2011 11:19:28 AM
Subject: Re: [Marlin] Extruder running backwards even when E values are increasing in gcode (#4)

My E-steps per mm are 80.7, I have verified that this is correct to within
few percent on my setup when extruding manually.

The advance seems to work well in most cases, for example when printing a
perimeter with 90 degree corners at very fast speeds (150mm/s). Honeycomb
infill at various sizes and large 100% filled areas look good too.

I didn't try the same print without the advance on, though. I can do that
later today to see what happens. There was also another pretty similar
infill pattern at higher levels in the print which didn't cause the
backwards motion, but did seem to cause the extruder to run only very very
slowly. Running with the advance on should always extrude the exact same
amount as without it, only with different timing, right?

2011/8/26 ErikZalm <
[email protected]>

Hello,

Thanks for testing/trying the advance feature.

It is a very preliminarily feature which needs some tuning / debugging etc.
I get almost no feedback so I am very happy with this feedback.

Can you give me your E-steps / mm ?

Then I can look at this effect and look for a solution/bug fix.

Best regards,

Erik van der Zalm

----- Original Message -----
From: "ttsalo" [email protected]
To: [email protected]
Sent: Friday, August 26, 2011 1:12:03 AM
Subject: [Marlin] Extruder running backwards even when E values are
increasing in gcode (#4)

I have a gcode file which appears to cause the extruder to run backwards
even when it should not.

Maze box gcode

The problem appears on layers 7-30 when the tight infill pattern is being
printed between the walls. I checked that the E values are increasing, but
the printer runs the extruder backwards hard when it tries to print the
infill. When it goes back to printing the perimeter, the extruder runs
perfectly normally forwards again.

I'm using Orca with Marlin 0.9.3 with the advance parameter at k=0.01. I
can provide any other details if needed.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-1910344

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-1911115

from marlin.

I've been playing with extruder advance a bit, but it's hard to debug.
It should also help with preventing stringing, so perhaps I'll generate some gcode to measure this effect
BTW, I noticed there is some more recent info about this feature http://reprap.org/wiki/Mattroberts'_Firmware.

from marlin.

This feature works only if volumetric extrusion is used.

It is not tested by many ppl. It needs some fine tuning/fixing. Feedback and testing will improve this function.

On Sep 23, 2011, at 10:36 PM, lampmaker wrote:

I've been playing with extruder advance a bit, but it's hard to debug.
It should also help with preventing stringing, so perhaps I'll generate some gcode to measure this effect
BTW, I noticed there is some more recent info about this feature http://reprap.org/wiki/Mattroberts'_Firmware.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-2182551

from marlin.

I just updated to version 0.9.9 and it would seem that the issue is no
longer occurring.
I developed a test piece for this case:
http://www.thingiverse.com/thing:11895
http://www.thingiverse.com/thing:11895The raised circles are made of 240
segments each. With version 0.9.3, when printing this object at 50mm/s, it
comes out ok. When printing at 100mm/s, the three outermost raised circles
are printed correctly, the next one produces some output and the 6 innermost
circles all produce erratic extruder behaviour and no plastic output. So it
would seem that segments per second is the factor that triggers the bug.
However, with Marlin compiled from today's sources, with the advance feature
on, all the circles were printed correctly even at 100mm/s.

2011/9/23 ErikZalm <
[email protected]>

This feature works only if volumetric extrusion is used.

It is not tested by many ppl. It needs some fine tuning/fixing. Feedback
and testing will improve this function.

On Sep 23, 2011, at 10:36 PM, lampmaker wrote:

I've been playing with extruder advance a bit, but it's hard to debug.
It should also help with preventing stringing, so perhaps I'll generate
some gcode to measure this effect
BTW, I noticed there is some more recent info about this feature
http://reprap.org/wiki/Mattroberts'_Firmware.

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-2182551

Reply to this email directly or view it on GitHub:
https://github.com/ErikZalm/Marlin/issues/4#issuecomment-2182609

from marlin.