TECHNET Archives

February 2012

TechNet@IPC.ORG

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Brian Ellis <[log in to unmask]>
Reply To:
TechNet E-Mail Forum <[log in to unmask]>, Brian Ellis <[log in to unmask]>
Date:
Sat, 18 Feb 2012 12:55:30 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (113 lines)
Rich

I started working on statistical analyses of ionic contamination testing 
about 1984 and published a simplified theoretical section on the subject 
and its interpretation in my 1986 book (pp 250-257). I did some bare 
software analysis on my instruments in 1987 with the CM-4 and some much 
more sophisticated analysis with the CM-5 in 1989 (I dare mention the 
model numbers as they are no longer made!!!).

Firstly, I would say that your one-sided curves were probably because of 
a lack of instrument sensitivity, perhaps due to limitations of 
resistivity measurement, as opposed to the ballistic conductivity 
measurements used in the CM series. In many years, I have never seen 
this with CMs.

Let me briefly expound what the CM-5 did. The test duration lasted until 
near-asymptote or 15 minutes, whichever was the shorter. The resultant 
curves were then extrapolated to quasi-infinite time. They were then 
analysed and the nature of the individual main contaminants (up to 
three) were determined by mathematical analysis of the curve shape. The 
results for each assembly number were then held in a database. After a 
minimum of five (I think, after 22 years) tests on a given assembly each 
new test was compared with mean and standard deviation and various 
degrees of warning were given for radical departures from the normal 
curve for that particular assembly, including the detection of slow 
drifts, even within the normal curve. This may occur, for example, as a 
product used for cleaning became exhausted or the flux in a paste 
absorbed humidity in the pot etc. In addition, after 20 or more tests of 
one assembly number, a full statistical analysis of the results could be 
made, giving more details.

Interestingly, individual tests to the left of the normal curve also 
gave a warning because this also indicated that something had gone 
haywire, especially if this was more than one isolated incident. If it 
were because, for example, the operator had just replaced the solvent in 
a vapour degreaser, then we had a logical explanation and the anomaly 
could be ignored. More often, it happened because of some sort of 
operator cheating because he did not want to re-clean a batch he knew 
may have been dodgy; a common one was to test an assembly that had 
already been tested or to hook the assembly so that it was only partly 
immersed in the solution! Believe me, after making CMs for donkey's 
years, I can state that the ingenuity of operators to obtain the results 
they wanted knew no bounds!!! The first computerised CM I made in 1978 
(a one-off) used a Commodore PET computer and there was no way the 
software could be protected; I lent it for field trials to a local 
customer who was also a friend. A month later, my friend told me that he 
was worried at first about the quality of his assemblies but that the 
operator must have improved the process as he was now getting excellent 
results. As always sceptical and knowing the assembly line, I went along 
to find out why: the operator had changed the software (in BASIC) limit 
from 1.5 µg/cm² to 15 µg/cm²!!!! Who would have believed it? This 
incident was part of the reason I dropped the PET in favour of the HP-85 
series, much more versatile and professional, for the launch of the 
first computerised ionic contamination tester in 1979. WOW! 33 years ago!!!

I have no idea what the current CMs are capable of because I retired in 
1997 and have lost touch (in reality, in 1991 when I licensed Multicore 
to take over the CM business with Graham's outfit taking it over later).

Brian

On 17/02/2012 22:22, Richard Kraszewski wrote:
> Thanks to all who responded to this string. Realized it could strike a chord.
>
>
> To carry this a step further on a very related topic...
>
> Any of you guys ever try to run a Cpk on ROSE data sets?  Most of the times I've tried to over the years, the data sets have been non-normal, single tailed distributions, with highest counts near zero and then tailing off towards 10.06. (Similar to having only the right side half of a normal distribution curve).  They have defied data transformation to a normal distribution, hence can't really run a proper capability analysis (data of course must be normal for a Cpk).
>
> You could of course (at least within Minitab) try to run as a non-normal distribution and just report a PpK, however with such a high count near zero it's next to impossible to find a statistically supportable non-normal distribution.
>
> I would appreciate any related experiences and/or thoughts on this topic.
>
>
> Rich Kraszewski
>
> -----Original Message-----
> From: TechNet [mailto:[log in to unmask]] On Behalf Of Richard Kraszewski
> Sent: Thursday, February 16, 2012 2:00 PM
> To: [log in to unmask]
> Subject: [TN] Correlation Factors for ROSE Testing
>
> While I realize that IPC specifically and the industry in general, does not support the use of ROSE correlation factors for the various testers, I have a need to see the official document that at one time quoted these specifically allowed factors.
>
> I took a cursory look though all 230 pages of IPC TR 583 and didn't see that table.
>
> I seem to recall a military specification that had that table. Was it 454? 28809, 2000?
>
> Does anyone recall?
>
>
> Rich� Kraszewski / PLEXUS
> �
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please contact helpdesk at x2960 or [log in to unmask]
> ______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please contact helpdesk at x2960 or [log in to unmask]
> ______________________________________________________________________
>


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] 
______________________________________________________________________

ATOM RSS1 RSS2