At 11:21 AM 5/06/01 +1000, you wrote:
> > Does anyone else wish to have the ability of at least reviewing and
> > possibly adjusting the priority of PCB design rules?
> >
> > I envisage a sort of spread sheet/grid arrangement where all the rules are
> > shown in their order of priority. There could be a drop list allowing the
> > user to filter the displayed rules according to type (All Rules,
> > Clearance, Plane Connection Style, etc).
> >
> > Currently, it is sometimes difficult to determine what the order of
> > application of the various rules will be.
> >
><..snip..>
>
>I have recently tried it out, after having vague recollections that such a
>feature existed. With the default menu for the Pcb Editor, a right mouse
>button click invokes a popup menu, which contains "Applicable Unary
>Rules..." and "Applicable Binary Rules..." entries. When one of these items
>is selected, you will be asked to click on either one primitive or two,
>after which a dialog box is invoked which lists what currently defined
>Design Rules apply to the primitive object (or two objects) in question. For
>each type of Design Rule, the associated Design Rules are listed, in order
>of dominance (most dominant rule top-most). Disabled rules are depicted with
>the use of strike-through text, while an accompanying tick indicates the
>most dominant enabled rule, while the remaining rules (enabled or otherwise)
>are accompanied by a cross instead.
>
>I suspect that this could match your interest in being able to review Design
>Rules, along with the order of dominance for these.
Not really - I am well aware of the right-click applicable rule
function. I want to be able to review all rules that apply to a PCB in one
go. the rules dialog does not satisfy this as it is tabbed-based. I want
a flat spreadsheet/grid view that allows all rules to be viewed in one go.
>I would like some time to fully think through your suggestion of being able
>to promote and demote Design Rules, but off-hand, this would not *always*
>make sense; I would not see too much merit in being able to demote a
>pad-specific Design Rule below a board-specific Design Rule, for instance.
Of course - but there are many times when the default implementation of
rule priority is not what is desired due to bugs and the assumptions of the
programmers.
If I asked for a pad-specific rule to have lower priority to a whole board
scope rule then so be it. Maybe the system could be smart enough to
realise that the rule is redundant and grey it out, so warning me that it
can no longer be applied.
>The current implementation does not support some types of Design Rules being
>defined in some ways, e.g. it is not always possible to specify a region as
>a qualifying criterion. As such, a case could be made for refining the
>existing implementation so that the implementation of all types of Design
>Rules are as "uniform" as possible.
I have asked for region scope, in particular, to be more widely
available. I tried to raise the discussion on rules many months ago with
little interest. I remain interested in what new and modified rules people
would like.
>But something that Protel really should do, and especially if they want
>their product to still be able to run on "consumer" versions of Windows (Win
>95, 98, and ME), is to do something about the user interface for Design
>Rules. I do not fully comprehend why the existing dialog box requires so
>much in the way of resources, but the current implementation does need to be
>overhauled, arguably even at the risk of having to cope with new bugs
>(before these are then ironed out).
Tabbed dialogs in Delphi are resource hungry - I do not know if that is the
fault of the underlying Tab common control Win32 API or the overhead Delphi
applies. Have a look at the rules dialog - it is tabs within tabs. Each
rule scope consists of a tabbed dialog and the whole thing is a tabbed
dialog. So depending on the number of rules you have there can be a lot of
tabbed dialogs and so heavy resource usage. At least that is as I
understand it. Delaying creation of forms until they are required, and
killing forms no longer required, is reputed to be one method of dealing
with heavy resource usage of Delphi-based programs.
>Design Rules are a pretty big topic; perhaps it would be better to focus on
>whether the current set of available Design Rules caters for what users want
>when designing "real world" PCBs. Can the KeepOut layer be specified as a
>layer when defining Clearance Rules, for instance?
Yes lets work out how the rule system can be improved... suggestions please.
Ian Wilson
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
