Yet they shelter under a 'Science' tax-break. It's duplicitous. They should publish their models and build process. If it's not available for replication, it's not science.
1. Hugely non-deterministic: repeat queries give vastly different responses. 2. Often returns incorrect and inconsistent results even for mathematical queries. 3. Often the responses include unwanted highlighting or presentation markup. 4. Defaults to German decimal notation.
On a similar bent, I recently discovered Handy (cross-platform) which is very well implemented local voice input: https://handy.computer/ ... serious finger saver and ideal for LLM conversations
After looking at some videos of what this even is, I'd say it can do it but will likely fail on the boolean operation where the two spirals intersect. It might work fine but it's an operation likely to trigger a bug, and it would be sensitive to the exact placement/pitch of everything. Having said that, using the "force to triangle mesh" option solvespace will probably work fine. That should be sufficient for the home 3D printing crowd to make some fun stuff, but you won't be able to save a STEP file then. Just my guess as to how this might go.
Everything I've read by Kurlansky has been awesome. Big fan of the thematic history genre. Simply great stuff. Gives adequate scope for authors to connect various dots without going all dry or embellishment.
Having studied (and written) histories myself, this sounds like an accurate description of histories in general. We don't need to make everything an encyclopedia. Sometimes it's fun to follow a conversational review of a breadth of material without getting in to the weeds. Kurlansky often includes personal anecdotes and has a good sense of where to dwell. This is what I appreciate in a writer: character and tact.
The same can be said for, well, 101-level class attendees.
People love to declare themselves experts on things; thus: the Expert Fallacy ("I know a lot about repairing carburators; let me tell you what is wrong with self-driving cars...")
Ahh, but can it do a clean self-reversing diamond thread including the reversing portion?
You'd be amazed how hard this is to achieve with open source tools. IIRC modern FreeCAD can't, old FreeCAD can, ~5 ways to achieve it in OpenSCAD don't work properly, Blender keeps shifting-sands and mostly can't but I believe the very latest can maybe do it with difficulty using geometry nodes.
Ok here is my result, which matches up well with the examples I have found from McMaster Carr. Note that not all STEP importers are robust enough to deal with files from OCCT based CAD packages. As I mentioned previously there are transition arcs from the left to right hand helices on both ends which enable the automatic reversing behavior.
from ocp_vscode import show_all
from build123d import *
od, p, n, d, e = 10 * MM, 12 * MM, 5, 1 * MM, 15 * MM
base_helix = Helix(p, 2.2 * p, od / 2 + 0.001, center=(0, 0, -p))
# retain a small piece below XY plane for orienting sketch
trim_base_helix = base_helix.trim(0.4, 1)
trim2_base_helix = trim_base_helix.trim(0, 0.72)
p0 = trim2_base_helix @ 1
t0 = (trim2_base_helix % 1).normalized()
t1 = Vector(0, 1, 0).normalized()
bisector = (t0 + t1).normalized()
if bisector.length == 0:
bisector = t0 # Fallback if tangents are perfectly opposite
ray = Axis(p0, bisector)
end_pt = ray.intersect(Plane.XZ)
transition_arc = TangentArc(p0, end_pt, tangent=t0)
rh_curve = Curve() + [trim2_base_helix, transition_arc]
profile = (rh_curve ^ 0) * Rot(Z=99) * Circle(d) # rotate seam out of the way
rh_sweep = sweep(profile, rh_curve)
splitter = Plane.XZ * Rectangle(10, 40, align=(Align.MIN, Align.CENTER)).face()
rh_sweep = split(rh_sweep, bisect_by=splitter, keep=Keep.BOTH).solids()[1]
lh_sweep = mirror(rh_sweep, about=Plane.XZ)
both_sweeps = Part() + [rh_sweep, lh_sweep]
cyl = Part() + Cylinder(od / 2, p + e + d / 2)
cyl -= both_sweeps
cyl = split(cyl, bisect_by=Plane.XY)
cyl += mirror(cyl, about=Plane.XY)
show_all()
I'm no expert on self-reversing diamond thread but I think this generates what you're looking for. Are pictures allowed here?
import copy
from build123d import *
from ocp_vscode import show_all
od, p, n, d, e = 10 * MM, 12 * MM, 5, 1 * MM, 15 * MM
with BuildPart() as thread_segment_builder:
with BuildLine():
path = Helix(p, 1.1 * p, od / 2 + 0.001)
with BuildSketch(path ^ 0) as diamond:
xsection = Polygon((0, d), (0, 0), (d, d / 2))
track = sweep(is_frenet=True)
# Trim the ends to align with Plane.XZ
Box(2 * p, p, p / 2, align=(Align.MIN, Align.MAX, Align.MIN), mode=Mode.SUBTRACT)
with Locations((0, 0, p)):
Box(2 * p, p, p / 2, align=Align.MIN, mode=Mode.SUBTRACT)
# Create the rod end with an extension beyond the threaded section
with BuildPart() as threaded_rod_end_segment_builder:
with Locations((0, 0, -e)):
Cylinder(od / 2, p + e + d / 2, align=Align.NONE)
add(thread_segment_builder.part, mode=Mode.SUBTRACT)
add(mirror(thread_segment_builder.part, Plane.XZ), mode=Mode.SUBTRACT)
# Position and trim the end and mid segments
threaded_rod_end_segment = Pos(Z=-d / 2) * threaded_rod_end_segment_builder.part
threaded_rod_mid_segment = split(threaded_rod_end_segment, Plane.XY)
# Build the rod from copies which is very efficient
threaded_rod = Compound(
children=[Pos(Z=i * p) * copy.copy(threaded_rod_mid_segment) for i in range(n - 2)]
+ [
Pos(Z=-p) * threaded_rod_end_segment,
Pos(Z=p * (n - 1)) * (Rot(X=180) * copy.copy(threaded_rod_end_segment)),
]
)
show_all()
A valiant attempt! Unfortunately, there are a bunch of artifacts after export_step() - I don't use vscode and show_all() was sidestepped - which break the thread, see https://postimg.cc/3kkzW94T Specifically, the end of thread is a hard diamond shape with a chunk missing, and the diamond threads don't cross over at all apparently because segments of the rod have rendered on top of others. python 3.13 build123d-0.10.0 cadquery_ocp_proxy-7.9.3.1
build123d can absolutely accomplish this. I downloaded a STEP file of a self-reversing (diamond) thread part from McMaster Carr for analysis. I will reply when I finish a recreation of it. Based on my analysis of the STEP I most likely will start with a regular left and right helices that are trimmed slightly before they intersect at the end. From there will need to apply constraints for tangency with the helices while staying fixed on the cylindrical body. There are multiple ways to achieve this. The next step is to perform a sweep (cut) on half of the transition plus one side of the helix. This can be done in two stages to avoid self intersecting sweep geometry (a big no-no in most/all BREP CAD kernels).
Do you have an image of the reversing portion? Any examples of pitfalls?
On the face of it, it seems like you'd define paths and sweep profiles for the material to remove. Is the difficulty in defining the path of the reversing portion, where it's not a helix?
Threads have a range of properties, all of which must be supported, then it's generally the capacity to mirror a thread along the same face (exactly), and at either end add a transition zone that reverses, preferably with configurable characteristics (straight portion, rounding, etc.). Many approaches fail because the reversing transition zone is not readily aligned with the existing thread except through hacks or because reversing is incompatible with the programmatic approach used. Once that's all done, there are additional complexities for a captured element to ride in it which typically has a geometric relationship with the thread pitch, crossovers and transition zone. It's one of those "harder than it looks" problems, even for machinists. That's why, if the codebase can achieve it, I'd give it respect.
PS. I also use a lot of OpenSCAD. Liked your comment. I started in POVRay so it made a lot of sense after managing non-FOSS CAD people for years.
I strongly recommend not buying a Macbook and instead hacking a mini: https://github.com/vk2diy/hackbook-m4-mini ... cheaper and restores control of peripheral selection and replacement. That is to say "such a system will last ~forever instead of ~3 years [when the first major component dies and replacement costs ~70% of a new Apple product]". Particularly with Asahi Linux progressing so quickly. https://asahilinux.org/ Without Asahi Linux I would not buy a Mac in 2026.
I too looked at Framework and like the idea, unfortunately in my case the supply chain was too slow to be tolerable, before even considering the price-performance ratio.
I strongly support the idea that the EU should force vendors to make consumer device repairs cost-effective and available or open source and expose their component interfaces in exchange for the right to sell in Europe. After all, the EU brought us USB-C, so we know regulatory pressure works. Thanks, EU!
reply