Monster Modelling Clay 3D printed attachments

Having fun with Simon and Lucas...

I'm planning to make spikes (red ones) and other attachments. But now (because I have 2 boys modelling monsters with at least 4 eyeballs and 10 teeth per monster) I'm in desperate need of extra extra extra eyeballs and teeth.


Here you can find the tooth and eyeball stl files.

Agree to the terms, download them and scale them according to your monster dimensions and make the best monster you can think off.


Velocity extruding revisited

After finding some time (actually it was so simple that I'm still asking myself why I didn't make time sooner) I finally got to changing the velocity extrusion logic.

My previous posts about velocity extruding and wire-laying were about how I changed the extrusion position (the E0-axis in reprap or A-axis in Machinekit) being calculated by the slicer to a situation where the extruder velocity is a result of the actual nozzle velocity. The big advantage is that tweaking the flow of plastic can be done real-time by adjusting the flow parameters. Because of the pressure in the nozzle due to the filament speed, and as a resulting compression force of the filament (and other causes) the flow of thru the nozzle will have a hysteresis.

  • You can notice this when you accelerate to a high speed with a high velocity, the nozzle will have to build up pressure. There will be stringy parts of the path that is being printed. So until a new equilibrium is formed, the flow will lag.
  • Then decelerating the pressure is too much, with respect to the lower velocity, and thus there will be an abundance of plastic. Resulting in wider paths and blobs when standing still.

Some of you will say: "But I can't see those stringy lines in my printer!" That's because I think that the pressure will in some cases be always too big so you don't notice. What you probably would notice though is that if you print only lines at various speeds the lines will not always be equally thick at the acceleration and deceleration positions.

This movie shows that with the lines I print the thickness is equal, at various speeds.

For the velocity extruding my workflow is as follows:

  • Slice with Slic3r with ALL line widths the same width and ALL line heights (layer heights) the same height. (I'm in the process of overcoming this obstacle, but that task is not finished yet).
  • Run a script to change the Slic3r generated code to suitable g-code. This link still links to the configuration files (including script) I used with my BBB rev B and BeBoPr-Bridge. I'll do a separate post regarding the script at a later date.
  • Have Machinekit installed with a suitable configuration for the velocity extrusion.
  • Print the product.

So how does the new velocity extruding work? This week I thought: "Let's make a nice graph with Graphviz visualising the way the calculations are done...". So I started to type, and after 3 lines of adding nodes and edges in Atom with .dot syntax and graphviz preview package installed I was thinking this would be a loooooot of work. And I had already done it in my .hal file.

I searched and ultimately found this post from Jeff Epler which explains how to generate a .dot file from a running hal instance (or hal configuration file). Such a shame I didn't search for this before because it would have made the work a lot easier.

Resulting in this file. I've exported it to a .pdf document so you'll be able to zoom in and explore. I've highlighted some nodes and below I'll explain what is done at that point.


because I have the linear delta kinematics, the velocity of the axes are measured as joint velocities. Not x, y and z in cartesian space, but the speeds of the tower carriages. This needed to be converted to cartesian because that's not standard in LinuxCNC yet. I shamelessly took the part of the kinematics file that handles the part of calculating x, y and z from the carriage positions and from this I made a hal-component.


This component takes the square root of the total of the squared velocities... meaning

The nozzle speed gets multiplied with the cross section area of the line, and further on divided by the cross section area of the filament to get to the extrude rate of the extruder.


these four take care of the retraction and pre-charge. These happen when the extruder velocity is coupled with the nozzle velocity and the time is set at greater than zero.


The magic happens here! This lincurve takes the speed as an input, and gives a offset value as an output. This curve now consists of 5 values. Anything in-between will get interpolated.


The final result is the position the extruder should have when it is compensated for the hysteresis of the filament. The derivative is taken from the (changing in time) position, resulting in a speed, which is being fed into (end of our journey):


which is input for the step generator for the extruder motor.

There's probably more that I forgot to mention, so if you've got questions or remarks leave a comment and I'll try to answer. Or else leave a message at the Machinekit group which I closely follow.

I'll publish the config files after I have cleaned up the unused artefacts of the previous velocity extruding. Here are the config files.

As an added bonus, for reading this far, here's a movie of the printer printing this part (for you who have a 3D printer and kids a must-have). I'm pretty happy with the result. There's room for improvement. Especially my mechanical setup. Due to the acceleration my hot-end overshoots. As a result the corner of the overhang at approx 4 minutes into the movie is a not as should be. Furthermore, at the end of the movie when I turn the connector around you'll notice little blobs.

I think that this is due to the way the extruder starts and ends. When starting the line, the nozzle will extrude and start to move. When that happens, the plastic is flowing in every direction without a preference. So an equal amount going to the side as, as to as the front and back. When the nozzle has speed, the plastic will become a straight line. Don't know how to solve that one yet. :) Probably when I improve the script for transforming the generated g-code. Then I'll be able to use different extrusion widths again.