<snip>
> As one example, I am thinking of how to set Solder Mask and Paste Mask
> expansion values. In AdvPcb 2.8, users set these on a pad-by-pad basis
> (though the global editing feature made it easier to set (and/or check)
> these properties on a multiple-pad basis). With Protel 3, 98, and 99
> (original version), these values were set by Design Rules. With Protel 99
> SE, it is now possible to set these values either by a pad-by-pad basis
> (like in AdvPcb 2.8) *or* by the use of Design Rules (like in intermediate
> versions).
>
> Personally, I think this is a commendable enhancement, and I was actually
> one of those who requested this. That said, there are times when I wonder
if
> the current implementation is as good as it could be. I can't help
thinking
> that if a user changes one (or both) of these values from a "Pad" dialog
> box, then perhaps that change should also result in the creation (or
> modification) of a Design Rule which (co-)records/logs/documents the user
> changing that setting in this manner. When a user places a Room (object)
in
> a PCB file, that results in a corresponding Design Rule being created; I
> envisage something similar for Solder Mask and Paste Mask expansion
> settings. In other words, there would be two-way synchronisation between
> Design Rules and settings changed on a pad-by-pad basis.
>
> By all means object if you think that what I am saying there is a load of
> c***. But the point I am trying to make is that Protel's efforts to
> accommodate users' requests can sometimes result in them having to cope
with
> conflicting aspects and/or concepts.
<snip>
> Geoff Harland.
I'm following up with a response to my own previous post. Thinking more
about it, one issue which would be problematic with what I suggested is what
would happen when pads are not uniquely identified, and different pads
sharing the same identity (e.g. Free-1 or U4-B) have distinct solder mask
and/or paste mask expansion values, which can presently occur when these are
set by using the "Pad" dialog box.
One way of coping with this situation would be to have the software monitor
for it, and when it is detected, a warning box is invoked. This would alert
the user that there are *other* pads having the same identity, and the
change that the user is currently making will *also* apply to them if the
user continues with it. If the user then wants to continue, that will then
happen, otherwise, the change will then be abandoned.
Alternatively, any Design Rules while were created (or modified) for such
pads (and/or vias) (as a consequence of changing these values by the dialog
box) would need to be labelled/tagged/qualified in some manner, to indicate
that the pads (vias) specified by that Rule are not unique, *and* that the
associated Rule does not apply to *all* of the pads (vias) concerned.
Perhaps a supplementary feature could be provided in which the pads (vias)
which are *not* subject to the Design Rule concerned could be placed into a
selected state, to facilitate their identification by the user.
This complication could of course be avoided if my suggestion was not acted
upon at all. But I consider that we currently have a situation where the
("Pad"/"Via") dialog box depicts the expansion values for a given pad or
via, but the Design Rules, by themselves, do not *always* do so as well
(/instead).
What do others think? (Your 2c worth of thought on this matter would be
appreciated.)
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 join or 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
