Experiment with threads.

[donmilne 2]

I'll be interested to know if you can reproduce this with the new library, since the inherent speed in combo with a lower poly count ought to make it quite sweet to use!

I have a feeling this whole problem might actually be due to a weakness in STL, mainly that it gives duplicate definitions of shared vertices, and these duplicates can be slightly different due to rounding errors, especially in ASCII STL (which OpenSCAD uses - inexplicably! All that precision in the modeling, only to throw it away in the render).

I know that Cura tries to correct these problems, but perhaps it couldn't in this case - in which case it would see the perimeter of the thread as a series of disjointed segments.

Yes, Cura behaviour may have been different in the past, but on the other hand it may have been a pure fluke that I got a fairly easy success last year, without too much digging. Though I note that I also ended up using that ISOThread_20120823 library, perhaps because it was the latest at the time.

It's a shame that OpenSCAD doesn't support exporting in OBJ format, which doesn't have duplicated vertices.

p.s. Certainly this application doesn't need a high segment count. As soon as you thread the two parts together the plastic will be smoothed out anyway!

 

[krys 206]

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!

 

[donmilne 2]

I can post the updated code if DonMilne is okay with that.

 

That's fine. There's nothing proprietary in what I sent you, I just made a few test calls to TrevM's library.

If OpenSCAD is displacing the threads outwards by 0.4mm then that would certainly explain why the body of my bolt now has threads protruding through. And if the threads are unsupported, then certainly that could cause blobby prints.

Oh, when when you talk about "achieving the same effect" by increasing the body diameter, I assume the effect aimed for was to obscure the threads. So in other words you're saying that this M6 thread actually has a diameter of 6.2mm? Houston, we have a problem! (unless he's trying to compensate for shrinkage?).

 

[Daid 306]

You might want to check out my thread code for this old design:

http://www.thingiverse.com/thing:24253

I'm using a different method then what I see in the screenshots above, which should help with slicing. As I see many slicing artifacts as well.

And as you can see, I printed the thread just fine on my old UMO.

 

[Anders Olsson 136]

Try Daid's thread-model!

The threads by TrevM, the way they look in the previous posts here, are not very suitable for 3D-printing.

You need a model that generates threads that, when scrolling through the slices, looks like an oscillating circle.

The slicing needs to be done in a way that preserves this shape.

In TrevM's model you have flat surfaces that disrupts that oscillating circle, that model will be very difficult print a nice thread from.

Here is an example of a M42x1mm thread that i have printed and used:

 

I have printed perfectly fine M6x1 and M5x0.8 threads using 0.1 mm layers this way.

 

[visu-al 2]

And if you know exactly how your thread should be and you know how to use blender then use blender addon bolt factory that creates good meshes to print and you can setup every value.

 

[donmilne 2]

I selected TrevM's library last year after having several near total failures with every other lib I found. The main problem being that OpenSCAD grinds to a halt when so many thread features are added.

I notice that Daid's "camera mount" example only has 4-5 thread turns. It would be interesting to see how it performs for a more realistic case, e.g. the first test in this topic. Of course some metric parameters would have to be defined first.

 

[krys 206]

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!

 

[krys 206]

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:

 

1. 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),
   
2. I don't really want to build a whole new library around it or manually build nuts and bolts in multiple steps, and
   
3. 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:

 

1. The central shaft cylinder does not contact the thread segments. (Hence the blobbing I experienced.)
   
2. 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.)

 

[krys 206]

(Also, it seems I am incapable of writing a short post!)

 

[donmilne 2]

I would appreciate a readable explanation of the changes, since while I am a coder, I code for Windows and embedded and do not use Linux patch tools.

[Edit] Never mind, I worked out the patch language syntax.

 

[donmilne 2]

Hmm. That was disappointing. I was quite excited by the possibility of having high quality metric threads rendered with the speed of the new TrevM library, but what I found instead was OpenSCAD taking forever (I cancelled it after 20 minutes) to compile and render the M10 bolt and two nuts of my test (compile+render being needed for STL export).

Perhaps I made a mistake with the patch, or misunderstood the purpose of it? How were you rendering your results?

 

[krys 206]

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.

 

[krys 206]

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.

 

[visu-al 2]

Here i created a little PDF how to do it with blender

https://www.dropbox.com/s/t6dc9e9rywltl7n/CreateBoltsInBlender.pdf?dl=0

 

1. Start Blender and go to File/User Preferences
   
2. Go to the Add-ons tab and in the upper left type in „bolt“
   
3. Click on the Box near the little man to activate the BoltFactory
   
4. (In 3D Space) Press Shift + A for the „add“ menue choose category mesh and click on “Bolt“
   
5. Now don’t do anything expect type in all your values in the left lower box named Add Bolt
   
6. If you can’t see that you need to press “t” to active the toolbar
   
7. For using in Cura you need to scale everything from blender 10X ( press S, 10)
   
8. (Edit) export to stl (while selected)
   

VISU-AL

 

[visu-al 2]

Oh yes step nr. 4 must be with the mouse over the 3d space

You can also create a library for everything you want some presets are allready there but you can also create presets that are respecting some shrinking if you know or testet the tolerances on your printer and automatically create all kind of heads hex or round with allen bit holes and then just export to stl or even scale it 10 times ( press S and 10) to have the right size in cura. i really love it. if someone wants preset libraries without creating them, just tell me what you want and i create it..

 

[donmilne 2]

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.

 

The test case in question is the bolt and two nuts script that I sent you, though I have since commented out the "$fs..." line and replaced it with "$fn=20;". This model is manifold (it's OpenSCAD after all), but has three separate parts.

The old ISOThread_20120823 library renders this in just short of 7 minutes, using the original "$fs..." line. The new "fast" library takes... I don't know, - I aborted after 20-25 mins because I need my CPU for other things!

[Edit] I decided to take a closer look at the timings, using the same "bolt and two nuts" script for each test. The old library takes 16m29s to render this test case. The unmodified new library takes 6m56s, and the modified new library takes 36m7s.

Part of this is that the old and new libs default to different render quality. As you've mentioned in an earlier post (and I didn't really register), the new library hard codes $fn=30, the old library used to do a calculation that resulted in $fn=12. If I comment out the hard coded value and use $fn=12, then the modified new library takes 9m33s, so it is faster than the old library.

 

[krys 206]

@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!

 

[krys 206]

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,5

Or, 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!)

 

[donmilne 2]

Your latest results are looking great. I will try your new lib later today.

Your timings are incredibly fast compared to mine. You're taking seconds and I'm taking minutes.

You're doing a full "Compile and Render (CGAL)" right? Not just a compile? I.e. you're doing the step required to export to STL?

Oh! And thanks for alerting me that there's a new OpenSCAD release out! (and just noticed that the menu wording has changed. It's now just "Render").

 

[donmilne 2]

Ok, I've given the new thread library a try, and I must say that the threads now look very nice. Perfect in fact.

The only remaining concern I have is that when I render this in OpenSCAD the threads seem to peek above the cyclindrical shaft I put on the bolt, even if the cylinder is slightly large, e.g. 6.01. At 6.1 the threads no longer show, but of course that means this M6 bolt will not fit in a 6mm hole! I'm not sure where the problem lies - and I don't really have time to check the code myself, so for now I'll just alert you. As far as I can tell from a quick Google search, the peaks of an M6 thread should be exactly 6mm dia.

[Edit] Never mind. The issue of the threads peeking through the cylinder was simply caused by the $fn=x number for the cylinder being different from the one the thread uses. Make them the same and the problem disappears.

 

[luke 0]

Cool project and great forum!!

 

[krys 206]

@DonMilne:

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.

 

[krys 206]

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!

 

[donmilne 2]

Just a note that your Thingiverse link is broken, it looks like you included some text inside the URL.