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

Reply via email to