Yes it was still reporting 0.300mm clearance error despite changing it to 0.1mm in the rules.
The nightly build is behind the fixes, so I’ll update it later and re-try.
Yes it was still reporting 0.300mm clearance error despite changing it to 0.1mm in the rules.
The nightly build is behind the fixes, so I’ll update it later and re-try.
@JeffYoung After updating, it looks like the clearance rule works
However, I’m not getting any DRC for the track width rule:
(rule “50-OHM_SING_OUTER” (clearance 0.245) (track_width 0.3))
The actual trace is 0.203mm. The rule defines the minimum track_width, here set to 0.3mm, correct?
Yes, your expectation is correct.
If you lower the track’s netclass track width to under 0.203, does it report that?
Hmmm… reproduces on my test board too, so I can debug it from here.
Fix pushed.
89c46e6834bf17ab5b4630ed5a1f4f48c5c23db3
It’s probably not a good idea to have the same word, “hole” in both Rule and Type tokens.
I updated my local install to c4142a58
which is newer than your commit but I’m still not seeing any DRC error/marker related to track width on my net.
I tried to add a priority rule (with value 10) to the selector on the top layer but still no luck.
When I change the “Minimum track width” in the DRC Control window to above 0.203mm, it reports all the nets violating this rule and this net is spotted too.
Am I missing something in my selector/rule?
(selector (match_netclass “SPI”) (match_layer “F_Cu”) (rule “50-OHM_SING_OUTER”) (priority 10))
(rule “50-OHM_SING_OUTER” (track_width 0.3))
Thanks.
The final syntax is likely to be quite a bit different.
Check the names of your copper layers in Board Setup > Board Editor Layers. I think the defaults are now “F.Cu” rather than “F_Cu” (my test board is very old).
Ha, I was wondering why the underscore instead of the dot.
Anyway, it seems like the layer name actually does not matter… I tried with the dot, but no luck. I changed it to “dummy”, added a rule for clearance and am getting the DRC for “Track too close to pad”, which shouldn’t be there…
@eeintech, can you post a project with just the track & pad that show the issue (with the fixed rules)? (If you don’t want to post it publicly you can also email it to me at jeff@rokeby.ie).
Thanks!
@eeintech was gracious enough to help me debug this, and it turns out I broke the single-item layer test when fixing the two-item layer test. Sheesh.
Fixes are up.
98be50883d76975e065c60066cbb831638e0fac5
Dear Jeff,
I’m very happy that implementation for KiCAD Clearance Matrix is advancing. Thank you so much for implementing it. I think it’s currently the biggest flaw that it is not yet implemented. I’m doing high voltage designs, and this helps me like crazy. So enough waffeling, let’s test.
I’m using the following KiCAD version: kicad-r15850.40b2038cf-x86_64.exe
First propose
I went to File->Boardsetup->Rules. Pretty intuitive. I would recommend to put a link to the syntax documentation. If I found this without your notice, it would just be a textfield for me.
Second propose:
When creating the rules, I would love to have units, because there are some imperial and metric units.
3. Propose
Although not directly related to netclasses, I would like to click on the error marker and see the message.
4. Propose
If I click on cancel in the rule edit window, (as my rule did not compile) I lost all my previous text and was left with an empty window. I want my old working rule version back.
5. Propose
If my rule does not comply due to syntax error, I would like an error message with detalied feedback what to fix. I saw from @eeintech that there was an error window, however I did not see it.
6. Propose
I have the problem, when enting the following text the rules do not compile. What did i miss?
(version 1) (selector (match_layer GND2) (rule inner)) (selector (match_layer POWER3) (rule inner)) (rule inner (clearance 0.3) (track_width 0.3) (priority 1))
When the putting in my previous synatix, that I saved to a text editor, it does not take it, hower it took it before.
(version 1)
(selector (match_layer GND2) (rule inner))
(rule inner (clearance 0.3) (track_width 0.3) (priority 1))
it seems that I get some wired chars, when it replaces the ‘"’ and that causes that issue.
Namely: 0043 and 0044.
7. Propose
The current fill algo does not respect edge cuts.
I tried also the follwing syntax without success.
(version 1)
(selector (match_layer GND2) (rule inner))
(selector (match_layer POWER3) (match_layer Edge.Cuts) (rule innertwo))
(rule inner (clearance 0.3) (track_width 0.3) (priority 3))
(rule innertwo (clearance 1.3) (track_width 0.3) (priority 2))
EDIT: I also tried the following with no sucess
(version 1)
(selector (match_layer GND2) (rule inner))
(selector (match_layer POWER3) (rule inner))
(selector (match_layer POWER3) (match_type board_edge) (rule innertwo))
(rule inner (clearance 0.3) (track_width 0.3) (priority 1))
(rule innertwo (clearance 1.3) (track_width 0.3) (priority 2))
FEATURE REQUEST
Can there be a rule, when there is an edge cut in line-of´-sight, this clearance another clearance is used. I need to put cutouts (edgecuts) to have lower clearance requirements, e.g. between transistor pins.
I guess the following people could be interested in testing too…
@ marcos
@ hildogjr
One more request
Is there an “invert” option. E.g the following:
(selector (match_layer POWER3) (NOT netclass “foo”) (rule innertwo))
Or also adding the bool operators ‘and’ and ‘or’ could be interesting.
@overthere You may have no success because you’ve added the “priority” token to rules, it should go into the selectors instead. I did this initially too and it did not work either. The rest looks good to me.
Just to be clear I’m only implementing part of it. Jon Evans and Tom Wlostowski are doing the other bits.
The selector syntax in the prototype is going to be replaced by an expression language. This should make rule inversion, etc. easier.
You can already click on an error marker and see the violation, the violation amount, and the constraint source. (All are in the status bar at the bottom of the window.)
The rule editor will get syntax checking, code completion, etc. in time.
I’ve run into the quotes thing as well. Not sure what the plan will be there yet.
The
(selector (match_layer POWER3) (match_layer Edge.Cuts) (rule innertwo))
won’t work because when checking clearances the edges are copied to the copper layer.
However,
(selector (match_layer POWER3) (match_type board_edge) (rule innertwo))
should work.
Is this for neckdown? If so we’ll be implementing “areas” where you can assign different clearance values. These are often used under BGAs and the like.
Yes, this will be nice on power electronic designs.
Starting to test it now…
About the Design Rules >> Constraints. I like the icons, very intuitive.
The zone fill option should be a option box (as Design Rules >> Violation Severity), not a check box.
I would like some import/export (JSON or INF format for example) of the Design Rules >> Constraints. This will be nice to easy define the manufacture specifications (also the limitation of the university drill machine).
It could also include the a checkbox for “Allow vias under components” (default ON with a ballon tip: it may make DRC lower when OFF). This check for vias inside the parts contours (interesting for home and university hand-made PCBs).
I have linked the Gitlab reports in this comment revision.
Yes, a link for the syntax will be nice.
But nicer some kind of autocomplete by the language when we type, if this design of text view will be the final user intended.
@JeffYoung could we expect (in future v6) some like this comment mine of a graphical way to link net and rules direct on Eeschema? Do you want that I split this request on Gitlab?
We are planning to support defining net class membership, diff pairs, and other things like that on the schematic side. The details are still being discussed.