Need some guinea pigs for a rule-based DRC <<PROTOTYPE>>

[JeffYoung]

@eelik

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.

Which did you use in your rule, a ‘.’ or a ‘,’?

[eelik]

‘.’, exactly what was quoted in an older post.

[JeffYoung]

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…

[craftyjon]

@eelik

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.

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.

[JeffYoung]

@eelik, I’ve merged changes which might fix the zone-to-zone decimal separator problem.

[JeffYoung]

@eelik

From another thread…

@craftyjon

You give a name to a copper zone or keepout area, then you can test for objects that are within that zone or keepout by using its name in an expression. If you want to create a rule area that does not have any side-effects other than being used to define rules, you create a keepout but don’t set any of the keepout restrictions.

The expression would look something like:

 (condition "A.insideArea('zone_name'))

I find this a bit restrictive. Why only zone/keepout?

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()?

[eelik]

@JeffYoung

Well, it needs to be something that has a well-defined area. It might be possible to turn it on for pads.

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.

[eelik]

@JeffYoung

I’ve merged changes which might fix the zone-to-zone decimal separator problem.

It seems to work now.

[Bastiaan]

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.

[eelik]

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.

[craftyjon]

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.

[eelik]

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.

[Bastiaan]

@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.

[eelik]

See Post-v5 new features and development news and the next post by Seth.

File format freeze is actually more important for end users for many purposes, also WRT to the DRC rules, but I haven’t heard about plans for that.

[JeffYoung]

Conditions replaced selectors. So just use:

(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"))

You may need single quotes around the netclass names:

(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'"))

[JeffYoung]

You definitely need the single quotes.

(To check your syntax click the bug icon at the bottom of the Rules Editor.)

[JeffYoung]

@eelik

would this be a good moment to start a new thread with better introduction and continue with the newer expression syntax with some examples?

Possibly. I worry that it will still experience a few more changes. (On the other hand, it’s a lot more stable than it was.)

[craftyjon]

I think for the sake of new people coming across this thread (like @Bastiaan) we should not do a new thread until after feature freeze

[eelik]

Then just explain the half-time situation and edit the first post with a link to the latter post.

[craftyjon]

This thread is for adventurous users who want to test a feature that is changing while they test it, and accept the pain and confusion that comes from doing so. I think it would be good to have another thread once we are at the point where the feature is stable enough that we want to do things like write more official samples, and avoid changing the syntax / doing other changes that confuse people. Before we are at that point, I’m not sure the value of a new thread.