PR 249541 Angle evaluation is incompatible with older versions - signs of eva

huangyhg

Angle evaluation is incompatible with older versions - signs of evaluations change
<< Lothar Schafer  --  08/02/07  17:16:16>>
I opened an old part program, programmed in version 3.7 MR3, that includes two dimensions of projected angles of a cylinder (evaluation to axis X and to axis Y).
Running the part program in version 3.7 MR3, I get the values I expect, they have the right sign and the programmed nominal is OK.
Running the part program in version 4.2 MR1 without any change, the measured values have inverted signs, the nominals are still the same. This means that the version 4.2 MR1 is incompatible with old programs that include angle evaluations.
The problem might have to do with the former possible toggle box TRUE e.g. COMPLEMENT that does not longer exist in 4.2.
A customer has the same problem in the actual 4.2 release with 35 degrees angles. They will never accept the software, if this compatibility is not given.
See attached ZIP File containing part program in 3.7, part program in 4.2, probe data and reports of 3.7 and 4.2.

Steps to reproduce:
Program an angle evaluation in 3.7 MR3
Run the program in 4.2 MR1
Results:
Dimensions have measured data with different signs
Expected Results:
Results should be absolute identic.
<<END>>



<< Don Turcotte  --  02/02/09  11:03:02>>
Mike e-mailed me about issues Korean customer is having with 2D angle.  Issue seems to be that they expect angle to change based on workplane.  I asked for more info from Mike.
<<END>>
<< Don Ruggieri  --  06/03/08  13:58:11>>
I've been testing these changes (via the local build) in v43R and comparing them to v37, and in all cases v43R looks good.  I've been using +/-180 and 0-360 settings, working with angles close to 180 as well as many others.  I've not been able to find a case where v43R can be considered wrong.  Even the sign of the deviation is correct in every instance I can see.
<<END>>
<< Don Turcotte  --  06/02/08  11:58:13>>
Last problem from Don R. : when in +/- 180 mode make sure angles are not < - 180.
******************************
Mon Jun 02 11:56:38 2008
******************************
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Turcotte  --  06/02/08  09:12:23>>
I have fixed the additional issue from Don R.
"Using my Angle_Test_03 program (attached) I have it set to 0-360.  I have the start at -, end at 225, and increment of 45.   When I execute the program, in the report, all the measured angles are positive as I would expect.  The question I have is regarding the nominal angles, some of them are negative.

Now keep in mind that I am using a loop and a variable to set these, but there are programs out there using variables as well to set nominal values.  I don? know the answer to this, but it is worth considering.  Should we be changing (making positive) nominal values that are set from variables?
"
Fixed in V42R, V43R, V431, V43B, V44B

******************************
Mon Jun 02 09:10:47 2008
******************************
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Turcotte  --  06/02/08  09:12:23>>
I have fixed the additional issue from Don R.
"Using my Angle_Test_03 program (attached) I have it set to 0-360.  I have the start at -, end at 225, and increment of 45.   When I execute the program, in the report, all the measured angles are positive as I would expect.  The question I have is regarding the nominal angles, some of them are negative.

Now keep in mind that I am using a loop and a variable to set these, but there are programs out there using variables as well to set nominal values.  I don? know the answer to this, but it is worth considering.  Should we be changing (making positive) nominal values that are set from variables?
"
Fixed in V42R, V43R, V431, V43B, V44B

******************************
Mon Jun 02 09:10:47 2008
******************************
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Turcotte  --  06/02/08  09:12:23>>
I have fixed the additional issue from Don R.
"Using my Angle_Test_03 program (attached) I have it set to 0-360.  I have the start at -, end at 225, and increment of 45.   When I execute the program, in the report, all the measured angles are positive as I would expect.  The question I have is regarding the nominal angles, some of them are negative.

Now keep in mind that I am using a loop and a variable to set these, but there are programs out there using variables as well to set nominal values.  I don? know the answer to this, but it is worth considering.  Should we be changing (making positive) nominal values that are set from variables?
"
Fixed in V42R, V43R, V431, V43B, V44B

******************************
Mon Jun 02 09:10:47 2008
******************************
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Turcotte  --  05/30/08  14:55:32>>
I fixed three additional problems based on Don Ruggieri's testing:
1.  When switching between +/- 180 mode and 0-360 mode, the angles should automatically update to make sense in the new mode.  V37R behaves this way.
2.  When entering a nominal, a negative value is converted to positive angle if in 0-360 mode.  An angle > 180 is converted to negative if in +/- 180 mode.  V37R behaves this way.
3.  The DEV and OUTTOL values should make sense.  For example if we are in 0-360 mode and the nominal is 0 but the measured is 359, then the DEV should be -1 (and not 359).  The same issue exists for +/- 180 mode when the nominal is 180 and the measured can be 179 or -179 (this should be DEV of -1 or +1).
I have fixed these problems in V42R, V43R, V431, V43B, V44B.

******************************
Fri May 30 14:35:12 2008
******************************
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V42R\INCLUDE\DIM_2D_A.H
V42R\MENU\DIMENSIO.CPP
V431\DIMENS\DIM_2D_A.CPP
V431\INCLUDE\DIM_2D_A.H
V431\MENU\DIMENSIO.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43B\INCLUDE\DIM_2D_A.H
V43B\MENU\DIMENSIO.CPP
V43R\DIMENS\DIM_2D_A.CPP
V43R\INCLUDE\DIM_2D_A.H
V43R\MENU\DIMENSIO.CPP
V44B\DIMENS\DIM_2D_A.CPP
V44B\INCLUDE\DIM_2D_A.H
V44B\MENU\DIMENSIO.CPP
<<END>>
<< Don Turcotte  --  05/28/08  17:30:36>>
From Bret:
"If they measure their lines in the opposite direction, shouldn? we be able to handle that.

Couldn? we add a check on the measured vectors before running through the main algorithm that checks to see if the nominal and measured values are 180 degrees off from each other and flip the vector accordingly before solving?
"

I have determined that the code was trying to do this but was implemented incorrectly.  I have fixed this and tested.
Fixed in V42R, V43R, V43B, V44B, V431.
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Ruggieri  --  05/27/08  11:27:47>>
Executing the program showed only a few anamolies, and Don T showed me that these cases are due to the feature nominal and measured vectors having the opposite signs.  Correcting this (in the feature) and updateing the related dimensions re-calculated these few so that they are all now in the same quadrant, and the deviations are in the range of feasability.
<<END>>
<< Don Turcotte  --  05/27/08  11:17:29>>
Latest issues from Don R. testing are related to fact that program has nominal and measured vectors in the opposite direction.
<<END>>
<< Don Turcotte  --  05/23/08  16:12:56>>
Don R.'s testing has verified that I have fixed the three remaining issues listed below on 05/22/08  17:11:11.
I have uploaded my fixes for these issues.
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Turcotte  --  05/22/08  17:11:11>>
I fixed three problems found by Don R.
1.  Angles at 180 degrees when in +/-180 mode don't always calculate correct measured.
2.  Sometimes get negative angles when in 0-360 mode.
3.  When the user lets PC-DMIS find the nominal, we also need to perform the same logic to find the correct relationship between the two features as we do when the user enters the nominal.  This is the logic implemented below on 5/20/08.
I gave Don R. the latest source files so he can build and test V43R before I upload.
<<END>>
<< Don Ruggieri  --  05/22/08  09:37:56>>
I submitted to Don T another test case this morning.  There is something happening when the angles are around 180 degrees that I don't understand.  I have two lines with a nominal of 180 degree angle.  I dimension them fron LIN1 to LIN2, and again from LIN2 to LIN1.
In the first case, the nominal is +180 and the MEASured reports as -179.671 so the DEViation reports as -359.671.  In the 2nd case the NOMinal is -180 and the MEASured is 179.671 so the DEViation reports as +359.671.  I don't see why yet, but they seem to be confusing the quadrants.
<<END>>
<< Don Turcotte  --  05/21/08  13:43:11>>
Did some more tests with Don R.'s latest test program which loops through start angle to end angle with a given increment.  Tried this in both +/- 180 mode and 0-360 mode and everything is working correctly.
<<END>>
<< Don Turcotte  --  05/21/08  11:15:20>>
In testing, Don R. found a case where the negative nominal did not produce the corresponding negative measured.  I found that the epsilon being used between the calculated nominal and the entered nominal was too small.  In some cases the calculation error was on the order of 3e-5.  I was using an epsilon of 1e-6, so I increased this to 1e-3.  Testing with odd angles such as 89.9, 41.5, etc. everything now works correctly.
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V431\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Don Ruggieri  --  05/21/08  11:11:23>>
We found one small test case which failed this rule.  Another fix is being implemented, and will be re-tested today.
<<END>>
<< Don Turcotte  --  05/20/08  17:45:38>>
I have fixed this by computing a temporary nominal based on the two vectors (V1 for feature1 and V2 for feature 2).  PC-DMIS will try four combinations to find a temporary nominal that is within epsilon of the entered nominal.

V1 to V2
V2 to V1
V1 to ?V2
?2 to V1

This will yield angles in each of the possible four quadrants.  Whichever case computes a nominal which is the same as the entered nominal, this combination is used when computing the measured angle.  With this change, I can load Ken? V37 program and get correct angles for all except the case of LIN1, LIN2 which has a nominal of 180.  These two lines are perpendicular, so a nominal of 180 makes no sense, and V43 will compute a measured of 90 which is a correct result.
If the user wants to enter a negative nominal (e.g., -90), the dimension setup must have angles set to +/-180.  If angles are set to 0-360, a nominal of -90 will result in a measured of 90 for lines that are perpendicular.  When angles are set to +/- 180, a nominal of -90 will correctly result in a measured of -90.

Fixed in V42R, V43B, V43R, V431, V44B
Files inserted to server
------------------------
V42R\DIMENS\DIM_2D_A.CPP
V42R\INCLUDE\DIM_2D_A.H
V43B\DIMENS\DIM_2D_A.CPP
V43B\INCLUDE\DIM_2D_A.H
V43R\DIMENS\DIM_2D_A.CPP
V43R\INCLUDE\DIM_2D_A.H
V431\DIMENS\DIM_2D_A.CPP
V431\INCLUDE\DIM_2D_A.H
V44B\DIMENS\DIM_2D_A.CPP
V44B\INCLUDE\DIM_2D_A.H
<<END>>
<< Changes made by Don Turcotte -- 05/20/08  17:46:36>>
Action:  Don Turcotte to David Petrizze, Assigned:  Paola Pallo to Don Turcotte, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  05/20/08  13:07:07>>
Skype call with Tim, Ken, Bret,
1.) Meas angle does not track nominal so if nominal is changed from 90 to 270, meas is reported relative to 90.
2.) V37 programs with complement flag set must be converted properly on loading.
<<END>>
<< Changes made by Don Turcotte -- 05/20/08  13:07:15>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to OPEN
<<END>>
<< Paola Pallo  --  04/24/08  17:00:52>>
Done.
For review:
V42R\DIMENS\DIM_2D_A.CPP
V42R\INCLUDE\DIM_2D_A.H
<<END>>
<< Changes made by Paola Pallo -- 04/24/08  17:03:53>>
Action:  Paola Pallo to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Tim Wernicke  --  04/23/08  16:12:32>>
Hi Paola, could you please merge your fix into V42R as well?  Thanks.
<<END>>
<< Changes made by Tim Wernicke -- 04/23/08  16:13:05>>
Action:  David Petrizze to Paola Pallo, Status:  REVIEW to OPEN
<<END>>
<< Don Turcotte  --  01/31/08  09:28:58>>
Reviewed.
This now works in a consistent manner for all cases of both lines and planes.  
<<END>>
<< Changes made by Don Turcotte -- 01/31/08  09:28:58>>
Action:  Don Turcotte to David Petrizze
<<END>>
<< Paola Pallo  --  01/18/08  15:37:19>>
Fixed. The angle between plane-plane should be calculated between their normal vectors , as for the line-line case.
Just to summarize :
1) the angle is considered positive when it is measured counterclockwise ( the input feature's  order is counterclockwise) , otherwise it is considered negative.
2) the angle between two lines ( or reducible to line feature as cone, cylinder, slot, ellipse) is calculated using the feature's vector (taking in consideration also its sign)
3) the angle between two planes is defined as the angle  between the planes' normal vector
4) a circle is considered as a plane feature
5) the angle between a plane and a line is calculated using a 'laying vector' that depends on the plane vector and  the current workplane
For review:
------------------------
V43B\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_2D_A.CPP
<<END>>
<< Changes made by Paola Pallo -- 01/18/08  15:37:56>>
Action:  Paola Pallo to Don Turcotte, Status:  OPEN to REVIEW
<<END>>
<< Gianni Revello  --  01/17/08  10:55:37>>
Paola, as agree, i've changed the status to open, in order to let you check the problems for Plane-Plane angles.
<<END>>
<< Changes made by Gianni Revello -- 01/17/08  10:56:01>>
Action:  Don Turcotte to Paola Pallo
<<END>>
<< Changes made by Gianni Revello -- 01/17/08  10:55:40>>
Status:  REVIEW to OPEN
<<END>>
<< Domenico Varacalli  --  01/15/08  16:27:10>>
I have made further tests with the calculation of the angles between two lines and between two plans. To see at the new file 249541_Base_Test_4.zip
The most evident problem is in the calculation of the Plane-Plane angle. With the new algorithm in 4.3 Version, the resulted measured angle is
always smaller of 90 degrees and therefore it is difficult to individualize the verse of the out of tolerance. Rather, the operator doesn't succeed
in understanding from that side should reprocess the part to correct the error. In the example (to look at the picture 90x4.GIF), I have prepared a practical
example with 4 angles between planes in the 4 quadrants, with working plane ZPLUS. During the execution of the program I have altered
(with a piece of paper) the points of the plans in such way to be gotten greater or smaller angles of 90 degrees. With the version 4.3 the angles are
always acute, instead with the version 3.7 could be coherent with the real dimension of the part.
But in this case the rule is not well defined. I think still some cases remain, that it would need to verify.
<<END>>
<< Paola Pallo  --  01/11/08  18:04:36>>
The actual results of D18,D20 etc. are correct and their sign is coherent with the rules implemented in v43 and generally accepted for the angle calculation (see the notes above) . The  large deviations come from nominal values that are wrong in sign.
<<END>>
<< Paola Pallo  --  01/10/08  17:24:57>>
Investigating on the wrong results, related to specific workplane cases.
<<END>>
<< Domenico Varacalli  --  01/08/08  14:18:56>>
I have made another On-line verification with the program 2D_QUAD_37MR3_1.PRG
This program contains many cases of calculation of angle 2D.
In the folder 37MR3 there is the original program with the correct results.
In the folder 43RC_CONVERT_ONLY there is the original program converted to the V4.3RC (Jan-7-2008)
In the folder 43RC_RUN there are the results of the program performed with the last version V4.3RC (Jan-7-2008)
In the PDF files produced with the V4.3RC seems that there are some errors of calculation.
(for instance to see the dimensions D18, D20, D22, D24...). To look at the file 249541_Base_Test_3.ZIP
<<END>>
<< Lothar Schafer  --  12/20/07  16:27:55>>
I just tested this angle problem, using version 4.3 beta of December 18. For me now it seems to be nearly OK, the way it works we should meet the customers expectations. But I think I see one chance to make the usage of PC-DMIS more easy in this section (see following).

One question:
Converting part programs that are done in version 3.7 you display the message that the dimensions are converted. If I understood right, this means that you re-calculate all the angles that are done with COMPLEMENT in version 3.7 to the normal (non-complement) angle, because the complement function does not exist any longer. I don? know, why you kicked out that COMPLEMENT function, because it was very easy to use in order to get the complement angle. Now, with this possibility missing, you have to construct new elements in order to get the angle on the other side. This makes it more complicate. I would like to suggest that if possible you re-animate this function for angle selection (just to have a possibility to toggle the two possible angles, but keep the selected if it is once done).
If that is not possible, do you see a chance to specify in your display message, which conversion is done (something like "COMPLEMENT angles are converted to normal angles or so")? With the actual message the customer does only know that something is changed in his part program, but not what is changed.
<<END>>
<< Paola Pallo  --  12/10/07  17:38:09>>
Fixed.
I reworked the 2D angle calculation applying the basic geometrical rules of the angles, and using the information available from the dimension itself , that is  the input features' type, their order inside the dimension and the current workplane .
Using above info, you will have the 2D_angle result according to the following conventional rules :
1) the angle is considered positive when it is measured counterclockwise ( the input feature's  order is counterclockwise) , otherwise it is considered negative.
2) the angle between two lines ( or reducible to line feature as cone, cylinder, slot, ellipse) is calculated using the feature's vector (taking in consideration also its sign)
3) the angle between two planes is defined as the acute angle ( < 90)  between the planes' normal
4) a circle is considered as a plane feature
5) the angle between a plane and a line is calculated using a 'laying vector' that depends on the plane vector and  the current workplane
I tested the math verifying a correct behaviour both importing the v37 created PRG of this PR, both using following PR's examples  :
- 235967 (angle between planes)
- 238599 ( angle between line and circle)
- 246674 (angle between lines on both sides of 0 degree)
I'm confident that these should be some significative examples of the most extensively used cases, but futher tests will be very welcomed.
For review :
------------------------
V43B\DIMENS\DIM_2D_A.CPP
V43B\INCLUDE\DIM_2D_A.H
V43R\DIMENS\DIM_2D_A.CPP
V43R\INCLUDE\DIM_2D_A.H
V44B\DIMENS\DIM_2D_A.CPP
V44B\INCLUDE\DIM_2D_A.H
<<END>>
<< Changes made by Paola Pallo -- 12/10/07  17:39:04>>
Action:  Paola Pallo to Don Turcotte, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Gianni Revello -- 12/07/07  17:14:21>>
Action:  David Petrizze to Paola Pallo, Status:  REVIEW to OPEN
<<END>>
<< Paola Pallo  --  12/06/07  12:56:34>>
Completed the modifications in 2D angle math, test in progress. I will upload shortly
<<END>>
<< Paola Pallo  --  12/03/07  17:52:32>>
Code changes in progress.
<<END>>
<< Domenico Varacalli  --  12/03/07  14:19:23>>
I have effected other tests, performing the program with angular variations of the measured elements, to reproduce the conditions in the different quadrants.
The results are in the new file: 249541_Base_Test_2.zip
<<END>>
<< Domenico Varacalli  --  11/30/07  18:08:30>>
I have prepared a program to simulate many cases of calculation of the dimension angle. Now I have made a first test and it seems that something
is not compatible with the sign of the deviation. In the folder BASE there is the program regularly performed without great errors, or with the deviations
all in tolerance. In the folder TEST there is the 1st run effected with both the versions (3.7MR1 and 4.3RC - 29 Nov, 2007). With the values in the PDF
it results evident a discordance of the measured values and the deviations. It needs to understand if it is a problem of interpretation or a problem
of calculation. The next tests that I will do will be more rapid, therefore we will have further information.
<<END>>
<< Paola Pallo  --  11/29/07  18:22:13>>
Meeting with Werner and Frank in Moncalieri office  and brief discussion with Mimmo who is preparing a test with the most significant cases.
<<END>>
<< Don Turcotte  --  11/19/07  12:00:12>>
Reviewed.
OK so far.
<<END>>
<< Changes made by Don Turcotte -- 11/19/07  12:00:12>>
Action:  Don Turcotte to David Petrizze
<<END>>
<< Paola Pallo  --  11/15/07  16:51:20>>
Uploaded the changes for point 1 in v43R, v43B,v44B.
On the way I fixed a problem relating nominal's changing in EW .
As agreed with Don, point 2 will be done later,  after Lothar's test, so that we could take  in consideration any further info/data he will supply.
For review:
------------------------
V43B\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_3D_A.CPP
V43B\INCLUDE\PARTPROG.H
V43B\SOURCE\partprog.CPP
V43R\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_3D_A.CPP
V43R\INCLUDE\PARTPROG.H
V43R\SOURCE\partprog.CPP
V44B\DIMENS\DIM_2D_A.CPP
V44B\DIMENS\DIM_3D_A.CPP
V44B\INCLUDE\PARTPROG.H
V44B\SOURCE\partprog.CPP
<<END>>
<< Changes made by Paola Pallo -- 11/15/07  16:52:21>>
Action:  Paola Pallo to Don Turcotte, Status:  OPEN to REVIEW
<<END>>
<< Paola Pallo  --  11/13/07  17:10:16>>
Coding to implement point 1. in above list (display message)
<<END>>
<< Don Turcotte  --  11/09/07  16:39:32>>
Changed text of IDS_ANGLE_DIMENSIONS_UPDATED per Tim's request to read:
The method of calculating Angle Between Dimensions has changed in this version of PC-DMIS.\nAll of the Angle Between Dimensions in this program have been updated.
Files inserted to server
------------------------
V43B\RESOURCE\LANGS\ENGLISH\Strings.RC
V43R\RESOURCE\LANGS\ENGLISH\Strings.RC
V44B\RESOURCE\LANGS\ENGLISH\Strings.RC
<<END>>
<< Don Turcotte  --  11/09/07  15:56:39>>
Phone conference with Tim, Paola and Lothar.  
1. We decided that when a V37 or earlier program with Angle Dimensions is loaded in V43+, all the Angle Dimensions will have their math re-calculated so the results in the edit window and report will be consistent with the new math algorithm used in V4.x versions.  A message shall be displayed to the user that the results have been updated.  
2. It was also agreed that the vector of the datum feature should always represent 0 degrees and that the calculated angle deviation should be relative to this 0.  No matter how many times a program is executed, the angle dimensions should always report a deviation in the same quadrant relative to the 0 degree position of the associated datum. The issue here is that the results be consistent from one run to the next so the user knows how to adjust the manufacturing process.
Paola, I have added a string to V43B and V44B to display a message when a V37 or earlier program with Angle Dimensions is loaded in V43+.  The message can be displayed by calling
   PCDMessageBox(m_pPartProgram,S_ANGLE_DIMENSIONS_UPDATED);
I have uploaded this change to V43B, V43R, V44B.  The string has been added to the resources, but I did not add any call to display the message dialog.
Files inserted to server
------------------------
V43B\INCLUDE\EDITRSTR.H
V43B\INCLUDE\strings.h
V43B\RESOURCE\LANGS\ENGLISH\Strings.RC
V43B\SOURCE\EDITRSTR.CPP
V44B\INCLUDE\EDITRSTR.H
V44B\INCLUDE\strings.h
V44B\RESOURCE\LANGS\ENGLISH\Strings.RC
V44B\SOURCE\EDITRSTR.CPP
V43R\INCLUDE\EDITRSTR.H
V43R\INCLUDE\strings.h
V43R\RESOURCE\LANGS\ENGLISH\Strings.RC
V43R\SOURCE\EDITRSTR.CPP

<<END>>
<< Paola Pallo  --  11/09/07  17:26:01>>
Conference call with Tim, Don and Lothar.
We agreed on following (brief note for my-self)
- during the initial serialization of an old PRG containing angle dimens , give a message about the fact that the internal math is changed and force the recalculation with the new one.
- improve the math ( save the info about which quadrant is used  when initially created and use it in later executions)
We will work on this fix on v43 code, and Lothar will help us with the test, starting from next Tuesday .
<<END>>
<< Paola Pallo  --  11/09/07  12:04:27>>
Phone talk with Lothar
<<END>>
<< Paola Pallo  --  11/08/07  18:21:36>>
Lothar, I looked at your example and I think PC-DMIS results in v43 are coherent with v37 . It is evident in the program imported from old version, but the differences you see  in the v43 created program  are not matter of incompatibility but are  related to the fact that the measured cylinder is different from v37 PRG :  cylinder actual direction was <-0.0000183,0.0000247,1> for the old PRG,  and it is  <-0.0000208,0.0000192,1> in the v43 PRG.
You cannot expect the same angle if the related feature is not the same.  
I would like to discuss it with you tomorrow morning, before the scheduled conference with Tim . Thanks  
<<END>>
<< Changes made by Tim Wernicke -- 11/07/07  09:25:15>>
Action:  David Petrizze to Paola Pallo
<<END>>
<< Lothar Schafer  --  11/07/07  15:13:36>>
I have to re-open this report after testing in 4.3 RC#2 of Oct 29.
I use two similar part programs, both done in older versions (see attached files "Feature Function Test.zip" and "Feature Function Test new ISO 1101.zip").
Only difference between them:
The progran "Feature Function Test" is done using the V37 compatible dimensioning method, the program "Feature Function Test new ISO 1101" uses the new dimensioning with feature control frames.
If you compare the evaluations you will see that in case 1 the converted value is 89.9986 (similar to the result in 3.7, that means compatibility).
In case 2 the result is 90.0011, the complementary angle to 180 degress (this means definitely NO compatibility with older versions.
For investigation I did a new dimension in version 4.3 (using both V37 and new dimensioning method), result in both the cases is -89.9986 with nominal changed to -90.
So I have now 3 different results for the same measurement. Which one should the customer accept for real?
The most critical issue is the changing to the complement angle => UNACCEPTABLE, definitely no compatibility of existing part programs.
<<END>>
<< Changes made by Lothar Schafer -- 11/07/07  15:13:38>>
Status:  REVIEW to OPEN
<<END>>
<< Lothar Schafer  --  10/30/07  09:45:29>>
Hi Paola,
just to clarify, we tested this, as Larry mentioned below, in the actual RC of 4.3, dated October 7th,  AND in the official release 4.2 MR1, dated september 5th. The error is in both this versions present. I will go on testing this in the next RC for factory integration test in hope that it is fixed then.
<<END>>
<< Paola Pallo  --  10/23/07  17:34:01>>
Fixed in v43R.
I merged the changes already added by Wade in the other versions (also in v42r) : actually I could not see the problem using  v4.2 mr1 (delivered in September 5th).
If you are using a version v42 dated July 21, as written here, then it was older, so it could not include Wade's fix.
For review
V43R\DIMENS\DIM_2D_A.CPP
V43R\DIMENS\DIM_3D_A.CPP
<<END>>
<< Changes made by Paola Pallo -- 10/23/07  17:36:36>>
Action:  Paola Pallo to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Paola Pallo  --  10/19/07  14:15:16>>
Looking at this, but wasting time in get a correctly built version ( today after downloading neither v43R neither v43B is ok )
<<END>>
<< Changes made by Tim Wernicke -- 10/17/07  09:11:31>>
Action:  Lothar Schafer to Paola Pallo
<<END>>
<< Larry Clark  --  10/17/07  08:08:03>>
Testing online at Leitz (Wetzlar) indicates no change to the erroneous results in v4.2mr1 and in v4.3FIT.  The sign of the measured angle values is still wrong.
<<END>>
<< Changes made by Larry Clark -- 10/17/07  08:08:27>>
Status:  RESOLVED to OPEN
<<END>>
<< Jerry Naylor  --  08/31/07  07:23:06>>
wasaddedtoreadme42B&42R
<<END>>
<< Paola Pallo  --  08/30/07  15:34:36>>
Reviewed.
Now the sign of measured result  will always match the nominal's .
It would fit  the most cases (not 246674 so far),  but according to Bret's this is the correct design.
<<END>>
<< Changes made by Paola Pallo -- 08/30/07  15:36:00>>
Action:  Paola Pallo to Lothar Schafer, Status:  REVIEW to RESOLVED
<<END>>
<< Changes made by Tim Wernicke -- 08/30/07  10:03:59>>
Priority:  Critical to Stop Rel.
<<END>>
<< Wade Burton  --  08/29/07  15:10:58>>
This particular part program was having problems due to a change from a few months ago that specifically affected V4.2.  I have fixed this now after we met to discuss this problem.  It wasn't so much a compatibility issue from V3.7 to V4.2.
Uploaded:
V42\DIMENS\DIM_2D_A.CPP
V42\DIMENS\DIM_3D_A.CPP
V42R\DIMENS\DIM_2D_A.CPP
V42R\DIMENS\DIM_3D_A.CPP
V43B\DIMENS\DIM_2D_A.CPP
V43B\DIMENS\DIM_3D_A.CPP
I haven't created the other new directories yet, but I'll make sure this gets to the other V44 as well.
<<END>>
<< Changes made by Wade Burton -- 08/29/07  15:12:21>>
Status:  OPEN to REVIEW
<<END>>
<< Changes made by Tim Wernicke -- 08/03/07  11:00:09>>
Action:  Lothar Schafer to Paola Pallo, Assigned:   to Paola Pallo
<<END>>
<< Lothar Schafer  --  08/03/07  09:42:55>>
Indeed I have to re-open this report again, because one of our key customers, "Dr. Johannes Heidenhain GmbH" will never accept a new version, if their existing part programs are not compatible. There is no chance to explain them they have to change the sign in the nominal in every "old" part program used in version 4.2. This is not a satisfactory solution for them. It is possible that the selling of an SMA for ca. 10 licenses depends on this solution. So please re-check the design, I think compatibility is a very big point for other customers as well.
<<END>>
<< Changes made by Lothar Schafer -- 08/03/07  09:43:02>>
Status:  RESOLVED to OPEN
<<END>>
<< Tim Wernicke  --  08/02/07  10:41:10>>
This has been discussed several times.  The deisgn has changed a bit.  You can override the nominal to the correct sign now.  Please see PR# 240078 for more information.  Please re-open if this is not satisfactory.
<<END>>
<< Changes made by Tim Wernicke -- 08/02/07  10:41:22>>
Action:  Tim Wernicke to Lothar Schafer, Status:  OPEN to RESOLVED
<<END>>
<< Changes made by Lothar Schafer -- 08/02/07  17:19:12>>
Priority:  to Critical
<<END>>