PR 244028 - Please check calculation of TP in DRFs

huangyhg

Please check calculation of TP in DRFs

<< Doug Sjogren  --  10/12/06  17:55:35>>
I e-mailed a file to Don Turcotte.  The features in the XZ plane when True Positioned to the ABC datums (Current Alignemnt & No FIt) produces a different number than when using DEC same conditions.  D is a Y surface plane where A is Z.  This is an experimental program and all of the datums are created in program mode and the feature deviations have been edited.  There is no difference in the output when using legacy and selecting dev perp to centerline.  I will talk to DOn about this tomorrow.
<<END>>

<< Changes made by Neil Kay -- 12/12/08  09:24:10>>
Action:  Wade Burton to Yanhua Huang, Assigned:  Don Turcotte to CMM Group
<<END>>
<< Changes made by Neil Kay -- 07/23/08  11:08:55>>
Action:  David Petrizze to Wade Burton
<<END>>
<< Don Turcotte  --  03/27/07  09:11:21>>
In all three of these cases, the dimension nominals for X and Z on the Advanced tab of the FCF dialog were set to the edit window nominals but with the output alignment selected as Datum Reference Frame.  When setting dimension nominals based on the values in the edit window, you must make sure that the output alignment is selected as Current Alignment since the nominal values that you enter are based on this setting.  I changed the output Alignment to Current Alignment and then set the X and Z nominals based on the edit window for these three FCF dimensions and everything reported correctly.
<<END>>
<< Larry Clark  --  03/26/07  17:01:30>>
E-mailed the following update to Don Turcotte:
I am getting peculiar results when opening the attached testplate_d.prg in V42B (diskset build 3/20/07).  The measured and nominal (theo) values for X appear incorrect in certain TP dimensions in the TEXTONLY default report and in the 'Text Mode Dimension Reporting' mode as follows:
FCFLOC11 (ref. CIR5)
  Default Report Mode
    measured X displays as -2.0000,  Edit Window displays 0.
  Text Mode
    NOMINAL X  displays as -2.0000, Edit Window THEO displays 0.
FCFLOC12 (ref. CIR6)
  Default Report Mode
    measured X displays as -3.0100,  Edit Window displays 1.01.
  Text Mode
    NOMINAL X  displays as -3.0000, Edit Window THEO displays 1.
FCFLOC13 (ref. CIR7)
  Default Report Mode
    measured X displays as -2.0000,  Edit Window displays 0.
  Text Mode
    NOMINAL X  displays as -2.0000, Edit Window THEO displays 0.
The fourth TP dimension in the group, FCFLOC14, does not exhibit the above discrepancies.  All four of the above dimensions are set to  FIT TO DATUMS=ON.

<<END>>
<< Don Turcotte  --  01/24/07  14:56:05>>
I have modified the 2d features (line2, circles, slots) to save their alignment data on execution.  This data is serialized in Basic_fe.cpp.  The datumref.cpp redo_math(...) method uses this data if available, otherwise it searches back from the datum command to find the alignment.
Fixed in V42 beta and V43B.
Files inserted to server
------------------------
V42\AUTOFEAT\AFCIRCLECONTACT.CPP
V42\AUTOFEAT\AFCIRCLELASER.CPP
V42\AUTOFEAT\AFCIRCLEVISION.CPP
V42\AUTOFEAT\AFLINECONTACT.CPP
V42\AUTOFEAT\AFLINELASER.CPP
V42\AUTOFEAT\AFLINEVISION.CPP
V42\AUTOFEAT\AFSLOTLASER.CPP
V42\AUTOFEAT\AFSLOTNOTCHCONTACT.CPP
V42\AUTOFEAT\AFSLOTROUNDCONTACT.CPP
V42\AUTOFEAT\AFSLOTSQUARECONTACT.CPP
V42\AUTOFEAT\AFSLOTVISION.CPP
V42\DIMENS\DATUMREF.CPP
V42\INCLUDE\BASIC_FE.H
V42\INCLUDE\GLOBALS.H
V42\MEASFEAT\BASIC_FE.CPP
V42\MEASFEAT\M_CIRCLE.CPP
V42\MEASFEAT\M_LINE.CPP
V42\MEASFEAT\M_RSLOT.CPP
V42\MEASFEAT\M_SSLOT.CPP
V43B\AUTOFEAT\AFCIRCLECONTACT.CPP
V43B\AUTOFEAT\AFCIRCLELASER.CPP
V43B\AUTOFEAT\AFCIRCLEVISION.CPP
V43B\AUTOFEAT\AFLINECONTACT.CPP
V43B\AUTOFEAT\AFLINELASER.CPP
V43B\AUTOFEAT\AFLINEVISION.CPP
V43B\AUTOFEAT\AFSLOTLASER.CPP
V43B\AUTOFEAT\AFSLOTNOTCHCONTACT.CPP
V43B\AUTOFEAT\AFSLOTROUNDCONTACT.CPP
V43B\AUTOFEAT\AFSLOTSQUARECONTACT.CPP
V43B\AUTOFEAT\AFSLOTVISION.CPP
V43B\DIMENS\DATUMREF.CPP
V43B\INCLUDE\BASIC_FE.H
V43B\INCLUDE\GLOBALS.H
V43B\MEASFEAT\BASIC_FE.CPP
V43B\MEASFEAT\M_CIRCLE.CPP
V43B\MEASFEAT\M_LINE.CPP
V43B\MEASFEAT\M_RSLOT.CPP
V43B\MEASFEAT\M_SSLOT.CPP
<<END>>
<< Changes made by Don Turcotte -- 01/24/07  14:56:19>>
Action:  Don Turcotte to David Petrizze, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  01/23/07  17:27:19>>
I found a problem with the existing algorithm when the preceding alignment is a best fit alignment.  I have fixed this -- the alignment pointer must point back to the Start _align command of the best fit alignment.  
I have implemented saving the alignment and workplane in datum features.  If the datum feature's measurement alignment exists, then datumref.cpp redo_math(...) will use that alignment and workplane, else it will search backwards from the feature command for the alignment (existing algorithm).  I have implemented saving the alignment and workplane in the measured line command in the executeprivate(...) method (with a flag to indicate a valid saved alignment exists).  Testing with this seems to work correctly.  This should probably also be implemented in measured circle as well as autoline, autocircle.  I am not serializing this alignment info.  Not sure yet if I need to.
<<END>>
<< Don Turcotte  --  10/18/06  17:27:14>>
I implemented a fix to datumref.cpp to redo the math for the constrained datum using the alignment and workplane that was in effect when the datum feature was measured.  This corrects the problem.  I implemented this by searching up from the datum feature in the program list.  Dave has suggested an alternative way to implement this fix by having the feature save the alignment transform that it is measured in.  This is a better way to implement the fix since this will work no matter what the program logic is.  I will look at implementing this instead.
Using a plane as secondary works in V41B, V42, V42R, V43B because these have Dave's fix to Best_pla.cpp for PR243284.  This fix is not in V41R which explains why using a plane as secondary did not work for Doug.  If we create a special release of V41 for Raytheon we will need both these fixes.
<<END>>
<< Don Turcotte  --  10/17/06  17:33:16>>
The issue here is datum constraining of a 2D feature (line) which is projected into a workplane.  At the time that the line is re-solved to constrain the datum, the alignment/workplane is not set up the same as when the line was created.  I am still looking into this but changing the active alignment level to be the same as the DRF gives more reasonable results but I have still not verified that this is correct.  Using a plane as the secondary works correctly in V41B (beta) and V42, but does not work in V41RC.  Since a plane is not a 2D feature I would expect the datum constraining of a plane not to have any problems.
<<END>>
<< Doug Sjogren  --  10/17/06  12:20:55>>
Don, I changed the active alignment so that it used the same datums and order of datums as the DRF and the numbers were now as expected.  It appears that the Primary datum in the DRF needs to be the active primary datum in the current alignment for this to work.  I don't know if the secondary and tertiary requirements are also similar.  
The other issue is that the result of using the DRF with primary datum perpendiicular to the feature plane is not going to allow movement in that feature plane as they had expected.  This is a application issue as the software is constarining as it should.
I will suggest the building of the current alignment, and see if it is acceptable.  However, this may escalate and need to be fixed.
<<END>>
<< Doug Sjogren  --  10/16/06  18:14:26>>
Don,
I will come see you in the morning.  The best fit alignmnets are an attempt to create a pseudo composite TP like we used to do prior to the GD&T tools.  I created a new composite TP using DEF and the lower half now produces results that I think he is expecting, but there is an issue, or maybe not, with the top control.
In speaking with Tom ideally they would like to be able to use the GD&T tools and get the results they are expecting.  
<<END>>
<< Don Turcotte  --  10/16/06  13:46:41>>
Create an alignment using A,B,C and then a Location of CIR5.  You will get the same results as true position of CIR5 using datums A,B,C.  Also create an alignment using D,E,C and then a Location of CIR5.  You will get the same results as true position of CIR5 using datums D,E,C.  The issue here is not with true position, since this reports the same as Location.  The issue here is the difference between line B and line E, since an alignment using D,B,C (or a tp using datums D,B,C) will give the same results as A,B,C.  This appears to be a result of the intervening best fit alignments.
<<END>>
<< Doug Sjogren  --  10/16/06  13:07:49>>
Don I am goping to look at this in 4.2 and clarify.  APparently the numbers were not coming out correct for Composite tolerancing and so he had done some best fits as a test. The best fits are causing the difference and he ideally wants to use the GD&T.
Hold off on looking at this until I resubmit.  Thanks.
<<END>>
<< Changes made by Tim Wernicke -- 10/12/06  17:20:48>>
Category:  true pos to GD&T, Action:  Tim Wernicke to Don Turcotte, Assigned:   to Don Turcotte, Priority:  to Critical
<<END>>

huangyhg

1. V43B\AUTOFEAT\AFCIRCLECONTACT.CPP
    switch (step_number)
    {
    case STEP_START_OF_EXECUTION:
      {  
        sbit(EXECUTING, TRUE);

        if( global_align ) // PR244028
        {
          m_machine2parts = global_align->get_alignment(MACHINETOPARTS);
          m_cad2parts = global_align->get_alignment(CADTOPARTS);
          m_workplane = global_workplane;
          m_bHaveAlignmentData = TRUE;
        }

huangyhg

2. V43B\DIMENS\DATUMREF.CPP
void CPCDdatum_reference::redo_math(CPCDcommand * pFeature)
    // PR244028
    BOOL bHaveAlignmentData = FALSE;
    CTransform machine2parts;
    CTransform cad2parts;
    int workplane = -1;
    CTransform save_machine2parts;
    CTransform save_cad2parts;
    if( pCmd && pCmd->is_feature() )
      bHaveAlignmentData = ((CPCDbasic_feature*)pCmd)->GetAlignmentData(machine2parts,cad2parts,workplane);
    if( bHaveAlignmentData && global_align )
    {
      save_machine2parts = global_align->get_alignment(MACHINETOPARTS);
      save_cad2parts = global_align->get_alignment(CADTOPARTS);
      global_align->set_alignment(MACHINETOPARTS,machine2parts);
      global_align->set_alignment(CADTOPARTS,cad2parts);
      global_workplane = workplane;
    }