Blobless Printing With Velocity Extrusion


The current crop of 3D printers are technically four-axis machines, with three axes of movement and a fourth for the position of the filament. [Bas] had an entirely different idea – why not link the speed of the extruder to the speed of the nozzle? It turns out this technique gives you more ‘plasticy-looking’ prints and a vast reduction in blobbiness.

[Baz] has been working with LinuxCNC, a BeagleBone Black and the BeBoPr-Bridge cape, and there’s been a lot of development with that system in turning many straight lines into one smooth arc. This led him to adjusting the flow rate of a nozzle while the printer is running, but this is difficult if the extrusion is controlled by position as in a traditional printer setup. A new configuration was in order.

What [Baz] ended up with is a config that calculated the speed of the extruder based on the speed the nozzle is moving over the print surface. This gave him the ability to add live nozzle pressure adjustment, and as a result, a near complete disappearance of the little blobs that appear at the start of each layer.

For a well calibrated machine, it’s only a small difference between the ‘normal’ and ‘velocity’ methods of controlling an extrusion rate. It’s a noticeable difference, though, and one that vastly improves the visual quality of a print.


29 thoughts on “Blobless Printing With Velocity Extrusion

  1. I thought all filament-based 3D printers had always done that. I don’t see why it wasn’t the first thing everyone thought of as soon as they had the idea to move an extruder in three dimensions.

  2. How could you /not/ do this? As the velocity of the head increases you need more volume of plastic for to cover the same area per unit time.

    Maybe something like using less extrusion speed at high constant velocity to make thin “threads” of plastic and then modelling that somehow could be neat.

    1. Same thought. Why would anyone not do this? It is standard in printing and CRT current versus spot speed on vector displays and in production candy and cookie making equipment, and basically everywhere – speed of sickle bar on a wheat combine. I don’t have a 3D printer but would have expected this to be part of the basic software before tweaking.

  3. It is actually a very nice thing that was done here. He does more than the typical ramping at acceleration and deceleration, but seemingly he adds a constant term to to the extrusion velocity while accelerating, and subtracts it while breaking. This is mathematically correct for compensation of pressure drop terms in the nozzle.
    What happens is that its basically a constant prime/deprime or in other words, constant rectract/unrectract, that is movement dependent.

    There were previous trials for implementation, e.g. in the Jetty Firmware.
    The trouble is that you need to move the extrusion axes asynchronous to the movement axis, it this quite nontrivial. There was an earlier implementation called “Advance”, in the Marlin firmware, that took different assumptions in the derivation, causing a time delay (opposed to addition/subtraction) in the filament velocity.

    1. So are you saying that your pressure compensation and Bas’s ‘velocity extrusion’ are pretty much the same thing? It may be just a reputation thing, but I have more trust in your explanation that in that of Bas’, and looking at the other comments it appears I am not the only one to not understand what problem he is trying to solve.
      I suspect a lot of his enthousiasm is for the HAL of linuxcnc.

    2. This has been successfully implemented in the Sailfish (Jetty) firmware for the last few years with excellent results. Good to see the Marlin guys finally catching up.

  4. Ok I read the article and I think I understand whats going on here. Instead of making the extrusion speed dependant on the velocity of the head (like all printers do already), he’s making it dependant on the acceleration of the head.

    This means that while the printer is accelerating (at the beginning of a move) the extruder runs faster in order to build up pressure. When the printer is decelerating (at the end of a move) the extruder runs slower in order to reduce pressure. This means there is no delay before the plastic starts coming out at the beginning of the move, and no extra plastic oozing out at the end of the move.

    1. If that’s the case then that’s actually noteworthy. Perhaps ” why not link the speed of the extruder to the speed of the nozzle?” should be changed.

      speed != velocity != acceleration

    2. Current implementation:
      Slic3r and other apps treat extruders just like 4th axis and export their position. Yes, they try to match extruder positions to xyz axes positions, but it is not possible to match second derivatives of position (acceleration), if only the position is provided and machine settings (acceleration values, velocity limits) are ignored.
      New implementation:
      Actual machine status (motion velocity) is monitored on realtime and extruder velocity is adjusted accordingly. I did not look at the code, but I feel pretty confident that extruder stepgen is running in velocity mode. And that is pretty big difference, if one has to calculate positions to match velocities and accelerations or if the velocity is actually being “given” right to stepgen to generate step/dir signals right away.
      And the fact the g-code defines thickness and width of the extruded line is something that I had never thought of and have never seen mentioned before. I somehow always thought that final layer thickness is defined by the distance between nozzle and previous layer, but now it seems only obvious that rate of extrusion compared to nozzle’s velocity also matters – for the same nozzle velocity speed up the extruder and extruded material is compressed and the extruded line gets thicker and wider or slow the extruder down and the extruded line should be thinner and narrower. This is really geat idea!
      I see previous comments that it is so obvious and should had been done etc. I just would like to see, how exactly do those people implement such a functionalty in Arduino and their really limited computing power.
      My main takeaway from this article – there is one more example of outstanding capabilities of LinuxCNC.

      1. Yes, Bas is running the extruder stepper controller in velocity mode, with the velocity calculated on-the-fly based on the machine state. For proper extrusion, you actually do *NOT* want the extruder speed fully coordinated with the other three axis, or you don’t have enough material at the start of the move, and too much at the end. The retract and “extra length on restart” settings are an attempt to fix this issue using fully coordinated machines, but it’s not a good model of the physics of what’s actually happening.

        The really cool thing is this was done almost entirely with HAL configuration, which is basically like a netlist of standard components (like PID loops, integrators, etc) you wire together to make your machine configuration. There are also tools like a virtual oscilloscope you can use to monitor and debug HAL configurations, making it pretty easy to experiment with alternate control techniques like this one.

  5. The correct way to deal with unintended blobs during extrusion is to account for the actual nozzle pressure instead of a linear linking between movement distance and extruder motor rotation. If you are able to correctly estimate the nozzle pressure at any time, this will result in very precise extrusion output.

    So yes, the described compensation is the right way to go.
    And – as already mentioned – done by all popular reprap firmwares already: In Repetier (and i think Marlin as well) this is called the “Advance factor”, which really helps a LOT especially when bound to low accelleration settings on your machine.
    I think it was first implemented by Matthew Roberts and described on the reprap mailing list…

    For the detailed implementation refer to:'_Firmware#Pressure_Management

  6. Linking the extrusion rate to the commanded path speed (as is normally done) is only a partial solution. The acceleration limits (and potentially any anti-jerk modification) of the actual physical system mean that for a commanded constant-speed path the actual velocity varies.
    What Bas has done is link the extrusion rate to the actual real-time velocity of the nozzle, not the idealised speed requested by the G-code.
    The acceleration/deceleration modifier is an extra tweak on top.

  7. Excellent illustration of the versatility of LinuxCNC!

    Also, excellent opportunity to launch the following idea:

    All our 3D printers are based on the G-Code, which specifies the successive positions of the nozzle, and velocities between these positions. The extrusion speed is correlated in different ways, but it is the movement of the nozzle which provides the tempo, upstream, and the extrusion rate has to be adjusted, downstream. This is the G-Code that wants that.

    But when you want to extrude a very viscous material as fast as possible, it would be better to make extrusion speed as constant as possible, and it should be this constant extrusion rate, which should give the tempo to the entire machine, and axes movement would try to follow the accelerations that result.

    In other words, we would need a file format for 3D printers that treat the extrusion rate as a kind of implicit clock against which the movements of the nozzle would be described in terms of continuous movement, rather than successive positions and speeds. It seems to me that this could simplify both the firmware and the slicer, which could use mathematical tools best suited to the description of continuous movement, as NURBS …

    In such a system, the overall printing speed is mainly determined by the capabilities of the extruder, and not primarily by the displacement motors axes. There would be no more blobs at each change of direction, but instead, all the angles are more or less rounded, depending on the mechanical performance of the machines and their ability to provide very high acceleration.

    We currently focus on the quality of the prints, but if we think long-term, printing times of several hours are not supportable by meanstream users. The G-code will be, one day or another, a bottleneck.

    What do you think?

    1. Given that it’s trivial to add commands, I don’t think the g code command set is necessarily a limiting factor. If you want to define a command to follow a NURBs path, then I think that can be done. It won’t be standard, but it seems every g code interpreter has non-standard idiosyncrasies.

      I don’t know if AVR can necessarily take that very well though. As such, I think relying on AVR uCs might be the current limiting factor.

      But moving beyond lines, or even beyond lines and arcs, would take advancing many steps in the tool chain. Your slicer needs to be able to open NURBS-based files, output slices as such, your printer controller hardware and firmware need to be updated to do that.

    2. Yes, I know that G-Code can handle NURBS. But, if the nozzle follows an NURBS XY path, the corresponding ideal extrusion rate is probably not constant, nor always maximum.

      Is it possible, with G-Code, to force the printer to assume always a real constant and maximum extrusion rate, upstream, the XYZ movements being calculated in accordance, downstream ? That means very jerky movements at every direction change, and supposes a low inertia and high performance mechanics. That means also a far better overall printing time…

      I think that it is not possible with G-Code. That’s the point.

      1. I think much of that can be done by changing how the interpreter operates, or done to a good extent by modifying the slicer to factor in those considerations.

        But the acceleration demands to maximize constant extrusion velocity well exceeds typical DIY and even commercial machines.

  8. I pretty much eliminated blobs in my parts, by increasing the extruder acceleration and dialing in my retraction. This is in Marlin firmware. My acceleration is 3000 mm/s^2, retraction, 1.0mm retraction distance, 2000mm/s retraction speed.

    I’ve seen one person find that LinuxCNC doesn’t necessarily respect that fast of a retraction acceleration setting.

    1. a factor as important as acceleration is the jerk-velocity, I usually say that 30 mm/sec is good for lightweight heads, while at least 10-20 is good for heavy heads.
      3000 is still a small acc. for bowden heads, 5000 would lead to better prints.

    1. No, because the corrections required mean the extrusion axis is not truly coordinated with movement in space (X, Y, and Z), and gcode has no way of specifying a different movement profile for one axis in a multi-axis move. The only way this could be approximated is to break each move down into lots of small segments and send gcode with the modified extrusion axis values. While possible, this is highly unlikely to work well on an AVR based controller, where serial communications are already a bottleneck.

  9. This is nothing new, Sailfish has done this correctly for a number of years. Properly pressure modeled and managed extrusion according to the speed. All done on a Atmega 2560 in realtime without any floating point calcs and with acceleration.

    Once you start printing at serious speeds (120mm/s) you need acceleration and you need well done pressure management, otherwise print quality is poor. Pressures at those speeds become very large, so you need to prime them and bleed them off in realtime.

    Marlin originally had a incorrect implementation of this, good to see they’re catching up to Sailfish.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.