> I will once AGAIN pipe in on this subject as it has been brought up by
> me and others time and again. Protel look at 2.8. You could modify
> ANY pad or via globally, all the way down the the thermal spokes,
> drill size, mask clearance, paste clearance!
>
> While this does not totaly address Mr. Wilsons solution it points Protel
> back to its roots where things were easy to do.
>
> Masks are not rules checked, Planes are not rules checked.
>
> Why are they in the rules section?
>
> Hell, Routing rules are not abided by.
>
> Pads, That's the issue. Look at em, they can be on all layers or one. We
need
> to be able to deal with each as an individual.
>
> Jim Mcgrath
In some (but (agreed) not all) ways, Protel 99 SE combines the "pad-setting"
features of AdvPcb 2.8 with the "rule-setting" features of intermediate
versions (i.e. Rev 3, 98, and original 99). As this is something I requested
myself (as did others) in times past, Protel are to be commended for
actually doing this.
OTOH, I am not convinced that the resulting implementation is as good as it
could be. I have previously stated that I think that setting a customised
soldermask expansion or pastemask expansion from a "Pad" (or "Via") dialog
box should ideally result in the automatic generation (or modification) of a
corresponding Design Rule; this would "co-register" the dialog box setting,
so that someone examining the Design Rules could detect/observe any
customised settings that were created from a dialog box (instead).
On the gripping hand (Niven and Pournelle's two SF novels on "moties" :) ),
there are complications with doing that as well. Pads are not necessarily
unique, and vias have even less of an "identity". So such "co-registering"
Design Rules would often apply to their associated pads and vias on a
*conditional* basis (whereas existing Design Rules always apply to all pads
and/or vias whose identity complies with the specifications of the
associated Design Rule (with the already observed qualification that dialog
box settings are yet more dominant, *but* such associated settings are *not*
displayed within the Design Rule entries)).
I am not privy to any details, but I would not rule out the possibility that
the next major version of Protel is going to provide an enhanced version of
the existing "Padstacks" feature. Hopefully, that would cater for situations
where users want through-hole pads and/or vias masked on one side of the
PCB, but not on the other side, as *one* example.
Design Rules, dialog box settings, and the "Padstacks" feature collectively
constitute a *giant* can of worms. They are not the only aspect of Protel
which is still problematic, but it would be good if we could establish some
consensus on what should be implemented, and how. Let the associated
discussions continue...
Regards,
Geoff Harland.
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
* - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Browse or Search previous postings:
* http://www.mail-archive.com/[email protected]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
