Comment by jcgrillo | Hacker News Reader

Comment by jcgrillo | Hacker News Reader

Parent Full thread

The main complaint I have with CadQuery et. al. is the API verbs are all coming from the point of view of describing bRep shapes instead of thinking about the design from the standpoint of "how would I make this?".

I think there's an opportunity for a code-first CAD API to incorporate GD&T and manufacturability information directly as part of the modeling process. For example, if I'm making a shaft I want to describe that operation as it will actually be performed in the shop e.g.:

  (1) select round stock of nominal dimension X
  (2) cut to rough length
  (3) chuck in 3-jaw chuck and drill center
  (4) flip around in 3-jaw chuck and drill the other center
  (5) mount between centers
  (6) turn to rough outer dimension
  (8) turn down to add the various bosses, threads, chamfers, other details, etc...

With this kind of a process I get all kinds of GD&T information for free--for example, the precision of my 3-jaw chuck determines how much larger my nominal dimension X needs to be than my target rough outer dimension to be able to reliably achieve it.

So I think these APIs are coming at the problem from the wrong point of view--they're all about driving the CAD kernel and telling it how to draw abstract shapes in a computer. Instead what I want is to tell the computer how I intend to make the thing and get an estimate of what the result will look like.

> So I think these APIs are coming at the problem from the wrong point of view--they're all about driving the CAD kernel and telling it how to draw abstract shapes in a computer. Instead what I want is to tell the computer how I intend to make the thing and get an estimate of what the result will look like.

I have certainly learned over time that when you're looking at an object that exists in the real world, one way to start to figure out how to model it is to figure out how it -- or its injection-mould positive -- was physically made. Can it be cut with a mill? Was it glued together in parts?

It absolutely is fun to try to work out how to come up with a shape subtractively from some giant primitive as if it was a block of steel. I often find myself visualising in terms of a scroll saw. I watched a couple of great videos about three-dimensional scroll-saw work and it weirdly affected my understanding of CAD!

Isn't that basically coding in G-code?

The problem of course is that that limits one to straight lines and arc moves.

Are there any really good G-code previewers for lathe work?

For that matter, what is the best 3D G-code previewer which will allow one to see the surface of the cut part in 3D? I'm about to break down and buy tkcnc --- is there something better?

> Isn't that basically coding in G-code?

No, I think G-code is too prescriptive and low level for the modelling task. What I'd prefer is some way to specify operations in a fluent, object-oriented API e.g.:

  round_bar = RoundBar(
    alloy=1018, 
    diameter=Dimension(1*Inch, error=0.010*Inch), 
    length=Dimension(12*Inches, error=0.25*Inch)
  )
  3_jaw = 3JawChuck(tolerance=0.005)
  between_centers = BetweenCenters()
  center_drill = CenterDrill(size=4)
  
  shaft = round_bar
    .chuck(configuration=3_jaw)
    .drill(bit=center_drill, depth=Dimension(0.250*Inch, error=0.02*Inch))
    .unchuck()
    .rotate(axis=Y, degrees=180)
    .chuck(configuration=3_jaw)
    .drill(bit=center_drill, depth=Dimension(0.250*Inch, error=0.02*Inch))
    .unchuck()
    .chuck(configuration=between_centers)
    .face()
    .turn(
      target_diameter=Dimension(0.750*Inch, error=0.001*Inch),
      length=Dimension(11.5*Inch, error=0.05*Inch, anchor=round_bar.tailstock_face()),
      finish=Rough
    )
    .external_threads(
      class=ThreeA,
      nominal_size=FiveEighths_18,
      length=Dimension(1.25*Inch, error=0.020*Inch, anchor=round_bar.tailstock_face()),
      reverse=False,
      relief=DefaultRelief(FiveEighths_18)
    )
    ...

I can see where you are coming from, and I've thought about similar ideas. But ultimately, I think this fails for separation-of-concern reasons. Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out. Those are wildly different programs and work flows.

Something like you propose might be an interesting thing to explore for creating CAM posts. The actual Gcode that your API would emit is going to vary quite a lot even within super-similar machines -- a 3+1 axis job targeting a machine with a FANUC controller is going to be pretty different from the same job targeting a machine with a Heidenhain controller.

> Describing the part is different from describing how to make the part. The same part might be sent to 3D printing for a non-functional fit prototype, sent to a prototyping machine shop to make 5 or so units on basic CNC machines that require 3 set-ups to complete it, and after a few design iterations scaled to production on a multi-spindle Swiss-style lathe that drops finished parts into the basket all night long, lights-out.

I think you might have a point here, but I'm going to push back on the idea that these three parts are the "same part" because they'll all have wildly different mechanical properties, dimensions, and dimensional consistency. They are not all necessarily interchangeable (although they could be, we'd have to integration-test them in an assembly to find out!).

My point is the "abstract part" isn't really a thing, and the real life characteristics of each concrete part are inextricable from the way it's made and what it's made of. I wonder if it would be helpful to force me, the designer, to think about it that way from the start?

3D printing is an odd case that tbh I hadn't really thought of. The things I make are all subtractively manufactured (except for welds which are addictive only in a degenerate sense), and I have no experience with 3D printing.

Too late to edit, but I've been foiled yet again by touchscreen phone autocorrect. While welding is certainly addictive (albeit in an entirely wholesome non-degenerate sense), what I meant above was additive.

Reply on news.ycombinator.com