Sunday, 16 March 2008

Filling in

I have been experimenting with various infill patterns. Here is a 40 x 10mm block made with 0.5mm filament at 50% fill: -

For simplicity I used alternating horizontal and vertical lines rather than diagonal. The layer height is 0.4mm so the width is about 0.6mm and so are the gaps. A couple of things that weren't obvious to me at the beginning were: -
The first and last lines of the fill must be adjacent to the outline so that the U turns on the alternate layer above have something to rest on, otherwise they curl upwards or downwards and don't bond to the outer skin. That means adjusting the gaps slightly to make the overall width correct. When the fill is 100% I adjust the filament width slightly to exactly fill the interior. Easy enough with a rectangular object but probably not with an irregular polygon.

The fill lines probably should line up with the those two layers below so that the intersections form a solid column of filament from top to bottom, otherwise some sag may be expected. Again trivial for rectangles but could get tricky to generalise.
Here is 33% fill, i.e. the gaps are about twice the filament width: -

This is 25%. Notice how, although the filament is laid down in a perfect square wave, when it shrinks it pulls itself to the first harmonic. A physical low pass filter!

And here is 20%: -

I found that when putting a lid over the top it struggled with an infill this sparse, so I settled on 25% as the limit for making closed boxes.

All the above are done with filament stretched to 0.5mm. When extruding through a 0.5mm orifice, left to its own devices the filament would be about 1mm due to die swell. I decided to try the same pattern with 1mm filament, i.e. with no stretching: -

As you can see the filament holds the square wave better but what is not obvious is that without stretching it sags a bit in the gaps where it is not supported from below. So some stretching is beneficial, when it comes to spanning voids, but it does increase corner cutting.

As I mentioned before, with my old nozzle, I could extrude 0.5mm filament at 16mm/s. This is what happens with the new one which has an exit hole which is too shallow: -

One unfortunate characteristic of FDM is that errors tend to be cumulative. What I mean by that is if, for example, the U turn of the zig zag fails to bond to the outer wall then that causes the next layer to have nothing to rest on, so that fails as well. The defect then propagates all the way up the object. With 100% fill, any errors tend to have less effect on the layers above.

Rather than slow down my experiments I decided to go to 0.75mm filament at 7mm/s until I make a new nozzle. Here is a 50% fill: -

I also added a bit of overlap between the fill and the outline at the u-turns to get a better bond.

So does the infill density affect warping? I made several test blocks and it looks like the answer is not much. However, I have come to realise that the warping takes hours to fully develop after the object is removed from the base so I will leave them overnight before attempting to make measurements.


  1. A very detail test. Good work!!

  2. Brilliant work, as usual, Chris. You keep a very high standard. Thanks! :-)

  3. At this point in your project, how were you sending commands to your bot? I am aware that you use ethernet, and your own firmwares. Are you using something similar to Gcode?

    Also, you talk about using 50%fill, etc. Is this a software setting, or are you redesigning your models to make adjustments in fill?


  4. Hi Robert,
    I send binary commands to my machine in UDP packets, with sequence numbers and retries.

    I don't send g-code to my machine because it uses machine independent units in floating point format. That takes a small micro milliseconds to convert to device specific integer units.

    Instead I let the PC do the maths and send device specific units in a format that is easy for a small micro to process. That keeps my firmware very small, simple and fast. The hard work is done in Python but as it is a much higher level language than C, it is also very small and simple, and because it runs on a PC it is fast enough.

    The commands are very simple, like goto(x,y,z) at step period t would be represented by a byte command code and four word parameters plus an optional list of words for the accel decel table. The acceleration requires a square root calculation, so again, best done on the PC and sent as a table.

    The test blocks on this page were generated with Python script, not from models, so the fill ratio is just a step size in a loop (actually a bit more complex so it starts and ends exactly at the boundary).

    Since then I have moved on to using Enrique Perez's Skeinforge Python suite, which slices models to g-code. I read the g-code and extract the path information and ignore the rest. You can set the fill ratio in his software as a percentage. No need to do anything to the model.

  5. Thanks -- quick reply too ;-).

    I am curious, even though I am not going to be using hardware anything like yours, can I see your firmware code?

    I ask because I am hoping to make my firmware in a similar manner...some ideas I have for the future of my controller.

    I'd also like to see your network protocol coding, but that's just because I haven't ever peeked at the source code for low-level networking.


  6. My email address is nop dot head at gmail dot com.

    Send me your email address and I will send you it.