It’s just a meaningless test board.
test_a_zone_1.zip (218.1 KB)
Pfft. That second crash is a typo. First one might be too…
[Edit: nope, the first one was due to failing to check for end-of-file (in several different places). Fixes for both on the way…]
OK, no critical problems any more. I finally got back trying the zone/zone clearance:
(version 1)
(rule zones
(condition "A.Name == 'zone1' && B.Name == 'zone2'")
(constraint clearance(min 1.0mm))
)
Interestingly, this works as expected:
But changing the clearance to e.g. 0.9mm doesn’t:
The project is the same than in the previous post.
I’m getting this with 0.9mm:
And this with 0.3mm:
(Those are with the single rule in your post directly above.)
It’s about parsing the numbers. My locale is fi_FI, the decimal separator in that locale is ‘,’ instead of ‘.’. Changing LC_ALL to en_US makes it behave like in your system.
EDIT: I think it doesn’t understand the . separator when locale has ,. It just cuts the number there. Therefore 1 was correct while under it were not.
It should be agnostic about the separator, accepting both. Otherwise the rule aren’t portable.
From another thread…
I find this a bit restrictive. Why only zone/keepout? How about letting it be any item? For example a pad, track segment or graphics. A requirement would be that all items can have a name or other simple means of identifying them.
Let’s take edge connectors and castellation as an example. We need (rule edge_clearance (constraint [ignore-edge-clearance]) (condition ... ) ) or something like that in combination with copper inside pads of a footprint. Depending on the exact syntax it could be easier to say for example
(rule "edge_pads"
(condition "A.insideArea(B.padOf('J1') || A.insideArea(B.padOf('J2')
(constraint...)
)
or even
(rule "edge_pads"
(area "a.padOf('J1') || a.padOf('J2') || a.Name=='leftEdgeConnArea')) ##each subexpression defines board item(s)
(constraint...)
)
than to draw several items into the board and use them. (In that example with “area” there are both pads and a named item.)
And if there’s need to draw an area, why not use any item? Defining a keepout zone without keepout properties feels a bit like a hack, and the shape may be difficult to draw. It could as well be any graphics shape which has the name property.
The name property could be implemented as a member in the base class of all items. It could be exposed in the object inspector or in other editing UI’s.
Another enhancement which would open new possibilities and allow rules without drawing new polygon areas would be to use groups. Item groups are under planning right now. Add A.belongsToGroup('groupname').
But as far as I can see, the plan for groups is at the moment too restrictive. They are for tying items geographically together and are exclusive. Rather, group should be more generic and there could be several kinds of groups. The most generic group would be only an abstract named list of items without any specific restrictions. One item could belong to several of these groups. Then the group name could be used in rules.
Even a the more restrictive geographical group would be fine for for example inner slots made with edge.cuts which may need different clearance than outer edge. At the moment it would need a zone around it. But if the segments are grouped together that group name could be used instead of a zone area.
This of course requires groups having names; I don’t remember if the group plans include that.
Which did you use in your rule, a ‘.’ or a ‘,’?
‘.’, exactly what was quoted in an older post.
Odd. I can certainly see it breaking the other way, but this is code and code is generally not localised. I’ll look into it…
This would be a separate feature from the geometric groups that have been implemented already for PcbNew. This sounds kind of like “component classes” in Altium.
Well, it needs to be something that has a well-defined area. It might be possible to turn it on for pads. And there is a similar function for footprints: inCourtyard().
I kind of like padOf() though. But you might also want to know the parent of a zone or copper graphic item in a footprint. Maybe isChildOf()?
I think every basic graphic item has a well-defined area, namely inside the graphics. For example all straight lines – graphics and track segments – are oval or stadium shaped areas. Circles are rings (not filled circles). Footprints are not well-defined areas. Text aren’t either, or dimensions.
It seems to work now.
I have searched through a lot of posts and finally found this. I am trying to set rules using this system but I just cannot figure it out. It seems syntax has changed over time, it is really difficult to start testing this without a clear starting point. The whole selector is not even covered in the syntax help in 5.99.
My goal: set clearance between two net classes to a different value than clearance inside the net class. Currently I have the following:
(version 1.00)
(rule HV
(constraint clearance (min 0.5mm))
(condition "A.netclass == HV && B.netclass == HV"))
(rule HV_Default
(constraint clearance (min 3.0mm))
(condition "A.netclass == HV && B.netclass == Default"))
(selector (match_netclass "HV") (rule "HV") (rule "HV_Default"))
However, this still sets a clearance of 3.0 mm between pads of components inside net class “HV”. I am really eager to use this but I am really missing a clear overview and explanation of the syntax.
Edit: this also does not work, here the 3.0mm is completely ignored:
(version 1.00)
(rule HV
(constraint clearance (min 0.5mm))
(condition "A.netclass == HV && B.netclass == HV"))
(rule HV_Default
(constraint clearance (min 3.0mm))
(condition "A.netclass == HV && B.netclass == Default"))
(selector (match_netclass "HV") (rule "HV"))
(selector (match_netclass "HV") (match_netclass "Default") (rule "HV_Default"))
To be complete: I need to set a clearance between all conducting parts (tracks, vias, pads) of all components in one net class and another. The clearance between parts of components in the same net class have to be much smaller. The application is isolation between high voltage referenced parts and low voltage side. This could also be achieved by adding a keepout zone with the correct width, but of course it would be much nicer to have this set in rules that DRC can use.
Yes, following this is increasingly more and more difficult. @JeffYoung, would this be a good moment to start a new thread with better introduction and continue with the newer expression syntax with some examples?
“selector” isn’t used anymore, you probably should be able to do it with costraints and conditions only. Selectors were replaced with expressions in the conditions.
I won’t speak for Jeff, but even though I know many people are excited about this feature, it might be best to hold off trying to use it for serious work until after feature freeze. The DRC system is still changing, and the rules system needs to keep up with it. Writing documentation, examples, etc. takes time that I think the dev team would rather spend on code before the feature freeze is in place.
I understand that, but I mean continuing this “guinea pig” testing, which would be easier if the current state would be better explained without need to browse through two gazillions of posts. Jumping on board now is difficult.
EDIT: most of the posts in this thread are now outdated in one way or another, pertaining to old syntax or already fixed bugs.
@eelik that sums up pretty well how I’m feeling as an outsider just coming across this, maybe just a fresh topic would already suffice to continue testing.
Is there any clue on which time scale feature freeze will happen and a release will be made? I know v6 has been in the works for a while and per the road map my guess still quite some time is needed for a stable release with its features.