Review - PR 244996 true position in a loop using Polar data display wrong val

huangyhg

true position in a loop using Polar data display wrong values
<< Michel Garrido  --  11/15/06  17:41:15>>
true position in a loop using Polar data display wrong values
2 bmp files attached
<<END>>

<< Changes made by Neil Kay -- 07/23/08  16:30:27>>
Action:  Paola Pallo to Yanhua Huang
<<END>>
<< Changes made by Neil Kay -- 07/23/08  10:46:33>>
Action:  David Petrizze to Paola Pallo
<<END>>
<< Don Turcotte  --  02/14/07  08:54:52>>
Merged into V42R.
Files inserted to server
------------------------
V42R\DIMENS\FEATCTRLFRM.CPP
V42R\DIMENS\TP_PA_LO.CPP
<<END>>
<< Changes made by Don Turcotte -- 02/14/07  08:55:06>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Rex Heagy  --  02/13/07  17:48:33>>
Additionally hit F5 and set USE_POLAR_DMIS_CONVENSION so that polar angle follows standard convension (0-deg at first named axis and positive rotation is towards second named axis, eg. XY, YZ, and ZX work planes).
<<END>>
<< Tim Wernicke  --  02/13/07  16:37:31>>
Please merge with V42R per my e-mail.  Thanks.
<<END>>
<< Changes made by Tim Wernicke -- 02/13/07  16:37:35>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to OPEN, Priority:  Critical to Stop Rel.
<<END>>
<< Don Turcotte  --  02/09/07  14:02:46>>
This has now been fixed in V42 beta and V43B.  You must use a variable on the PA nominal in the dimension edit window.  This allows PC-DMIS to update the nominal angle as you clock around the part in the loop.  You can look at the test program attached in "R244996 V24R.zip" as an example.
Files inserted to server
------------------------
V42\DIMENS\FEATCTRLFRM.CPP
V42\DIMENS\TP_PA_LO.CPP
V43B\DIMENS\FEATCTRLFRM.CPP
V43B\DIMENS\TP_PA_LO.CPP
<<END>>
<< Changes made by Don Turcotte -- 02/09/07  14:03:12>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  02/08/07  17:28:25>>
You can put a variable on the FCF PA nominal in the edit window, but this updated value (coming in through read_text(...)) is not in the updated axes list during execution.  The PA value is updated through read_text(...) during each iteration of the loop but this new PA value is lost along the way... Still looking...
<<END>>
<< Don Turcotte  --  02/08/07  10:54:52>>
I have created a test program and attached.  The issue here is that in order to loop through holes at different angles to the alignment origin, you must put a variable on the feature PA nominal (THEO) of the true position dirmension.  This works for legacy true position (as in the attached program), but does not work for FCF true position.  Still working on this...
<<END>>
<< Don Turcotte  --  02/07/07  17:21:52>>
I am creating a program to duplicate using true position with Polar data in a loop so I can run using the simulator w/perturbed data to try to reproduce the problem.
<<END>>
<< Don Turcotte  --  11/20/06  17:34:28>>
There is only one FCFLOC1 which is in a loop that executes twice.  The graphics window, however, shows two FCFLOC1 callouts, the first with a size tol of +/- 0.02 and to datums A,B.  The second occurrence has a size tol of +/- 0.1 and to datums A,B,C.  The report window also shows this.  The deviation of the first FCFLOC1 in the report is correct, the deviaiton of the second is a huge negative number.  However, if I F9 on the FCFLOC1 and switch to the advanced tab, then press OK, then repaint the report, the deviation is correct.  I am continuing to look at this...
<<END>>
<< Changes made by Tim Wernicke -- 11/20/06  14:40:57>>
Category:  Flow Control to GD&T, Action:  Paola Pallo to Don Turcotte, Assigned:  Paola Pallo to Don Turcotte
<<END>>
<< Paola Pallo  --  11/20/06  15:11:58>>
Looking in the code, I saw that some modifications were added by Don to fix another issue with TP inside a  loop (241630) . Then  I repeated a  test , verifying also  in offline  that the deviation for PA axis in the second iteration is ~ 49 , which seems really too big.
In this case the loop command is defining an internal reference system, which is fine for the auto circle execution, since it is correctly measured inside the second iteration, but evidently it is not properly used inside the DRF definition .
Tim, according to Gianni's e-mail, I should focus on Sheet Metal arguments, so  please may you re-assign this ? Thanks
<<END>>
<< Paola Pallo  --  11/17/06  17:53:28>>
Downloaded the program and verifying the results.
Applying a FCF with 3 datum on a polar circle in a loop is not really the simplest case, and it's possible that there is still a bug .
Offline I can't duplicate it since all deviations are 0 , so I will check it online (Dea capability part fits the case) .
<<END>>
<< Changes made by Don Ruggieri -- 11/15/06  13:41:15>>
Action:  Michel Garrido to Paola Pallo, Assigned:   to Paola Pallo, Status:  MOREINFO to OPEN, Priority:  to Critical
<<END>>
<< Michel Garrido  --  11/15/06  18:52:36>>
Attached files prg and prb
<<END>>
<< Don Ruggieri  --  11/15/06  12:23:42>>
Michel, can you attach the program and probe files also.  I think this would help a lot to find the problem.
<<END>>
<< Changes made by Don Ruggieri -- 11/15/06  12:24:03>>
Action:  Tim Wernicke to Michel Garrido, Status:  OPEN to MOREINFO
<<END>>