I’m curious to understand the difference between the R8 ‘new stuff’ of ‘auto plane’ and the regular ‘cplane to object’ approach.
I’ve decided that Cplanes are in fact crucial to the whole parametric ideologies. And I intend to focus on them a fair amount.
I believe that no matter the part type, the “Cplanes” should be exploited as much as other parametric programs do.
Pretty much any part file should contain an intuitive interface to the XY, XZ, YZ planes – as well as an assortment of auxiliary types and of course any custom type.
Yes, Rhino has ‘named cplanes’ etc, but the key here is intuitive access to such a GUI.
I am interested in seeing how GH will empower me with said Cplane functionalities.
This is close to what I’m thinking, and similar to something I’ve seen before in GH:
Exactly:
Somem like this:
…
I’ve got a few projects that came across my desk recently, which might give me some motivation to learn more about GH. I’m going to try turning them into some examples for GD&T / Constraints testing. I’ll most likely be attempting to use GH for the parametrics and anything that will help.
The first one will be a rectangular type part. The other part I have on my list atm, is more of an angle-bracket type part. I might put them in separate threads.
For the rectangular part this is literally all they gave me to work with fml lol:
not even sure which holes should be countersunk, so will update later 
I’ll be doing updates over time, to demonstrate how things are going.
My theories behind dimensional / geometric – constraints – is mostly based on principles of degrees of freedom in design intent / features n’ such. I’ll be focusing on the ‘constraints’ principles. The GD&T portion is more of a tangential detail in this regard.
I’ll be using GH to learn as I go and see what I can do with it for these demonstration purposes.
Finally finished the GH primer 
For the sake of time I might just do this all manually the old fashioned way and just dream about doing it via constraints, and add constraint style stuff later, cause the boss might get mad if I take too long on this 
Initial file prep:
rectangular_plate.3dm (2.9 MB)
I’ll add more developed versions later.
I’m mostly sharing this job to make it more interesting for me and also to provide real world example for what I’d like to use ‘constraint’ style technology for – until a good constraint-UI exist, it will mostly be theory and prototyping.
From the initial setup you can see the rectangular prism looking object appears to be real close to the dimensions of 3"x6"x0.75".
The problem here is I don’t know exactly what the design intent is or even the tolerances. However, it would be nice to be able to still setup the whole job in a manner where those 3 simple dimensions can be adjusted at any time via 3 simple inputs, to be whatever they need to be and automatically adjust. Hence, dimensional and geometric constraints.
For now I will just use the dimensions shown in my first screen shot, cause that’s what the silly thing measures via my digital calipers. And without the customer telling me what they want, I can only guess.
Apparently this thing will interface with a Fanuc M-16iB series robot, so I’ll try to upload the bad GD&T data I got for that in a minute.
I’m not even sure this will suffice. I might have to measure the robot directly or find better drawings lol. I’m not sure what they mean by h7 or H7
So far I used some midline references, offsets, and mirroring. Of course there’s many ways to constrain geometries n’ such. Basically used one 11/32" circle and mirrored it twice, then wirecut.
I will have to figure out the countersink angle later (similar previous job was 90 deg) and decide on some type of cone shape there.
similar prev job with diff dimensions, just checking countersink reference.
Using metric units referenced in an inch unit file should be fun
Would be nice if the hidden lines were dashed a little better. 
Oddly the print looks bettter than it did on screen …
Just that stuff you’re supposed ta put on your layouts to tell ppl how to make something 
