GD&T Cone Configuration

[[Br...]]

I have a couple questions relating to cones. My first question is after constructing a Ø using an intersection, I would like to get the circularity of the Ø. When I try this using the 'Circularity' definition within the GD&T menu, nothing will display, and I'm left pulling in the 'Result Element' and using a formula from the form value. Is it possible to get the circularity callout of a constructed feature? Appreciate any help with this issue, thanks. 

[[Br...]]

Please sign in to view this quote.

…sorry I should have been a little more explicit about the meaning of the form value I’ve used. What I did was take the form value of the cone because that was all I had to go on. Thank you…

[[Ch...]]

I would think probably not due to the fact it is a constructed feature.

 

If you measured the cone with 2 paths, you could :

1) recall each path points to a circle to evaluate individual roundness or 'circularity'.

2.) Since cylindricity can only be used on cones , and they do not have "conicity" - but perhaps they should ? - you can use the 'Form' characteristic on nearly any feature.

In theory I would imagine this would be a fairly close result to if it were intersected and able to report out.

 

There is probably some other super crafty way as well as projecting measure points along your measured cone angle to your surface - just theorizing, not sure how it would be done. I'd go with method 1 or 2. 

 

 Good luck.

[[Br...]]

Thanks for following up Chris much appreciated. Your 2nd method is what I actually used to get some kind of a result seeing there wasn't anything else to work with. Since it's not available, I wonder, if a person were to take each of the features used to create the constructed feature and do some type of mathematical conversion. In a sense help the software come to a resolution. How about using one of the features (i.e. flat surface) the construction has and setting up an alignment using this measured feature. Then, do the same constructed circle? 

 

[[Br...]]

I had another question on top of this one, and here it is...

Its cone related and like the first, it would help to put this oddity to rest also. Take a measured cone with two scan paths and report the angle. I already know the angle is correct, however, we need the actual reported per print. The print states this conical feature should be 30°, pretty simple right, but we get something in the neighborhood of 129°...? Under some circumstances I would use the 'Half Cone Angle' from the pull-down, but as you can see this will not work in this case, since I'm looking for something to be in the neighborhood of 30° and not 64.5°. What I end up doing in this case is measuring a line either up or down the slope. It gives the correct angle, but I was looking at being efficient by using the cone feature to correctly display the angle. Some cone features have no problem reporting the correct angle, however, some come up different and being quite off the mark. Is there an answer to this issue, without creating multiple alignments just to get a simple callout for one dimension? Again, appreciate your help on the first one, any help here would be much if not more appreciated...thank you!

[[Ch...]]

For the first topic; my best advice would be : if you want form, avoid using a constructed feature...use a measureable feature..so...

Measure 16 lines on your cone and intersect them all with the plane. Recall the intersections into a circle ...should do it, havent tested it, pretty sure I've done it in the past.

For non-standard angle reporting, you will likely have to take the results and subtract it from 90° with a formula. 90% of the time if the cone is from the CAD model. either its full angle or half angle matches print in my experience. PErhaps your cone angle is truly off, try measuring 6 lines - and report individually, you can just recall them into a cone as well.

Good luck.

 

 

[[Br...]]

Thanks for the feedback. Your 16-intersecting point definition of a circle makes more sense than taking a cone itself to construct a circle, at least for a callout of circularity. I haven't tried that either, but again, it makes sense to create a circle with points rather than two separate scan paths at two different levels (cone). There could be too many variables for the software to handle if you're using two paths (cone) at an intersection. Afterall, it's only one path that creates a circle and not two.

The high angle differences from my second cone configuration needs more thought. It has to be something with the software and how it's calculating the alignment while using two features to get the angle. Unless you can find out more on that subject, will need to tinker around with that one a little more. The angle of 30° is correct, the software is doing something else in the background...?? Will have to see how the first issue of circularity turns out. Thanks again.