At 12:08 AM 1/18/2003, Robert M. Wolfe wrote:
Abd ul-Rahman

Isn't this just really saying the silkscreen IS the defining factor????
No. The "extents" of the footprint are the defining factor in 99SE, if I am correct -- I didn't check it. Often the silkscreen is the outermost primitive.

IMHO the silkscreen layer should never have been used as an indicator
or ultimately the real extents of a part. There really needs to be a user
defined layer that will be used at the extents of a part to check part
clearance.
Yes. I think that's what I wrote.

And that layer does not necesarily have to be an assembly layer.
There is no such thing as a P99SE "assembly" layer. There are only "mechanical layers," which the user can personally define as "assembly" if desired.

I have seen systems that define both actual part and real world
clearances required for assembly/test/rework etc., and control over
which rule pending level of technology required for design.
Let me guess. What did those systems cost?

And line widths really should have nothing to do with it
when you are defining a clearance just center as if it were
a zero width line.
Yes. Again, this has all been said not only in this thread but before.

 Only silkscreen itself should be considered
for thickness itself with respect to all other features. But part
clearance should be to a dimension MMC, etc not ever dealing
with the thickness of a line defining it.
Of course. Now, to do it at present -- sort of -- , use a mech layer to create a clearance layer with zero width lines (yes, Protel will display them at one pixel) at MMC. Make this a part of all footprints. Do not allow silkscreen lines or any other primitive to extend outside this area. The present clearance rule will only report real collisions (assuming that all parts are rectangular in maximum extent.) This will not work perfectly, but it would work for most parts. And with the DXP additional rules, it will work even better.

But it would still be better to check for line intersections between different footprints on that clearance layer. And the huge problem with this solution is that one would have to rework all footprints.

Protel's way of dealing with this can of worms was to use the component extents. This was a quick-and-dirty solution, almost better than nothing. The mistake was in using true primitive extents (which goes to the outside of outlines) and/or in not allowing negative clearance. Probably better to have used line-center for the silkscreen portion of the extents instead of line-edge as they did. There isn't really a need for negative clearance except as a compensation for the first mistake....

DXP then adds the exception rules which allows one to disable checking for particular parts, so that, one, for example, could place one part under another while suppressing the collision error.

The comment made by one writer that they would rather see 100 false error messages than miss one real problem (or something like that) misses the point. If you see 100 false error messages you are very likely to miss the one real error. What are you going to do the next revision? Check every one of those 101 errors again? This is why, in my opinion, good design requires killing all the phoney ERC reports in schematic; preferably one designs so that the error reports don't come up, but where that is impractical one suppresses them with a No-ERC Directive. In PCB one can do something like this, sometimes, with a special rule. We have asked for better special rules, perhaps a PCB equivalent of No-ERC, which is truly generic, it will suppress *any* error report.


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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