Welcome! Log In Create A New Profile

Advanced

Compensating for extruder lag

Posted by dc42 
Compensating for extruder lag
August 31, 2014 02:40PM
One of the artefacts I observe in prints is that there is excess filament deposited at the ends of top infill. This photo illustrates the problem, it has blobs just inside the perimeter:



I'm assuming that this is not a problem specific to my printer, but is a general problem. I'm also assuming that it is associated with the time it takes to reduce and then increase the extrusion rate so as to match the movement speed at the ends of a run, where the head decelerates, reverses direction, and accelerates.

My thoughts on correcting this in the firmware are:

1. Add a configurable delay to the steps sent to the XYZ stepper motors, so that the extruder is given a head start.

2. Adjust the extruder motor stepping rate so that it depends not only on the desired rate of extrusion, but also on the rate of change of the desired extrusion rate. When the desired rate is increasing, there would be a pressure burst to get the extrusion rate up to speed; and similarly when the desired rate is decreasing the pressure would be reduced to account for the fact that even if the extruder motor is stopped extrusion will continue for a little while. It would also be possible to add a term corresponding to the second derivative of the desired extrusion rate, and so on.

Where I would like some help is:

1. Is there anyone reading this who understands fluid dynamics, and can provide an equation describing the pressure vs. time profile needed to achieve a desired extrusion rate vs. time profile?

2. Is there anyone reading this who has a subscription that allows them to download this article free of charge: [manufacturingscience.asmedigitalcollection.asme.org]

3. Any other suggestions on how to correct for this issue?

Edited 1 time(s). Last edit at 08/31/2014 02:43PM by dc42.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Re: Compensating for extruder lag
August 31, 2014 03:17PM
Quote
dc42
2. Is there anyone reading this who has a subscription that allows them to download this article free of charge: [manufacturingscience.asmedigitalcollection.asme.org]..

Could be "Calendar" from this short thread has access to the article

Quote
Calendar
...Research article: "liquefier dynamics in fused deposition modeling" gives this model, the article is based on a bigger thesis with loots of information on what happens to the plastic in the extruder..
[forums.reprap.org]

Erik
Re: Compensating for extruder lag
August 31, 2014 03:18PM
My guess is that there is still an issue in the Move code, because some extruder moves are not performed too well. I added a work-around for an extruder issue a while ago, but it isn't perfect, it just conceals the actual bug. Especially during top infills, the selected extruder should accelerate and decelerate the same way the print head does, but I feel its feedrate is quite constant. If the extruder actually stopped before a reverse infill move is performed, I guess this would improve print quality and possibly remove the artifacts you described. I figure this would require quite a few changes in the move code to couple the print head velocity with the extruder feedrates, but unfortunately I won't have time to implement this during the next weeks. TBH, I'd really like to remove my work-around in DDA::AccelerationCalculation once again and to have a closer look at why the actual miscalculation occurs. How do you think about this?
Re: Compensating for extruder lag
August 31, 2014 03:46PM
Quote
ormerod168
Could be "Calendar" from this short thread has access to the article

Quote
Calendar
...Research article: "liquefier dynamics in fused deposition modeling" gives this model, the article is based on a bigger thesis with loots of information on what happens to the plastic in the extruder..
[forums.reprap.org]

I've already asked him, but no joy yet.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
August 31, 2014 03:51PM
Quote
zombiepantslol
My guess is that there is still an issue in the Move code, because some extruder moves are not performed too well. I added a work-around for an extruder issue a while ago, but it isn't perfect, it just conceals the actual bug. Especially during top infills, the selected extruder should accelerate and decelerate the same way the print head does, but I feel its feedrate is quite constant.

Hi zpl, have you any evidence for that? I've studied the Move code, and I believe all the motors (XYZ and extruders) always accelerate and decelerate in step with each other.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
August 31, 2014 04:52PM
Hi dc42, I did experience a problem with earlier 0.78 builds where I was missing filament during prints, I believe I even sent you a test file to reproduce this a while back. As a result, I implemented a temporary work-around in DDA::AccelerationCalculation, which seemed to resolve this bug. But now I think it's well possible this issue was somehow related to the faulty timeStep calculation in the original firmware, so it might be worth a try to remove the additional code from AccelerationCalculation again (both RRP's and my code) to see if it affects print quality in any way.
Re: Compensating for extruder lag
September 01, 2014 02:03AM
Hi DC, I'm still not convinced that the acceleration of the Feeder isn't just a fraction high, and / or at the end of a movement, the de-acceleration of the feeder isn't high enough to allow for the slight dribble from the nozzle at the end of a run. I'm going to guess that acceleration and de-acceleration rates are treated the same, which in a perfect world would be all well and good. If it was possible to add a de-acceleration rate for the feeder to the M201 line I think that would help (or have it as a seperate M??? setting so it got ignored by other firmware). The value for the de-acceleration would only have to be a fraction greater than the acceleration I think. Also I think the spring in the PTFE tube doesn't help things as it adds a tiny squirt of plastic at the end of a run.

Which reminds me, the backlash in the feeder gears can't be helping my machine, so I'd best print a new set later.

Kim


Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete
Re: Compensating for extruder lag
September 01, 2014 04:07AM
Quote
dc42
2. Is there anyone reading this who has a subscription that allows them to download this article free of charge: [manufacturingscience.asmedigitalcollection.asme.org]

Hi, I don't have access to that particular site but I do have access to quite a few journals on ieeexplore and sciencedirect, if perhaps you find something on those sites.
Re: Compensating for extruder lag
September 01, 2014 04:26AM
I've thought about this some more and I think the main issue may be the springiness of the filament in the Bowden tube rather than the fluid dynamics in the nozzle. I've worked out a mathematical model for the effect this has, and the adjustment needed to the extruder drive step rate to counteract it. One consequence is that the end of a deceleration, it may sometimes be necessary to reverse the direction of the steps, i.e. retract filament instead of feed it.

I hope to try this out in the firmware when I find time. It's not trivial because of the need to retract as well as extrude filament, but it's probably easier than my original plan (introducing a delay between extruder movement and XYZ movement).

What I would really like to know is whether direct drive (non-Bowden) extruders suffer from the same effects (e.g. excess filament deposited at the ends of top infill runs). If my hypothesis is correct, they shouldn't, or at least the effect should be greatly reduced.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
September 01, 2014 05:40AM
Quote
dc42
I've thought about this some more and I think the main issue may be the springiness of the filament in the Bowden tube rather than the fluid dynamics in the nozzle. I've worked out a mathematical model for the effect this has, and the adjustment needed to the extruder drive step rate to counteract it. One consequence is that the end of a deceleration, it may sometimes be necessary to reverse the direction of the steps, i.e. retract filament instead of feed it.

I hope to try this out in the firmware when I find time. It's not trivial because of the need to retract as well as extrude filament, but it's probably easier than my original plan (introducing a delay between extruder movement and XYZ movement).

What I would really like to know is whether direct drive (non-Bowden) extruders suffer from the same effects (e.g. excess filament deposited at the ends of top infill runs). If my hypothesis is correct, they shouldn't, or at least the effect should be greatly reduced.

I was about to post this myself - I've noticed the difference between my Prusa which is geared, but has a short straight vertical feed and the Bowden tube system on the Ormerod. I'm also fairly sure it's to do with the curved bowden tube - depending on the slack between the tube and the filament there would be a certain amount of over-feed in order to get enough pressure to push the filament against the top of the tube so that it feeds through the hot end - Then when you retract, you'd have to counter that until the filament is against the bottom of the tube before it will start actually retracting from the hot-end. This could explain why the retraction needs to be as much as 5mm so as to not have strings. The Prusa you can get away with a .8mm retraction!

I would say that you might be able to calculate a time-bias based on the normal retraction distance, or alternatively a constant based on the diameter of the tube as it relates to the filament diameter?

Edited 2 time(s). Last edit at 09/01/2014 05:52AM by VortyZA.
Re: Compensating for extruder lag
September 01, 2014 06:35AM
VortyZA, what you are describing is hysteresis in the Bowden filament feed. This is an effect I had not considered, and separate from the springiness issue that I have been looking at. My hope is that during normal extrusion where filament is being extruded continually but at varying rates, hysteresis can be ignored, because there is always a positive force on the filament and so the filament is always at the top of the tube. But hysteresis obviously does increase the amount of retraction needed at the end of a print or during a tool change, when releasing the force on the filament is not enough to prevent ooze and it is necessary to retract the filament from the nozzle.

Another contribution to hysteresis is when the tongue that locks the brass Bowden end into the extruder drive is not a tight fit, and the brass end moves up and down a little as filament is extruded and retracted.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
September 01, 2014 06:46AM
Hi dc
In the back of my mind I remember that either the Marlin firmware or a setting in Slic3r is called "firmware retraction".
Have you heard of this?
I am unsure what it is without further investigation but this might be someone elses attempts to counteract this effect in the Marlin firmware.
It might be worth quickly looking into. I can look tonight and get back to you, if you dont have time today.
Lloyd
Re: Compensating for extruder lag
September 01, 2014 07:35AM
Hi ezwul,

There is a setting in slic3r called "Use firmware retraction". I must confess that haven't looked at the Marlin firmware, but I doubt that the atmega processor it runs on has the power for the calculations needed to do firmware compensation for this issue.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
September 01, 2014 08:11AM
Quote
dc42
VortyZA, what you are describing is hysteresis in the Bowden filament feed. This is an effect I had not considered, and separate from the springiness issue that I have been looking at. My hope is that during normal extrusion where filament is being extruded continually but at varying rates, hysteresis can be ignored, because there is always a positive force on the filament and so the filament is always at the top of the tube. But hysteresis obviously does increase the amount of retraction needed at the end of a print or during a tool change, when releasing the force on the filament is not enough to prevent ooze and it is necessary to retract the filament from the nozzle.

Another contribution to hysteresis is when the tongue that locks the brass Bowden end into the extruder drive is not a tight fit, and the brass end moves up and down a little as filament is extruded and retracted.

I would imagine that you'd have this effect whenever the extrusion rates change, whether it's retraction or changes between infill and perimeter or when lifting the head for the start of the next layer. If you print a cylinder you find that there's a seam running up the outside where the spot that the hot end stops has a little more of a blob than where it starts again. The seam effect is still visible on a direct feed system, but it doesn't tend to have the same amount of bulge.
The springiness of the filament would try find the point where there's the least compression on it, which would probably be when it's at the bottom of the tube, so there would be a little bit of 'drooling' as the additional material is pushed slowly out of the nozzle.

That being said, I'm not sure if that's what is being shown in your picture - are you talking about the extra extrusion whenever the hot end changes direction? I haven't looked at the G-code, but does the extrusion change speed at those points? If so, then could it not be hysteresis causing some of that?

Some more questions that I wonder about:
If you were to have a single straight line, would it start thin, then end with a thicker bit? That would probably imply that it's something to do with the springiness in the tube/filament/hysteresis - building up pressure, then constant pressure, then releasing the pressure at the end.
If you made a V, then surely the point of the V would be slightly thicker as the filament is overlapping on the same spot? Compounding that, there would be a deceleration and acceleration at the point, while the extruder is unlikely to change speed, so there would be even more excess material.

Edited 1 time(s). Last edit at 09/01/2014 08:28AM by VortyZA.
Re: Compensating for extruder lag
September 01, 2014 08:48AM
Hi dc

The brief description on this Marlin Issue Page was:

"The slicer has to tell the firmware when to retract somehow. Autoretract is just detects the slicer's attempts to retract and replaces them with firmware retraction. Advantages include being able to modify retraction settings mid-print, or between reprints without reslicing, and it also handles some things better that slicer-based retraction (for instance, setting different retraction and recover speeds, which I've found makes a huge difference)."

I believe the modifications are made with the LCD control panel.
Re: Compensating for extruder lag
September 01, 2014 10:17AM
Quote
VortyZA
That being said, I'm not sure if that's what is being shown in your picture - are you talking about the extra extrusion whenever the hot end changes direction?

Yes.

Quote
VortyZA
I haven't looked at the G-code, but does the extrusion change speed at those points? If so, then could it not be hysteresis causing some of that?

The gcode doesn't include extrusion speeds, it includes extrusion amounts. It is up to the firmware to accelerate and decelerate the head at the end of the lines, and keep the extrusion rate in step with the head speed.

Quote
VortyZA
If you were to have a single straight line, would it start thin, then end with a thicker bit? That would probably imply that it's something to do with the springiness in the tube/filament/hysteresis - building up pressure, then constant pressure, then releasing the pressure at the end.

That is what I think. Here is another scenario that should be easy to test. Use gcode to command printing several fairly short lines one after the other, all in the same direction, alternately at a high speed and at a lower speed. I would expect the line to be too thin where the speed changes from slow to fast, and too thick where it changes from fast to slow. I shall try this! I will also allow me to measure how much compensation I need.

Quote
VortyZA
If you made a V, then surely the point of the V would be slightly thicker as the filament is overlapping on the same spot? Compounding that, there would be a deceleration and acceleration at the point, while the extruder is unlikely to change speed, so there would be even more excess material.

In theory I don't think there should be any overlapping, unless the filament takes a short cut when the direction changes.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
September 01, 2014 01:40PM
Quote
dc42
Quote
VortyZA
If you made a V, then surely the point of the V would be slightly thicker as the filament is overlapping on the same spot? Compounding that, there would be a deceleration and acceleration at the point, while the extruder is unlikely to change speed, so there would be even more excess material.

In theory I don't think there should be any overlapping, unless the filament takes a short cut when the direction changes.

I was playing with simple drawings and ignoring acceleration and deceleration it looked like a 90 degree L shaped turn would have about 5% extra material deposited at the corner - The overlap between the vertical and horizontal which would have to go somewhere - likely to be behind the nozzle or to the sides.



(Thanks for the Public folder hint)

Edited 2 time(s). Last edit at 09/01/2014 02:11PM by VortyZA.
Re: Compensating for extruder lag
September 01, 2014 01:56PM
I see what you mean. There will be a rounding of the outside corner, and the missing filament will end up on the inside corner. It will be worse when doing infill up to a square perimeter, because the infill normally meets the perimeter at 45 degrees. This means the head has to turn through 45 degrees, then move sideways by one extrusion width, then turn through 135 degrees (or the other way round). The 135 degree turn will result in even more excess extrusion into the inside corner than the 90 degree turn you illustrated.

I'll try doing some mixed high/low speed straight lines and some turns through various angles to try to identify the contributions of the various factors.

From this forum, you can link to dropbox pics in your public folder, but not in other dropbox folders.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Compensating for extruder lag
September 01, 2014 02:39PM
Possibly something along these lines - considering that each line overlaps the previous by a small amount..


But considering that they are not a simple 2D drawing but have a curve it's likely that only the overlap on the corners would result in extra material.

Edited 1 time(s). Last edit at 09/01/2014 02:41PM by VortyZA.
Re: Compensating for extruder lag
September 01, 2014 02:53PM
Maybe the easiest way to delay the XY moves is by doing it in the stepper driver code by means of a software "bucket brigade" (shift register) delay. e.g. instead of outputting to the motor hardware register(s) directly, flag whatever you were going to output to the start of a memory chain. A separate timer interrupt shifts the chain up by one at fixed intervals, and whenever a flagged stepper action reaches the end of the chain it is output to the hardware. The interrupt interval needs to be no greater than the shortest driver output interval. The delay will be the interrupt interval multiplied by the memory chain length. To save processing time you would use a (wrapping) pointer instead of physically moving data through lots of memory locations (current pointer is input location, pointer-1 is output location)

Dave
(#106)
Re: Compensating for extruder lag
September 02, 2014 04:29PM
Quote
KimBrown
Hi DC, I'm still not convinced that the acceleration of the Feeder isn't just a fraction high, and / or at the end of a movement, the de-acceleration of the feeder isn't high enough to allow for the slight dribble from the nozzle at the end of a run. I'm going to guess that acceleration and de-acceleration rates are treated the same, which in a perfect world would be all well and good. If it was possible to add a de-acceleration rate for the feeder to the M201 line I think that would help (or have it as a seperate M??? setting so it got ignored by other firmware). The value for the de-acceleration would only have to be a fraction greater than the acceleration I think. Also I think the spring in the PTFE tube doesn't help things as it adds a tiny squirt of plastic at the end of a run.

Which reminds me, the backlash in the feeder gears can't be helping my machine, so I'd best print a new set later.

Kim

Don't forget that in a corner (a change of direction) that there would naturaly be a de-acceleration (normaly), so if the de-acceleration was greater than the acceleration out of it, then you wouldn't end up with so much plastic at the corner......

I still think that a de-acceleration setting would help a great deal, and be a simple solution.... But adding it in to all the code is going to take some time.


Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete
Sorry, only registered users may post in this forum.

Click here to login