Mark and Dennis thanks for the reply:
Actually Dennis hit the nail on the head  :   smarter DRC would cover the
problem.      I not sure Mark understood the issue ,    On inner layers
where there is no trace , there is actually no pad  if you generate gerbers
with " unconnected pads on inner layers removed"   This is the setting that
board  manufacturers prefer, since they remove "floating" pads anyway.
Unconnected pads,  float, causing shorts, and also cause premature  drill
bit wear.  Every board house removes these whether you include them or not.

In 99SE is  assumed that the pad is present for the DRCs whether the
connection is there or not.  Thus on inner layers clearance should actually
be allowed from trace edge to hole edge  ( as allowed by manufacturing).
Mark, vias are padless internally on all designs  unless they connect to a
trace. Removal of these pads only helps manufacturing .  A via consists of
top pad with min annular ring, bottom pad with min annular ring and a barrel
with no pads  unless it is connected a signal layer inwhich case it has one
pad on that layer.    The internal and external annular rings are
independent of the floating pads.

A smart DRC rule  ie    "unconnected pads on inner layers removed" would
solve the problem.  Can that be done in DXP?  can we see it SP7 which by the
way I would also pay for.


Mike Reagan
EDSI
Frederick


----- Original Message -----
From: Mark Koitmaa <[EMAIL PROTECTED]>
To: Protel EDA Forum <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 1:49 PM
Subject: Re: [PEDA] Inner pad feature


> Mike, since you are talking about high density connectors I assume you are
> using minimum via sizes. If so, given todays minimum hole sizes and
annular
> rings, is it advisable to route this close to a hole? In my experience,
> taking into account hole position tolerance and over drilling to
compensate
> for hole wall thickness, routing this close to 'padless' via might result
> in a short.
>
> Maybe your fab house can do better, but the ones I've used need at least
> 5.5 mils around a via hole to prevent break out of the hole wall. This is
> what we use as minimum annular ring. For a decent fab yield we need at
> least 3 mils air gap to the nearest trace. Removing the unused via pad
> during layout doesn't buy us any extra routing room so I don't see any
> advantage in removing the unused via pad.
>
> If you are using vias with a greater than minimum annular ring, wouldn't
> you get the same by just reducing the annular rings on the affected vias?
>
> Mark Koitmaa
> TechServ
>
> At 10:15 AM 9/17/2002, Mike Reagan wrote:
> >One feature I would like to see in "future" releases or service packs is
> >removal of inner pads before processing gerber data.  In other terms
inner
> >pads would not be added to a via until a connection is made to that via.
> >The reason for this is for high density connectors where I am trying to
> >route between pad, I often get violations, when in fact the real gerber
data
> >will have no clearance  violations after gerbers are processed with
removed
> >inner pads.   This would allow proper routing in high density connectors.
> >The padstack for a via would automatically represent the a via the way it
> >really looks to the fabricator not to the designer.
> >
> >An no ,I dont want to go the way Accel did with their complicated
padstacks
> >because then I have to spend time creating a complex stack library with
> >silly names.  Editing vias in either PADS or Accel is time consuming,   I
> >like being able to double click and everything about that object appears.
> <snip>
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to