PR 261260 Reported straightness wrong from a constructed 2D line

huangyhg

Reported straightness wrong from a constructed 2D line

<< Ron Jakl  --  04/20/09  15:57:06>>
Using the legacy straightness dimension the value that is reported from a 2D constructed line is either zero or the length of the line.  I saw the problem on another program and was able to recreate it offline (see attached program).
<<END>>

<< Yanhua Huang (Development Notes)  --  06/05/09  18:42:51>>
1. Fixed one issue, when create a per unit straightness on BF 2D line, max and min is not set in reporting window.
******************************
Fri Jun 05 18:37:12 2009
******************************
Files inserted to server
------------------------
V44B\DIMENS\DIM_STRA.CPP
V44B\PCDSFIT\INCLUDE\geometry.h
V44B\PCDSFIT\SOURCE\STRAIGHTNESS2D.CPP
<<END>>
<< Don Turcotte (Development Notes)  --  06/04/09  11:55:56>>
Skype chat with Andy and Yanhua :
[10:59:11 AM] WAI Andy Roberts says: ok.  Now we can all type in the same window
[11:01:59 AM] WAI Andy Roberts says: Don, it appears from the code in DSFit that we compute signed distances for 3d bf lines.  I haven't verified this with a test.  Is this ok?
[11:02:21 AM] WAI Andy Roberts says: The sign will be based on the reference vector.
[11:02:42 AM] WAI Andy Roberts says: The actual distances would still be 3D distances.
[11:03:28 AM] WAI Andy Roberts says: This is for runout.
[11:03:32 AM] yanhua Huang says: The thing is, for a 3D line it doesn't make sense to have negative distances, but it shouldn't really matter.  So long as the magnitudes are correct.
>For view 3D point info from graphic analysis, I saw some nagative deviations...
[11:05:52 AM] Donald Turcotte says: I tend to agree with Yanhua.  The MAX, MIN reported for 3D straightness is probably based on these signed deviations.
[11:06:20 AM] Donald Turcotte says: As long as the DEV value that is reported is correct.
[11:06:52 AM] WAI Andy Roberts says: The thing we have to be careful with is that the code in DSFit is for everything...
[11:07:12 AM] WAI Andy Roberts says: For lines created from hits, and any other feature.
[11:07:44 AM] WAI Andy Roberts says: In the case of lines created from hits we need a reference vector, because even for 3D lines we compensate in a plane.
[11:08:24 AM] WAI Andy Roberts says: In that case the distances for a 3D line could go negative.
[11:09:46 AM] Donald Turcotte says: 3D straightness uses a cylindrical zone as described in ASME Y14.5.1 Mathematical Definition section 6.4.1.1 Straightness of a Derived Median Line.
[11:10:33 AM] Donald Turcotte says: "Straightness for a derived median line is a cylindrical volume..."  this is 3D straightness.
[11:11:38 AM] Donald Turcotte says: 2D straightness is Straightness of Surface Line elements where the zone is bounded by two parallel lines.  Here it makes sense to use the referenced vector which defines the plane of the lines.
[11:11:38 AM] WAI Andy Roberts says: However, if you were creating a line from a bunch of generic points (without tip radii) then your fit doesn't take any probe radii into account.  You should also not have to worry about a reference vector when straightness is done.
[11:12:04 AM] WAI Andy Roberts says: I wish I had a copy of the standard.
[11:12:13 AM] WAI Andy Roberts says: Do you know where I can get one?
[11:12:40 AM] WAI Andy Roberts says: Here's the thing that we always struggle with that I don't think the standard considers...
[11:13:08 AM] WAI Andy Roberts says: When we do fits we don't have points, we have little balls.
[11:13:29 AM] WAI Andy Roberts says: When we do straightness we sometimes have points, and other times balls.
[11:13:47 AM] WAI Andy Roberts says: So, we have to compensate when we do straightness.
[11:14:11 AM] Donald Turcotte says: I thought that was the difference between BF and BFRE lines.
[11:14:19 AM] WAI Andy Roberts says: The direction of compensation becomes crucial.
[11:14:22 AM] WAI Andy Roberts says: True.
[11:14:33 AM] Donald Turcotte says: to get the standard go to www.ansi.org
[11:14:41 AM] WAI Andy Roberts says: ok, thanks for the link.
[11:14:53 AM] yanhua Huang says: straighthness, deviation(points) = radius distance(meas point, fit line) * dot{reference vetor, line [meas point i - projection point i'(meas point projection onto fit line )] } ?
[11:15:27 AM] Donald Turcotte says: You really want the mathematical book "Mathematical definition of dimensiong and tolerancing principles"
[11:15:38 AM] WAI Andy Roberts says: ah.  ok.
[11:17:35 AM] Donald Turcotte says: For 3D straightness, I don't think we should use the reference vector since a 3D line has no reference vector.
[11:17:48 AM] WAI Andy Roberts says: That's the thing...  You bring up an important point Don.
[11:18:02 AM] yanhua Huang says: don, is there a new version fot this math book relative to ASME 2009?
[11:18:17 AM] WAI Andy Roberts says: However....
[11:18:34 AM] WAI Andy Roberts says: When we fit a 3D line we compensate each point in the same direction.
[11:19:09 AM] Donald Turcotte says: I haven't seen a math standard for 2009 yet, but you can check at www.ansi.org to see if one exists yet.  Usually takes a while after the new standard is published to get the math book updated.
[11:20:23 AM] Donald Turcotte says: Compensating the points is really a separate issue from evaluating the straightness.
[11:21:35 AM] WAI Andy Roberts says: Well, at some point you have to consider where the ball touches the line.
[11:22:06 AM] WAI Andy Roberts says: That will define a compensation direction.
[11:22:40 AM] WAI Andy Roberts says: The hit vector is not necessarily the same as the compensation vector.
[11:25:33 AM] Donald Turcotte says: Yes, i understand.  This is a CMM probe compensation issue.  But once all the data is probe comp'd, the calculation of 3D straightness does not involve a reference vector since it uses a cylindrical zone.  Actually, since 3D straightness is really intended for a derived median line, I don't think it makes sense to use a BFRE constructed line when doing 3D straightness.  Seems like 3D straightness should be done with a BF constructed line.
[11:26:19 AM] WAI Andy Roberts says: I was looking for a reference but haven't found it.  However, if you imagine 2 balls, then you can fit an infinite number of lines through them.  If you have three balls that are not colinear you can get something like 6.  Dan Zwick pointed that out to me once.
[11:26:43 AM] WAI Andy Roberts says: So the problem with 3 balls is that you have to pick one of those 6 or so solutions.
[11:27:39 AM] WAI Andy Roberts says: The fact is, fitting a line through a bunch of balls was never accomplished.  And instead we took the approach of iteratively computing a 3D line and changing the compensation direction.
[11:28:08 AM] WAI Andy Roberts says: In the end we have a compensation direction which is orthogonal to the line and in the workplane.
[11:29:00 AM] WAI Andy Roberts says: So, when we solve for a line we should be saving that compensation direction, since it's not necessarily the hit vector.
[11:29:15 AM] WAI Andy Roberts says: And I think that we save it in the COMMON_SURFVECTOR.  (I'd have to check)
[11:30:13 AM] WAI Andy Roberts says: So, when we do straightness we can't just use the hit vectors for compensation, we need to use the same vector computed when we solved.
[11:30:25 AM] WAI Andy Roberts says: This is for BFRE.
[11:30:39 AM] WAI Andy Roberts says: For BF there really is no technical issue.
[11:31:45 AM] Donald Turcotte says: This is fine for BFRE to use the ref vector for the probe comping when computing the line.  Why is the ref vect used for computing the 3D straightness?
[11:32:39 AM] WAI Andy Roberts says: I do agree with you that straightness shouldn't have anything to do with compensation, but the way we implemented it, we have some bookeeping that involves compensation...
[11:33:26 AM] WAI Andy Roberts says: The ref vect is really the compensation direction.
[11:33:49 AM] WAI Andy Roberts says: We could compensate it prior to sending the data to DSFit to compute straightness.
[11:34:23 AM] WAI Andy Roberts says: But the math should be the same.  For some reason Dan included it in his DSFit code.
[11:35:27 AM] WAI Andy Roberts says: Also, it is possible that the tip radii are not all the same.
[11:35:59 AM] Donald Turcotte says: I think it makes more sense to do the probe comping on the hits before sending to DSFit for straightness since the straightness computation should not be concerned with probe comping issues.
[11:36:56 AM] WAI Andy Roberts says: Yeah.  I think you have a good point...
[11:37:12 AM] Donald Turcotte says: 2D straightness needs the ref vector since this defines the "measurement direction" but 3D straightness does not since uses a cylindrical zone.
[11:38:26 AM] WAI Andy Roberts says: One thing that I believe Dan wanted to do was to use the same error function for solving the line and computing the straightness/runout.  So that's probably why he has compensation in that DSFit code.  I think he never got around to merging them though.
[11:38:51 AM] yanhua Huang says: Dan had written a new straightness math(straightness2D) to calculate radius distance(point, line) in t:\V44B\PCDSFIT\SOURCE\Straightness2D.cpp...
[11:39:14 AM] WAI Andy Roberts says: oh.  I don't think I've looked at that.
[11:39:21 AM] WAI Andy Roberts says: I'm not sure I'm understanding something Don...
[11:40:26 AM] WAI Andy Roberts says: You still have to know where on the ball the touch point is for 3D straightness, right?
[11:41:47 AM] WAI Andy Roberts says: To me that's compensation.  So I think you are suggesting that once I have that then I can pass my precomped data to the straightness method without a reference vector.
[11:42:01 AM] WAI Andy Roberts says: for 3D
[11:43:45 AM] WAI Andy Roberts says: In that case I think we could stop negating the distances (for 3D)
[11:44:07 AM] Donald Turcotte says: I am saying for 3D that you should do the probe comping on the hits, then pass the probe comp'd data to the straightness calculation.  Actually the same should be done for 2D straightness.
[11:44:28 AM] Donald Turcotte says: Yes, then we don't need to negate distances for 3D.
[11:44:38 AM] WAI Andy Roberts says: That's fine.
[11:44:58 AM] WAI Andy Roberts says: But I think that as long as we have the math right we can get by for now.
[11:45:14 AM] WAI Andy Roberts says: I'm not sure how many places I'd have to change the code for that.
[11:45:21 AM] WAI Andy Roberts says: maybe it's not so bad.
[11:46:05 AM] Donald Turcotte says: I would not do any major redesign on V44B at this point.  Just make the changes needed to get the correct results and leave any redesign for the next version.
[11:46:15 AM] WAI Andy Roberts says: ok.
[11:47:19 AM] WAI Andy Roberts says: Do you forsee any issues if we suddenly change the distances for the 3D line to all positive?
[11:47:49 AM] WAI Andy Roberts says: I'm not sure it's actually creating a problem.
[11:48:18 AM] WAI Andy Roberts says: because we do have code to compute the actual vectors for deviations.
[11:48:26 AM] WAI Andy Roberts says: And I think that's correct.
[11:48:53 AM] WAI Andy Roberts says: I may actually create a problem if I do that.  I'd have to be careful.
[11:49:17 AM] Donald Turcotte says: We should test the graphical analysis and textual analysis.  I guess the issue is how does the user know where along the line are the out-of-tol sections.
[11:49:42 AM] WAI Andy Roberts says: ok.  I'd feel more comfortable with a test first.
[11:50:48 AM] WAI Andy Roberts says: If we decide to make all the distances positive all you need to do is check ndim == 3, and if so don't multiply by s here:
    d = s * dist(ndim, pdActls, P);
this is in line.cpp.
[11:51:39 AM] WAI Andy Roberts says: However you need to make sure that the code above that where the vectors are computed is still correct.
[11:52:09 AM] WAI Andy Roberts says: Anyway, I can help change that if needed.
[11:52:57 AM] WAI Andy Roberts says: If you can do some tests to see if graphical analysis and textual analysis is ok.
[11:53:40 AM] Donald Turcotte says: k, thx
[11:55:14 AM] WAI Andy Roberts says: Yanhau, I did briefly look at Straightness2D.cpp.  Maybe that's something we can look at using.
[11:55:23 AM] WAI Andy Roberts says: probably in a later release though.
<<END>>
<< Yanhua Huang (Development Notes)  --  06/04/09  21:51:22>>
in V42R, used m_RefVec, PR254949 and PR258945 did change to vals.Refvec for V432 and V44B.
<<END>>
<< Ron Jakl (Customer Notes)  --  06/02/09  16:51:22>>
Hi Don,
I ran some additional tests on the machine in the showroom using version 4.3 MR1.  I am surprised that you cannot recreate the error I am referring to.
If I construct a line in the X axis of the alignment system and ask for the legacy straightness I get a value that is possible.
If I construct a line using points measured along the Y axis of the alignment system the reported legacy straightness if the length of the line which is not possible.
If I construct a line using points measured along the 45 degree angle of the hexagon test block the reported legacy straightness is also wrong.  I repeated this offline as shown in the following.
LIN1       =FEAT/LINE,CARTESIAN,UNBOUNDED,NO
            THEO/<38.2,5.278,9.763>,<0.7071068,0.7071068,0>
            ACTL/<38.2,5.278,9.763>,<0.7071068,0.7071068,0>
            CONSTR/LINE,BF,2D,PNT1,PNT2,,
            OUTLIER_REMOVAL/OFF,3
            FILTER/OFF,WAVELENGTH=0
DIM STRA1= STRAIGHTNESS OF LINE LIN1  UNITS=MM ,$
GRAPH=OFF  TEXT=OFF  MULT=10.00  OUTPUT=BOTH
AX    NOMINAL       +TOL       -TOL       MEAS        DEV     OUTTOL
M       0.000      0.010      0.000     38.793     38.793     38.783 -------->
<<END>>
<< Don Turcotte (Development Notes)  --  06/02/09  14:25:38>>
I don't know how the straightness dimension in this program came to have a deviation of 600.  When I recreated both legacy and FCF straightness dimensions on this BF line I never got a deviation larger than 0.03445.
I created a V42 version of this program so I could compare the results for both legacy and FCF straightness of both the 2D and also a 3D BF line for V42 MR4, V432, V44B.  I got the following results:
V42 MR4
   Legacy 2D/3D = 0.03445
   FCF      2D/3D = 0.03445
V432
   Legacy 2D/3D = 0.02058 (this seems to be an incorrect result)
   FCF       2D = 0.03445, 3D = 0.03474 (the 3D value here is larger than V44B 3D FCF straightness)
V44B
   Legacy 2D/3D = 0.03445
   FCF      2D = 0.03445, 3D = 0.02348
The legacy straightness of 0.03445 is correct.  If you create an alignment to rotate the Y-axis to the line, then report the Location dimension X-axes for all the points, you will see that the range of X values ranges from a max of +0.02117 to a min of -.01328 which is a range of 0.03445.  This is the definition of legacy straightness.
So it seems that the Legacy 2D/3D straightness of the BF line is incorrect for V432.  This should be considered a Stop Release issue for V432.
<<END>>
<< Changes made by Yanhua Huang (Field Changes) -- 05/15/09  20:54:17>>
Action:  Ron Jakl to Yanhua Huang, Status:  MOREINFO to OPEN
<<END>>
<< Ron Jakl (Customer Notes)  --  04/28/09  12:21:38>>
Hi Yanhua, I am not sure what additional information you require
If you want me to send the probe file I will but I don't believe sending this will help as you can duplicate the problem on your computer using your own probe file.
<<END>>
<< Changes made by Yanhua Huang (Field Changes) -- 04/24/09  15:43:43>>
Action:  Yanhua Huang to Ron Jakl, Status:  OPEN to MOREINFO
<<END>>
<< Yanhua Huang (Development Notes)  --  04/24/09  15:34:48>>
sequence = 175 serialized in STRA1. Could not call do_math when m_feature->sequence = 174 in offline mode.
t:\V44B\DIMENS\DIM_STRA.CPP
int CPCDdim_straightness::executeprivate(int step_number, int mode)
    if ((sequence <= m_feature1->sequence || (global_align && sequence <= global_align->sequence)))
<<END>>
<< Yanhua Huang (Development Notes)  --  04/24/09  15:24:05>>
One simple solution for you.
Please delete this legacy straightness dimension and recreate a new one. You should get the following results.
DIM STRA1= STRAIGHTNESS OF LINE LIN1  UNITS=MM ,$
GRAPH=OFF  TEXT=OFF  MULT=10.00  OUTPUT=BOTH
AX    NOMINAL       +TOL       -TOL       MEAS        DEV     OUTTOL
M      0.00000    0.01000    0.00000    0.02058    0.02058    0.01058 ------->
Ron,
If you found dimension deviation is odd, please attach your probe.  We will investigate further the reason.
<<END>>
<< Changes made by Tim Wernicke (Field Changes) -- 04/20/09  15:25:21>>
Action:  Tim Wernicke to Yanhua Huang, Assigned:   to Yanhua Huang, Priority:  to Critical