Close
0%
0%

Icepick Delta

A highly experimental open-source 3D printer with a rock bottom bill of materials

ttnTTN
Similar projects worth following
The Icepick Delta is a highly experimental open-source 3d printer that was inspired by the Firepick Delta [1]. It uses a traditional non-linear delta configuration to remove the need for linear rods and bearings, as they are a significant build cost.

The project aim is to build a 3d printer as cheap as possible, using off the shelf parts and as many 3D printed parts as possible. It has been designed from the ground up using Freecad, before any files from the Firepick Delta project were available.


Links to CAD files and firmware can be on the left below.


[1] http://hackaday.io/project/963

Updated 8th Jan, 2019: Fixed broken firmware link.

The design goals of low cost have been met. I think this is about as cheap as one can build a 3D printer. Looking back, going straight from repstrapping to building a printer like this has been very challenging and educational. Lots of fun and learning has taken place. Overall it has been a great learning experience. As the saying goes, everything is hard before it's easy. For example, when I started this project I didn't know how to use CAD. I have definitely learned a lot in the process.

I'll be shelving this project, it has met its goals of being super cheap and printable.

This hasn't been without cost though. Calibration is very tricky. All parts must be produced and measured precisely to be able to print anything at all!
Dialing it in is very time consuming. Calibration is not impossible, it must simply be done in a logical order, making sure at every step that every part is measured accurately.

This leads me to the next design phase. I would like to design a Reprap that is easy to calibrate, has a rock bottom bill of materials, highly printable, and can reprint copies of its own parts. All this while maintaining accuracy of the parts.

I hope you enjoyed reading!

P.S. I have set up a new project page.


Credits

Special thanks goes to Matt Kimbal for teaching me how to use FreeCad. I would also like to thank the Firepick Delta team for inspiring this project. Without you guys this project would not have been.

  • 6 × 608zz bearings +3 bearings if you are using a 3mm filament drive
  • 6 × traxxas rod ends (one set) or use the printable sockets joints
  • 6 × Rods (for arms) I've been using wood rods, old kite rods are perfect for this Carbon fiber is common too, very light but it is costly.
  • 2 × meter of GT2 belt Very cheap. Worth the cost over fishing line and pinion rack drives
  • 3 × 16 tooth GT2 pulley If you order from alliexpress get the from robotdigg. Other sellers sometimes sell you pulleys with 5.1mm diameter holes. Robotdigg set me pulleys that fit snug on the 4.99mm motor shafts.

View all 29 components

  • Careful observations..

    TTN04/05/2015 at 20:20 0 comments

    After the following video was shot, I did some careful stopwatch work and found is actually running at approximately 3.5 times than reported. This means that in the video it is actually running at 56mm/s perimeters and infill at 140mm/s at 1400mm/s^2 acceleration.


    This is because the firmware calculates the speed at the motors, rather than at the end effector. The moves of the print head a proccessed in segments per second. The arduino struggles to calculate more than 40 segments per second due to the math thats required to run this. I plan on moving from Marlin firmware to Repetier firmware as Repetier is written with speed and efficiency in mind. Hopefully this will allow for more segments per second and so more precise movements.


    At speeds over ~50mm/s actual, backlash becomes visible. I think I've identified where it is coming from mainly:

    • Frame flex (lifting the printer onto another bench throws the bed off from level)
    • Flex in the stepper pulley motor shafts, as the pulleys are mounted too far from the motors.
    • Flex in the wood chipboard mounting plate
    • The upperarms are quiet rigid as are the pulley mounts. I think fixing the above mentioned issues will help a lot.

  • Faster Firmware

    TTN01/03/2015 at 11:25 2 comments

    A follow up on my previous project log:

    This firmware hasn't become any faster. The next thing to try is adding inverse kinematics to a firmware that has had performance in mind since its beginnings.

    Teacup and Repetier firmware are both using long ints and ints for all calculations instead of floats, as the avr cpu doesn't have the hardware for doing float calculations so it is much slower. For example, 10,000 float operations of multiplication take 212ms, where as to do them as int's takes only 127ms, much faster.

    I initially wanted to use Teacup firmware, but there is no delta printer support, making the addition of inverse kinematics a lot harder, so, for now I'll see how much faster it will go on Repetier.

    It shouldn't be very difficult to integrate the inverse kinematics function into Repetier, but I'm a c++ noob and have been busier lately, so this may be put on the backburner for a while.

    To be continued..

  • New pulley wheel

    TTN12/20/2014 at 19:52 0 comments

    The original upper pulley wheels where fine, but it was difficult to tension the belt. So I redesigned them:

    The new pulley design has a piece in the lower right section for tightening the belt by screwing in the screw:

    The upperarms are also less prone to catching on the lower arms when homing from varying positions.

  • Arc tangent lookup function

    TTN12/20/2014 at 19:46 0 comments

    After struggling with C code for a while I've managed to make a function which calculates the arctangent value by means of a lookup table, which is much faster than recalculating the arctangent value each time it is needed. But is it actually faster than the arctan in the Arduino library?

    //===================================================
    //==== lookup table for arctan (testing 123..) ======
    //===================================================
    float scale_float = 10.0; // used to increase number of points in LUT_atan array
    const int scale_int = 10;
     
    const int w = 20 * scale_int;
    float LUT_atan_array[w]; // should be 20*scale, but am struggling with the syntax
     
     
    void make_atan_array() {
      for (int i = 0; i < (20 * scale_int+1); i++)
      {
        LUT_atan_array[i] = atan(int(i) / scale_float);
      }
    }
     
    float LUT_atan(float rads_in) {
      float num = rads_in * scale_float;
      int is_negative;
      if (num < 0)
      {
        is_negative = 1;
        num = num - 2*num;
      }
      else
      {
        is_negative = 0;
      }
     
      // pick a point in the array below num and above num
      int X0 = int(num);
      int X1 = X0 + 1;
      float Y0 = LUT_atan_array[X0];
      float Y1 = LUT_atan_array[X1];
     
      // linearly interpolate between points in array
      float slope = (Y1 - Y0);
      float result = Y0 + (num - X0) * slope;
     
      if (is_negative == 1) // if input was negative, make the array output negative
      {
      result = result - 2 * result;
      return result;
      }
      else
      {
      return result;
      }
    }
    
    Writing this in python was easy, doing it in C: not so easy. I found a way to run it against the actual arctangent function and print the values comparing them to serial. It is accurate to 3 decimal places. Timing how long it took to do 10,000 iterations (approximately 130milli seconds on an Arduino Mega 2560) showed that my function was about two or three miliseconds slower per 10,000 iterations than the atan function in the Arduino library, which is dissapointing. This means the Arduino math library is probably already using a similar lookup table method.

    Oh well. Now I know more about C++ and lookup tables :)

  • Firmware

    TTN12/13/2014 at 05:12 0 comments

    Since the Icepick-delta is a true non linear deltabot, it requires some math to move it. It turns out this has done this before (yay!). A big thank you to mzavatsky for writing the inverse kinematics code and bigdaveakers for making it so much easier to incorporate into marlin.

    Replacing the delta functions in marlin_main.cpp and adding defines to configuration.h and we have results!

    #ifdef DELTA
    
    float f = BASE_SIDE;
    float e = END_EFFECTOR_SIDE;
    float rf = DELTA_ARM_LENGTH;
    float re = DELTA_DIAGONAL_ROD;
    
    const float sin120 = DELTA_SIN120;
    const float cos120 = DELTA_COS120;
    
    float x0;
    float y0;
    float z0;
    
    // the function is called with like so at another point for the M665 gcode command: recalc_delta_settings(delta_radius, delta_diagonal_rod);
    // for initial testing, this will be ignored
    
    int delta_calcAngleYZ(float x0, float y0, float z0, float& theta)
    {
    float y1 = -0.5 * 0.57735 * f; // f/2 * tan 30
    y0 -= 0.5 * 0.57735 * e; // shift center to edge
    // z = a + b*y <-- what is this for?
    float a = (x0*x0 + y0*y0 + z0*z0 +rf*rf - re*re - y1*y1)/(2*z0);
    float b = (y1-y0)/z0;
    
    // discriminant
    float d = -(a+b*y1)*(a+b*y1)+rf*(b*b*rf+rf);
    
    if (d < 0) return -1; // non-existing point
    
    float yj = (y1 - a*b - sqrt(d))/(b*b + 1); // choosing outer point
    float zj = a + b*yj;
    
    theta = atan(-zj/(y1 - yj))*(180/DELTA_PI) + ((yj>y1)?180.0:0.0);
    
    return 0;
    }
    
    
    void calculate_delta(float cartesian[3])
    {
    // inverse kinematics: (x0, y0, z0) -> (theta1, theta2, theta3)
    // returned status: 0=OK, -1=non-existing position
    
    float theta1 = 0.0;
    float theta2 = 0.0;
    float theta3 = 0.0;
    
    x0 = cartesian[X_AXIS];
    y0 = cartesian[Y_AXIS];
    z0 = cartesian[Z_AXIS] - DELTA_HOME_POS;
    
    int status = delta_calcAngleYZ(x0, y0, z0, theta1);
    
    if (status == 0) status = delta_calcAngleYZ(x0*cos120 + y0*sin120, y0*cos120-x0*sin120, z0, theta2); // rotate coords to +120 deg
    if (status == 0) status = delta_calcAngleYZ(x0*cos120 - y0*sin120, y0*cos120+x0*sin120, z0, theta3); // rotate coords to -120 deg
    
    delta[X_AXIS] = -theta1;
    delta[Y_AXIS] = -theta2;
    delta[Z_AXIS] = -theta3;
    
    }

    That's a lot of math, just for one segment of a move. The Arduino calculates X number of segments per second, as defined in configuration.h. That's all fine and well, but with this much math, the Arduino can only handle 40 segments per second :(

    At 40mm/sec, it would result in 1mm long segments. Much too large! The regular linear delta firmware such as the Rostock, can manage 200 segments per second on the Arduino mega.

    What to do?

    At this stage, I'm thinking optimize. I found a forum post by Jamesdanielv on replacing the square root function with the one he has posted. He claims it is 3 times faster, and is accurate within 3.5%. As an experiment, I replaced all square root function in the firmware with the faster one, this resulted in a new maximum segments per second: 50. A 20% increase. Not bad. Still far too slow.

    I'm not comfortable replacing all square root functions. I'm unsure that the function will work in all cases after some members commented that it will not work in all cases (buffer overflows or something?). I may do some more investigation and use it later.

    Next up we have the arctan function in the code, perhaps this can be sped up? Doing some googling, it appears a lookup table may be the answer..

    Worst case scenario I could always upgrade to something with an ARM proccessor, but I'm reluctant, after all, the project goal is to develop a reprap with a rock bottom bill of materials.

    To be continued..

  • My Icepick-delta is up and running

    TTN11/30/2014 at 05:51 4 comments

    I got it running! With the help of this link and this link,

    I managed to figure out how to change the firmware to deal with the non linearity of this type of delta (my fork of marlin on github). I haven't yet got bed leveling working, but it doesn't seem to be working on the normal marlin firmware either.

    So far it prints very nicely at low speeds (30 mm/s, 0.1 mm layer height, pla, 0.5 mm nozzle, 3000 acceleration set in firmware) EDIT: Looking back it wasn't actually doing 200mm/sec, as the arduino couldn't calculate the moves fast enough.

    At higher speeds the limitations of the design become apparent ( 200mm/s, 0.2 mm layer height, pla, 0.5 mm nozzle, 3000 acceleration set in firmware)

    EDIT: Looking back it wasn't actually doing 200mm/sec, as the arduino couldn't calculate the moves fast enough.

    The ratio between the steppers and the upper arms is 1:14. Ideally it would be in 1 to 20 - 50 range. As long as the machine runs slow and the microstepping can really make its effects apparent. I wouldn't say that there's any fatal design faults in the icepick, but that 1:14 ratio is a bit of a snag. I have some ideas about using braided fishing line and some very small pulleys, if used, the big pulleys could be much thinner. Another alternative may be to increase the size of the main pulley, and cut off a piece off the bottom which isn't required, but increasing the pulleys may make the design a bit too bulky.

    Ideas are welcome! Leave them in the comments below :)


  • slow going..

    TTN09/27/2014 at 02:08 0 comments

    The semester break has come and gone. I haven't done anymore work on the project. Studies are moving too fast! Meaning I can't spend time on the project. So it will be shelved till further notice. I will definetly complete the project don't worry ;)

  • More Iterations :)

    TTN08/09/2014 at 11:07 0 comments

    Parts arrived sooner than expected! I also got more filament from Diamond Age Solutions so now I can continue.

    Iteration 5 of the pulley belt clamp, I'm only printing a fraction of the pulley to save on printing while I test what works best. I'm satisfied with it. It holds the belt very tight, is robust and easy to print and adjust.

    The upperarms also went through a few iterations and I printed a couple. I'll get some pictures up when I get a complete set.

    As with all my project files for the Icepick Delta, they can be found on the github repository.

    Any questions or suggestions, please do ask!

  • Progress!

    TTN07/14/2014 at 19:30 0 comments

    The target printable area will be at least the standard 200mm cube. The Delta Robot Forward/Inverse Kinematics Calculator has been very helpful. with the configuration as below, we'd will theoretically have a working cylinder of at least 200mm in diameter and 200mm high. That's the theory anyhow, and theory and practice, are too often not the same ;)

    We got most of the cad drawings done. What we have so far is on the Github repository. I'll start printing parts when replacements for my printer arrive in the next few days.

    One thing that we would like to do is replace the standard traxxas rod ends with printable universal joints. I have a few ideas which I will be testing.

    The firepick project calculations came out at a resolution of 0.0201mm when using a 10:1 ratio on the stepper motor to the upper arm which was 100mm long. To get the desired build volume, I had to make the upperarms longer. To maintain accuracy I settled on a ratio of 14:1. Using the accuracy information as above from the firepick project and pulley ratios, the accuracy should be 0.0215mm. When I did the calculations by hand I came out with an accuracy of +/-0.04mm, which should be ok. If my accuracy calculation result of +/- 0.04 mm, which has a generous amount of tolerance, is wrong, and the calculations based on the firepick of +/- 0.0215mm are correct, that would be even better. The catch here is that I am assuming x16 microstepping (on 1.8 degree steppers), which may not actually perform as well as I'd like.

    Special thanks goes to Matt Kimbal for teaching me how to use FreeCad and all his wonderfull input who without this project would not have been.

    I got some of the frame put together over the weekend. The semester has started now, so I expect not to have much time to work on the project. I ordered parts which have an expected arrival time of 20 to 45 days which should be in time for the mid semester break :P


    The frame does have a little flex when force is applied. I might add some reinforcing pieces later.

    Repstrapping with this design shouldn't be too hard, given you have access to a lathe like me. It's an attractive option, as creating round parts on a lathe is not difficult ;) Some bits of custom wood for the upper arm, a printed part for the end effector and motor mounts and I should be all good to go!

View all 9 project logs

Enjoy this project?

Share

Discussions

craig.r.meyer wrote 12/30/2017 at 19:34 point

First of all: I very much admire your ambition and work ethic in making this machine, and making it work.  Thou art indeed the man.

As for for printing accuracy: You've had a couple years to think about it now, and I want to ask you a few questions please.

Today, how much of the IcePick's printing inaccuracy do you mentally chalk-up to the harder inverse-kinematics sticking you with just ~40 segments per second?  

As for tooth-belts, plenty of linear-slide delta-type machines do just fine with tooth-belts, so do you still (partially) "blame" the arms (instead of linear-slides) for its inaccuracy problems?

In general, I'm puzzled as to why there's be so little work being done on delta-arm type machines like this.  I'm not calling the whole world stupid, but I AM genuinely confused as to what their inherent deficiencies -- if any -- might actually be.  So your comments will be very much appreciated.  And thank you.

  Are you sure? yes | no

AVR wrote 10/03/2015 at 02:21 point

Really impressive! Been following for a while watching. Would you say it prints as well as a standard belt-tower delta or better? I'm just curious. I have a Rostock myself.

  Are you sure? yes | no

TTN wrote 10/03/2015 at 05:14 point

I haven't owned a standard delta but the icepick delta prints worse compared to my cartesian printer. The resolution is simply lower with the belt and arm gearing. With the more complex kinematics you have to drop the segments per second from 200 to 40 unless you use something faster than an arduino eg a smoothieboard or something with an ARM proccessor in it so that reduces precission a bit as well. So overall, I'm going to have to say worse. Have you seen the Nelu printer? It's pretty neat I really like what the guy has done with this concept check it out: https://sites.google.com/site/3dneludeltaen/3d-printer/delta-robot-nelu

and: http://reprap.org/wiki/3d_printer_nelu

  Are you sure? yes | no

ekaggrat singh kalsi wrote 04/03/2015 at 12:31 point

wont it be possible to invert the printer and make a simpson style grounded delta. That way you can avoid the wooden frame altogether? 

  Are you sure? yes | no

TTN wrote 04/03/2015 at 21:11 point

That is possible. It would still need a lot of calibration and it is very difficult to calibrate. If I want to go the inverted delta route, I think I would end up pretty close to the current Gus Simpson design given enough time. I want something that is easy to calibrate, cheap, very printable, and self replicating. I've got a new project that will hopefully tick all those boxes.

  Are you sure? yes | no

ekaggrat singh kalsi wrote 04/04/2015 at 02:31 point

sorry for my noobness, but why would invering it require more calibaration than when running it normally?

also where are the cad file can't seem to find them .

  Are you sure? yes | no

TTN wrote 04/04/2015 at 10:56 point

There's a link for the cad files on the left a bit below the pictures. which points to here: https://github.com/TTN-/IcePick-Delta

Inverting it isn't going to affect calibration. Its just that these type of delta's are hard to calibrate in general. I'd like something that is easy to calibrate so I'll move away from the new printer design I won't be using a delta setup like this in my new project. I've made a page for it already: http://hackaday.io/project/4878-reprap-neumann

  Are you sure? yes | no

3dreplicator wrote 01/21/2015 at 23:12 point

A very interesting project, I really liked, I'll repeat it! Already ordered components and printed items. Closely watching the progress. Do not stop!

  Are you sure? yes | no

TTN wrote 01/21/2015 at 23:28 point

Don't worry, I won't! I've got some ideas brewing that I think you'll like ;) I'll write a project log when I've materialized some if it.

  Are you sure? yes | no

Neil Jansen wrote 12/22/2014 at 02:11 point
Hey, this thing looks familar :) I'm the creator of FirePick Delta (http://hackaday.io/project/963-300-pick-and-place-3d-printer). Saw this come in on 3dprint.com, on my Google Alerts.

Really cool seeing that others are using our rotational delta platform and trying to take it in new directions.

  Are you sure? yes | no

TTN wrote 12/22/2014 at 19:48 point

Wow. I wasn't even aware of that article. Thanks for letting me know :) Thats really cool!

  Are you sure? yes | no

gebloom wrote 12/20/2014 at 10:44 point
Hello everybody. Seeing how deep you are into printing and mathematics I really had to to screw up my courage to leave my comment. It is difficult for me to discuss sth. of which I have seen only one 2D photo. Moreover being new to the field of electro mechanical devices and not yet owner of a printer I do not know the market and its parts.
Maybe I am raising a storm against myself yet ...
I wondered upon first sight of your device: Why these arms extending from the big wheels and not just wire running along the rim down to the (sufficiently heavy) extruder and up again? I principally mistrust all joints and cogwheel/rail couplings or such. Usually beams when stepped mean backlash or oscillation and lever length means leverage.
Should not stepper speed be sufficient for lifting and lowering of the extruder?
Is a dedicated stepper or a combo of a linear motor/distance meter (in case a mere speed lift of the extruder were desirable) too expensive?
In any case I would prefer the plate to be moved relative to the extruder (with the asymmetrically induced weight of the dangling power cords and filament).
I principally mistrust all joints (play or insuff. line-up) and cogwheel/rail couplings (possible stuttering(?) of surfaces gliding) or such. Usually beams when stepped mean backlash or oscillation and lever length means leverage.
What are the coil springs near the lever joints for? Do they serve only as a means to prevent a pitching of the wooden levers in their joints? By pulling the levers together they might be skewed.

Is there a video of the printer in motion, detailed enough so one can see how the mechanical parts (wheels,levers) move? Is there a discussion of the construction to be found somewhere?
I wish you success at your endeavour. I'd like to see the icepick rule :)

  Are you sure? yes | no

TTN wrote 12/20/2014 at 19:17 point
You mean like strings coming down from the pulleys? Like this? http://youtu.be/hrsDBdnj5E8
There's a link about 3/4 down the page called project logs here's the link directly: https://hackaday.io/project/1565/logs
The springs on the traxxas rod end joints are to take up the teeny little bit of play they have. This is common practice on delta printers.

  Are you sure? yes | no

gebloom wrote 12/23/2014 at 22:56 point

Hi TTN. Thank you for answering, for the big images, the link to the logs (am new on hackaday) and for not flaming me, for after watching the video of that cable drawing machine I wonder what I may have had in mind in order to reduce the tilting of the printhead which would be inevitable if it merely hung from the ropes. I felt ashamed. Was I even aware of the triangular frame ot your icepick? Yes I should have been and I do not remember now what alternative I had envisioned then.

My vision instead may have been of a rectangular frame with a set of bowden wire fastened to the printhead assembly so that the printhead is pulled down and up by one dedicated stepper "giving or pulling leash" and the two other synchronized stepper(s) securing the orientation of the head and positioning
it somewhere in the plane over the plate.

Not being good at kinematics I can't do a quick sketch and therefore I must leave the wiring schematics to the experts.

I do not know whether wired actuation is even realized somewhere in the Reprap universe (do you?). But I am looking around a bit - about 3 days now ;) - and learning by the hour.

For the time being I know little less than the web images of Prusa i3, Huxley, Ormerod and Rostock - watched an ORION delta video today. Wow! Luv it! - so I now understand your motivation. The deltas are elegant and fast like a mantis!
Oh BTW: I love the levers of the Icepick. I have always cherished the

wooden sticks of New years eve's fireworks.

  Are you sure? yes | no

TTN wrote 01/09/2015 at 11:35 point

Gebloon, about that intersting delta design.. I came accross this, I think you will like it: https://designmakeshare.wordpress.com/2013/09/16/introducing-skydelta/

Found the link in this discussion: http://forums.reprap.org/read.php?178,344022

  Are you sure? yes | no

ekaggrat singh kalsi wrote 12/20/2014 at 02:33 point
is it not possible to use two pulley gear train? that would decrease the diameter of the pulleys and give a higher build height?

  Are you sure? yes | no

TTN wrote 12/20/2014 at 19:09 point
It's one of the things I still want to look into. I don't know how herring bone gears or any sort of gear is going to hold up to constant use and still stay play free, to be researched :)

  Are you sure? yes | no

Jacob Barber wrote 07/21/2014 at 19:41 point
I'd love to help with the programming side of things. Contact me when you're ready to get things going!

  Are you sure? yes | no

TTN wrote 07/24/2014 at 23:53 point
Sweet! Thanks for the offer : )
It seems the firepick team has already implemented the inverse delta kinematics in marlin with auto bed leveling too. I haven't tested it so if I have problems or discover bugs I'll file a bug and maybe we can work on it. Here's the repo: https://github.com/firepick-delta/Marlin

  Are you sure? yes | no

TTN wrote 07/27/2014 at 10:05 point
I might want to look at using the teacup firmware, as it it more efficient than marlin. Teacup firmware has no support for inverse delta kinematics so that's something you could look at implementing. By default, firepick marlin firmware has the delta kinematics the delta_segments_per_second set to 50. I haven't done any tests, but I'm guessing it must be near its limits which is too low for my liking, as it would mean there are 2 mm per segment if its printing at 100mm/sec. I'll have to run some tests some time.

  Are you sure? yes | no

TTN wrote 12/25/2014 at 04:48 point

I just remembered your comment here. Woops. I got most of the software working already. Performance is what I've been trying to inprove. I layed most of it out in this project log: http://hackaday.io/project/1565/log/11869-firmware

Here's my firmware fork of marlin: https://github.com/Laura3/Marlin/tree/Marlin_v1

  Are you sure? yes | no

greyworld wrote 06/23/2014 at 01:08 point
Yeah lets make this thing!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates