I want to see how much of the Darwin design I can make out of HDPE as that is the plastic I have the most of and is the easiest to get hold of. It should also be the cheapest but I think I got a very bad deal with mine.
To extrude HDPE quickly, without losing accuracy, requires a fan blowing on the work piece while extruding at around 240°C. The PTFE insulator in the extruder starts to lose its strength under these conditions and it also extends about 0.5mm due to thermal expansion. The JB-Weld heater insulation also degrades rapidly. To address these problems I am working on a design using stainless steel as the insulator, which I first blogged here. Here is a second lash up I made to progress the idea :-
At the bottom is a brass nozzle made by the man himself, Adrian Bowyer, and is described here. It has already been superseded with the anti-ooze design shown here.
Above that is a brass barrel that came from BitsFromBytes, with my experimental Cerastil heater on it. I attached a thermistor to the barrel with JB-Weld.
The brass barrel is screwed into the end of a 1/4" stainless steel tube. The other end has been tapped with a 1/4" UNF thread and screwed into a small north bridge heatsink from a PC motherboard (40 x 40 x 15mm). I drilled through the centre and tapped it. To lock it in place and give a good thermal connection I made a square nut from a piece of 10mm aluminium bar. I spread heatsink compound on the threads.
The top of the stainless steel tube is screwed into an old PTFE barrel to join it to the pump. The barrel had swollen so that it wouldn't hold an M6 thread anymore, but fortuitously it seems to have swollen just enough to match 1/4" UNF.
This is by no means the final design, it is far too long and flimsy, it's just to test the concept using existing parts.
I also wanted to try insulating the barrel and nozzle with PTFE. I made an end cap that fits over the nozzle by plunging an 8mm end mill into a 12mm PTFE rod :-
The idea of this is to keep the fan wind off the nozzle and also give it a non-stick surface so that when filament curls upwards and will not stick to it. I also insulated the stainless steel tube with a piece of 12mm PTFE rod with a 7mm hole drilled through it. Here is the completed assembly :-
The gap in the PTFE where the heater and thermistor are and where the wires emerge is covered with fiber class wool. I hate the stuff, I only have to think about it for it to make me itch all over. It is a much better insulator than PTFE though, but I wanted something smooth and slender to not disrupt the airflow from the fan too much.
The wires are sleeved with PTFE insulation and then plugged into a floppy drive connector. So everything at the hot end is good for about 300°C.
How well does it work? Well it took me a long time to be able to get it to extrude HDPE semi reliably. Thermally it works well. With the fan off and the barrel at 250°C the heatsink only gets to about 45°C, easily cool enough to mate with HDPE, ABS and probably PLA and PCL as well. With the fan blowing it cools down to room temperature. The heater power goes from about 60% to 80% so the insulation works well enough. A better idea might be to lag the pipe with a thin layer of fiberglass wool and then wrap it with PTFE baking parchment to give it a smooth outer surface. Or maybe an outer metal pipe with fiberglass in between.
Mechanically it is not that great. It seems to a need lot of force to extrude. I had to open up the hole in the nozzle from Adrian's 0.4mm to my standard 0.5mm. I also had to up the temperature to 250°C. I think this is mainly due to where I am measuring it and how I calibrated the thermistor. Previously I measured the nozzle temperature and calibrated it with a thermocouple inserted into a hole in the nozzle. With this version the thermistor is in a notch on the surface of the heater barrel and I calibrated it with a thermocouple inside the empty barrel. Looking at the value of beta that I got I think that it is considerably hotter inside the barrel than the thermistor is outside. I am not sure how this is. With the heater on the outside of the barrel I can't see how the inside could be hotter. Perhaps the thermal connection of the thermistor to the barrel, via JB-Weld is not as good as it it could be. When sited in the acorn nut nozzle it was half buried in a hole.
Even with the nozzle removed it is quite hard to extrude 3mm filament by hand. Part of this has to do with how long the total barrel is and the fact that it has three joints. The inside of the stainless steel barrel is not as slippery as the PTFE. It might also be the case that the molten section extends further up the barrel causing more viscous friction. I plan to shorten the whole thing considerably: I will combine the clamp with the right angle bracket and take the tube right up to the base of the pump. I will support the heatsink with a cradle structure resembling an upside down table. More importantly, I will shorten the heater barrel by combining it with the nozzle and screwing the tube into it. Making it from aluminium, which is two and a half times a better conductor than brass and easier to machine, should make it easier to get a consistent temperature measurement.
As there is a continuous temperature gradient down the stainless steel, the point at which the plastic melts will be about halfway up so I think the heated nozzle can be quite short indeed. The limiting factor is how long it takes the heat to get to the centre of the filament with the very poor thermal conductivity and high specific heat capacity of the plastic.
Here is an HDPE version of the opto bracket with my best PCL version behind :-
I have no idea why it is so grey. It is not as neat as the PCL one but most of the errors are due to blobs forming when the extruder moves between extruding. These cause the nozzle to be displaced sideways when it gets close because it is so flimsy. Shortening it and supporting it properly will improve matters for sure. I also need to incorporate Adrian's anti-ooze valve somehow.
Saturday, 3 May 2008
Monday, 21 April 2008
Fun with Python and G code
The current RepRap host software is a monolithic Java program that imports STL files, lets you place the objects to be made on the table, slices and dices them and controls the machine.
In my opinion the slice and dice code should be a separate program from the machine controller. Its inputs should be the 3D model in STL format plus the filament dimensions and the output should be an XML file with extruder paths grouped into layers, outlines and infills. The machine controller then reads the XML and controls the speed, temperature, fan, nozzle wiping, cooling delays, etc, according to the selected material and the machine characteristics. A third layer of software should be the communication protocol to the slave device, e.g. SNAP or G code over serial, USB, Ethernet, etc.
I have moved a little way towards that model by making my machine accept G code from the RepRap host or Enrique's Skeinforge script. I throw away most of the G codes, looking at just enough to build be an internal representation of the extruder path. This is simply a list of layers, which are lists of threads, which are lists of points. From that information I can control my machine, make animated GIFs or preview the paths in a GUI. All of this is trivial in Python.
Here is my first cut at the preview GUI: -
The preview shown is from G code generated by the RepRap host, and here is the object it made: -
Behind is the same object made from G code generated by Skeinforge.bsh. The RepRap one has sharper corners and the infill is a bit better but the Skienforge one is faster to produce because it has sparse infill.
Here is a video of it being made: -
Here is my first attempt to make Vik Olliver's shot glass: -
When it got to the stem the fan could not get the heat away faster than it was arriving and the whole thing became a molten mass. I fixed that by slowing down the extruder to 8mm/s when the layer gets small: -
It took five hours to process with Skeinforge and an hour and a half to build. I couldn't get the RepRap host to process it.
In my opinion the slice and dice code should be a separate program from the machine controller. Its inputs should be the 3D model in STL format plus the filament dimensions and the output should be an XML file with extruder paths grouped into layers, outlines and infills. The machine controller then reads the XML and controls the speed, temperature, fan, nozzle wiping, cooling delays, etc, according to the selected material and the machine characteristics. A third layer of software should be the communication protocol to the slave device, e.g. SNAP or G code over serial, USB, Ethernet, etc.
I have moved a little way towards that model by making my machine accept G code from the RepRap host or Enrique's Skeinforge script. I throw away most of the G codes, looking at just enough to build be an internal representation of the extruder path. This is simply a list of layers, which are lists of threads, which are lists of points. From that information I can control my machine, make animated GIFs or preview the paths in a GUI. All of this is trivial in Python.
Here is my first cut at the preview GUI: -
The preview shown is from G code generated by the RepRap host, and here is the object it made: -
Behind is the same object made from G code generated by Skeinforge.bsh. The RepRap one has sharper corners and the infill is a bit better but the Skienforge one is faster to produce because it has sparse infill.
Here is a video of it being made: -
Here is my first attempt to make Vik Olliver's shot glass: -
When it got to the stem the fan could not get the heat away faster than it was arriving and the whole thing became a molten mass. I fixed that by slowing down the extruder to 8mm/s when the layer gets small: -
It took five hours to process with Skeinforge and an hour and a half to build. I couldn't get the RepRap host to process it.
Wednesday, 16 April 2008
Python & Beans make object
Having got bored of making rectangular blocks for months I decided it was time to hook up my machine to the RepRap host software so that I could make arbitrary 3D objects from STL files. My original plan was to hack the host code to replace the serial comms with Ethernet and cope with the differences of my machine from the RepRap Darwin. Zach Smith added a G code back end so I decided to just add a G code parser into my Python to save me having to modify the host.
In the meantime Enrique Perez published a plug-in script called Skeinforge.bsh for ArtOfIllusion that also converts 3D objects to G code extruder paths. It is written in the Beanshell script language, which is Java like. I decided to try both approaches, as in theory a G code parser would allow me to use either.
Enrique posted some new scripts that process G code and drive the RepRap hardware using a Python SNAP protocol driver written by greenarrow, so I didn't even need to think about writing a G code parser, I just cut and pasted a few lines from Enrique's.
Before letting it drive my machine I thought it would be a good idea to look at the paths on screen. I knocked up a little script which used my HydraRaptor simulator to draw them. The script is just a few lines of Python that use TkInter.
It was soon apparent that Enrique's code had a bug that left off some of the outline, but apart from that it looked very promising because it has the ability to do sparse infill. That speeds up building objects, saves plastic and reduces warping so it is very worth while. Not only that, it had a novel infill pattern. Instead of parallel lines like this: -
He moves the ends together so that the outer wall is stronger: -
This looks like a good idea because it makes the outer wall effectively two layers thick but probably gives a bit less warping than a second continuous layer would give.
In order to communicate the results to the forums I came up with the idea of making an animated GIF showing all the layers in sequence. This turned out to very easy using Google and Python. The Python Image Library (PIL) can make GIF files and I found a script called gifmaker.py which takes a list of images and uses PIL to calculate the deltas and write out an animated GIF.
Enrique fixed the bug very quickly, here is the sliced extruder pump body: -
The red lines are moves without filament flowing (ideally) and the each new section of filament is a different colour.
And here is the same object sliced by the reprap host :-
A side effect of Enrique's algorithm is that the corners get rounded, however I don't think that matters too much because the filament has a minimum bend radius anyway. The main downside is that beanshell script is very slow, so it takes longer to slice than it does to extrude at the moment. A faster PC will probably sort that.
The first object I tried to make was this opto mounting bracket from the RepRap Darwin: -
I choose it because it is small, so does not take too long, but reasonably complex with a horizontal hole. Here is the sliced path from Enrique's script: -
And here is my first attempt at making it: -
This is PCL extruded onto MDF, 0.625mm filament extruded at 10mm/s with the fan on, no interlayer pauses.
A bit hairy due to the extruder not being able to stop the filament flow quickly, but I was quite pleased with it for a first attempt. It is too tall due to a bug in my code and its not the latest version, which has teardrop shaped holes to make the overhangs less than 45°.
Here it is cleaned up a bit: -
It is 50% filled which is probably not appropriate for this size object in PLA but that part is fully functional I think.
Enrique was pleased to see it as he doesn't have a machine to test his code with. A perfect partnership, he writes all the hard bits in beanshell script and I write the easy stuff in Python!
In the meantime Enrique Perez published a plug-in script called Skeinforge.bsh for ArtOfIllusion that also converts 3D objects to G code extruder paths. It is written in the Beanshell script language, which is Java like. I decided to try both approaches, as in theory a G code parser would allow me to use either.
Enrique posted some new scripts that process G code and drive the RepRap hardware using a Python SNAP protocol driver written by greenarrow, so I didn't even need to think about writing a G code parser, I just cut and pasted a few lines from Enrique's.
Before letting it drive my machine I thought it would be a good idea to look at the paths on screen. I knocked up a little script which used my HydraRaptor simulator to draw them. The script is just a few lines of Python that use TkInter.
It was soon apparent that Enrique's code had a bug that left off some of the outline, but apart from that it looked very promising because it has the ability to do sparse infill. That speeds up building objects, saves plastic and reduces warping so it is very worth while. Not only that, it had a novel infill pattern. Instead of parallel lines like this: -
He moves the ends together so that the outer wall is stronger: -
This looks like a good idea because it makes the outer wall effectively two layers thick but probably gives a bit less warping than a second continuous layer would give.
In order to communicate the results to the forums I came up with the idea of making an animated GIF showing all the layers in sequence. This turned out to very easy using Google and Python. The Python Image Library (PIL) can make GIF files and I found a script called gifmaker.py which takes a list of images and uses PIL to calculate the deltas and write out an animated GIF.
Enrique fixed the bug very quickly, here is the sliced extruder pump body: -
The red lines are moves without filament flowing (ideally) and the each new section of filament is a different colour.
And here is the same object sliced by the reprap host :-
A side effect of Enrique's algorithm is that the corners get rounded, however I don't think that matters too much because the filament has a minimum bend radius anyway. The main downside is that beanshell script is very slow, so it takes longer to slice than it does to extrude at the moment. A faster PC will probably sort that.
The first object I tried to make was this opto mounting bracket from the RepRap Darwin: -
I choose it because it is small, so does not take too long, but reasonably complex with a horizontal hole. Here is the sliced path from Enrique's script: -
And here is my first attempt at making it: -
This is PCL extruded onto MDF, 0.625mm filament extruded at 10mm/s with the fan on, no interlayer pauses.
A bit hairy due to the extruder not being able to stop the filament flow quickly, but I was quite pleased with it for a first attempt. It is too tall due to a bug in my code and its not the latest version, which has teardrop shaped holes to make the overhangs less than 45°.
Here it is cleaned up a bit: -
It is 50% filled which is probably not appropriate for this size object in PLA but that part is fully functional I think.
Enrique was pleased to see it as he doesn't have a machine to test his code with. A perfect partnership, he writes all the hard bits in beanshell script and I write the easy stuff in Python!
Subscribe to:
Posts (Atom)