>The first rule has the highest priority. Rules are tested against all >objects. So your first rule will generate an error on all holes not equal >to 42mil. It won't help that you have alternative rules following.
I would say, that the rules are tested against all objects covered by the rule's scope.
Create a rule that covers only the objects you want to test or excludes the objects you don't want to test. E.g. in this case, in the general rule with the scope 'board' (if there is such a rule) he should exclude the holes of the sizes he wants to check specifically, and create rules to check each of them individually.
The problem is how to distinguish those hole sizes from the rest. They could belong to a net, a component, a class or something else.
That is certainly true, and is a technique that is very useful in DXP (use the NOT function to exclude objects from a rule rather than including objects).
The problem here, as you say, is constructing a sensible rule that is guaranteed to test correctly all holes. What if one net was not part of a class? Or what about free holes not connected to a net? What about nets with a mix of permitted holes?
It is also made more complex as vias are not an object in the hole constraint scope list (neither is pad specification an allowable scope in the hole size rule). So you would have to use nets or net classes and then you have a problem ensuring full coverage, don't you.
How would you frame a rule that checked that all holes on a board were either 28 or 35 mils. Interesting exercise. Should include free vias and pads, component pads, anything connected to nets and anything not connected to a net. A further restriction would be that if the net classes etc, or whatever, were used were not correctly maintained, that the system was failsafe and would not let through un-wanted hole size (in other words, if I forgot to maintain the class info correctly, I would not potentially allow an unwanted hole to get through the system - this may be best done by a "whole board" scope checking against one of the desired hole sizes (the most common presumably)).
Lets try a simpler case. How would you check, reliably that for a given net, say VCC, that holes were either 28 or 35 mils and nothing else. Test this against a VCC net that has both 28 and 35 mil holes. I can't see a method of doing this in P99SE.
P99SE does not have a ready method of selectively excluding things from a check. If something meets the scope (in net VCC, say) it will be tested against the rule. So a 35 mil hole will generate an error when tested against the VCC/28 mil rule, and visa versa. Now if we could exclude anything that had a hole size of 35 mils from the 28 mil test then we may be getting somewhere - but again P99SE does not allow a pad specification to be used in a hole constraint scope - and it does not allow a via hole size to be a valid scope and, anyway, it does not support "not equal to" operations on via and pad specifications even if these scopes were supported in the hole size constraint rule.
I may be missing something but I can't see hole a rule set could be constructed to ensure reliable full coverage and to restrict holes to one of a number of possible sizes when on any given net any of these permitted holes is acceptable. The problem is not so hard if *all* vias/pads on any particular net are the same. Then a series of net classes can be used.
Maybe I am missing something. Igor, I'd certainly be interested in seeing how it could be done,
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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/[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *