Machinekit and Additive Manufacturing

It's been a while since my last post, so it's about time for an update.

Since I stopped with the Opiliones project I've still been working on my 3D printering. I'll call it an Additive Manufacturing machine (AM) because I think the name 'printer' indicates it's as simple as pushing a button and having a physical product within the minute. And that's simply not true, It's manufacturing and not printing.

I've been working with LinuxCNC, a BeagleBone Black and a BeBoPr-Bridge board (Cape) since end of december last year. LinuxCNC (and it's recent fork Machinekit) is software for controlling machines...

Recently there has been a lot of development in this area, IMO one very important one is the blending of many short lines (very common output of slicing software) into smooth motion. This is important because when you are making a product, the quality of the extrusion benefits from a smooth constant motion.

I've been hacking away recently in making the configuration files fit my machine. One thing that I use when setting up a machine is adjusting the flow rate during running a program. But this is difficult if the extrusion is controlled by position. You'd have to remember the current position and from that point on you'd need to multiply the positions from that offset point. A lot of calculations and it's currently not available. During the discussions on the Machinekit group the idea came to make the extrusion dependant on the actual nozzle speed.

One of the fun things about being open (source) is that when you want to have extra functionality you can add it yourself. It takes some learning curve sometimes (LinuxCNC, linux, working with git, pull requests etc) but in the end you can actually improve and have exactly what you (think you) need.

So I ended up with:

  • Changing the configuration files so that LinuxCNC calculates speed of the extruder based on the nozzle speed (the extruder axis is velocity controlled instead of position controlled).
  • Adding functions for setting width of the line being extruded and the height of that line (the current layer).
  • (Un)linking the extruder with the nozzle velocity.
  • Writing scripts that post processes the slicer g-code output (remove all A-axis positions) and inserts the dimensions into the g-code.

Now you don't necessarily have to slice, you can draw on your bed, like with Logo Turtle on the MSX 1 (If you don't know what an MSX 1 is, you probably are a lot younger than me) put the pen down, draw a line, put the pen up (but in G-code).

What's so extremely powerful is the HAL module. You want something added? Then take the blocks you need, multiplying, limiting, etcetera and virtually rewire your machine behaviour.

Because the HAL is so powerful it took little effort to add the bonus function: Live nozzle pressure adjustment. An extra adjustment of the extruder for the current speed. Why? Because inside the nozzle there is a pressure depending on the extruding velocity. So when you start extruding (v=0) you have to build up pressure (having too little plastic while accelerating) and when decelerating you have too much pressure, resulting in a release when you are stopped. This is something you frequently see on sides of the product. See picture below of standard blobs, with plain and simple extrusion.  The 3 lines at the bottom makes an "S" movement with disconnecting the extruder speed with the nozzle on the vertical movement, but without retracting. The top 3 lines is the "S" movement, but with retracting.

Standard extruding

Because it just takes some virtual rewiring of the HAL i've added the derivate of speed function (ddt) and used that as an input for a lookup table (lincurve, thanks Andy) which adds velocity when accelerating, adds none during constant speed, and subtracts velocity while decelerating. Effectively taking care of the pressure hysteresis inside the nozzle. Want to have other/more specific/finegrained control then you just insert points in the lookup table. Imagine doing that to a elastic bowden extruder? I have my extruder mounted on the effector, with just 8 cm between the drive wheels and the nozzle of my E3D hot-end but even there this phenomenon is there. See result below after adjusting, no blobs at the end of the lines.

Pressure adjusted extrusionhere's a comparison of the "normal" extruding at the left, and the "pressure adjusted velocity controlled extrusion" at the right.

Difference between "normal" and "pressure adjusted" extrusion

And last but not least velocity controlled extrusion in action.

update 1: see this post how you can use this for PCB additive manufacturing
update 2: see this post how you can lay down wire in a pattern
update 3: I've updated the velocity extruding. Go here if you're interested

Thanks a lot to the guys at the Machinekit and LinuxCNC users list.

More info?

Until merged in the main branch, my working branche on the velocity extruding is here.

Have fun!


17 thoughts on “Machinekit and Additive Manufacturing

  1. Pingback: Blobless Printing With Velocity Extrusion

  2. Pingback: Blobless Printing With Velocity Extrusion - Tech key | Techzone | Tech data

  3. Pingback: Blobless Printing With Velocity Extrusion | Hack The Planet

    • That's very interesting. I've just read it. Right now it's just a simple lookup table. Only affected by the acceleration. But that needs to be improved because many short lines in i.e. a thin rectangular shaped infill are coming out a little thin. It actually needs to depend on a combination of both during non constant speed.

  4. Bravo ! Connecting the extrusion rate to the nozzle velocity, that is the question.

    But go further: the extruded material is viscous and generally poorly follows any variations of the extrusion rate. So this rate should be as constant as possible, and it is rather the velocity of the nozzle that should fit!

    Unfortunately, this idea does not seem very compatible with a system based on the G-Code.

    What do you think, you all?

    • At this moment the extrusion gets a little boost in speed on acceleration, and is held back a little when decelerating. When the speed is constant nothing gets adjusted. It's rather crude and could be improved (see previous comment of Bernhard Kubicek). The fun thing is that improving the calculation is done in the configuration files.

  5. So, do I understand it correctly that your new process ignores the E (or A) coordinate and instead makes a new value derived from the velocity of the hotend?
    So how/where would you set the thread width and thickness that is laid down? The thread width plays an important part in the path calculations when slicing. Is it really smart to (supposedly) move it into the machine controller?
    It is noble but impractical to try to keep gcode machine independent, creating new gcode usually is done very quickly. So I would suggest moving this correction factor into the gcode generator engine? (you will need some extra info about the machine when doing so)

    • This has nothing to do with Cura, it has to do with the Firmware/Controlling software.

      As far as I understand it, Marlin (used by many 3D printers as firmware) already does the above. And has been doing so for a long time now. The is only a LinuxCNC issue.

      • No, it has nothing to do with slicing. It has to to with managing flow and hysteresis of the pressure (read a spring system) depending on speed and speed change in real time. LinuxCNC does the control of velocity and speed. And that are the only real world variables in the extrusion proces.
        I don't know the internals of Marlin, but the fun is that for changing the behavior of my machine I only need to change some configuration files. If you don't want to run in this mode, then switch to the standard 4 axes mode and run it that way.

  6. Any thoughts on going one step farther & tying extruder temperature to nozzle speed?

    Something I've actually been meaning to poke at, since heat transfer is going to depend on the extruded mass & amount of time it spends in the melt zone...

    • In theory you could take speed into calculating the temperature. You'd have to model that system. But I think that the reaction time in a lot of hot ends is a little long wrt the extrusion discharge volume.

  7. Would the inclusion of a high precision accelerometer on the extruder assembly aid with velocity calculations? It seems like that might be an effective way of ditching the lookup table and doing velocity calculations in realtime, to accommodate different types of extruder assemblies (Bowden vs. direct drive for example) where differences in weight of the extruder assembly probably affects the velocity calculations...?

    • Hi Gregory,
      The calculations are done in real time, they are taken from the actual Cartesian velocity. The lookup table is very simple, in fact, it's a straight line. With little effort you could write a real time component for this, doing more difficult calculations. I think that adding an accelerometer will make it more difficult instead of easy, because when you move in an arc, you'll have an acceleration, but same speed, and it is the absolute combined speed change that holds the secret.

      When you compare Bowden vs direct drive extrusion, the biggest influence/difference will be spring system of the tube and filament.

Leave a Reply

Your email address will not be published. Required fields are marked *

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