I made a "Magic Spring"(slinky) on a 3d printer.
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
current code, tested, works
Java Source File - 4.99 kB - 03/10/2017 at 13:36
tiny(ir12.5 or17.5) slinky 1mm layer height .35 fudge factor
g - 2.38 MB - 03/10/2017 at 13:25
tiny(ir12.5 or17.5) slinky 0.47mm layer height 0.45 fudge factor
g - 5.10 MB - 03/10/2017 at 13:25
test print with fudge factor of .33 0.7mm layer height
g - 3.38 MB - 03/10/2017 at 13:25
test print with fudge factor of 1 0.7mm layer height
g - 3.40 MB - 03/10/2017 at 13:25
test print with fudge factor of .5 0.7mm layer height
g - 3.39 MB - 03/10/2017 at 13:25
tiny(ir12.5 or17.5) slinky 1mm layer height 0.45 fudge factor
g - 2.39 MB - 03/10/2017 at 13:25
tiny(ir12.5 or17.5) 1mm layer height .55 fudge factor
g - 2.40 MB - 03/10/2017 at 13:25
fixed some error with code, added some comments code now outputs parameters used at top of gcode file. now uses a calculated extrusion factor multiplied by a fudge factor.
Java Source File - 4.98 kB - 03/09/2017 at 16:01
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.