-----Original Message-----
From: Clifford, Tom
Sent: Friday, May 20, 2005 10:19 AM
Hi Werner and the others I agree and here's my 2-cents worth ........
1) Doing F/A post-"failure" is absolute. Cable-connector artifacts are certainly fixable. Ring it out, fuss a bit, then re-set the Anatech, make some notes and keep cycling/counting. In contrast, PWB artifacts are certainly a serious diversion, and I agree must be considered separately from solder-joint failures. Depending on whether you are looking at PWB features or solder-joint features, you might be able to jumper around an identified anomaly and keep going.
2) Manual-probe for opens (for solder-joints) is a very reassuringly reliable confirmation of a properly set up Anatech's detection. The Anatech catches them a few cycles sooner than the manual probe. During bench probing, make sure you don't push down on the component, otherwise you'll get apparent continuity again.
3) Resistance does not ease slowly upward. It flickers a bit during ramps, then skies to wide-open within a few cycles of the first flicker. Subtle corrections for resistance/temperature effects and thresholds are typically not that important.
4) Fractures (visible and pry-apart-verified) always start happening long before the joint starts showing resistance-increase or opens. You can see the crumbled shear-plane working it's way thru the fillet waist, then developing into cracks, which get worse and worse as cycling proceeds, then the joint goes electrically wide-open.
5) I certainly agree that failure definition is crucial. "Crack"-free life is 1/4 to 1/2 electrical-open life, and that ratio depends on scores of factors. Folks typically know that. Some of us use (or at least we think we use) a definition of 1/2 fracture-plane area as the "life". That's tough to measure (requires lots of tests and de-caps) and apply. Certainly predictor-models and their users must cope with the crucial distinction between life-at-first-shear-damage and life-at-first-full-open.
6) The "random" question is pervasive. Early-fail mavericks typically show a workmanship reason, and their life could be discounted, in defining the population metrics. We use any early-fail maverick (that shows statistically out-of-family life, as anecdotal evidence in workmanship/QC guidance. Mavericks aside, all the specimens in the population that's left (beta 6-9 typically, in test), all look pretty much the same (certainly "same" is arguable, what with void content and local geometry effects still undefined).
7) Early-fail mavericks are the bane of high-rel applications. What is statistically representative and inevitable, and what is a fixable never-to-be deployed maverick? We (not speaking as a company rep !!) always agonize over whether we should we use a low maverick-inclusive beta in early fail projections, or use a controlled-test beta-8 projection? anyhow ....
cheers Tom
-----Original Message-----
From: TechNet [mailto:[log in to unmask]]On Behalf Of Werner Engelmaier
Sent: Friday, May 06, 2005 5:23 PM
To: [log in to unmask]
Subject: Re: [TN] IPC 9701 Failure Definition
Hi Bev, What you say may be true to some extent,
(1) having one reliable source should be good enough;
(2) commercial laboratories have no problems, they simply have learned to properly shield;
(3) would you not rather have a sensitive test method that gives a failure indication when failure occurs;
(4) how to you in any real sense 'calibrate' something that is more or less random?
Hi George, That is why the proper design of test vehicles is so important. One needs to exclude extraneous failure modes by design to the extent possible. I fully agree that FMA is very important, but you do not want your FMA to be a search for a needle in the haystack.
Werner
-----Original Message-----
From: TechNet Wenger, George M.
Sent: May 6, 2005 8:51 AM
To: [log in to unmask]
Bev, I wasn't a member of 9701 during those discussions either but my
experience says I agree with Werner's assertion that event detectors are
better than data loggers at determining when an event occurred.
However, I'm going to side with your comments. Data loggers are easier
to come by and less expensive and aren't as finicky as event detectors.
The kinds of problems I've seen during reliability testing aren't due to
poor detection of events but understanding exactly what failure
generated the event. I'm sure you would agree that you can't ( or at
least shouldn't) run a reliability evaluation, with data loggers or
event detectors, without doing FMA. I've seen too many cases during my
previous employment and with the current Pb-Free testing to know that
it's sometimes more import to know what failed. I'm currently
evaluating temperature cycling failures on Pb-Free test vehicles that
were subjected to 6000 cycles of 0C to 100C. The event detectors
indicated that approximately 25 to 30% of the peripherial leaded
packages on the test boards failed. Manual resistance measurements
after the 6000 cycles confirmed the detected events. However, FMA has
shown that the peripheral leaded package Pb-Free solder joints were not
the reason for the failures. In one case the events detected were
cracks in through-vias used in the daisy chain and in the second case
the events detected were cracks in outer-layer daisy chain traces.
Regards, George M. Wenger
-----Original Message-----
From: TechNet Bev Christian
Sent: Friday, May 06, 2005 8:05 AM
To: [log in to unmask]
Werner, I was not a member of the committee during those discussions. However,
if a company has a library of completed testing using the data loggers
and they that a product tested to X number of cycles which they know by
experience will be equivalent to more than the life of their expected
product, shouldn't that be good enough? Or better yet, they have run
experiments with both data loggers and event detectors and have
correlated the results?
Probably the main reasons people use data loggers over event detectors
are:
1) data loggers are easy to come by - more people sell them
2) event detectors are SO finicky when it comes to glitches . You
practically have to ground your grandmother three countries away to not
have spurious signals.
Regards, Bev RIM
-----Original Message-----
From: TechNet Werner Engelmaier
Sent: May 5, 2005
To: [log in to unmask]
Hi, Yes you are correct. HOWEVER, I have a real problem with the use of
data loggers for finding solder joint reliability. They have been shown
to miss failures for many thousands of cycles after the fracture
actually occurred. I strongly advise against the use of data loggers [
they are o.k. for bare board testing] for solder joint reliability
testing. Their inclusion in IPC-9701 was against my advice and against
all my experience.
Werner Engelmaier
-----Original Message-----
From: TechNet Kirshenbaum Mordechai
Sent: Wednesday, May 04,
To: [log in to unmask]
Subject: [TN] IPC 9701 Failure Definition
According to *4.3.3.3 in IPC 9701, for data loggers, failure is defined as
a maximum of 20% nominal resistance increase within a maximum of five
consecutive scans.
But the TCR of the daisy chains copper conductors is 3900 ppm/C,
therefore, the ohmic resistance readings at 100 C will increase by more
than 20% of the nominal resistance, taken at the start of the test, at room
temperature.
Thus this imply that the nominal resistance and all the other resistance
measurements should be taken at the same temperature?
---------------------------------------------------
Technet Mail List provided as a service by IPC using LISTSERV 1.8e
To unsubscribe, send a message to [log in to unmask] with following text in
the BODY (NOT the subject field): SIGNOFF Technet
To temporarily halt or (re-start) delivery of Technet send e-mail to [log in to unmask]: SET Technet NOMAIL or (MAIL)
To receive ONE mailing per day of all the posts: send e-mail to [log in to unmask]: SET Technet Digest
Search the archives of previous posts at: http://listserv.ipc.org/archives
Please visit IPC web site http://www.ipc.org/contentpage.asp?Pageid=4.3.16 for additional information, or contact Keach Sasamori at [log in to unmask] or 847-615-7100 ext.2815
-----------------------------------------------------
|
