At 04:34 PM 11/21/01 +1100, Ian Wilson wrote:
Method 2 is better but may not work with a future release as really
keepout tracks do not need a net assignment, but hopefully Protel will
realise the problem and add Object Kind (with at least Keepout as an
option) to the min/max rules scopes, or explicitly provide reliable
support for such dummy nets.
In general, the decisions to limit rule scope to certain criteria instead
of all available criteria, like the decisions to limit what attributes of
primitives are exported or what can be edited, lead occasionally to user
frustration. If it is necessary to have some kind of safety lock, fine, it
is only rare that we need what they have not provided, but when we need it,
it can be *very* frustrating.
Width attributes of keepout track should not be DRC'd period. I think I'd
also vote for automatic clearing of net assignment to it, but I could be
convinced, I suppose, that one might want to define a keepout track with an
assigned net as prohibiting all copper primitives *except* the track's net.
But that could also have its problems, I think first of the routines that
report track length, do they include net-assigned keepout track?
The existing problem, like many of the current Protel anomalies, is a
result of Protel giving us a new feature, a very valuable feature indeed,
one which we requested (layer-specific keepouts are one of the new things
in Protel 99SE); but when something new is added, there are hosts of
consequences which may not be forseen or discovered in Beta testing. So as
long as the program is being functionally improved by the addition of new
features, I expect there to be at least minor bugs, the kind that may take
months or longer for us to discover.
There are those who fault Protel because there are bugs in the program, who
consider that somehow Protel has ripped us off by allowing software with
bugs to be released. I, for one, am grateful that they did not wait for
perfection before releasing the software, and I hope that they continue to
give at least equal priority to improving function and features. Yes, when
a bug has been reported and it still remains through two subsequent service
packs, someone has goofed, but, by my book, Protel has some slack until
that point.
That there are a few such long-standing bugs shows that Protel's policies
(I'm referring to the Protel programming group which may or may not share
personnel with other Altium groups) can use improvement. We can encourage
and help them by our work in clearly identifying bugs; we can extend this
by giving priorities to the fixing of these bugs, as we did in the past
with desired features.
[EMAIL PROTECTED]
Abdulrahman Lomax
Easthampton, Massachusetts USA
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
