Auto Cone extracted from a COP

I was reading your clicking comment as something you did when it was time to select features for intersecting the cone and the plane. If you had had two cones at the same place, then it would have been possible that you selected different cones when clicking on the different ends.

As for the original problem, I agree with you - the intersection with a plane should be in the same place if the differently constructed/measured cones really are exactly equal. but depending on how the points are collected, if the cone is constructed or measured directly, if the probe compensations of the measuring points are used as from the original vector/surface points ( BF) or re-computed ( BFRE) using the surface normal of the computed cone, all of this may make a difference, especially if you're using vector points, but also a surface point may well have a vector different from the same point calculated from the actual cone.

Normally the differences are very small, but as a draft angle doesn't make for 'nice' cones (vertex very far away, if I understand it correctly), the sensitivity even to small measuring errors can be quite large. Also, the draft angle may not be present in the cad model, giving PC-DMIS the wrong theoretical surface normals.

Our models here always have the correct draft angles on them. We make our own models here. The patterns are made from our models. It's not always a draft angle I am measuring....I have also had cone features that were part of the casting design ( nice cones ) that when done with auto cone, come up way off.

Since you mentioned that draft angles do not make nice cones ( vertex far away ) , I assume you are talking about the constructed cone. Again, the results that I get from the constructed cone isn't what I have an issue with. If you look back at my original post, I verified my results with a caliper. The result from the constructed cone and the caliper matched. It is the auto cone that gave the wrong results. It would just be nice If I could trust the results from auto cone. Only reason I would like to make more use of the auto cone feature is that it reduces lines of code. On average I take 20 surface points to construct my cones. 20 lines of code versus 1 line of code for each cone feature.

I have had auto cones give results over an inch off on a 9 inch dia. circle, way beyond measurement error.

Tech support finally did remote in last week( after I posted this thread ) and saw what I am talking about. That person did not have an answer. They said they were gonna get other people involved. That is the last I heard from them. If I am doing some thing wrong, I would like to know what that is. I don't think I am though, I think it is in the software.

Thanks for your input.

I did some offline testing, and mathematically on perfect CAD hits, an auto cone and a cone constructed from the hits of the auto cone are completely equal, except for the CONE_START and CONE_END values. Any construction involving CONE_START or CONE_END will get different results on auto cone and constructed cone.

I never used cone start or cone end as one of my inputs to construct my circles. I either use an existing plane( intersection of cone and plane ) or a defined height from "origin". Actually I never used the cone feature in the construct a circle menu until I ran into this issue and started to play around with different options to see if some thing else would work. All it did was make me scratch my head even more.

At this point, I am just going to wait for the ticket close email to come through and I will respond " still waiting for answers "

Update: Had a team viewer session with a Hexagon Application Engineer yesterday. He saw what I have been seeing and was able to replicate the issue on some test parts at his facility. He has logged it as a bug along with a color mapping issue I found in 2016.

On a side note, I also asked if I should be using BFRE to construct circles, cones, cylinders etc., etc. He said BFRE is for hard probed points, not laser scan points. Although he said it wouldn't hurt anything if BFRE was used, but that you wouldn't see any real difference in the results.

Sounds to me like the noise you're getting from the cone's scan isn't being filtered out properly. That noisy cone yields a noisy circle.

If you're taking auto surface points and constructing a cone out of it, that filtering is being set inside of the feature, but since it's on a CONICAL surface, the auto surface point isn't the correct one to use. Auto surface points are going to create an average centroid from all the points subsampled. The more curved the surface, the smaller an area you have to sample to be repeatable, and therefore you'll be the most susceptible to noise. Best to stick with Auto Cone in this application.

- are you correctly using your center offset (green) / search length (purple) / clipping parameters and confirming your pointcloud subsample via the segregated points option? This is fundamental to using any laser-extracted features in PCDMIS, please see the attached picture





-Is your auto cone coming from a scanned pointcloud or scanned mesh? Clearly a scanned mesh will have less noise than a pointcloud

-How are you filtering your cloud before you construct a cone from it? Are you using Random? Curvature? Uniform? What standard deviation of points are you keeping inside of the Auto Cone?

-Is it sprayed? or are you scanning on a shiny surface? Obviously we prefer a sprayed surface. If the surface is shiny, maybe a zigzag/flyingdot scanner would prove more effective than a line scanner

IMO, your Auto Cone isn't correlating to your Constructed Cone due to a difference in subsampling or filtering.