PR 261753 polar angle didn't give the correct values when the angle is great

huangyhg

polar angle didn't give the correct values when the angle is greater than 90 degree
<< Jean Wang  --  05/12/09  07:18:57>>
polar angle didn't give the correct values when the angle is greater than 90 degree, and I set the angle display from 0 to 360.please see the file cam_angle.rar.
Steps to reproduce:
1,create a pp which scan a 3D cams
2,get the polar  radius,angle and Z values
3,I create the ploar angle should gradually increase according to the coordinate system
4, but the angle reduce when the ploar angle is greater than 90

Results:
I need the angle increase gradually
<<END>>


<< Changes made by Yanhua Huang (Field Changes) -- 05/15/09  21:23:26>>
Action:  Don Turcotte to Yanhua Huang
<<END>>
<< Changes made by Yanhua Huang (Field Changes) -- 05/15/09  21:23:00>>
Action:  CMM Group to Don Turcotte
<<END>>
<< Changes made by Rex Heagy (Field Changes) -- 05/14/09  16:20:41>>
Status:  OPEN to REVIEW
<<END>>
<< Changes made by Rex Heagy (Resolution Data) -- 05/14/09  16:20:31>>
** Bug Fix - Likely Exists in Previous Versions -  -  -  **
<<END>>
<< Rex Heagy (Development Notes)  --  05/14/09  16:20:18>>
Backed out previous changes to parstree.cpp. Added optional paramter to ATan3() which is only set TRUE from the go_polar() function. This is called from gp() when converting system coordinates to polar. Now Expressions and Features in Edit Window follow 0-360 convention for polar angles. I created location tolerances and using F5 toggled between 0-360 and +/- 180. The dimensions converted appropriately.
Files for review:
******************************
Thu May 14 16:17:23 2009
******************************
Files inserted to server
------------------------
V432\FLOW\PARSTREE.CPP
V432\INCLUDE\GLOBALS.H
V432\SOURCE\GLOBALS.CPP
V44B\FLOW\PARSTREE.CPP
V44B\INCLUDE\GLOBALS.H
V44B\SOURCE\GLOBALS.CPP
<<END>>
<< Bret Naylor (Management Notes)  --  05/14/09  13:44:00>>
Rex.  I don't think this is the right thing to do.  We have a setting that controls whether to use 0 to 360 or whether or not to use 180/-180 in the software.  Perhaps we don't need a change here.  Instead, we should probably just refer the user to this setting and have them switch to the 0 to 360 degree setting instead.
<<END>>
<< Changes made by Rex Heagy (Field Changes) -- 05/14/09  14:46:08>>
Status:  REVIEW to OPEN
<<END>>
<< Changes made by Rex Heagy (Field Changes) -- 05/14/09  08:52:42>>
Action:  Rex Heagy to CMM Group, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Rex Heagy (Resolution Data) -- 05/14/09  08:52:34>>
** Bug Fix - Likely Exists in Previous Versions -  -  -  **
<<END>>
<< Rex Heagy (Development Notes)  --  05/14/09  08:52:11>>
Files for review:
******************************
Thu May 14 08:50:29 2009
******************************
Files inserted to server
------------------------
V432\FLOW\PARSTREE.CPP
V44B\FLOW\PARSTREE.CPP
<<END>>
<< Rex Heagy (Development Notes)  --  05/14/09  08:51:32>>
Reviewed online Wikipedia for Polar Angle which has it defined as: 0.0 <= PA < 360.0. Implemented this rule and removed processing for +/- 180 option.
<<END>>
<< Ted Eads (Review Notes)  --  05/14/09  02:40:57>>
Assuming of course there is no need to actually be able to express the position as both 0 and 360.
<<END>>
<< Changes made by Ted Eads (Field Changes) -- 05/14/09  02:36:18>>
Action:  CMM Group to Rex Heagy, Status:  REVIEW to OPEN
<<END>>
<< Ted Eads (Review Notes)  --  05/14/09  02:36:06>>
This is a small thing that you don't necessarily have to do but to avoid the ambiguity of allowing more than one value for the same angle, so to speak, it may be better to only allow equality on one end of the 0 to 360 range.  In other words, force the angle to be
0 <= angle <360    rather than    0 <= angle <= 360
Looks like all it would take to do that is a change of
                while(360.0 < RetVal.d)
                  RetVal.d -= 360.0;
to be
                while(360.0 <= RetVal.d)
                  RetVal.d -= 360.0;
<<END>>
<< Changes made by Rex Heagy (Field Changes) -- 05/13/09  16:48:49>>
Action:  Rex Heagy to CMM Group, Assigned:  CMM Group to Rex Heagy, Status:  OPEN to REVIEW
<<END>>
<< Changes made by Rex Heagy (Resolution Data) -- 05/13/09  16:48:40>>
** Bug Fix - Likely Exists in Previous Versions -  -  -  **
<<END>>
<< Rex Heagy (Development Notes)  --  05/13/09  16:48:26>>
Merged changes over to v432.
File for review:
******************************
Wed May 13 16:47:03 2009
******************************
Files inserted to server
------------------------
V432\FLOW\PARSTREE.CPP
<<END>>
<< Rex Heagy (Development Notes)  --  05/13/09  16:10:08>>
File for review:
******************************
Wed May 13 16:04:47 2009
******************************
Files inserted to server
------------------------
V44B\FLOW\PARSTREE.CPP
<<END>>
<< Rex Heagy (Development Notes)  --  05/13/09  16:09:46>>
Added support for GETOPTION(ANGLERANGE360) for PA Expressions.
<<END>>
<< Changes made by Rex Heagy (Field Changes) -- 05/13/09  09:00:51>>
Action:  CMM Group to Rex Heagy
<<END>>
<< Don Turcotte (Development Notes)  --  05/12/09  14:19:04>>
I wrote a test program to verify that the Location dimension is reporting PA correctly when angle mode is set to 0-360.  Negative angles from the ASSIGN statement read in from a file were converted in the report to the corresponding positive value in the range 0-360.  The dimension is working correctly using a FILE and ASSIGN statements.
The problem seems to be in the way that the expressions in this program calculate the angle that is saved in the FILE.  Since ATAN returns an angle in the range +/- PI/2 (+/- 90), you must keep track of angles that should be in the second or third quadrants.  For example,
            ASSIGN/AA=RAD2DEG(ATAN(V6Y/V6X))
            IF/V6Y>=0 AND V6X<0
            ASSIGN/AA=AA+180
            END_IF/
            IF/V6Y<0 AND V6X<0
            ASSIGN/AA=AA+180
            END_IF/
The ATAN function will return a correct +/- angle for the first and fourth quadrants.  The dimension will convert this correctly to 0-360, so only the 2nd and 3rd quadrants are a problem.
<<END>>
<< Changes made by Tim Wernicke (Field Changes) -- 05/12/09  10:56:12>>
Action:  Tim Wernicke to CMM Group, Assigned:  Yanhua Huang to CMM Group, Priority:  Critical to Stop Rel.
<<END>>
<< Jean Wang (Customer Notes)  --  05/12/09  09:17:32>>
Hi Tim, this problem exists from v42,v43 and v44, so we can't get the correct ploar system result when we measure cams and other rotary parts,it should be a very high priority,thanks.
<<END>>
<< Changes made by Yanhua Huang (Field Changes) -- 05/12/09  09:15:18>>
Assigned:   to Yanhua Huang, Priority:  to Critical
<<END>>
<< Jean Wang (Customer Notes)  --  05/12/09  09:03:57>>
the same result I get from v44.
<<END>>