PR 242340 Question on how Profile is calulated for Jan at Lockheed

huangyhg

Question on how Profile is calulated for Jan at Lockheed
<< Don Ruggieri  --  08/08/06  13:01:13>>
data is in  08072006_01a.zip.  Jan DeNijs at Lockheed is a PC-DMIS NC customer using version 4.0.   He has some questions on the way Profiles are calculated.  I briefly discussed this with Don Turcotte and decided ti was best to log it in as a problem report for Don to address.  Below is Jan's e-mail message -
Steps to reproduce:
Here’s how I build the report for the planar features:
1.      I output the Z-values plus the flatness of the plane. This gives me a good idea where the plane is in machine coordinates.
2.      I output the profile to the calculated plane
3.      I output the profile to the set of individual points
4.      I output 1 point to give me a Z-reference. This is again to give me some nominal Z-reference.
5.      I output the profile to the individual points

Simple question 1: why, on a profile, does the nominal read 0.0000 in the print-out? Shouldn’t that be the Z-value (basic dimension)?
Simple question 2: why is the report bar on the right always purple for the negative values, no matter what I have? Why is it colored at all when my profile is almost zero? I would expect small colorations to the negative, like I have when the error goes positive. But it seems the purple bar is always solid purple on the negative side. Please explain.
Anyway, for plane DATUM –H- all seems well.
3.      But now go to the back of the report and find feature PLSH10H8. Now look at the profile to the plane and the profile to the point set. The plane is T.0009 and the point set is -0.0001? Why this huge difference? Looking at the Z-raw data, it seems to me that -0.0001 would be the right number. Where does this +0.0009 come from??????????????
This feature has the worst discrepancy. But PLSH10D4 “B”, PLDATL SH3, PLSH6G4, PLSH10B1, PLSH10A2, PLSH10F2, they all seem to suffer from the same issue.

4.      Please review PLSH10F3 “A”: here I have 0.0005” for the calculated plane profile, 0.0004” for the set and 0.0003” for the worst of the individual points. Which one is the correct one????? In most cases the set seems to agree with the individual points. But on this one, they all disagree.

5.      I guess that I want to know exactly how profile is calculated. If you look at the data, you’ll find that in some cases I am dealing with a small datum plane on one side of the part. And the profile on a small other plane far from the datum plane is called out to this small datum. How does profile get calculated? Is the datum plane (best fit plane???) extended under the actual plane? Or is the Actual plane extended until it is over the datum? How are planes bounded (in case of parallelism)?
<<END>>
<< Changes made by Neil Kay -- 02/24/09  19:03:23>>
Status:  RESOLVED to CLOSED
<<END>>
<< Rex Heagy  --  07/30/08  12:55:07>>
Reviewed.
<<END>>
<< Changes made by Rex Heagy -- 07/30/08  12:55:14>>
Action:  Rex Heagy to Don Ruggieri, Status:  REVIEW to RESOLVED
<<END>>
<< Changes made by Neil Kay -- 07/22/08  19:35:42>>
Action:  David Petrizze to Rex Heagy
<<END>>
<< Don Turcotte  --  08/25/06  13:10:02>>
Actually, executeprivate of CPCDdim_profile should also check the sequence of the datums since the datums may have been remeasured but not the considered feature.  (This was not the problem with Jan's program.)  I added code to do this.

In summary, I made corrections to Dim_prof.cpp is_ready() (see below) and executeprivate() as well as corrections (see below) for the linear graphic bilateral control in DimensionReportControls\DimLinearControl.cpp and
MENU\DIMENSIO.CPP.
Files inserted to server
------------------------
V41B\DIMENS\DIM_PROF.CPP
V42\DIMENS\DIM_PROF.CPP
V43B\DIMENS\DIM_PROF.CPP
<<END>>
<< Changes made by Don Turcotte -- 08/25/06  13:10:09>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Don Turcotte -- 08/25/06  12:03:31>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to OPEN
<<END>>
<< Don Turcotte  --  08/25/06  10:55:52>>
The issue here is that the profiles in Jan's program have a NULL pointer to the primary datum so PC-DMIS uses the V3.7 algorithm for computing profile which is computed relative to the current active alignment.  When you F9 the profile and press OK, the profile command is recreated with correct datum references.  The serialization of CPCDdim_profile was fixed by 236954 in November, 2005 to serialize the datums in both V40 and V41.  Jan started with a V3.7 program and was running an early version of V40.  Tony has talked to Jan and is sending him an e-mail to recommend upgrading to V41.  Jan understands that he will have to edit all the profile dimensions (F9 + OK) or recreate them to get corrected profiles with datum references.  We have verifed here that once the profiles have been edited and have correct datum references, saving the edited program will correctly save the datum references so when the program is reloaded everything works correctly.
I have also verified that when the program is executed from the CNC journal file, the sequence numbers have been set up correctly so the executeprivate() of CPCDdim_profile will call do_math().
<<END>>
<< Changes made by Don Turcotte -- 08/25/06  10:56:07>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Bill Wilcox  --  08/25/06  07:40:29>>
Don, please call me on this. thanks.
<<END>>
<< Don Turcotte  --  08/24/06  17:45:17>>
I reopened this because Tony G. says it still doesn't work when executing from a CNC journal file.  I worked with Tony and was able to duplicate what he is doing.  After executing this way, the value for FCFPROF4 (PLSH10F2) is -0.0005.  But when you F9 this profile and refresh the report the value is 0.0002.  We are still trying to figure out what is going on...
<<END>>
<< Changes made by Don Turcotte -- 08/24/06  17:45:18>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to OPEN
<<END>>
<< Don Turcotte  --  08/24/06  13:00:24>>
Further testing with my test program using the offline simulator with noise data and everything seems to be working correctly now.
<<END>>
<< Changes made by Don Turcotte -- 08/24/06  13:01:15>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  08/24/06  11:19:59>>
The issue here seems to be that the is_ready() of CPCDdim_profile is not checking for the datum features to be ready (V3.7 and earlier had no datums) so the do_math() can be called before the datums have been measured.  I have uploaded a fix for this.
Files inserted to server
------------------------
V41B\DIMENS\DIM_PROF.CPP
V42\DIMENS\DIM_PROF.CPP
V43B\DIMENS\DIM_PROF.CPP
<<END>>
<< Bill Wilcox  --  08/24/06  08:09:46>>
By editing the dimensions you are forcing them to be re-calculated. If they are not up to date before that then there is a problem with the optimixzation in PC-DMIS to only re-calculate something when an input has changed. The inputs all have a sequence number and the dimension has a sequence number. The dimension does not get re-calclated unless at least one of the input sequence numbers is greater than the dimensions. Seems like we need to verify the sequence numbers of the features to determine the order that they are getting updated.
<<END>>
<< Don Turcotte  --  08/23/06  17:35:40>>
When I load the program in Profileissue.zip and show the report, the values for profile are wrong.  If I F9 on the profile command and then press OK and refresh the report, the values look better.  In some cases (e.g., PLSH10F2) the profile is still off from what I would expect by about .0002, in other cases (e.g., PLSH10D4 "B")  it seems to be almost right on (off by .00005).  I created a separate program in PR242340 and modified the nominals to create a known error.  The profile reported relative to the datum in this test was correct, so I am confident that the profile is being reported relative to the datum.  I am not clear on how to resolve this and Ken thinks it may be related to the NC process.  I’m not clear that it is, but it seems odd that when you load the program and show the report, you get bad numbers, but F9 on the dimension commands and everything improves.
I sent e-mail to Tony G. and Dave for suggestions.
<<END>>
<< Don Turcotte  --  08/22/06  18:11:25>>
Looking at these addition issues from Jan...
<<END>>
<< Don Turcotte  --  08/22/06  18:10:17>>
Additional issues from Jan in e-mail (ref. Profileissue.zip)
"If you look at the program, I first establish a datum frame called F, E, G., please see the first page of the PDF file. This reference frame is on the fixture.

Then I measure a plane on the part called DATUM -H- SH3 E7 and evaluate it to FEG for profile. I do not see a problem with that.

Then I measure 2 cylinders and call them datum J and datum K. I set up the datum structure.

Then on the bottom of page 4, spilling over onto page 5, I measure plane PLSH10F2 and try to evaluate the individual points to HJK. Here is where the problem is!!!!!!!!!!!!!!!!!!!!!

Please note that datum –H- is low by about 0.0005”, see the actual Z-position data. And the profile reports that.

Then I measure PLSH10F2 and try to evaluate to HJK. Based on the actual Z-data, plane PLSH10F2 shows to be just as low as datum –H-. These 2 planes are close together and have very good flatness and orientation. Since PLSH10F2 is just as low as –H-, I would expect that PLSH10F2 to have an almost perfect profile to HJK. See page 5, and it reports -0.0005 for the profile. This is totally wrong! It reports the numbers to something else, maybe EFG?????? It can NOT be to HJK! And that is wrong!!!!! Maybe it does not report to any datum whatsoever.

The next plane PLSH10F3 "A" shows the same behavior.

Now skip to page 13. I measure datum –L- there. Observe that again it is not evaluated correctly. -L- is only about -0.0001 below HJK. But profile is again reported based on the actual Z-measurements (or maybe EFG). It reports the profile out, while I am convinced that to HJK it should have been very good.

After –L-. I set up a new reference frame with datum LMN.

So until now it seems that PC-DMIS does not evaluate to the (proper????) datums when dealing with profile!

Now here comes the kicker: see page 18, 19, 20: PLSH10D4 "B". It is evaluated to LMN. Seemingly now, this is done (almost) right!!!!!!!!!! It seems as if that plane PLSH10D4 "B" is properly evaluated to the datum frame (although I am still a little suspicious that it actually may be referencing HJK).

So anyway, here is the problem: why does PC-DMIS appear to not evaluate to Datum H when measuring PLSH10F2, but it does work correctly when I evaluate PLSH10D4 "B" to LMN. So sometimes it seems to work, sometimes it does not.

From here on out, it seems to be working just fine!!!!!!!

Now it seems that PC-DMIS actually IS evaluating to (the proper; I am not sure) datums!

So why does it do it right in one instance, and wrong in the other????????????? Makes no sense to me. Must be either pilot error or a bug of some kind.

On top of that, I have this confusing reporting of actual profile number.

Please try to give this your soonest attention as this is becoming a major issue here!

Thanks, Jan.
"
<<END>>
<< Don Turcotte  --  08/22/06  15:26:17>>
In summary,
Simple question 1: The nominal for a profile is the nominal profile tolerance which is normally 0.0 (just as nominal flatness is zero).  It's not the Z-value since a profile is considered to be on a generic surface, not necessarily a plane.  It's just the deviation of the actual measure points from the nominals along the nominal vector, so with perfect data the profile is 0.0.
Simple question 2: why is the report bar on the right always purple for the negative values, no matter what I have?  I have uploaded a fix for this problem in the linear graphic.
3.  Profile of plane and profile of point set are different.  If I create a new profile FCF on the plane, then I get the same result as the point set.  Also, if I F9 on the existing profile of the plane and then press ok, the recalculation gives the same value as the point set.  The question here is how were these commands originally created.  Is this an issue of the values not being the same after execution?
4.  Again, if you F9 on the plane profile and then OK (causing a recalculation), you get 0.0004, the same as for the set.  I don't know why the plane profile was different when first created, but I don't know the whole sequence of events that went into creating this program.  If you look at the range of deviations for the individual points, you will see that they range from 0.0003 to -.0.0001 which is also a total deviation of 0.0004 (PC-DMIS reports max-min when max and min are opposite signs).  So this seems to be working correctly.
5.      I guess that I want to know exactly how profile is calculated.   The datum plane(s) is simply used to create a datum reference frame alignment.  This alignment is applied to the considered feature such that the difference in the nominal and actual datum reference frames is reflected in the considered feature.  The profile is simply the difference between the nominal and actual measure points along the direction of the nominal vector.  The reported profile value is the max - min deviation.

I have uploaded my changes to fix the linear graphic.
Files inserted to server
------------------------
V41B\DIMENSIONREPORTCONTROLS\DimLinearControl.cpp
V41B\MENU\DIMENSIO.CPP
V42\DIMENSIONREPORTCONTROLS\DimLinearControl.CPP
V42\MENU\DIMENSIO.CPP
V43B\DIMENSIONREPORTCONTROLS\DimLinearControl.CPP
V43B\MENU\DIMENSIO.CPP
<<END>>
<< Don Turcotte  --  08/21/06  17:26:55>>
Simple question 2:  I have fixed the problems with the linear graphic but I haven't uploaded my changes yet.
4.  Again, if you F9 on the plane profile and then OK (causing a recalculation), you get 0.0004, the same as for the set.  I don't know why the plane profile was different when first created, but I don't know the whole sequence of events that went into creating this program.  If you look at the range of deviations for the individual points, you will see that they range from 0.0003 to -.0.0001 which is also a total deviation of 0.0004 (PC-DMIS reports max-min when max and min are opposite signs).  So this seems to be working correctly.
<<END>>
<< Don Turcotte  --  08/11/06  14:21:56>>
Continuing to look at this... The way that the linear control is set up is not correct for bilateral profile tolerances.  The text graphic is correct so I am looking at how these differ in the way that the data is set up.
<<END>>
<< Changes made by Bill Wilcox -- 08/11/06  09:09:21>>
Assigned:  Paola Pallo to Don Turcotte
<<END>>
<< Don Turcotte  --  08/10/06  17:35:02>>
Continuing to look at this... I did notice that if I F9 on the plane profile FCF command and then simply press OK on the FCF dialog, then the profile re-computes with the same deviation as the profile on the individual points.  I'm not sure why that is but possibly the plane profiles were created first and then some other changes were made to the program.  I also tried creating an alignment that is the same as the datum reference frame and doing a legacy dimension for comparison.  I still can't explain all the results that I am seeing.
<<END>>
<< Changes made by Don Turcotte -- 08/10/06  17:35:02>>
Priority:  Medium to Critical
<<END>>
<< Don Turcotte  --  08/09/06  17:35:02>>
Simple question 1: The nominal for a profile is the nominal profile tolerance which is normally 0.0 (just as nominal flatness is zero).  It's not the Z-value since a profile is considered to be on a generic surface, not necessarily a plane.  It's just the deviation of the actual measure points from the nominals along the nominal vector, so with perfect data the profile is 0.0.
Simple question 2:  Always purple for negative values seems to be because all the deviations are positive.  Although, purple is not the appropriate color here. Still looking at this.
Simple question 3:  Why the profile of plane gives different value than the profile of individual points is a problem.  I am also still looking at this.
<<END>>
<< Changes made by Tim Wernicke -- 08/08/06  13:32:03>>
Priority:  to Medium
<<END>>