thread lisp
@Anonymous wrote:
Does anyone have a lisp routine for creating various types of external threads?
I haven't used it, but >here< is one I'm aware of. It's very likely re-writable now to use the Helix command, which was not available at the time, but if it does the job....
Kent Cooper, AIA 
@Anonymous wrote:
.... I'm talking about unified, square and acme threads.
I find there are multiple versions of some of those, such as >here<, where [in the teal-colored area on the left] there are ten varieties of "Unified" thread standard, and two "Acme" varieties. It wouldn't be difficult to come up with something to automate drawing those, but perhaps it would need to be narrowed down. Maybe the fewer-varieties information in some places such as >this one< for "Unified" threads is adequate for your purposes.
Square threads seem to be more of a one-configuration deal, e.g. >this<.
In all cases, it would be comparatively easy to come up with something for the thread profile, given a pitch, but are you also looking to draw both sides of the thread on a bolt or nut at the same time? The websites show that there is a relationship between diameter and thread pitch that would need to be accounted for somehow, and it's not just a linear thing, but goes in steps, with some pitches applicable to only one diameter but some applicable to more than one [see the chart in the second link labeled "Standard trapezoidal thread pitches for metric diameters"].
Kent Cooper, AIA
@john.uhden wrote:
What are you doing? I didn't solve anything!
[I thought the same.... As an Expert Elite person, I wield the power to un-designate Post 7 as the solution, if you like and if the OP doesn't.]
@Anonymous, it also occurs to me that this could be done with Shape-embedded linetypes [though that may not be a good approach because of the nature of the ends of such lines], or with Blocks, either ARRAYed or MINSERTed or placed using a MEASURE command. A single Block definition could cover all possible Square threads, for instance, and another all possible Acme threads, presumably defined so that the Pitch distance could be used as the scale factors.
Kent Cooper, AIA
@john.uhden wrote:
Yes, I would appreciate your undesignating #7 (or whatever) as a solution. ....
[Done.]
@Anonymous, another thought arises: Would I be correct in assuming that you need to do this only along straight paths, but never curved ones? I would probably take an approach similar to what you see >here<, and that can deal with curves [look at the image attached at the first Comment], but a straight-only routine would be much simpler to do.
EDIT: >This< is another routine that uses the same kind of approach. Both step along the "path" and determine vertex locations off to the sides as they go, which seems the right kind of approach to what you're after, if a Polyline profile is the desired end result.
Kent Cooper, AIA
Kent1Cooper wrote:\
.... Both step along the "path" and determine vertex locations off to the sides as they go, which seems the right kind of approach to what you're after, if a Polyline profile is the desired end result.
Like this, for the "Acme" form along a straight path, in very simplest terms:
(defun C:AGT ; = Acme Gear Teeth [2D profile only]
(/ p1 p2 ang L R len pitch sofar)
(defun pt (step side)
(polar
(polar p1 ang (* pitch step))
side
(/ pitch 4)
); polar
); defun
(setq
p1 (getpoint "\nStart of Acme gear teeth profile: ")
p2 (getpoint p1 "\nOther end of profile: ")
ang (angle p1 p2)
L (+ ang (/ pi 2))
R (- ang (/ pi 2))
len (distance p1 p2)
pitch (getdist "\nPitch {tooth C-C}: ")
sofar 0.0
); setq
(setvar 'osmode 0)
(command "_.pline" p1 "_width" 0 0); leave in Pline command
(while (< sofar len)
(command
(pt 0.0646544 L)
(pt 0.435346 L)
(polar p1 ang (/ pitch 2))
(pt 0.564654 R)
(pt 0.935346 R)
(polar p1 ang pitch)
); command
(setq
sofar (+ sofar pitch)
p1 (polar p1 ang pitch)
); setq
); while
(command ""); finish Pline
(princ)
); defun
It doesn't save and reset any values, nor remember your Pitch setting to offer as default the next time, nor have any of the usual enhancements, but it seems to work -- if it does what you want, those things can be added.
Those multi-decimal-place values are to achieve the 29-degree "valley angle" I find in the sources. Simply altering those to 0.0, 0.5, 0.5 and 1.0 will make the Square-tooth form. Swapping the L and R letters next to them will make it flip the in and out directions to the opposite sides.
You pick two points to do it along, which can be [for example] Osnapped to the endpoints of a Line, but it doesn't need a Line or other path element drawn first. It draws complete cycles of an out- and an in-side of the profile, so it overruns the end of the overall length if it isn't a whole multiple of the Pitch -- Trim as needed. Another thing it could probably be made to do is to stop at the first vertex that's past the overall length, wherever in the cycle it is, but that's more complicated.
Kent Cooper, AIA
@Anonymous wrote:
What should the lisp file name be?
Anything you want, as long as the filetype ending is .lsp and it's in some location you'll be able to find it in. I usually use names from which I'll recognize what it's about in a list of file names, so perhaps AcmeGearTeeth.lsp, or if you end up with different ones for different forms, maybe something generic-to-specific such as GearTeeth-Acme.lsp, so that all Gear-related ones occur together in an alphabetical list. [For the same reason, consider changing the command name, such as to GTA.]
Use APPLOAD to load it, and the command name to use it is the part after the C: [in this case, AGT (if you don't take the suggestions above or below)].
And now thinking about it, I'd say, really, both the file and command names should be called something involving Threads, not Gear Teeth -- don't know why my mind went there....
Kent Cooper, AIA
@Anonymous wrote:
I loaded the app, but AutoCAD says it's an invalid command.
It worked for me. Does it at least load without any error message, with the error only when you type the command name? Could something have gone wonky in copying/pasting? Post your actual .lsp file.
Kent Cooper, AIA
It didn't attach, somehow.
One possibility occurs to me: If you copied/pasted the code into a word processor, such as MS Word, and saved it into a .lsp file from there, it may have converted quotation marks and/or apostrophes into "smart quotes" [the kind that look different at the beginning of a quote than at the end], which would mess things up. If that's how you did it, try it again using a plain-text editor such as Notepad, so they'll be "dumb quotes."
Kent Cooper, AIA