PR 257022 Profile evaluation is done different than in 3.7 even if you choose

huangyhg

Profile evaluation is done different than in 3.7 even if you choose "37 compatible"
<< Lothar Schafer  --  09/12/08  13:55:37>>
I run the official part program for machine acceptance test regarding ISO 10360-4. This program is done in version 3.7 and has to be compatible in version 4.3 as well.
For graphical output reasons I calculate several profiles type "FORM ONLY" in this part program. What I see in version 4.3 is, that the measured value of the profile is NEGATIVE in some cases (SCAN3 and SCAN4 in the attached PDF files). This is impossible for profiles. Form ONLY profile has to be MAX-MIN, positive value. The calculation looks very strange, if you compare maximum, minimum and measured data.
For comparison I did the same measurement with version 3.7, here everything is OK. So I think something is broken in the profile evaluation after converting 3.7 programs to version 4.3. This means that all the old part programs are no longer compatible in version 4.3.
For further investigation see attached files with part programs, probe files and output files, both in version 4.3 and 3.7.
<<END>>


<< Changes made by Neil Kay -- 02/20/09  12:46:23>>
Status:  RESOLVED to CLOSED
<<END>>
<< Jerry Naylor  --  10/29/08  16:53:56>>
wasaddedtoreadme431
<<END>>
<< David Petrizze  --  10/13/08  09:20:35>>
Reviewed.
<<END>>
<< Changes made by David Petrizze -- 10/13/08  09:20:39>>
Action:  CMM Group to Lothar Schafer, Status:  REVIEW to RESOLVED
<<END>>
<< Don Turcotte  --  09/29/08  14:58:25>>
I have resolved this for Lothar by changing the profile formonly math so that formonly includes size only when the UseISOCalculations registry setting is false.  When this setting is true, the V37 calculation for profile formonly is used which does not include consideration of size.
Changed in V43B, V44B, V431 (V43 MR1).
Files inserted to server
------------------------
V431\DIMENS\DIM_PROF.CPP
V43B\DIMENS\DIM_PROF.CPP
V44B\DIMENS\DIM_PROF.CPP
<<END>>
<< Changes made by Don Turcotte -- 09/29/08  15:00:32>>
Action:  Don Turcotte to CMM Group, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  09/23/08  10:58:05>>
I have received test results from Rob Jensen and discussed with him.  Rob Jensen has tested this with both legacy and FCF profiles.  Everything in V43MR1 is now working correctly according to standard including profile formonly.  The only issue he noted is that the Min/Max fit for formonly does not report the expected results.  He will do further testing.  I have attached his test program.
<<END>>
<< Don Turcotte  --  09/19/08  17:14:53>>
I have talked with Rob Jensen and he is going to test the latest changes.  We are inclined to undo the changes that were made at Bob H.'s request to include size in the evaluation of formonly since this is causing other users problems.  If the user wants to include size in the consideration of size, this can be done with an external alignment and a formandlocation profile dimension.
<<END>>
<< Don Turcotte  --  09/18/08  17:22:08>>
I have addressed the issue of removing NO_FIT from the list of bestfit types in Task #104732 (only in V44B with FCF profiles).
<<END>>
<< Don Turcotte  --  09/18/08  17:19:31>>
I received the following e-mail from Frank Herr via Bob H.:
""we had an internal discussion also with our AE Quindos expert about this issue. We agree completely with your arguments:

a)       Form only should never allow to be used without a BestFit
b)       Vector BestFit should be the default.
c)       The profile have to be accurate (means all theoretical radius values which describing the profile should be correct)
d)       ISO didn’t include a similar description for profiles like roundness, cylindricity, straightness, flatness, …  for the special cases of profiles
(some customers like to see it but it’s not part of the ISO.


<<END>>
<< Don Turcotte  --  09/17/08  17:11:40>>
I sent the following e-mail to Bob H., Lothar, Frank Herr, Rob Jensen, Dave P.:
"The four profile dimensions in question in the 10360-4 program have formonly and NOFIT selected (DIM SCAN1, DIM SCAN2, DIM SCAN3, DIM SCAN4).  I changed these to be VECTOR fit with the appropriate workplane.  I obtained the following results with the latest V43 MR1.  There was a problem with the linear graphic related to changes for PR# 256922 which I have fixed, but I have made no other changes to the code.  With a VECTOR fit selected, the results appear to satisfy the concerns that Lothar had.

Regards,
"
<<END>>
<< Don Turcotte  --  09/16/08  17:04:04>>
Sent the following e-mail to Dave, Lothar, Bob Hospadaruk, et al.:
"Dave,

Lothar has retested this and the profile formonly results are still not acceptable to him using the ISO 10360-4 program.  In order to resolve this dilemma, I have modified the code to use the registry setting for UseISOCalculations to control whether formonly includes size as Bob has requested (UseISOCalculations false) or formonly ignores size (UseISOCalculations true) as it did in earlier versions of PC-DMIS.  

I have verified that this change corrects the problems that Lothar has noted, but I have not uploaded my changes.

Since UseISOCalculations also controls whether formandlocation reports the profile deviation as (max-min) (UseISOCalculations false) or as 2 times max deviation (UseISOCalculations true), it may be better to add a new registry setting to control how formonly works.

Any comments/suggestions would be appreciated.

"

Bob Hospadaruk responded:
"I’m curious about Lothar’s opinion on this; the 10360-4 test should include affects of size in the evaluation of the scan data.
From ISO 10360-4 paragraph 6.1.b:

b) the maximum absolute difference between any individual calculated radius and half of the certified value of the
diameter of the test sphere is no greater than MPETij as specified by the manufacturer taking into account the
uncertainty of measurement according to ISO 14253-1, and…

I see from Lothar’s comments in the PR, his concern is mainly that the MAX value might sometimes be negative (I which case the MIN would be more negative).  I don’t think the complaint is about wether or not Formonly includes size effects, but rather that the MAX value might sometimes be negative.

Lothar, couldn’t you use some logic in you evaluation to change your algebra if the sign of MAX and MIN are the same?  MAX and MIN are both negative when all datapoints are less than the nominal size.  This is a situation that we must trap for the ISO 10360-4 as well.
"
<<END>>
<< Changes made by Lothar Schafer -- 09/16/08  17:06:34>>
Product:  Spiral Bevel Gear to PC-DMIS
<<END>>
<< Lothar Schafer  --  09/16/08  17:01:35>>
Hi Don,
I just made this test with the actual version, but the results are still wrong. Please compare the attached file "Report002.PDF".
What I see:
Scan 1:  MAX = +0.00016
               MIN = - 0.00066
               MEAS = MAX-MIN= 0.00082   =>  CORRECT
               OTOL  = 0.0012
               OUTTOL = 0.0006                   =>  INCORRECT
               RIGHT SHOULD BE:
               OUTTOL = 0

Scan 2:  MAX = -0.00011
               MIN = - 0.00074
               MEAS = -MIN= 0.00074            =>  INCORRECT
               OTOL  = 0.0012
               OUTTOL = 0.00014                   =>  INCORRECT
              RIGHT SHOULD BE:
              MEAS = MAX-MIN = 0.00063
              OUTTOL = 0

Scan 3:  MAX = -0.00014
               MIN = - 0.00057
               MEAS = -MIN= 0.00057            =>  INCORRECT
               OTOL  = 0.0012
               OUTTOL = 0
              RIGHT SHOULD BE:
              MEAS = MAX-MIN = 0.00043

Scan 4:  MAX = -0.00006
               MIN = - 0.00066
               MEAS = -MIN= 0.00066            =>  INCORRECT
               OTOL  = 0.0012
               OUTTOL = 0.00006                  =>  INCORRECT
              RIGHT SHOULD BE:
              MEAS = MAX-MIN = 0.0006
              OUTTOL = 0

It seems that the calculation goes wrong, if the MAX value is negative.
My question: Why is the MAX value calculated to negative?
In version 3.7 the MAX value is calculated positive. Is here a fit  missing?
<<END>>
<< Changes made by Lothar Schafer -- 09/16/08  17:04:31>>
Status:  MOREINFO to OPEN
<<END>>
<< Changes made by Lothar Schafer -- 09/16/08  17:04:09>>
Action:  Lothar Schafer to Don Turcotte
<<END>>
<< Changes made by Lothar Schafer -- 09/16/08  17:03:35>>
Category:  dimensions to , Product:  PC-DMIS to Spiral Bevel Gear
<<END>>
<< Tim Wernicke  --  09/15/08  15:19:09>>
ftp://ftp.wilcoxassoc.com/PC-DMIS-Versions/RC/v4.3MR1/
<<END>>
<< Don Turcotte  --  09/15/08  15:49:41>>
Lothar,
A fix was made for PR#256922 on 09/10/08 to correct the problem of negative values for the measured value in formonly.  I suspect that you have not tested with this modified version.  Please re-test with the most recent version of V43 MR1.
<<END>>
<< Changes made by Don Turcotte -- 09/15/08  15:50:17>>
Action:  Don Turcotte to Lothar Schafer, Status:  OPEN to MOREINFO
<<END>>
<< Don Turcotte  --  09/15/08  15:15:24>>
Sent e-mail about this issue to Dave, Bob Hospadaruk, Rob Jensen, Tim:
"Dave,
This is a V43 MR1 Stop Release issue reported by Lothar who is using the ISO 10360-4 program.  This problem was introduced by the change that we made for PR#254323 and PR#254833 (submitted by Bob) to include the consideration of size when evaluating formonly profile.  

Rob Jensen, in PR#256922, has noted several other issues that these changes have caused.   I discussed these with Rob and came up with the best possible solution short of undoing the fix for Bob’s PR’s.

With the additional problems now cited by Lothar in the ISO 10360-4 program, I see three possible courses of action:

Undo the changes for PR#254323 and PR#254833 that include the consideration of size when evaluating formonly profile.  Rob has handled this in the past by instructing his users to construct an appropriate alignment to evaluate formonly when size is important (using formandlocation instead of formonly).
Keep the current changes, but require to user to construct a feature of size (CIRCLE, CYLINDER, SPHERE) from the data in order to evaluate formonly with size.  In this case, formonly on a scan or non-feature of size would revert to the V37 method of computing formonly which does not take into account size.  This has limitations since the user may have a surface which is not a feature of size but the user wants formonly to take into account size.  In this latter case, the user would be forced to revert to constructing an alignment as done in #1 above.
Add a checkbox to the dialog that allows the user to control whether formonly includes size or not.  Since the resources are frozen for V431 (V43 MR1), this would seem to be a course of action only for V44B.

Any suggestions?
"
<<END>>
<< Changes made by Tim Wernicke -- 09/15/08  08:59:28>>
Action:  Tim Wernicke to Don Turcotte, Assigned:   to Don Turcotte, Priority:  Critical to Stop Rel.
<<END>>
<< Changes made by Lothar Schafer -- 09/12/08  14:05:36>>
Priority:  to Critical
<<END>>