How to represent threaded holes in a 3D model?

Jim Canale

I'm uncertain how to go about displaying a threaded hole in a BricsCAD model.  I can create a circle, and use the "push/pull" tool to extend it through the part.   But that only gives me a through hole.    I don't know if there is a tool which will create a standard threaded hole.   Anyone have any ideas on this?  Thanks for your time.

Richard Webb

I do this  by creating an appropriate threaded section from the X-Solids hardware menu and subtracting that from the solid. Almost as fast as extruding or pushing a circle. Subtracting the X-Solid doesn't yield a dimensionally perfect hole since, of course, internal threads are slightly larger than the corresponding external threads (not to mention that the X-Solid "threads" aren't actual helical entities). Works fine for the visual indication in the resulting 2D projections that "these" holes are threaded and "those" are not.

I have made actual correct helical objects, with the right tooth profile and the works, to "cut" a proper thread path. It was fun (and looked super) but that's far more detail than is typically needed, since the callout should include all of the necessary drill/tap information.

Jim Canale

Thanks Richard, I will give that a try.

Is there a provision to create a helix in BricsCAD?   Haven't found it.

Jim Canale

Richard, I couldn't get this to work.   I made a slab 1.5" thick, opened up X solids, grabbed a screw just as long, as the slab was thick, and then used the "subtract" command.  Nothing happened, excepting the screw was deleted.   

Richard Webb

I'd use a length of threaded rod instead of a screw as the "subtract" object but, regardless, it should have worked just like any other subtract operation. There's nothing special about it. PDF of a quick'n'dirty "threaded hole" attached.

WRT helical objects: The old Lisp routines that I used to create helical paths back in the Intellicad and pre-V8 Bricscad days aren't well behaved in V13 and I'm afraid I am not a good enough Lisp hacker to fix them. (Too much Lisp might burn out my embedded C neurons.)

This http://www.caddigest.com/subjects/AutoCAD/tutorials/select/southworth_3d_screw.htm seems to work using a non-helix technique.

There is also a helical tool in the add-on GeoTools application by Rakesh Rao and company. I haven't tried it but Rakesh is a frequent contributor here and I'm sure he'll drop in with more information.

Drawing1 Model.pdf

Jim Canale

I finally got your method to work.  I don't know what I was doing wrong.  I took a slice through the block.  No, doesn't look too much like a real thread, but it will do.   I'll check into Geo Tools and the other method.  Thanks for your help.

Section of Threads.jpg

martin@enco.us

Drawing a helix in Bricscad requires an external routine.  Try an online search for "helix.lsp".  There are several different routines by the same name. 

Richard Webb

Yes, the helix.lsp routine by Tony Tanzillo works most of the time. There are some conditions where it seems to produce an "insane spiderweb" instead of a helix but I haven't nailed down what triggers the bizarre behavior. Still, most of the time it does generate a good looking helix. (Set SURFTAB1 to a large enough integer.)

Trying to use that as a sweep path is where a problem arises. The non-planer path induces rotation in the swept object. I'm guessing that the xsweep routine maintains the orientation of the swept object relative to an axis normal to the path (which is fine for a planar path, of course) rather than with respect to the overall axis of the helix.

The normal to path behavior is probably desirable and correct in the general case. I suppose there would have to be an option to constrain or specify the axis of rotation separately from the sweep path.

helix_test.dwg

Jim Canale

Richard, I like your method.  Thank  you!

Nuno Gouveia

I have made actual correct helical objects, with the right tooth profile and the works,

Hi,

Can you tell us how you managed to draw it?

Thanks

Richard Webb

The current version's HELIX plus SWEEP commands work well, with very little drama and good results. I did need to mirror the "profile entity" to get it to form an external thread (to flip the normal of the sweeping region?). Cutting with a simple equilateral triangle makes a nice, quick threaded shape.

The devil is in the details, as usual. The ANS and ISO 68 thread profiles are a little bit more work to construct.

Knut Hohenberg

@Richard:
Funny, I just raised a SR some days ago, since I ran into various modeling errors doing exactly what you describe. I wonder if this might be platform specific (I'm on linux)...

Richard Webb

With recent versions prior to V14 and using "home made" helix paths I would see the screw profile sweep along the path and rotate around the axis (as it should) but also rotate around the sweep path itself. It made for an interesting pattern. It worked okay on LISPed helices 'way back on version 6 or 7 but there have been many changes to the code base since then.

In the current V14 release for Windows and using the built-in helix command, it seems to be working okay, although I'll admit that I haven't poked at it really hard to try to break it. The attached is a swept equilateral triangle in the pre- and post-swept states for you to try out. Note that it was done with the built-in sweep command, not Konstantin Sakellaris' sweepx.

Drawing1.dwg

Sakko

@Richard:

due to bugs in the sweeping API (programming libraries), it was impossible prior to Version 14.2.10, to sweep a profile
along a 3d sweep path (helix , 3D polyline, 3D spline etc) in V14 using the SWEEPX command.
In Version 14.2.10 the libraries were reverted to the previous less buggy version to resolve the most serious problems.
Look at the release notes of the 14.2.10 Version of Bricscad....
SR41598, SR41531 - SWEEP: to avoid regressions introduced in Teigha 3.09, implementation of sweeping API was partially reverted to state used in version 3.08.
....
Thanks to your DWG, i tried to use SWEEPX to produce the result you produced with the native SWEEP command
only to realise that a non-sense swept solid is created (yellow) even after selecting the basispoint of the sweep operation and the "Translate Path To SweepEntity" option.
Align SweepEntity To Path/No Alignment/Translate Path To SweepEntity/Translate SweepEntity To Path
Enter an Align Option [AE2p/No/TP2e/TE2p]: TP
The same in V13 !

In Autocad 2012 the SWEEPX and native SWEEP commands don't produce any swept solids using your profiles (triangle and Helix)
raising two errors  "the sweep operation results in a self intersecting solid" and "sweeping the selected object is impossible" respectively.

These 2 errors led me to the idea to check concistency of your solid produced in V14 by the native SWEEP command only to find
that it is not a valid solid. By trying to slice the solid using the native SLICE command i get the error :
.....
Modeling operation error:
inconsistent edge-face relationships
Slice is failed for object (33C)

So i think the ACIS libraries and their ODA Teigha and .NET wrappers need a substantial lifting to enter mainstream application development.
Maybe in V15.
attached you find a DWG to check out...

SpiralsAndProblems2.jpg

SweepTest.dwg

SpiralsAndProblems.jpg

Richard Webb

Interesting, Konstantin. Yes, the red object on the right with the "loopy" result is what I was getting up to the current release.

As I mentioned, I haven't really poked at the issue very hard. My need for threads is to add a call-out for something like .250-20UNC-2B and be done with it. An actual thread profile is surprisingly complex and waaaaay more detail than I need for production drawings.

That said, I do agree with your more detailed examination. It looks like there is a soft spot here.

Knut Hohenberg

Hello Konstantin,

that's roughly consistent with the results I had using version 14.2.07 beta on Linux. If I had looked at the windows release notes, I wouldn't have raised a SR...

However, I tried a bit further, and now it looks to me as if the problem lies more in the helix than in the sweep:

Sweeping a profile that has the exact turn-height of the helix results in unusable geometry. I guess this is due to the fact that the helix is a rather rough approximation of the mathematical shape, so that the turn-height is slightly varying along its perimeter, which results in a steady alteration between self-intersection and gaps in the created solid.

If I draw the profile slightly smaller than the turn-height to avoid self-intersection, everything seems to work:
in the attached drawing, I swept the red triangle along the helix (using SWEEP with align=No and selecting the start point of the helix as base point), and then subtracted the result from a cylinder with the same height and radius as the helix. The created solid seems to be valid: I was able to subtract an inverted cone (revolve of the green profile) from it, and then then used the slice command to cut it into two halves (using the zx/0,0/both options).

helix.png

helix_5.dwg

Sakko

Hello Knut,

I could reproduce your description and confirm your assumption !
The problem seems to be the self intersecting solid as a result of a non-perfect Helix (...steady alteration between self-intersection and gaps in the created swept solid..).

This led me to the idea to check some solids with particular "edge conditions" using the native SWEEP, SECTION or SLICE commands.

Case 1 + 2:
create 2 wedges and union them (2). SECTION and SLICE don't work if the plane runs through the common edge of the 2 wedges.
Otherwise it produces correct results.

Case 3, 4, 5 :
SECTION and SLICE don't work if the plane runs through the common apex of the 2 Pyramides and/or cones.
Otherwise it produces correct results.

Case 6, 8 :
Sweeping a circle profile that has the exact turn-height of the helix doesn't necessarily results in unusable geometry.
In these cases you can SLICE and SECTION the swept solid unless the plane runs through the center of the sweep (similar to 1,2,3,4,5).

Case 7 :
The sweep path polyline(red) is so created that the middle part has a length = circle diameter of circular sweep profile.
The sweep stops at the second vertex of the polyline path. Autocad creates the complete swept solid !

In all the above cases we have either common apexes or edges or tangent touch curves (case 6,7,8) and rather valid solids.
In Autocad the SLICE and SECTION commands produce valid sections(regions) and Slices in all cases also if the plane runs through
common edges or centers of "self-tangential" solids.

You find the dwg in the attachment.

EdgeConditions.dwg

EdgeConditions.jpg

Knut Hohenberg

Hello Konstantin,

I think the problem is how to define which kind of geometry should be regarded as "valid solid" in BricsCAD.

For self-intersecting geometry, the answer is IMO clear: these are not valid ACIS solids, and when I understand your previous post right, AutoCAD will try to prevent you from creating such bodies.
However, BricsCAD's SWEEP command lets you create self-intersecting solids without a warning; these may allow certain further modeling operations, but you're almost sure to run into problems. See e.g. the solid in the attached file: you can slice the solid as long as the problem area is not hit by the cutting plane (the green one), otherwise the operation fails (the red one).
My understanding is that BricsCAD should reject such geometry with a clear error message right away, unless SOLIDCHECK is disabled. ACIS seems to offer this functionality (http://doc.spatial.com/index.php/Self-intersecting_Checks_in_Sweeping), no idea if it is not reliable or simply disabled.

(The funny twisting of the sweep if the path is a non-planar spline (does not occur with 3d-polylines) is another story.)

Your wedge and cone examples are IMO less clear cases:
These solids are non-manifold, which ACIS can handle, although I do not understand from the documentation (http://doc.spatial.com/index.php/Manifold_and_Non-manifold_Objects) if slicing such geometries is supported.
Since BricsCAD currently just offers basic solid editing, I'm inclined to think that not allowing such geometry would be wiser for the moment.

Anyway, the slice should never fail silently as it does now...

spline_sweep.dwg

self-intersection(2).png

Knut Hohenberg

I overlooked your example 7: this indicates that there is indeed a check against self-intersection / non-manifold geometry built into the sweep command - it is just not working in all cases.

Sakko

Hi Knut,

i would conclude now that the API for SWEEP (and LOFT....) operations is for the time beeing under construction...
The only thing that matters is when the  "ACIS-Teigha-NET. Wrapper API"  is going to be reliable for application development !
It's about providing basic functionality in a cohesive and sound API and commands.
The one does not exclude the other !
My last concluding example....

A rectangle (yellow) is swept along the 3d Spline(red) and the Helix(red) with default options. (no profile Basis and alignment changed)
The green results are produced by the native SWEEP command and the cyan by the SWEEPX command. It is self explanatory.
So have a nice weekend..!

SweepJokes.jpg

SweepsJokes.dwg

Swanand Ghanekar

You can insert a thread component from the Bricscad library, dissolve that component and then subtract it from the parent solid. You can get the threads. But the representation in drawing view is not proper nor it doesn't show in multileader about the same. Bricsys shoud do something on it.

  

@Richard Webb:

I'd use a length of threaded rod instead of a screw as the "subtract" object but, regardless, it should have worked just like any other subtract operation. There's nothing special about it. PDF of a quick'n'dirty "threaded hole" attached.

WRT helical objects: The old Lisp routines that I used to create helical paths back in the Intellicad and pre-V8 Bricscad days aren't well behaved in V13 and I'm afraid I am not a good enough Lisp hacker to fix them. (Too much Lisp might burn out my embedded C neurons.)

This http://www.caddigest.com/subjects/AutoCAD/tutorials/select/southworth_3d_screw.htm seems to work using a non-helix technique.

There is also a helical tool in the add-on GeoTools application by Rakesh Rao and company. I haven't tried it but Rakesh is a frequent contributor here and I'm sure he'll drop in with more information.