PR 249182 The TLP and TLN reports for the ISO 10360-4 have graphics which are

huangyhg

The TLP and TLN reports for the ISO 10360-4 have graphics which are confusing, although the corresponding numerical values seem fine.

<< Don Ruggieri  --  07/16/07  11:34:37>>
data is in 07162007_01a.zip.  The TLP and TLN reports for the ISO 10360-4 have graphics which are confusing, although the corresponding numerical values seem fine.

Steps to reproduce:
If you look at the graphics for the THP and THN reports, they show deviation symbols which seem to correlate well to the numerical values.

When you look at the graphics for the TLP and TLN tests, the graphics imply huge errors, but the numerical values seem fine.  Why is that?
<<END>>


<< Changes made by Yanhua Huang (Field Changes) -- 05/19/09  16:22:08>>
Action:  Wade Burton to Yanhua Huang
<<END>>
<< Changes made by Neil Kay -- 07/23/08  12:09:03>>
Action:  Liqiang Zhu to Wade Burton
<<END>>
<< Don Turcotte  --  07/24/07  14:57:48>>
I have fixed this by changing dim_prof.cpp so that IgnoreCadToPart is temporarily reset (ignored) only when the profile creates its own alignment.  In the case of legacy profile formandlocation and legacy profile formonly NOFIT, the IgnoreCadToPart is not ignored since in these two cases the profile is using the active alignment.  Don R. has tested this change with both the RI and German versions of the 10360 program and everything now works correctly.
Fixed in V42 beta, V42R, V43B.
Files inserted to server
------------------------
V42R\DIMENS\DIM_PROF.CPP
V43B\DIMENS\DIM_PROF.CPP
V42\DIMENS\DIM_PROF.CPP
<<END>>
<< Changes made by Don Turcotte -- 07/24/07  14:58:26>>
Action:  Don Turcotte to Liqiang Zhu, Status:  OPEN to REVIEW
<<END>>
<< Don Turcotte  --  07/24/07  08:56:32>>
I made the change described below and the graphics now looks ok.  Don R. is testing this change with the V42R PCDLRN.EXE that I built.  I have not uploaded any source files yet.
<<END>>
<< Don Turcotte  --  07/23/07  17:34:24>>
I have sent e-mail to Don Ruggieri.  He will be in tomorrow so I can discuss this with him.  One possible solution is to change the profile dimension so it uses the "Ignore Cad to Part" setting only when using a legacy profile (which has no datums) and the user is not asking for formonly with a fit technique (form only with other than NO FIT will require the construction of a bestfit alignment).  In all other cases the profile would ignore "Ignore Cad to Part" (treat is as off).
e-mail to Don R. : "Don,
The issue here seems to be that we changed the dimensions to ignore the “Ignore Cad to Parts” setting since when this is set, the true position calculations are bogus.  We changed all the dimensions to ignore this setting, but maybe the profile should not ignore it.  I’m not clear on why “Ignore Cad to Parts” is set in these programs.  Can you shed some light on this?  This is a Stop Release issue for V42R MR1.
"
<<END>>
<< Steve Barber  --  07/17/07  15:36:25>>
This is being caused by the change for #246933 (also a StopRel). The cad_to_parts.m_data[0] is shifting which is what the analysis is showing. That change is causing the alignments to perform a do_math() and ignore the ignore_cad_to_part flag which is set for these part programs. When you multiply the shift by 1000 the values get large.
All you need to do to see this is to:
1) load the V41 part program
2) change the SCAN1 DIM_PROF from using SCNUM1 to use SCNUM2. This drives us into the varous math areas.
V42 with the change for #246933
Target [9.575767][-0.615598][8.001844]
MeasBC [9.549441][-0.616399][7.834592]   <----
Approach [0.766420][-0.049271][0.640447]
temp_val [-0.127254]
==================
V42 skipping over  the change for #246933  (matches V41)
Target [9.575767][-0.615598][8.001844]
MeasBC [9.573573][-0.615463][7.999959]  <----
Approach [0.766420][-0.049271][0.640447]
temp_val [-0.002895]
The above code was generated from CPCDscan::profile().
<<END>>
<< Changes made by Steve Barber -- 07/17/07  15:36:57>>
Action:  Steve Barber to Don Turcotte, Assigned:  Steve Barber to Don Turcotte
<<END>>
<< Steve Barber  --  07/17/07  14:21:16>>
Just comparing some of the deviations from one of the profiles:
      V42                               V41
value [-0.023786]   value [-0.000202]
value [-0.023507]   value [-0.000097]
value [-0.023261]   value [0.000255]
value [-0.023822]   value [-0.000783]
value [-0.022942]   value [0.000015]
My first guess would be a filtering issue (or some sort of math issue).
<<END>>
<< Steve Barber  --  07/17/07  12:30:34>>
I currently agree. I'm looking at the deviation array (saved when closing the program) and V42 looks way out. I am trying to narrow down what may be causing this.
<<END>>
<< Don Ruggieri  --  07/17/07  09:32:31>>
In 07172007_01a.zip I've included a single TLP run from v4.1 showing good results.  In 07172007_01b.zip I've included a single TLP run from v42MR1 showing the strange results.
<<END>>
<< Changes made by Tim Wernicke -- 07/17/07  09:25:48>>
Priority:  Stop Test to Stop Rel.
<<END>>
<< Don Ruggieri  --  07/17/07  09:04:12>>
Two more items of interest on this -
1) If I put a comment on line 674 to display the value of the variable called SCNUM1, in both v41 and v42MR1 it returns the same thing, "XSCANPLN1" so I have to suspect this is not the problem.
2) If I run the program in v41, I get good results.  If I then open the program in v42MR1 (and DO NOT execute), and press F9 on the report statement near the end of the program, the results are still good.  This tells me that it is not a report problem.
Consequently, it seems to me that it is in the process of collecting and analyzing the data.  More to follow. . .
<<END>>
<< Don Ruggieri  --  07/16/07  16:19:55>>
My thoughts aside, in 07162007_01b.zip are two cases.  One shows all 4 tests in v41 with no such issues.  The other shows all 4 tests in v42 with the latter two tests (TLP, TLN) exhibiting this behavior.
<<END>>
<< Don Ruggieri  --  07/16/07  11:42:41>>
I don't believe this is exclusive to v42.  I will be performing comparison tests soon and report here.
<<END>>
<< Changes made by Tim Wernicke -- 07/16/07  11:41:09>>
Action:  Tim Wernicke to Steve Barber, Assigned:   to Steve Barber, Priority:  to Stop Test
<<END>>

huangyhg

(void) SetIgnoreCadToPart(m_pPartProgram,FALSE); // PR249182 - don't reset IgnoreCadToPart unless we are constructing an alignment (will be restored on return to do_math(...))