Skip to main content

Extruder Velocity Advance

Extruder velocity advance  (EVA) has been implemented in all major 3D print fimwares (everyone has their own name for it).  It is intended to increase extrude width accuracy and reduce extruder ooze after extrusion ends.  Here's my overly simplified explaination of what it does, how it is useful and its challenges.

For this explaination, I'm going to use an example extruding move of 0.5 seconds that starts and ends at zero velocity, and then continues on without extruding.



You can see above the velocity and position porfiles.  Tthe velocity ramps to 60mm/s and back down before continuing on.  The length of the extrude move is about 22.8mm.  In an ideal situation, the extrusion volume would be proportional to the distance traveled.  For each mm the head moves, we want a precise amount of plastic to to be deposited on the part.



Using a simple fluid flow model, the above graph shows the ideal volumetric extrusion compared to the simulated "real" output.  The gap between the two lines is the extrusion rate error.  The larger the gap the worse the error.  Ideally they would be coincident.  The goal of EVA is to "over extrude" in such a way as to get the real output and the ideal output to match as closely as possible.  A graph of the error looks like this:


If one squints at the graph above, it looks a little like the velocity profile from the first graph.  This would suggest that the error in extrusion rate may be related to the velocity of the motion ( There are theories of fluid flow with big names that explain/model this behavior).  It should also be noted that the tail of the error that extends beyond the end of the extrude move (0.5s) is what would likely ooze out during the following non-extruding move.  Idealy this tail would not exist.

If we advance the filament by the volume of the error while moving, and remove the advance as we come to a stop, we should be able to counter this error.



Combining the ideal extrude volume (red dotted line) with this extrude compensation (yellow line) above gives us the blue line above.  Note that although it attempts to overextrude, it still starts and ends at the same volume as is ideal.  So in effect, the same amount of filament will be fed into the extruder, only with a different profile that we hope will give us the correct output as the move is made.



Above we can see the simulation of the compensated extrude rate (dark blue line).  As we would hope, it ovelaps with the ideal extrude rate.  If we look at the extrude volume error, we see a significant improvement:

The dark blue line at the bottom is the error after compensation.  Notice the volume of the error is very near zero at the end of the extrude move.  This should result in significanly less ooze (stringing and bulging corners), while also helping the width of an extrude to stay more consistent over it's entier length (less thining in the middle).  Keep in mind that these results were generated with a simple fluid flow model, so in the real world it is unlikely that this compensation technique would perfectly eliminate ooze related problems.  Having said that, even if it is not perfect, this offers improvement over no compensation.

The challenge with this compensation, is that it requires tuning a coefficient to reduce the error each time there is a major change in the printer extrude parameters.  This is due to the fact that the compensation is tightly tied to the resistance of the extrusion by the follow parameters:
  • Plastic type (ABS, PLA, PETG... )
  • Hot end temperature
  • Nozzle diameter
  • Nozzle wear
  • Hot end thermal stability
  • Extruder compliance (Bowden vs. Direct)

If this parameter is set too high there will be over extruding early in the move (or even skipped extruder steps in extreme cases), and extrude starvation near the end.  If the parameter is too low, then the advantages of this technique are not fully realized.  Unfortunately, there is no current model for taking into account all of the above factors (and more) and giving an accurate compensation coefficient.  This leaves it to the operator tune this by trial and error.  Most firmwares will give an initial value that works reasonably well for most people.  This is still better than nothing, but leaves room for improvement.

In a future post I will go through the tuning process and include pictures to help highlight the improvement and aid in the tuning by other people trying to maximize their print quality.















Comments

Popular posts from this blog

Computing Junction Deviation for Marlin Firmware

As part of developing my own 3D printer firmware, I also keep an eye on what is happening in other firmware.  One feature that is causing confusion in the Marlin community is the junction deviation setting.  Up until recently, Marlin used the jerk method (hence forth referred to as "archaic jerk") it inherited from Grbl for computing corning speed (junction velocity).  With the option now in Marlin to use junction deviation instead of jerk, there are many people who want to know what are good settings for junction deviation to insure they get reasonable movement while printing.  In this post I will give an equation for converting the jerk values into junction deviation and my derivation of this equation.

Introduction to Kynetic CNC

This project started as a result of the the wildly successful Teensy 3.5/3.6 kickstarter.  At the time I was amazed by the specifications of these microcontrollers and thought, "With all of that processing power, could I create from the ground up a completely new 32bit 3D print engine that would improve upon the capabilities of the current 8 bit printer controllers?"  Soon after that, I started making notes about how I would do motion control if not limited by the power of the processor.
  After two years of part time work on this project (I have a full time job and full time family),  I'm now ready to discuss the details and where it is going.

Extra Smooth Moves

In an effort to provide a no compromises motion controller, one major milestone is converting the trajectory planner and motion control from constant acceleration to minimum jerk.  For simplicities sake, the original Kynetic motion controller was done as constant acceleration.  I have now completed the work to make it use the much smoother minimum jerk algorithm.