Empty quotes work now, but there’s another crash with '' with or without content.
(condition "A.Name('') && B.Name('')")
or
(condition "A.Name('x') && B.Name('y')")Ahh… it’s not the empty strings. Name is a property not a function call. So it should be A.Name == 'x'. Still tracking down why it crashes…
I managed to get this evaluated without crash or errors:
(version 1)
(rule "twozones_clearance"
(constraint clearance(min 0.5mm))
(condition "A.Name == 'zone1' && B.Name == 'zone2'")
)
But the result is this:
Do I have something wrong, is this supposed to work?
BTW, I find C-style expression syntax cumbersome. There should be no need for double =, & etc. because we don’t do assignments in the expressions, right? Simple A.Name = 'x' should be enough.
And when I try it with one = character, accepting the dialog crashes.
Same here. I’ve both zones connected to the net GND.
The function-call-instead-of-property-reference thing turned out to be a fairly thorny bug in the underlying code generator. I believe the fix for that also fixes the single ‘=’ problem (or at least I can’t reproduce that).
I haven’t had a chance to look into the zone filling yet.
I find Pascal syntax cumbersome. I prefer one used by C/C++ or Python 
Tom
1 Like
I like indentation of Python. Let’s be specific then: the idea of using double characters, == etc., for comparison and single for assignment was wrong to begin with, whatever the century and language, and that’s an objective fact
No luck yet – another problem. KiCad goes into a loop which uses 100% of a core and eats up memory when doing the check for this:
(version 1)
(rule z
(condition "")
(constraint clearance(min 0.5mm)
)
I don’t know if the order of items inside rule is important, but IMO it would be more natural to have the condition(s) first, then the constraints.
EDIT: it does that with the constraint first, too.
EDIT 2: it seems to choke on the constraint.
EDIT 3: and this crashes:
(version 1)
(rule z
(condition "a.Name == 'zone1'")
)Could you send the board (in priv)? Is it a large design?
T.
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.