I made a "Magic Spring"(slinky) on a 3d printer.
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
deltaspring.jarspring centered on origin(0,0) for delta style 3d printersJava Archive - 2.89 kB - 07/05/2023 at 14:00 |
|
|
Spring.java2023 updated source code. Cleaned up by thinking in radians instead of degrees. Read notes for slinky.jar for some more changes.x-java - 4.15 kB - 06/25/2023 at 10:25 |
|
|
slinky.jarNewer code, includes a spiral for priming/adhesion printed at 210 before cooling extruder down to target temp during print. Now asks for zigzag per nozel(assumed 0.4mm) instead of degrees per zigzag recommend starting at 2. Asks for extrusion multiplier instead of fudge factor, multiply old fudge by 2, or start somewhere around 0.8-0.9java-archive - 2.89 kB - 06/25/2023 at 10:09 |
|
|
spring3.jarcurrent 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 |
|
|
magspring.jarstandalone 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 |
|
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...
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.
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.
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.
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.
Create an account to leave a comment. Already have an account? Log In.
Just saw your work at MRRF2023. Awesome job! Is it possible to generate gecode to be centered on origin (X0, Y0)?
added "deltaspring.jar" that centers on 0,0 for delta printers. I'm trying to keep the number of variables down for ease of running, would appreciate anyone's input as to whether things like offset need to be included in every revision, or would be better off as one-off versions of the code.
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
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?
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).
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.
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?
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 :)
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.
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
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.
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!
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)
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
Become a member to follow this project and never miss any updates
will this work with bed levelling kits like the CR-Touch?