How Precise is the Ultimaker?
Now we finally finished up on Monday with a very well received presentation. Before you (hopefully) enjoy reading our results I would like to thank a couple of people and institutions for supporting us:
- Ultimaker Ltd. for creating this incredible machine. Great company with great people. Best start-up this year.
- Paul Candler for being a loyal and talented discussion partner, joining us in the ride of "being new in 3D printing". Not to name his achievements regarding the Netfabb profiles - groundbreaking stuff...
- Netfabb GmbH & everybody working there. Namely Alexander Oster and Karl Fruth - thanks guys for the great cooperation.
- Erik van der Zalm, Bernhard Kubicek, Matthijs Keuper, Bradley Feldman as well as others for adapting Marlin to work with the Ultimaker.
- The Ultimaker Community in general. Seldom experienced such a capable crowd of people in one spot. Applause to everybody.
- Unversity of Bayreuth and especially the Lehrstuhl für Umweltgerechte Produktionstechnik.
Download "Open Source Rapid Prototyping – Präzisionsmessungen anhand des Ultimakers" (80 pages, German, 2.5 MB)
Download "Presentation Slides" (37 slides, German, 2.4 MB)
Sadly I couldn't convey my team mates to write this in English. It's quite sad that it's not as accessible as it could be to the community. But still: Measuring results should be easily understandable. You also could try translate.google.com (and then "translate document" --> "choose file" --> set "German" --> "$your_language" --> hit "Translate") in order to ease the pain.
So what is this all about?
In the last weeks we've printed several test objects to make an statement on these categories:
- X/Y/Z accuracy
- Rounding/Holes
- Overhangs
After seeing quite some inaccuracy over all tested parts (meaning parts are too big in almost all cases), we've dug deeper and put the Ultimaker itself into our nice dimensional measurement device. Then we drove the print head without any material printed and measured the difference between the Gcode and the actual travelled distance.
Interestingly enough we saw too low values for short travels and way too high travels for higher distances. So there seemed to be at least two diametrical effects going in there. Our current working hypothesis is that the steps/mm variable is set too low (in contrast to what is discussed here) and the opposing force appears to be mass inertia of the moving parts (print head, sliding blocks, axis) themselves.
On top of that there seems to be a thermal/material characteristic which results in bigger parts separately.
Instead of further researching and tackling every single effect for itself, the community changed the steps/mm variable in Configuration.h of the currently developed firmware Marlin to a lower value in order to make parts smaller. This value should also be the mathematical correct one (which still bothers me, because it's not fitting our research results ;)).
Judging from our research I would personally expect to still see quite some inaccuracy for bigger parts when inertia kicks in for long and fast moves. Therefore the best way would be to increase the steps/mm value so that the machine travels the way it should (testing with very low speeds). And then add another component to the firmware which dynamically calculates the expected inertia effect and prevents it. Last but not least there has to be an other software-side function to scale the outer lines inward to compensate for thermal effects of the material.
As already said: This would be the best way to do it in my eyes. But if further testing shows that just by changing the steps/mm variable to a lower value cures all inaccuracy to an acceptable level this would be a much simpler approach. Also I would like to do some more pure machine travel measuring in order to confirm/disconfirm my expectation that with the now lower value the actually moved distance is way to low for small parts (and therefore compensates on material behavior and inertia).
I would love to hear your comments on all of this!
Florian
