|
maybites
|
||||||||||||||||||||||||||
Sidebar |
KnowHow_MakerBot
Table of contentsIntroductionDuring a Workshop Week above the beautiful lake of Lugano in switzerland I had the chance to test a version of the new MakerBot provided by a friend of mine (I don't own one myself).The following text is a collection of my experiences, condensed into tips, critique and advices. InstallationSince I am a happy OS X user, first I had to struggle with the hiccups of an open-source project that obviously has been developed by linux and window aficionados. True, there are OS X installations, but none of them worked for me out of the box. To make it quick: The following worked for me at the end: 1.ReplicatorG Version 003 (none of the later Versions did the job) 2.Skeinforge that comes with Version 006, but ONLY after I installed the Python Version from http://www.activestate.com/activepython/ 3. I always start it from a Terminal window: cd /Applications/replicatorg-0006/skeinforge/ python skeinforge.py Conversion from SKL to GCODE - FilesThe python Script is tricky and requires the existence of the previously transformed SKL-File, which is not part of the installation. This is obviously a bug and should be fixed as soon as possible (A bug report exists). A way around this is to change the following file - skeinforge has to be run at least once (with a disgracefull exit) in order to create it: /Users/yourusername/.skeinforge/profiles/makerbot_ABS/skeinforge.cvs since the folder .skeinforge is invisible best use TextWranglers function File > Open Hidden... replace the line that looks like: Open File to be Skeinforged /Users/maf/Desktop/workshop/mathias.stl with a path to an existing file. Another point to look at: I used Blender (blender.org) to create 3D Objects, and sometimes I forgot to select the objects before exporting them, so Blender created an empty SKL File, I didn't notice this and Skeinforge just exits without any hint when trying to convert it. PrintingMy first object was a cheap test to see how far the printing process can handle overhanging structures. This is the result:
a cube cut out of a cube. the printout was made as seen, the reason the frontal edge hovers is because I tried to clean away the leftover plastic that was filling the space inside I was impressed, but it looked as if the ABS was pulled away again on very small spots, as the edged seen here:
This effect was not due to the reason I will later observe Next Object was a bit more elaborate: A casing for a fan I took out of an old iBook. I intended to create a cooling fan for the printing head, and I thought it as a first test to see if its possible to print actually something functional beyond a proof of concept.
Fan
Blender Screenshot of Fancasing I step ahead: I was unsuccessful. First it looked all great. I successful printed out the first prototype, which was meant to see if my scaling was correct and if the wall strengths would do. I used a brand new unused white printbed that comes with MakerBot.
Printout of FanCasing The print was perfect, except a shift of the lower layers.
Shift visualized With this success I decided to correct some of the dimensions
Improved Casing For the following steps I have unfortunately made no Pictures, but I try to describe as good as I can. First I struggled to start a clean Print on another (already used printbed). The problem started at the nozzle. The ABS tends to make a little bend right after it leaves the nozzle, and glues itself at the nozzle again. this is almost unavoidable, even when I tried to take away the excess ABS after the testextrusion right before the nozzle touches the printbed in order to start the print. What happened was the following:
the ABS bends as soon as it comes out of the nozzle. then on print-start the ABS doesnt stick enough to the printbed, but keeps sticking to the side of the nozzle. When the nozzle is moving, it pulls off the ABS worm from the printbed (the strange lines are little arrows that indicate the pull-off-force) and creates a honeymoon-festoon. as soon as the next turn comes, the mess is complete I tried to change the GCode File so the printing head has more time to print a clean line of ABS before it starts to print the Raft. and in case a festoon is created, it can be pulled away with a tweezer before the Raft printing starts. My suggestion would be to make this or something similar a standard:
Sketch of an improved Raft. the line should be as long as possible, and printing speed slow, so there is enough time to make corrections with a tweezer With this my success of a clean start was much better, but still, sometimes the print wouldn't stick on the printbed. It looks as if the ABS is not as gluey at the beginning of the process, because most of the time the fist half of the Raft didn't stick, while the second half did just fine. Sometimes the Raft was built up fine, but than another effect came into play: Because I printed a rather large surface (85 x 40mm x 3mm), the heat in the process became a problem. The part started to bend (assumed reason: the ABS tends to loose some of its volume when hardening, shorting the the little ABS worms just enough so tensions can appear). And because the printbed and the ABS didn't stick to each other very well, the Object started to bend on one corner upwards (because of the tension) and so came into the way of the nozzle. The results can be imagined. I heard there are professional machines that work the same way, but heat up the printing space just below the melting point. This way this tensions can be relaxed. But obviously this is no solution for this problem. Now I didn't have any more clean printbeds left and I had to search for another surface that was more sticky, and at the end I found (on another table but mine) 3M IsolationTape (I didn't write down the type, I think it was one that can cope with higher temps) that did the trick. Maybe other IsoTape will work as well, but it has to withhold the 200+ degrees, and that 3M Tape did just that without creating a mess. It does the job even better than the white printbed stuff, because the ABS really sticks to it, and as Tests showed, was even able to keep the forces of the heat tensions at bay.
Copper Bed covered with 3M tape. This tape has even been used multiple times as one can see Now you can imagine the happiness I felt when the printing process progressed so far, that everything looked like a success, especially when 2 full days of try and error lied ahead. But no, another problem came along: THE GCODEMy observation was, that the Gcode produced by Skeinforge is, well, shabby. I do have high regards for those that develop the scripts, because the problems encountered by this task are beyond me. But the Gcode is in my opinion the reason why MakerBot is not a useful tool but a toy. Now what happens: Skeinforge (I wasnt able to test the other Gcode Generator – RepRap Host – because it generates NullpointerExceptions) generates Paths for the nozzle that collide with already printed Paths. This collisions are the reasons for the Shifts (observed as well by Picture 6). And on large surfaces as the example above the effect is even stronger. Makerbot is almost indestructible because it doesn't break if the printing process is obstructed by outside forces, but this flexibility and its inability to know its own absolute position will let this happen as long as the GCODE is not clean. Another observed problem is the layerthickness. There is a way (carve in skeinforge) to set the layerthickness. Obviously it was set to thin for my prints, and I should make some more test with a higher thickness to see if the same problems occur. A better solution would be a measurement tool, that allows to make adjustments after each layer. Easy said – I dont have an idea how to make such a thing on the cheap and precise enough. Overall impression of the makerbotAn excellent toy, just short of being a useful tool yet, but not because of its mechanical and electronic design, but because of the available software and some shortcomings in controlling the printing process to the precision the machine is capable of. |
Sidebar |
||||||||||||||||||||||||
|
Powered by TikiWiki CMS/Groupware v2.3 -Arcturus-
[ Execution time: 0.86 secs ] [ Memory usage: 11.84MB ] [ 72 database queries used in 0.0 secs ] [ GZIP Enabled ] [ Server load: ? ]
|
||||||||||||||||||||||||||