3 ms·

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 d

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.

throwgfgfd25 2y ago
> 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!
WillAdams 2y ago
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?
- jcgrillo 2y ago
  > 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) ) ...
  - dbcurtis 2y ago
    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.

throwgfgfd25 2y ago

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

WillAdams 2y ago

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?

jcgrillo 2y ago
> 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) ) ...
- dbcurtis 2y ago
  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.