5-axis 3D printing
-
did you have a look at linuxcnc?
http://linuxcnc.org/docs/devel/html/motion/5-axis-kinematics.html
-
I currently program 5 axis vertical milling machines XYZ+A&B axis rotary trunnion A is +or- 999 degrees, B is +or- 120 degrees. I see no reason why you could not use 5 axis CNC software to generate your G code, I use both Surfcam and Edgecam. both have fully integrated customizable Post Processor generators.
-
CNC and 3D printing does not uses same tools... For example, CAM softwares don't know how to manage bridges or so.
I don't think driving the 5 axis is a problem; it's more a matter of a clever slicer to take advantage of additionnal axis.
-
-
@haraldschmidt said in 5-axis 3D printing:
getting a self-made 5-axis 3D Printer work at my University.
What's your goal? Being able to print shapes that can't be printed on a regular 3D printer? Any example?
-
Look autodesk powermill additive 2019/2020 with netfabb strategies.
It should be able to handle 3 + 2 axis interpolations for print -
Hi,
I started to work on a pseudo 5 axis 3D printing stuff. This is a work in progress, but I share it so you may give me some advices
-
As you can see on the wiki page, the idea is to map a portion of sphere onto the plane: this part works fine, and I can have the part sliced the usual way¹.
Now, I need to implement the kinematic. My first idea was to post-process the G-Code file, and transform the X/Y/Z coordinates to X/Y/Z/A/B coordinates with a Python script. But it is not that simple, as the additionnal bed rotations make the kinematic non linear So, the only way is to implement that in the firmware.
Some months ago, I started to look in the CoreXY code, but I'm wondering if it would not be easier to build a 6 axis Delta or Stewart platform... Delta kinematic is already implemented, with all the segmention stuff, and adding 3 axis is maybe easier than tweeking the CoreXY code to make it segmented. A 6 axis Delta is maybe also easier to build than a 2 axis bed rotation.
David, what do you think? Would it be hard to extend the 3 axis Delta kinematic code to a 6 axis kinematic?
Any advice welcome.
¹ BTW, I made some tests with my sphere_to_plan mapper, and found that slicing the portion of sphere mapped to plan uses much less filament : on my little test part, I found 3m40 vs 4m12 ; this is 17% less, and this is done without support for the sphere! If my Python code is correct, this is an argument to develop 5 axis 3D printers.
-
Sorry but I don't understand what you want to do with xyzab.
At most you can exchange a linear axis with a rotary one.
I've been working on 5-axis milling machines for several years and what you say doesn't make any sense -
The goal is to print a sphere as if it was a plan. A/B axis are bed (or hotend) tilt along X/Y, and are used to ensure the hotend is always normal to the sphere at the printing point.
Once the STL file of the sphere is mapped to the plan (which works fine) and sliced, the X/Y coordinates of the G-Code describe the sphere of the original stl file. The firmware should then convert these X/Y coordinates (which the printer still see as a plan) to new X/Y/Z/A/B coordinates to re-create the sphere in the printer space.
-
@fma Have you thought this through? You'll need to tilt the head, not the bed. Otherwise the part will fall off. To start the sphere, the print head will need to be tilted and positioned such that it is inside the sphere which could be difficult if the part is solid. If you start with the head outside the sphere, then the head will need to be below the bed. Half way up the sphere, you'll need to switch the head from inside to outside.
-
There is no problem to tilt the bed +-35°, the part won't fall, as it is very thin compare to its width. I've seen people putting their (small) printer upside down while printing!
The sphere will be printed from outside, this way:
The bed rotations would be inside the sphere, more or less at the flat bed height (flat bed which won't exist anymore). So, the hotend have to raise while the bed tilts.
BTW, I plan to make a sphercial bed, so there is no need for supports. This bed can be 3D-printing, and by adding a raft for each print, can be re-used several times, giving very good adhesion.
-
One concern with rotating the part might be that you loose (or vary) the force of gravity to help squish the layers as well, but if parts fall off then bed adhesion might be worth looking into in any case.
-
I don't think gravity plays a big role in layer adhesion; it is more a matter of temperature and speed... And this part will have no strenth on it, so even if layer adhesion is bad, this is not a problem. The goal is 1) save time and filament 2) give a nice finish 3) have fun while designing the printing process
-
When printing in a xy plane as you will be doing its at least a constant force, I'm just relaying some of the stuff I've read with regards to "true" 5-axis printing.
-
If I use a tilting bed, the hotend remains vertical. But it would be more fun to build a dedicated 6 axis Delta, if David can implement the kinematic
-
@fma But your illustration is for a slice of the upper part. If you want to print the lower part and keep the tool at 90 degrees to the print surface at all times, you'll have to print the lower half with the tool inside the sphere. Because if it's outside the sphere then it will need to be below the bed. So you'll never be able to print a solid sphere - only a hollow one. For the first half, you'll need to keep tilting the bed until it reaches 90 degrees (at which point the part will likely fall off). After the half way point, you'll have to move the tool to the outside then tilt the bed back in the opposite direction.
-
As said in a previous message, I plan to print BB-8 panels, which are only portions of sphere...
-
After doing the sphere-to-plan projection of a stl file, I sliced the resulting G-Code, and parsed it through another python script to generate the final G-Code.
This second script bascially makes the invert plan-to-sphere projection (no tilt management for now), and also cut the long segments into shorter ones, so a long move in the X/Y planes actually moves along the shpere instead of colliding it.
I then upload the resulting G-Code file to the Duet, and start printing (without filament). And it works! I can see the hotend describing the sphere intead of the plan
Things are not perfect, and I have a little difference between the planar segment length and the spherical one (a bug in my code I can't find). So, I will have to compensate the extrusion to keep it correct. As I also cut the planar segment in equal smaller segments, the segments on the sphere are not equal anymore: there are a lot of very very short moves towards the top of the sphere, and I clearly notice some jerk issue, or something like that. I need to investigate.
Before I dig in these bugs, I will use a small acrylic half ball as bed, try to put it at the right position (center of the bed), and print on it. Or I can create the support with the part, so it is transformed by the scripts. Don't know if it works, but it worth trying
Of course, even without bugs, the print won't be correct, as the hotend is not normal to the print surface, but this is really fun
-
First try: