TECHNET Archives

March 2009

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:
Jack Olson <[log in to unmask]>
Reply To:
TechNet E-Mail Forum <[log in to unmask]>, Jack Olson <[log in to unmask]>
Date:
Fri, 27 Mar 2009 09:31:35 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (110 lines)
 Over the past few weeks many of you have submitted comments about some of
the requirements in the new IPC-2610 series on Electronic Documentation
currently being developed by the IPC. Thank you all for taking the time to
respond. This is a final follow-up to let you know what I submitted back to
the group that will be resolving these issues at the committee meetings next
week at APEX/EXPO:

-=-=-=-

Holes located off grid should be individually dimensioned on the profile
(board outline) drawing or on the drill pattern, whichever is more
convenient.
When printed board features fall off grid, they shall be individually
dimensioned and toleranced on the Fabrication Data Set.

- While nearly everyone agreed that grids are useful during the design of
circuit boards, no one could think of a reason to use them in subsequent
operations fab/assy/test, nor could anyone point to a specific process that
would benefit from seeing the grids specified in the final documenation
package.

-=-=-=-

The drawing revision description block shall identify the specific changes
made. It is not acceptable to just reference to the Engineering Change
Proposal (ECP) or other engineering document that initiated the change

- This seems to create a significant amount of difficulty for many people.
Maybe the intention is that "if a change to a design is a minor revision, it
is better to list the actual change than to point to an external document"
(don't quote me) but for major revisions, this SHALL is impossible for most
companies.

-=-=-=-

The initial release of a design will be given a (-) revision. Subsequent
revisions will be assigned A,B,C,etc, leaving out I,O,Q,X,S,Z

- Almost everyone balked at this. Maybe the message should be "there are
good reasons for following these guidelines where older technology is still
being used (fax, microfiche, etc) but for modern electronic documentation,
any system that allows accurate tracking and removes ambiguity is
acceptable" (again, don't quote me, I'm just trying to express the idea.)

-=-=-=-

Three fiducials (or registration targets) shall be located on grid and on
each layer of data pattern. Each additional layer or data pattern shall have
fiducials located at the same points which, shall register with each other,
layer to layer.

- I think this is an incorrect mixture of terms. Let's use fiducials to mean
the small dots that cameras can use to verify location/alignment (which
virtually everyone uses, but only on surface layers, which needs to be a
SHALL) and targets to mean layer registration features (that few designers
use anymore, and should NOT be a SHALL)

-=-=-=-

Unplated through hole patterns, especially tooling and mounting holes (board
mounting holes, interface connector mounting holes, board top plate/mounting
bracket mounting holes, etc.) are generally drilled in separate drilling
operations as one of the last fabrication operations. They shall be
explicitly dimensioned and toleranced, even if they occur on grid.
- The reader may misinterpret this to mean that unplated holes shall be
dimensioned, but I think you meant that at least one dimension should locate
the unplated PATTERN into the overall design. Of course any hole
tolerance/location that is so critical that it should cause accept/reject at
final inspection must be dimensioned as well. I don't think anyone would
argue that.

-=-=-=-

A note on the fabrication data set shall specify the acceptable bow and
twist requirements

- Choosing this one characteristic out of all the conditions listed in the
6012 Appendix A seems bizarre. What seems much more important in the big
picture is that once a class is declared, any requirement specific to the
design which deviates from that default class requirement MUST be specified
in the documentation. That's just common sense (and should be a SHALL even
though I used MUST in the previous sentence, ha).

-=-=-=-

Ok, that's it! I hope I'm not overlooking anything, and if my inexperience
has led me astray from the reasoning behind any of these SHALLs, please use
your own good judgement. Again, sorry I won't be there next week to help
out.

(by the way, thanks for the encouraging words in your interview with Andy)

Hope the meetings go well, Have a great conference!

Jack
CID+


.

---------------------------------------------------
Technet Mail List provided as a service by IPC using LISTSERV 15.0
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
-----------------------------------------------------

ATOM RSS1 RSS2