Close
0%
0%

3D printed "Magic Spring"

I made a "Magic Spring"(slinky) on a 3d printer.

Similar projects worth following
I wrote a java program to produce the g-code.
printed on "printrbot simple metal"
current print is "sainsmart dark wood fill"(210c)
has been printed with "hatchbox glow in the dark"(180c)
output file is named "auto0.g" because printer will automatically print a file with that name on the micro SD card.
Basically, the printer "zigzags" between an inner radius, and an outer radius while constantly increasing the height.
The factors have been tweaked such that every layer lays on top of the previous one with minimal adhesion(unlike a normal print where settings are optimized for maximal adhesion).
The finished helix sits quite rigid, until the layers are forced apart(fingernail works!)
If anyone tries this print, I recommend cancelling after 4-5 layers and double checking that it will separate, it is frustrating to have a completed print that wont come apart.
I hope the google drive link works(uploaded entire project folder, g-cod


spring3.jar

current iteration of the .jar. removed G29 for compatibility reasons, added offsets for aligning to printable area(go negative to center for a delta, offset of 0,0 will put bottom and leftmost points on zero)

Java Archive - 10.55 kB - 03/26/2018 at 16:35

Download

magspring.jar

standalone version of java program. it's a first step towards not needing to compile every time to change parameters. "java -jar magspring.jar" for people like me that don't know how to get command line java running.

Java Archive - 10.15 kB - 03/10/2017 at 17:57

Download

MagicSpringRev3.java

current code, tested, works

Java Source File - 4.99 kB - 03/10/2017 at 13:36

Download

tiny-035.g

tiny(ir12.5 or17.5) slinky 1mm layer height .35 fudge factor

g - 2.38 MB - 03/10/2017 at 13:25

Download

tiny047-045.g

tiny(ir12.5 or17.5) slinky 0.47mm layer height 0.45 fudge factor

g - 5.10 MB - 03/10/2017 at 13:25

Download

View all 14 files

  • Keeping promises from MRRF

    mpclauser03/26/2018 at 18:42 0 comments

    I had a great time over the weekend at Midwest Rep Rap Fest.  I had some very positive feedback from everyone who saw my slinkys.  

    Brian from "TheMakerHive" gave my code a try.  This marks the FIRST KNOWN TIME someone other than me has produced a slinky using my code(it failed twice, but went long enough before failing to produce a success).  the results, printed in "filablend" samples, are amazing.  Another member of themakerhive(sorry i missed your name) tried on his massive printer, with mixed results.

    I told several people that i would post the latest iteration of the code here, and have done so.  here are some notes on using "spring3.jar":

    It must be ran from the command line(example "java -jar spring3.jar")

    It will ask for several parameters, all are floating point numbers so type in any decimal value and hit enter

    Temperature: is obviously the temperature to print at, it depends on the filament, but i'v used anywhere from 170 to 200

    average radius: the radius(half the diameter) to the middle of the actual plastic.

    width: the width of the actual plastic(will probably end up slightly smaller than this).  aim for no more than 40% of your radius, and no less than double layer height, or 4*nozzle width, whichever is greater.

    layer height: the height of the plastic per revolution, this is different than a normal layer height and more equivalent to a "vase mode" layer height.  setting this at twice the nozzle width seems to give good results and good separation.  i've tried 5* nozel width with poor, but useable results.  im assuming there is an upper limit to how thick a layer can be before the thermal mass starts melthing the layer below it, but have not reached that point yet.

    degrees per zigzag: at the moment this must be calculated, but I've found good results with 2 zigzags(4 movements) per nozzle width, i hope to change this setting to asking for nozzle width and calculating automatically. to run the calculation yourself : movement=2*pi*radius(use average).  for 2 zigzag per nozzle width, movement=(noz/2)*360/(deg/zz)   feel free to vary this, more zigzags takes longer but produces a smoother part.  

    height: overall height of the spring. short(20-30mm) for quick tests(or you can just stop part way through) super tall(100-200mm) for when you rely want to get a working chunk from in between fail points(first 2 layers are almost a guranteed fail, experament with different methods of sepparation, and how well the slinky lies back after.

    offset x/y: these are how far the leftmost point, and bottom point are from 0,0.  make negative to move closer to center of a delta bot.

    fudge factor: used in extrusion calculation. NOTE calculation is wrong, so fudge factor of 0.5 will result in 100% extrusion.  i usually set to 0.45(90%)

    here are example settings:

    temperature: 180  //random cheap amazon filament, found through trial/error
    average radius: 10  //rather tiny for anything useable, but good for a test
    width: 4 // rather wide for this radius, going to be a realy stiff spring
    layer height: 1  // may be pushing 
    degrees per zigzag: 1  // realy the calculation i punch into google is 20*pi/0.4=157 this is how many nozel widths it would take to cover the circumference of the slinky, i want twice this many so 314,  close enough to 360, so i put 1 degree per zigzag to give 360 zigzags per rotation.
    height: 100  //rather large for a test, may cancel depending on how it goes
    offset x: 20
    offset y: 20  //my PEI sheet is smaller than the default print bed, so i've got it on at an angle, and it dosent come down to the corner.  this makes certain it will not go off my bed.
    fudge factor: .45  //90% extrusion factor

    settings for the one i printed several times at MRRF

    temperature: 170  //crazy cold
    average radius: 30  //about palm sized
    width: 5  //just looks right
    layer height: 1  //again just looks right
    degrees...

    Read more »

  • Accomodations

    mpclauser03/11/2017 at 04:49 0 comments

    To anyone who would like to try this print, but has a printer with special needs, post in the comments, and i will be happy to try and adjust my code for your printer.

    some things that i know may cause issues:

    my vertical axis is Z, some printers label the vertical axis Y. I find this annoying about minecraft, but understand the design logic of Z coming out of a blackboard, rather than off a sheet of paper. I'm happy to create a y-vertical version of the code if people show an interest. In the meantime, the currently available code should be easy to adjust for this type of printer: open the code in editor of choice, find-replace ALL no quotes "Y" with "Q", than "Z" with "Y" and finally "Q" with "Z".

    my zero point is at a corner, and all axis move positively away from that point, i believe some printers(i know the makerbot for one) have 0,0,0 in the center of the buildplate, and x and y can both be posative or negative. for smaller springs, this still works, and just shifts where the print is positioned. for larger springs, this may attempt to push past the boundries of the printer. the solution is a simple edit in the source code, removing the offsets, however editing the pre-produced gcode would be a nightmare(unless you made a scrypt to read values and subtract the offset back out)

    any other discrepancies between the way my code operates, and the way your printer is designed, I make no promises, but i'll be happy to look into possible modifications.

  • "Layer height"

    mpclauser03/10/2017 at 16:02 0 comments

    A note on what i refer to as layer height;

    Cura would say my print is 1 layer tall(it only checks comments for layer:X)

    Repetier-Host will say my print is tens of thousands of layers tall(it counts every increse in Z as a layer(i assume for the printers with y as vertical, it coutns Y))

    I say my print is 150 layer tall(i count a layer as a full rotation of the helix, or one separate cross section)

    so, when I say my layer height is .47, I mean that if one "layer" of the slinky is measured it should ideally be .47mm tall(i'm getting a bit more than that, it's not completely flat across the layer)

    The plastic is actually adhering to the path extruded immediately before it, and not(hopefully) to the previous "layer", so maybe Repetier is the most right, and my layer height is actually 0.000648mm

    I have printed 1.5mm tall layers of the slinky with a 0.6mm nozzle and it looks good



    so, even though the layer height seems a bit extreme for the nozzle size, nothing about this print conforms to traditional slicer logic.

  • Confession Time

    mpclauser03/10/2017 at 13:58 0 comments

    So, while it's a good idea to clean up code, and add comments before letting the public criticize it, it is a BAD idea to write the code from scratch, and and upload it for the public before you have tested it.

    I have uploaded the fixed code to the files here, I have updated my google drive.

    I have uploaded multiple example codes, most of which i have tested(at least for the first 4-5 rounds) and they separate with little to no trouble.

    SORRY to all those that wasted filament on my broken code.

    here are 3 tiny test prints when i was working on the fudge factor. from left to right they are 1.0, 0.5, 0.33

    they have all been printed at 0.7mm layer height, average radius of 20mm and width of 3mm, and delta of 1

    1.0 has been lost, but i believe it measured more like 6mm width, no chance of sepparation

    0.5 is a touch oversize 3.5mm, separated well

    0.33 (actually calculated/3, but close enough) too small 2.4mm width, separated as i pulled it off build plate.

    the fact that my calculated extrusion factor is so much more than necessary leads me to believe there is a large error somewhere in my code, but for now i'll just stick to a fudge factor of 0.45 and go on with life.

  • printed large spring

    mpclauser03/09/2017 at 16:20 0 comments

    last night I printed this behemoth. it was still printing this morning, but the printer was much closer to the max height than repetier thought it was, I'm wondering if I need to calibrate the printer.

    there are some flaws noticeable in the photo, but overall it printed fairly nice.

    width should be 4mm(inner radius 36, outer radius 40) but actually measures just over 3 for most of the print. i'm blaming this on too small of an extrusion factor, it's clearly moving 4mm, but edges are pulling back.

View all 5 project logs

Enjoy this project?

Share

Discussions

jpickens wrote 04/27/2018 at 04:01 point

Success!!!

Thanks to Michael for the help getting my Javascript sorted.  This is a slightly modified gcode print which Michael sent me.  I have since been creating new sizes of springs using the Java code.

Here is a video of my experiences with the Magic Springs

https://youtu.be/lZsZwM0scjY

  Are you sure? yes | no

Juan Garcia wrote 05/20/2017 at 13:28 point

I noticed the default value assigned to your extrusion factor variable `extr`  at the top isn't being used anywhere since you reassign `extr` with `ecalc * fudge`.

Just wondering if that default value was old code, or if it's meant to be used somewhere before being overwritten later, and maybe that was deleted by accident?

  Are you sure? yes | no

mpclauser wrote 05/20/2017 at 15:17 point

extr setting was old code, that's the value that printed my first slinky. Poor coding to leave it there, but it brings back memories of twerking it every time till it was just right. And fudge is always under .5, because my calculations assume a radial progression with every movement(triangle wave), while the actual code only progresses every other movement(sawtooth wave).

  Are you sure? yes | no

Juan Garcia wrote 05/27/2017 at 11:58 point

Cool, thanks!

Side question: I'm trying to understand the extrusion value for `G1`. After reading the docs http://reprap.org/wiki/G-code#G0_.26_G1:_Move I was under the impression that the extrusion amount would be a fixed value, calculated by the length of the segment zigging or zagging between `ir` and `or` (the the amount of plastic to lay down from the previous G1's end to the end of the current G1). But in your source and other gcode examples, it's steadily increasing for each `G1`.

Clearly it works (already have a bunch of slinkys printed), so I'm not debating that. I guess I'm just looking for insight since it seems counter-intuitive to me.

  Are you sure? yes | no

Chris Mitchell wrote 03/10/2017 at 11:44 point

Wow ok my 1st, 2nd and 3rd attempt at this does not look like your article pic :(

Actually it's just all fused together and no where near as smooth as yours. if i back off the extrusion multiplier it starts curling up and printing rough. more experimentation (and beer) required!
What kind of printer / material did you use ?
Do you normally print first & subsequent layers at 0.47mm ?
What's you nozzle width?

  Are you sure? yes | no

Chris Mitchell wrote 03/10/2017 at 11:49 point

Oops, after re-reading your project text..no need to reiterate printer / material hehe.

But i am still curious about the nozzle width and your normal layer height that you print at. 0.47 seems a bit extreme but i guess you came to that figure after *some* experimentation :)

  Are you sure? yes | no

mpclauser wrote 03/10/2017 at 14:15 point

I posted bad code SORRY! new files uploaded, old ones are still here as a monument to my stupidity. 

the height of .47 was actually worked out from my original code(before the bad code i uploaded), had layer height set at "0.7", but was using separate numbers for angle per zigzag, and zigzags per layer, my calculations were off(0.5 degrees and 1080 per layer) obviously this gave me 2/3 of my intended layer height.  at the time, it worked because i was just adjusting factors until i got what i wanted, but it would confuse anyone who tried to read through my code. the new code calculates movements per layer based on degrees per movement.

0.47 may seem like too big a layer height(especially when i was originally printing with a 0.4mm nozzle) but remember that most of the plastic is intended to stick to the previous movement, and not the previous layer.

Now that I am using a calculated extrusion factor rather than an absolute factor, that constantly needed adjustment, I have printed a whopping 2mm layer height that looks great(with the 0.6mm nozzle)

think of it less as a 0.47mm layer height, and more as a 0.47/720 layer height, with only 2 movements per layer.

  Are you sure? yes | no

Chris Mitchell wrote 03/11/2017 at 02:15 point

All good buddy :)
I know how these things tend to go hehe, it's been a fun experiment so far with some encouraging results. I'll check out the new code and files, thanks for updating the project :)
I might just have see what it does with a 0.8mm nozzle too

  Are you sure? yes | no

mpclauser wrote 03/07/2017 at 16:19 point

thank you for the info Clayton, the link was helpful

I've tried several more attempts with PETG, I believe my filament has absorbed moisture, the print is brittle(partially due to low print temp) , and makes snapping sounds when printing. I'm going to put this one on the back burner while until I can get it dry. Onward to adjusting the parameters for a bigger PLA slinky.

  Are you sure? yes | no

Clayton G. Hobbs wrote 03/06/2017 at 17:46 point

Pretty neat!  I accidentally made something like this once.  My first PET test print was a hollow cylinder, sliced with the spiral vase setting.  The temperature was too low, so the layers separated, leaving me with a nice little Slinky.  Cool to see someone doing it on purpose!

  Are you sure? yes | no

mpclauser wrote 03/06/2017 at 18:00 point

What temp were you printing? I've tried PETG a couple times, it's fused together quite securely(of course, when I want PETG to fuse, it will not)

  Are you sure? yes | no

Clayton G. Hobbs wrote 03/06/2017 at 19:11 point

I don't remember with any certainty, as it was a couple years ago.  It
might've been 212 °C though, looking at the correction to a typo on
Taulman's website: http://taulman3d.com/t-glase-features.html

  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