krys
-
Posts
820 -
Joined
-
Last visited
-
Days Won
10
Content Type
Forums
Events
3D Prints
Posts posted by krys
-
-
Hi folks,
I have recently upgraded my UM2 with the extrusion upgrade kit.
Something I have always wanted to do was to print in polycarbonate at higher temperatures. I have successfully done the Labern fan shroud in PC at 260 degrees and it works great (no warping), but for stronger parts I believe I need higher temperatures.
Others have done higher temperatures, but I want to confirm current knowledge/wisdom.
From my reading, the new TFM coupler is much better at high temperature, and I think the TinkerGnome firmware will let me set the nozzle temperature up to 300 degrees, so my questions are these:
1) Are my assumptions above correct?
2) Is TinkerGnome's firmware now stable and working with UM2+ (and upgrade kit)?
2) Should I also get an I2K, or is that no longer necessary?
3) If so, should I also get a shorter TFM so the spacer still works?
4) Would I need anything else?
5) Should I be concerned with anything else?
6) Any tips on getting PC to stick? (I used crazy glue on kapton tape and that worked sorta okay but still warped a bit.)
Any insights would be much appreciated. Thanks very much.
-
Hi Folks,
It's been a long time since I have been on the forums. I love my printer though!
I have recently installed the UM2 extruder upgrade kit, but I cannot seem to find the '+' stickers. Either my kit did not include them, or (more likely), I have misplaced them, though I have looked all over and cannot find them.
I know it is a little thing and completely inconsequential, but it is really bugging me to not have the silly little '+' symbols.
Is there any way I could get new stickers sent to me?
My upgrade kit is from shop3d.ca. The printer was built by fabrc8. ... If that matters.
Thanks very much,
Krys
-
Hi there,
Izzy just posted these: https://www.youmagine.com/designs/wire-retainer-clip
I printed them and they work great.
It is a small thing, but very convenient.
-
Krys: Thank you very much for introducing me to this thread
No problem! I just figured you might have been interested in the reasoning behind my mucking about.
Thanks again. Welcome!
-
Just a note that your Thingiverse link is broken, it looks like you included some text inside the URL.
Fixed. Thanks!
-
Okay, I have post up my version on Youmagine at: https://www.youmagine.com/designs/openscad-metric-nut-bolt-threads-library.
It should have everything needed to just use the library.
I also posted a remix on Thingiverse at: http://www.thingiverse.com/thing:742847, but it just points to the Youmagine version.
Finally, I posted a comment on TrevM's original (updated) version, letting him know what we have been up to and inviting his feedback.
So with all this done, other than any continuing conversation on this thread or with TrevM, I think I am done with threads.
Thanks again to all who help and especially to DonMilne. It is really appreciated.
I hope my changes are useful to others.Edit: Fixed broken URL. Thanks DonMilne!
-
1
-
-
Rendering: Yes, full render for export. Edit code, clear cache, F5 preview, F6 render, measure time. I guess my laptop is just really good at 3D rendering.
Threads peeking out: Yeah, even with different $fn for the cylindar, I think it is just a visual glitch in OpenSCAD. When I load the STL in Cura, the cylinder is always smooth. (Er... I think. I should probably verify that.)
@Luke: Thanks! It is really mostly the hard work of TrevM on thingiverse. We just tweaked a few things and tested stuff.
-
Okay, so I think I have finished tweaking TrevM's library and it now works really well.
Once I realized that he had a bunch of fudge factors (tweaked offset numbers) in there, probably to make things work on his printer (Makerbot?), then I decided to take them all out and see what I got. What I got were bolts that worked perfectly! I had to widen the nut hole diameter a bit, that is now the only fudge factors in there now.
The results speak for themselves:
(Printed on UM2, Normal quick profile. = 0.1mm, 20% infill, and something effectively a bit less than 50mm/s.)
And they are neither too tight, not too loose.
I had also tested the original library against OpenSCAD 2103.01, but the results were the same. So, the issues are not due to changes in OpenSCAD. As I said, I just think TrevM added fudge factors to make things work on his printer, and I guess his slicer smooths over the gaps.
(Patch & edit instructions at the end of this post)
Anyway, I then went back to DonMilne's thread test code, trying different things to compare speed and results. Here are the render times I got, with a cleared cache between each render:
-
Original 2012 library: 30s
-
Unmodified New library: 1m 2s + threading issues on cylinder
-
My Tweaked UM2 library: 51s + threading issues on cylinder
-
My Tweaked UM2 library, $fn=30 instead of $fa & $fs: 51s + threading issues on cylinder
-
My Tweaked UM2 library, cylinder r=6 instead of 5.8: 52s + no more visual issues
-
My Tweaked UM2 library, $fn=30, r=6: 55s
-
My Tweaked UM2 library, r=6, override library and cylinder to $fn=60: 1m 51s
-
My Tweaked UM2 library, r=6, override $fn=12 to match 2012 library: 24s
From this, I cannot really tell if the new library is really that much faster, given roughly the same settings. But regardless, being able to use the newest version of the library with adjustable heads and the ability to specify our own $fn is still good.
Here are some OpenSCAD 2015.03 renderings of $fn=30 and $fn=60:
And here is how Cura 15.02.1 sliced them:
$fn=30:
$fn=60:
As one can see, $fn=30 seems sufficent for nice results. More than that is probably overkill.
Here is my updated version of DonMilne's Tread Test.scad code that I used to test and generate the above:
/* Thread test */
//use <ISOThread/ISOThread_20120823.scad>
//use <OpenSCAD_ISO_metric_thread_library__functions_updated/ISOThread.scad>
use <Metric_Nuts_and_Bolts_UM2/ISOThreadUM2.scad>
/*......................................................*/
module main()
{
dia=6;
fn=30; // 30, 60, 12
wrench=0;
hex_bolt(dia,34,$fn=fn,WrenchSizes=wrench);
translate([dia*3,0,0]) hex_nut(dia,$fn=fn,WrenchSizes=wrench);
translate([-1*dia*3,0,0]) hex_nut(dia,$fn=fn,WrenchSizes=wrench);
translate([0,0,3]) cylinder(r=dia/2,h=23, $fn=fn); // r=5.8
}
/*......................................................*/
//$fs=0.4; $fa=2;
main();So that is what I have got. I don't know if my changes are *correct* per Metric Standards, but they seem to work, at least on M6. I did not have other sizes in steel to further validate.
I will also try to put up my updated version of the library as a remix and try to contact TrevM to let him know what I have done. Luckily he was nice enough to make his code Public Domain.
Lastly, I did also try some a library at https://github.com/JohK/nutsnbolts, but neither of them would print well with my minimal testing, so I went back to TrevM's code.
Okay, enough talk, here is the patch to TrevM's updated library to work on UM2. I hope it is useful to others. After all this, I think I am pretty much done with threads and nuts and bolts!
@DonMilne: If you have any troubles with my updates, let me know and I will help however I can.
Patch:
--- /home/krys/3D Printing/My Things/Metric_Nuts_and_Bolts_UM2/ISOThread.scad
+++ /home/krys/3D Printing/My Things/Metric_Nuts_and_Bolts_UM2/ISOThreadUM2.scad
@@ -123,7 +123,7 @@
translate([0,0,tn*p]) th_out_turn(dia,p,thr);
// do remainder
for(sg=[0:n])
- th_out_pt(Rmin+0.1,p,s,sg+(t*thr),thr,h,p/thr);
+ th_out_pt(Rmin,p,s,sg+(t*thr),thr,h,p/thr);
}
module thread_in_pitch(dia,hi,p,thr=$fn)
@@ -200,7 +200,7 @@
difference()
{
cylinder(r = rolson_hex_nut_dia(dia)/2,h = hi, $fn=6);
- translate([0,0,-0.1]) cylinder(r = dia/2, h =hi + 0.2);
+ translate([0,0,-0.1]) cylinder(r = dia/2+0.1, h =hi + 0.2);
}
translate([0,0,0.1]) thread_in(dia,hi-0.2);
}
@@ -213,7 +213,7 @@
difference()
{
cylinder(r = fairbury_hex_nut_dia(dia)/2,h = hi, $fn=6);
- translate([0,0,-0.1]) cylinder(r = dia/2, h =hi + 0.2);
+ translate([0,0,-0.1]) cylinder(r = dia/2+0.1, h =hi + 0.2);
}
translate([0,0,0.1]) thread_in(dia,hi-0.2);
}
@@ -228,7 +228,7 @@
Rmin = (dia/2) - (5*h); // as wiki Dmin
s = 360/thr;
for(sg=[0:thr-1])
- th_out_pt(Rmin+0.1,p,s,sg,thr,h,p/thr);
+ th_out_pt(Rmin,p,s,sg,thr,h,p/thr);
}
module th_out_pt(rt,p,s,sg,thr,h,sh)
@@ -242,7 +242,7 @@
// sh = segment height (z)
{
as = (sg % thr) * s; // angle to start of seg
- ae = as + s - (s/100); // angle to end of seg (with overlap)
+ ae = as + s; // angle to end of seg (with overlap)
z = sh*sg;
//pp = p/2;
// 1,4
@@ -294,7 +294,7 @@
// sh = segment height (z)
{
as = ((sg % thr) * s - 180); // angle to start of seg
- ae = as + s -(s/100); // angle to end of seg (with overlap)
+ ae = as + s; // angle to end of seg (with overlap)
z = sh*sg;
pp = p/2;
// 2,5Or, instructions:
Change line 126 from:
th_out_pt(Rmin+0.1,p,s,sg+(t*thr),thr,h,p/thr);to:
th_out_pt(Rmin,p,s,sg+(t*thr),thr,h,p/thr);Change line 203 from:
translate([0,0,-0.1]) cylinder(r = dia/2, h =hi + 0.2);to:
translate([0,0,-0.1]) cylinder(r = dia/2+0.1, h =hi + 0.2);Change line 216 from:
translate([0,0,-0.1]) cylinder(r = dia/2, h =hi + 0.2);to:
translate([0,0,-0.1]) cylinder(r = dia/2+0.1, h =hi + 0.2);Change line 231 from:
th_out_pt(Rmin+0.1,p,s,sg,thr,h,p/thr);to:
th_out_pt(Rmin,p,s,sg,thr,h,p/thr);Change line 245 from:
ae = as + s - (s/100);to:
ae = as + s;And lastly, change line 297 from:
ae = as + s -(s/100);to:
ae = as + s;(If you are reading this, you totally rock the marathon forum post!)
-
Original 2012 library: 30s
-
@VISU-AL:
That is really helpful!
If/when I play with Blender again, this will be convenient.I think it will serve as a decent reference for the future. (Search keys: blender nut bolt metric threads)
Thanks very much!
-
As for your long render, during my experimenting, when I had something non-manifold (not one solid part), the render took a long time and then warned me about it. Maybe something similar happened to you.
-
Hi DonMilne,
Okay, I will put it in words. (I am also a Windows coder by day, but Linux lover by night.)
Take the updated/current ISOThread.scad and make the following edits:
Line 126, in thread_out_pitch(), change:
th_out_pt(Rmin+0.1,p,s,sg+(t*thr),thr,h,p/thr);To:
th_out_pt(Rmin-0.1,p,s,sg+(t*thr),thr,h,p/thr);Line 231 in th_out_turn() change:
th_out_pt(Rmin+0.1,p,s,sg,thr,h,p/thr);To:
th_out_pt(Rmin-0.1,p,s,sg,thr,h,p/thr);Those 2 make the bolt threads touch the cylinder. I did not change the nut threads as they are already touching the nut and the tolerances seem okay.
Next,
Line 245 in th_out_pt() change:
ae = as + s - (s/100);To:
ae = as + s + (s/100);This one makes the bolt thread segments overlap properly.
Line 297 in th_in_pt() change:
ae = as + s -(s/100);To:
ae = as + s +(s/100);And this one makes the nut thread segments overlap properly.
That it. Save the changes and enjoy!
I hope this helps.
-
(Also, it seems I am incapable of writing a short post!)
-
Hi folks,
Okay, so I did a bunch of testing and tweaking and code spelunking this weekend. I have made progress and fixed all but 1 issue with the newest/current version of TrevM's library. Patch below.
But first:
@Daid: I really like your solution! it is clever and elegant. Unfortunately:
- I have no idea how to turn it into a Metric Standard compatible library (or even make any real changes, I am not 3D modeller or engineer),
- I don't really want to build a whole new library around it or manually build nuts and bolts in multiple steps, and
- My test print of the threads seemed a bit thick and saggy (but that is probably my newbie-ness showing.)
... So I kept poking at TrevM's code.
@Anders: Agreed. Daid's code makes nice smooth threads and you have identified one of the issues with TrevM's code that is core to the problem. ... I fixed that though.
@VISU-AL: That's really great to know. I have only barely poked at Blender. I am glad there is support there. But I am really enjoying OpenSCAD right now and have kind of sunk my teeth into getting something working with it. I also wonder if there is a FreeCAD library for doing threads around. I would assume so, but I don't know.
@DonMilne: I did not poke too much at Daid's code to see how it performed if longer. But from just my cursory poking, it seems like it is a slower. Though I would have thought it should be faster because of fewer distinct objects to render. I could be totally off base here though.
Okay, with specific responses done, here we go with my experiments and results:
So, I did a diff of the old-but-working version of TrevM's library (hence forth called just 2012), and the current updated version (hence forth called Updated). Once I saw what changed, I started poking at Updated to see if I could get the same results. It seems like TrevM made the original version, then branched off with 2012, then updated Original to Updated and forgot about the 2012 changes. Or possibly 2012 was original and then he switched away from that design, which would make more sense.
There are 2 issues that both Original and Updated have:
- The central shaft cylinder does not contact the thread segments. (Hence the blobbing I experienced.)
- The thread segments do not touch each other. (Hence the jagged slicing in Cura.)
In the code it seems like there are plus-a-bit values when there should be minus-a-bit values and vice versa.
So for #2, I first tried just cranking up the number of cylinder faces and thread segments, but that gave only lackluster improvement and destroyed all performance gains. Then I reversed some signs on the appropriate minus-a-bit values and the thread segment spaces went away. The nuts and bolts now print practically perfectly. Even at $fn=30.
As for #1, there are, as I discovered, 2 solutions: a) Move the threads in to touch the cylinder, or B) widen the cylinder to touch the threads.
When I did #a to the bolt, everything worked, no nut changes necessary. Yay solved! ... or not. It turns out that this makes lovely nuts and bolts that work together flawlessly. But when I test against my steel "real" M6s, the steel nut works on the printed bolt, but the printed nut does not work on the steel bolt. It's too tight. Way too tight.
When I did #b, however, the printed nut now worked on the steel bolt, but the steel nut would not work on the printed bolt. Though the printed nut worked on the printed bold nicely.
So to sum up, I have a patch that lets us use the nice, fast Updated library with smooth threads and no blobs. It just will not play nicely with steel. So, the library is almost-but-not-quite Metric Standard compatible.
(The ones at the back are just with high facet/segment count. The ones at the front are with the patched code #a and #b.)
I suspect that a happy medium can be found by playing with those tolerance values. I will keep poking.
I also have not yet tried to contact TrevM (which would have been an obvious first step!), and I still have no idea why his code works for him and not me. ... Unless it an OpenSCAD issue, or he is using a more forgiving slicer, or he is not using the code he published and did not publish what he actually uses. :(
Anyway, here's the patch. Hope it is useful to someone. If I get the steel-compatibility issue resolved I will post another patch. And I will take this all back to TrevM and see what he says.
Thanks to everyone for the help and suggestions!
The patch:
----
--- /home/krys/3D Printing/OpenSCAD Libraries/OpenSCAD_ISO_metric_thread_library__functions_updated/ISOThreadOriginal.scad
+++ /home/krys/3D Printing/OpenSCAD Libraries/OpenSCAD_ISO_metric_thread_library__functions_updated/ISOThreadSmaller.scad
@@ -123,7 +123,7 @@
translate([0,0,tn*p]) th_out_turn(dia,p,thr);
// do remainder
for(sg=[0:n])
- th_out_pt(Rmin+0.1,p,s,sg+(t*thr),thr,h,p/thr);
+ th_out_pt(Rmin-0.1,p,s,sg+(t*thr),thr,h,p/thr);
}
module thread_in_pitch(dia,hi,p,thr=$fn)
@@ -228,7 +228,7 @@
Rmin = (dia/2) - (5*h); // as wiki Dmin
s = 360/thr;
for(sg=[0:thr-1])
- th_out_pt(Rmin+0.1,p,s,sg,thr,h,p/thr);
+ th_out_pt(Rmin-0.1,p,s,sg,thr,h,p/thr);
}
module th_out_pt(rt,p,s,sg,thr,h,sh)
@@ -242,7 +242,7 @@
// sh = segment height (z)
{
as = (sg % thr) * s; // angle to start of seg
- ae = as + s - (s/100); // angle to end of seg (with overlap)
+ ae = as + s + (s/100); // angle to end of seg (with overlap)
z = sh*sg;
//pp = p/2;
// 1,4
@@ -294,7 +294,7 @@
// sh = segment height (z)
{
as = ((sg % thr) * s - 180); // angle to start of seg
- ae = as + s -(s/100); // angle to end of seg (with overlap)
+ ae = as + s +(s/100); // angle to end of seg (with overlap)
z = sh*sg;
pp = p/2;
// 2,5(If any non-coders need help understanding this, please say so and I will post a human-friendly explanation.)
- I have no idea how to turn it into a Metric Standard compatible library (or even make any real changes, I am not 3D modeller or engineer),
-
Agreed. I will poke at Daid's and TrevM's code this weekend. It is also good to know that there is an alternative with Blender, but I am really liking OpenSCAD right now and want to get something there to work well and reliably.
Daid, do you mind if I make a new library using your code? I would post it as open source and credit you, of course. I don't know if I will go down that path, but if I do, is it okay with you?
I will also likely try to contact TrevM for his thoughts/insights. And I think I will revisit the other library I tried first to see if I can get different results now. It had some nice features that TrevM's code does not. (Bolt head size controls, etc.)
I will keep you all posted! Thanks again for the great ideas!
-
Okay, so DonMilne sent me his original files, so I did some comparisons.
Using his settings from is gcode file, and slicing his original STL in Cura, the threads look like they would work.
Even regenerating the STL from the SCAD and slicing it seems to be correct. So definitely the older ISOThread_20120823 library works properly.
I then tried updating his origial Thread Test SCAD to use the new library. I can post the updated code if DonMilne is okay with that. Otherwise PM me.
What I changed was the following:- Changed the library to the updated one.
- $fn=45 is about equivalent to $fs=0.4; $fa=2, so I changed that.
- The new library defaults to $fn=30 and uses that for the cylinder and number of thread segments.
- The original library, for an M6 used 12 facets for for the cylinder and 12 thread segments.
- The original library dynamically looks up a good $fn number to use based on diameter.
- The new library does not. :(
- To force the new library to render like the old one, pass an explicity $fn into the module call. (i.e. hex_bolt(6, 34, $fn=12). This way you can have your global $fn be whatever you want.
- Doing the above seems to create threads like the older library.
- Hoever the threads also seem to be wider in the new library, so DonMilne's additional plain cylinder had to be widened from 5.8 to 6.2 mm to acheive the same effect.
- I pulled out TrevM's old quality lookup function and put it in Thread Test and used it to figure out the best $fn.
- Rendering this updated STL and slicing it in Cura (still with DonMilne's original settings from gcode), gives this:
This looks like my other previous failures. So I think the new library is the source of the issue, perhaps regardless of $fn value.
After this, looking really closely at the model in OpenSCAD, it seems that the old library puts the thread segments right against, touching, the shaft cylinder; but the new library leave a very small space. The threads are not actually touching the shaft! :(
I think that is the problem. I think that might also explain the seemingly wider threads that required the widening of the plain cylinder. I do not know if changed to $fn impacts or Cura's slicing here or not. Maybe higher $fn is fine, but the thread seperation from the shaft is the issue.
I don't yet know why the new library puts that extra space, but I think it is a mistake. I will look at it more closely tomorrow.
... I wonder maybe it is an incompatiblity with OpenSCAD 15.03, which I have, versus 14,xx. Hmm...
Anyway, this is what I have figured out so far. I hope it helps. I will continue this adventure tomorrow.
Thanks very much DonMilne for all your help. You rock!
- Changed the library to the updated one.
-
Here are the pics.
The fails:
One can see the issue with the way Cura 15.02.1 slices the threads. They print like that too. lob, blob, blob. Not continuous.
The success:
Lower shaft side count and lower thread segment count leads to better/smoother slicing.
I hope this helps others trying to print threads!
-
Okay, so based on what has been said here, I did some more testing:
- I tried more of DonMilne's mentioned settings.
- I tried the older library.
- I tried M12 instead of M6.
- I tried DonMilne's $fa and $fs.
- I tried larger and smaller $fn.
- I tried the Default profile in Expert mode. (Which is different than the Normal quickprint profile.) O_o
- I scaled an M6 up 200% in Cura.
- I tried different temperatures. (I was using 215 for the UM Silver) (Tried 200 and 190).
- I switched to ColorFabb Ultra Marine Blue PLA/PHA (brand new!). Tried the M12 and 200% scale.
- I compared various combination of the Fix Horrible settings.
*None* of that changed anything. :(
I was pretty much ready to throw in the towel here. And I super was bummed about it.
However, some observations and some learning:
- The new library sets $fn to 30 as a global setting.
- To override it, you need to pass $fn into the module call as an argument.
- If $fn is set, $fa and $fs are totally ignored. (That's in the docs.)
- Forcing $fn=0 lets you use $fa and $fs again.
- The old library does not set $<anything>.
- DonMilne's $fa and $fs settings seem to be about equal to $fn=60.
- For me 215 C seems to give better bare-glass bed ahesion over 210 C.
- Both the old and new libraries leave small spaces between each thread segment and also between the threads and the shaft. I am guessing this is to allow for precision plastic flow while printing, but that is a guess.
Lastly, looking at the different $f[asn] results in Cura's layer view, I think I see the problem. I just don't know how to fix it.
The threads are being sliced as a series of disconnected single or double squares, even with thicker shells. So the printer is just going blob, blob, blob, instead of a nice continuous line. I think this is the issue.
Maybe older versions of Cura merged the thread squares better. I don't know. But that would explain why it worked a year ago and not now.
So, now, in a last bit of desparation before I give up, I noticed that there is a "newer" old version of the library (ISOThread_20120823.scad) and it looks like it automatically adjusts $fn and thread quality based on the given diameter. Trying this version, reduced the number of thread and shaft segments, but Cura actually sliced it more continuously and more closely packed.
Printing this version of an M6 seemes to have worked quite nicely! So, YAY SUCCESS!
I will post some pics to help explain and show the results.
But the final answer seems to be to lower $fn and number of thread segments so that Cura can slice it more seemlessly. I think Cura has changed and has become less forgiving in it's interaction with this library.
Now with this new insight, I will have to see if I can get good results with the new library. Low poly FTW! Counter-intuitive! ... (Unless I am wrong.)
Many thanks for all the help! I am super happy now!
(Sorry for the massive post!)
- I tried more of DonMilne's mentioned settings.
-
Hi everyone,
I am the proud owner of a brand new UM2. Only had it a few days so far. It seems the thing to do here is to post a hello message in this thread. ... So, hello from Ottawa, Canada!
So far I have having great fun learning OpenSCAD, messing things up and going overboard with filament purchases.
I will say that the positive vibe I got lurking on the forums is part of why I chose and Ultimaker, so thanks to everyone already!
Take care!
Krys
-
Here is a picture of some of my attempts. One can see the problem with the threads clearly, I believe.
-
Hi there,
Just got my Ultimaker 2 a few days ago and this is my first forum post.
I am trying to print a nut and bolt based on this thread, but I am not having any luck.
I know this thread is a year old, but I was wondering if DonMilne or anyone else could share their specific settings that got this to work. (Or should I start a new thread?)
On my side, I have tried print an M8 and an M9, using the updated version of TrevM's library, on normal, high and ulti quality quickprint profiles. I have tried slowing speed to 5 mm/s on all speed settings, I have tried disabling combing. I have been using a shell thickness of 1.2 and 25% infil, per DonMilne's information. I have also tried turning off "combine everything (type-a)". Lastly, I am using Ultimaker Silver PLA for this.
The problem seems to be sagging or bubbling on the threads. I will post a picture just as soon as I figure out how to do it here.
I am not usually one to post on forums, but this one has defeated me.
Any wisdom shared would be much appreciated.Thanks in advance.
Upgrade your Ultimaker 2 with the Extrusion upgrade
in UltiMaker 3D printers
Posted
Thanks neotko. I will quadruple check again tonight, but I really have checked over and over again... all over.