|
Profile axes M & M1 are not correct.
<< Doug Sjogren -- 05/16/05 11:07:38>>
I thought this might have beeen logged in already, but I could not find it. The M1 axis created as a result of report #216590 seems to not be working correctly. From the report, M1 should be Location and M Form, but that is not what is being sent.
From Xstats11.tmp
DIM2: D1PLN 1 BM1 0.000000 1.100000 1.100000 0.043734
DIM2: D1PLN 1 BM 0.000000 2.200000 0.000000 -0.178696
DIM2: D3 PROFPLN3M1 0.000000 2.200000 2.200000 0.104365
DIM2: D3 PROFPLN3M 0.000000 4.400000 0.000000 0.104365
From report #216580
Location should be M1 axis, Form M axis.
DIM2: ITEM1SCN2M1 0.0000 0.0200 0.0200 -0.0170
DIM2: ITEM1SCN2M 0.0000 0.0400 0.0000 0.0340
PC-DMIS reports,
DIM D1= PROFILE OF SURFACE OF PLANE PLN 1 B FORMANDLOCATION UNITS=MM ,$
GRAPH=OFF TEXT=OFF MULT=1.00 OUTPUT=BOTH
AX NOMINAL MEAS DEV +TOL -TOL OUTTOL MAX MIN
M 0.000 -0.179 -0.179 1.100 1.100 0.000 -0.135 -0.179 ----#-----
Datapage reports,
D1 D1
M1 M
05-05-16 10-12-55 0.044 -0.179
Should be -0.179 0.044
PC-DMIS reports,
DIM D3 PROF= PROFILE OF SURFACE OF PLANE PLN3 FORMANDLOCATION UNITS=MM ,$
GRAPH=OFF TEXT=OFF MULT=1.00 OUTPUT=BOTH
AX NOMINAL MEAS DEV +TOL -TOL OUTTOL MAX MIN
M 0.000 0.104 0.104 2.200 2.200 0.000 0.022 -0.082 ----#-----
Datapage reports,
D3_PROF D3_PROF
M1 M
05-05-16 10-12-55 0.104 0.104
Should be -0.082 0.104
<<END>>
<< Changes made by Neil Kay -- 02/25/09 16:25:19>>
Status: RESOLVED to CLOSED
<<END>>
<< Jerry Naylor -- 02/18/08 09:45:15>>
wasaddedtoreadme37RMR4
<<END>>
<< Don Turcotte -- 02/15/08 16:12:39>>
Merged into V43R.
Files inserted to server
------------------------
V43R\DIMENS\BASIC_DI.CPP
<<END>>
<< Changes made by Don Turcotte -- 02/15/08 16:12:56>>
Action: Don Turcotte to Doug Sjogren, Status: OPEN to RESOLVED
<<END>>
<< Tim Wernicke -- 02/14/08 14:29:47>>
Agreed, please go ahead in V43R Don. Thanks.
<<END>>
<< Changes made by Tim Wernicke -- 02/14/08 14:29:58>>
Action: Tim Wernicke to Don Turcotte, Status: REVIEW to OPEN, Priority: High to Stop Rel.
<<END>>
<< Doug Sjogren -- 02/13/08 16:51:44>>
Ultimately I would preferr to see three axes, but giveen that this would be a major change this will stil be beter than what is currently done. So M as FORM and M1 as largest location error should work. I think this should be in the next available release.
<<END>>
<< Changes made by Doug Sjogren -- 02/13/08 16:51:46>>
Action: Doug Sjogren to Tim Wernicke
<<END>>
<< Don Turcotte -- 10/23/07 16:36:05>>
I talked with Doug and looked at implementing reporting M, MX, MI with a "<" added to either MX or MI (whichever consumed the most tolerance), but Steve B. indicated that this could cause problems with stats or pc-dmis. So I looked at reporting M and M1. The changes to the command mode edit window were straightforward but the changes that would be required to report two axes in the legacy and FCF profile report tables were extensive and judged too risky.
So all I ended up changing was to ensure that M as sent to stats is always the form value as Doug requested. The M1 value sent to stats is max or min, whichever consumes the most tolerance (this hasn't changed).
Fixed in V42 beta, V43B, V44B.
Doug, please review this change and notify Tim if you would like to have this merged into V42R and/or V43R. This is a low-risk change.
Files inserted to server
------------------------
V42\DIMENS\BASIC_DI.CPP
V43B\DIMENS\BASIC_DI.CPP
V44B\DIMENS\BASIC_DI.CPP
<<END>>
<< Changes made by Don Turcotte -- 10/23/07 16:36:58>>
Action: Don Turcotte to Doug Sjogren, Status: OPEN to REVIEW
<<END>>
<< Doug Sjogren -- 10/19/07 09:46:41>>
Is anything going on with this?
<<END>>
<< Changes made by Doug Sjogren -- 10/19/07 09:46:43>>
Status: MOREINFO to OPEN
<<END>>
<< Doug Sjogren -- 09/15/06 08:12:29>>
Don, if M could always be the Form value that would be better.
It would also be nice if the Form & Location were evaluated on two separate lines. This would be easier for users and their customers to interpret.
<<END>>
<< Changes made by Doug Sjogren -- 09/15/06 08:12:32>>
Action: Doug Sjogren to Don Turcotte
<<END>>
<< Don Turcotte -- 09/13/06 11:22:27>>
Reviewed.
Doug, I'm not clear that the way stats output now works is entirely what you want. M1 is reported as the largest deviation (positive or negative). M is reported as the "measured" value. This is the M axis in the edit window and on the report for legacy profile dimensions. In cases where the max is positive and the min is negative (or vice versa), this is max - min so this is also the form value. In cases where both max and min are negative or both max and min are positive this M value will be the largest of max,min. Not the form value. In V40, the user can set the registry value UseISOCalculations so this M value would always be 2 times max deviation.
<<END>>
<< Changes made by Don Turcotte -- 09/13/06 11:22:45>>
Action: David Petrizze to Doug Sjogren, Status: REVIEW to MOREINFO
<<END>>
<< Changes made by Don Turcotte -- 09/13/06 11:22:27>>
Action: Don Turcotte to David Petrizze
<<END>>
<< Steve Barber -- 04/13/06 16:49:14>>
Uploaded:
V42\DIMENS\BASIC_DI.CPP
GetRecortPartInfo was wrong in the V4X versions - not in V37. savestats was also correct. Seems to be wrong only in the V37R stream. I think V37Beta will be correct.
<<END>>
<< Changes made by Steve Barber -- 04/13/06 16:49:32>>
Action: Steve Barber to Don Turcotte, Status: OPEN to REVIEW
<<END>>
<< Steve Barber -- 04/13/06 16:35:49>>
Don & I talked. I will make the change to V42. He will review it. It should be noted that V37R, V40, V41 will generate different results than 3.6.
<<END>>
<< Changes made by Steve Barber -- 04/13/06 16:35:55>>
Action: Don Turcotte to Steve Barber
<<END>>
<< Steve Barber -- 04/13/06 16:24:43>>
Don,
Looking at the history, V2 of the resync for V37R did not contain your changes. V1 did.
I guess that is the root of this current issue.
Steve
<<END>>
<< Steve Barber -- 04/13/06 16:18:32>>
Don,
Going back far enough to #216580, Doug & I settled on M being FORM (this is no change from prior versions). I added M1 which was to be Min/Max LOC value. There was also alot of discussion with this on #226268. I left M unchanged so it would not interfere with anyone looking at that value. I do not think #226268 reset the code back to its original state - or it was overwritten at some point. I have both 3.5 & 3.7r (formally 3.6?) to compare:
V3.7R
// if we are a DIMENSION_PROFILE then we have to send different info - sab - #216580 - 21-Apr-2003
// I don't think it corrects #211622
if ((type() == DIMENSION_PROFILE_SURFACE || type() == DIMENSION_PROFILE_LINE) && IsBilateral())
{
// If the profile is Bilateral, then this is FORMANDLOCATION so the M1 value should be the form
// which is simply max - min.
Measured = get_max() - get_min(); // PR226268
tmpaxis = ES_M + _T("1 ");
// If we want to issue the other value we could open this code - sab
stats_line(m_pPartProgram, this, m_feature1, (LPTSTR)((LPCTSTR)tmpaxis),
Nominal, PlusTol, MinusTol, Measured,
m_current_stats_DP, m_current_stats_DES, m_current_stats_SPC);
tmpaxis = ES_M + _T(" ");
PlusTol = PlusTol + MinusTol;
MinusTol = 0.0;
Measured = get_measured();
}
V3.5
// if we are a DIMENSION_PROFILE then we have to send different info - sab - #216580 - 21-Apr-2003
// I don't think it corrects #211622
if (type() == DIMENSION_PROFILE && IsBilateral())
{
double val1, val2, valmax;
int first_or_second = 0; // 0 for first, 1 for second
val1 = get_max() - PlusTol;
val2 = - get_min() - get_minus_tol(FALSE);
valmax = max(val1, val2);
if (valmax == val2) // used val2
first_or_second = 1;
if (first_or_second)
Measured = get_min();
else
Measured = get_max();
tmpaxis = ES_M + _T("1 ");
// If we want to issue the other value we could open this code - sab
stats_line(m_pPartProgram, this, m_feature1, (LPTSTR)((LPCTSTR)tmpaxis),
Nominal, PlusTol, MinusTol, Measured,
m_current_stats_DP, m_current_stats_DES, m_current_stats_SPC);
tmpaxis = ES_M + _T(" ");
PlusTol = PlusTol + MinusTol;
MinusTol = 0.0;
Measured = get_measured();
}
I do not understand the math end enough to say what V4.0 should be sending. I guess it could change based on registry settings?
Steve
<<END>>
<< Changes made by Steve Barber -- 04/13/06 16:19:04>>
Action: Steve Barber to Don Turcotte
<<END>>
<< Don Turcotte -- 04/12/06 17:15:10>>
In the edit window, the M axis MEAS when the dimension specifies FORMANDLOCATION is the formandlocation value which is max-min deviation unless both deviations are negative or both are positive, in which case the value is the largest deviation. In V40, the user has the option of always reporting this instead as 2 * the max deviation based on a registry setting.
When the dimension specifies FORMONLY, the M axis MEAS in the edit window is the form. In this case there is only a positive tolerance (the neg tol is 0.0).
In V37 savestats() and V40 GetRecordPartInfo(), the comment says M1 should be the form, but this is reported to stats with a plus and minus tol. The M value which is then the location is reported with a single tol set to plus+minus.
So there seem to be several points of confusion :
1. Doug thinks M1 should be location and M form in the stats, but the reverse is being done.
2. The stats form reports a plus and minus tol, the stats location reports only 1 tol
3. The MEAS value for formandlocation is calculated differently when both max and min are negative or both max and min are positive.
<<END>>
<< Changes made by Don Turcotte -- 04/12/06 17:16:10>>
Action: Don Turcotte to Steve Barber
<<END>>
<< Changes made by Tim Wernicke -- 04/10/06 15:14:39>>
Action: Wade Burton to Don Turcotte, Assigned: Wade Burton to Don Turcotte
<<END>>
<< Changes made by Tim Wernicke -- 05/18/05 11:36:52>>
Category: statistics to dimensions, Action: Tim Wernicke to Wade Burton, Assigned: to Wade Burton, Status: MOREINFO to OPEN, Priority: to High
<<END>>
<< Doug Sjogren -- 05/18/05 10:59:37>>
Tim, I downloaded from the link, version is dated 5/13/05, and the results are the same. If nothing else, the M1, Form, should have the unilateral tolerance.
<<END>>
<< Changes made by Doug Sjogren -- 05/18/05 10:59:52>>
Action: Doug Sjogren to Tim Wernicke
<<END>>
<< Tim Wernicke -- 05/17/05 10:16:26>>
Yes, many of the GD&T issues were fixed after the 4/22 build. The latest 3.7 MR2 candidate is here: ftp://files.wilcoxassoc.com/v37all.zip
<<END>>
<< Changes made by Tim Wernicke -- 05/17/05 10:16:32>>
Action: Tim Wernicke to Doug Sjogren
<<END>>
<< Doug Sjogren -- 05/16/05 18:29:40>>
April 22 is the date of the PCDLRN. I believe this was the MR2 candidate at one point, I have not loaded any of the later Betas. Is there a new MR2 candidate, and any target for MR2?
<<END>>
<< Changes made by Doug Sjogren -- 05/16/05 18:29:42>>
Action: Doug Sjogren to Tim Wernicke
<<END>>
<< Tim Wernicke -- 05/16/05 13:48:43>>
Doug, exactly what build of 3.7 are you using?
<<END>>
<< Changes made by Tim Wernicke -- 05/16/05 13:48:46>>
Action: Tim Wernicke to Doug Sjogren, Status: OPEN to MOREINFO
<<END>>
<< Doug Sjogren -- 05/16/05 12:29:46>>
I looked at that report and it does appear that Wade may be working on this as an enhancement.
The original problem, and it is stil a problem if I interpret correctly, is that the M axis sometimes contains form values and sometimes contains location values, which the former can potentially be double the latter. This leads to Capabiltiy indices that are not correct.
Perhaps we need an MS, FM, & LC axes. If there are two lines for the dimension, then M, & M1. That can be worked out, but we need to do Capability on Form, and also location, and perhaps location needs to be senbt as absolute value, or the same issue arises.
In this case though it looks like M1 is being sent as location, if you consider the tolerances, but has the measured value( or Form). The Measured value, M has only a single positive tolerance as if it is Form, which it happens to be in this case, but not in the D1 dimension
DIM2: D3 PROFPLN3M1 0.000000 2.200000 2.200000 0.104365
DIM2: D3 PROFPLN3M 0.000000 4.400000 0.000000 0.104365
DIM2: D1PLN 1 BM 0.000000 2.200000 0.000000 -0.178696
At this point, I don't think it is possible to get what is desired from Datapage due to this.
<<END>>
<< Steve Barber -- 05/16/05 11:31:51>>
There was quite a bit of discussion on #226268. But I do not know if this is right or wrong.
<<END>> |
|