PR 242149 True position "Perp to centerline" does not work

huangyhg

True position "erp to centerline" does not work in loops and other FCF looping issues
<< Don Turcotte  --  07/27/06  15:20:41>>
When a true position dimension is in a loop, you must put variables on the axis nominals in order for the report to be generated correctly.  Since "perp to centerline" relies on the nominal vector of the considered feature in order to be calculated correctly, true position with "perp to centerline" does not report correct results in a loop.  There is no way to define variables for the nominal vector of the considered feature, since this is not exposed in the dialog nor in the edit window.   This is a problem for both FCFs and legacy true position and has been since at least V3.7 and probably even earlier.
<<END>>


<< Changes made by Neil Kay -- 02/25/09  19:18:17>>
Action:  David Petrizze to Yanhua Huang
<<END>>
<< Don Turcotte  --  06/11/07  14:09:17>>
COMPUTEDEVIAITONPERPENTOCENTERLINE is ON even in loops.    This will normally work correctly if the FCF uses variables for X,Y,Z nominals and the feature uses variables for X,Y,Z and I,J,K nominals and target values.
However, I have modified the code to turn off COMPUTEDEVIATIONPERPENTOCENTERLINE if
   a. the zone is spherical or
   b. there is only a primary datum and the datum is a point type or
   c. the considered feature is a point type.
Files inserted to server
------------------------
V42\DIMENS\FEATCTRLFRM.CPP
V43B\DIMENS\FEATCTRLFRM.CPP
<<END>>
<< Changes made by Don Turcotte -- 06/11/07  14:09:51>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  06/11/07  09:16:32>>
Correction: the PR where "erp to centerline" is not working in a loop is 248467.
<<END>>
<< Don Turcotte  --  06/07/07  10:08:55>>
This is not working with the program in 248247 (as corrected by that PR).
<<END>>
<< Changes made by Don Turcotte -- 06/07/07  10:08:57>>
Action:  David Petrizze to Don Turcotte, Status:  REVIEW to OPEN
<<END>>
<< Don Turcotte  --  04/17/07  15:22:23>>
Talked with Dave about #2 (read_text(...)) and we agreed to use global_execute_mode instead of global_loop_start since the latter will not catch situations where the user has variables on the dimension nominals but is not using a LOOP command.
<<END>>
<< Don Turcotte  --  04/16/07  09:26:31>>
Uploaded fixes for V42 beta and V43B.

Files inserted to server
------------------------
V42\DIMENS\FEATCTRLFRM.CPP
V43B\DIMENS\FEATCTRLFRM.CPP
<<END>>
<< Changes made by Don Turcotte -- 04/16/07  09:26:45>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  04/13/07  17:24:39>>
The issue with # 3) below is that when execution starts update_global_parameters(...) is called which sets the global_datdef to NULL.  There is an alignment at the beginning of the loop which calls update_below_changed_alignment(...) when it is executed.  This in turn calls update_part_coords(...) of the feature control frame which in turn calls update_internal_commands(...).  Since at this point global_datdef is NULL, the internal commands are built with no datums.  This is a general problem which has nothing to do with loops.  I have fixed this by adding a call to update_global_datdef(...) at the beginning of update_internal_commands(...) if the global_datdef is NULL.
On issue #2) below, Dave suggested using global_loop_start instead of global_execute_mode to determine when read_text(AXIS_NOMINAL,...) is being called with data in the current active alignment.  This works for this case which uses a loop but I'm not clear that this is a good solution in general since the user can create a loop using IF and GOTO commands without using the LOOP command.  Also any time the user has expressions on the dimension nominals and the output alignment=Datum ref, even when not in a loop, this would not work.  Will discuss further with Dave.
<<END>>
<< Don Turcotte  --  04/12/07  17:08:48>>
In looking at this again, it was not clear to me why this shouldn't work since the user can put variables on the IJK of the considered feature even though the dimension nominals don't expose the considered feature's IJK.  I went back to the original program from SAM Singapore that initiated this PR and I found that with variables on the XYZ and IJK nominals (and targets) of the considered feature and variables on the XYK nominals of the FCF dimensions, true position perp to centerline in a loop was not an issue.  I did find several other issues of looping with FCF's :
1)  The datum shift table in the report is empty for all the iterations.  This is because FeatCtrlFrm method CopyNeededInfoFromOriginal(...) was not copying the datum shift segment info.  I have fixed this.
2)  When the FCF output alignment=Datum reference frame, the reported results are wrong.  This is because the loop command calls read_text(...) to update the AXIS_NOMINAL values based on the variables used (expression evaluation).  This values are in the current active alignment, but the read_text(...) is also used by the edit window so it assumes the values are in the selected output alignment.  I have fixed this by checing in read_text(...) for AXIS_NOMINAL if global_execute_mode so we can temporarily put the axes in current alignment.  This fixes this problem.
3)  When the DATDEF commands are in the loop, the first iteration FCF has an empty datum shift table in the report.  This is because the first iteration FCF tp_start command has no datums.  I have not figured out how to fix this in the code, but moving the DATDEF commands outside the loop works.  So this is the workaround.
I have attached the SAM program (TEST.PRG) and also two modified versions -
  TEST E has the DATDEF commands inside the loop and so exhibits problem 3)
  TEST F has the DATDEF commands outside the loop and so works correctly.

<<END>>
<< Don Turcotte  --  04/11/07  17:30:17>>
Dave recommended that we expose <X,Y,Z> <I,J,K> all on one line of the edit window for the dimension nominals but this violates the paradigm of dimension axes.  So I added I,J,K axes to the advanced tab axes list (and automatically to the edit window command and summary modes), since this was much simpler.  I wrote a program to test these changes and in the process of testing I am not clear why dimension nominals for the IJK of the features are necessary since the user can put variables on the THEO IJK of the features themselves and these would not be overwritten by dimension nominals (if we leave the FCF as is and don't add IJK nominals).  In preliminary testing, this seems to work (variables on the feature IJK nominals and no dimension IJK nominals).  I will continue testing.  The original problem here may have been due to the way that V4.1 handled dimension nominals.  We have improved this in V4.2 so what may have actually been a problem in V4.1 may no longer be a problem in V4.2.
<<END>>