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).
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.
I imagine the upcoming feature to have areas with relaxed rules would help.
I would then need to add areas around all the footprint pads in the design for this exception.
It is hard to put into words this requirement if I wanted this to be done automatically. The simplest thing I can think of in terms of possible rules is “do not apply this rule around the pads of the track’s net”.
I’m about to push an update that hopefully addresses some of the issues.
Main changes:
Priority is gone. Selectors are evaluated in order; last one that matches wins.
Distances need to be categorised as min, max or opt.
Disallow constraints are now implemented. (They’re easiest to use with keepout zones, but they will work with any zone they match against.)
Improved parse error reporting which puts your cursor at the error.
Autocomplete for rule syntax.
Syntax help. NB: the help is for the new syntax which will replace separate selector statements with condition statements within the rules. This is not yet implemented, so you still need to use selector statements for now.
I’m an Allegro user with heavy Constraint Manager usage.
I do high-power designs including off-line AC-DC SMPS and that is an area where constraints add a lot of value to KiCad.
Here are some thoughts and observations:
Rules don’t capture multiple layers
If the clearance is different on different layers, which is almost surely will be, this requires multiple rules.
And if those multiple rules together form one meta-rule, each of the rules needs to capture that commonality but yet have a difference.
This results in rules something like “30V_internal” and “30V_external”.
Would be better to allow one rule to capture many layers (and just a specific layer, too, of course) based on location and type:
All outer
All inner
All signal
All power plane
All mixed
All jumper
Naturally, if this is handled with a GUI it’s not so painful to have to type out each rule but any UX would be better with a single rule name.
Net class groups
In offline power supply circuits with a primary and secondary domain, all nets in those domains must be kept apart.
This currently requires a huge mess of constraints, encompassing every net class to be sure no nets are missed.
If one of more net classes could be captured in a group then the groups could be constrainted with far fewer rules.
Could have a single ‘primary’ net class group, single ‘secondary’ net class group, and one rule setting constraint between the groups.
Another example would be grouping of nets on each side of a board-board connector or wires that need to be constrained the same.
Pins and tracks/zones are distinct
IPC-2221A has different columns for copper on internal layers, copper on external layers under mask, exposed leads, etc.
Different clearance rules are needed for each of those three locations, and it’s messy to do right now. #1 above captures some part of it, but rather than having loads and loads of rules it would be easier to have a single smart rule.
Could have a single rule named “30V” with different spacings for different elements: track-track, track-zone, pin-pin, etc.
Clearance line around pads is generally wrong
There is a clearance line around pads that indicates the clearance for the net.
As there used to be a single value for the net this was a valid line.
But it no longer applies across the entire board because the clearance between a pad and another other object can vary.
The clearance line therefore is confusing, at best, and should be removed or somehow consider there can be many clearances to each pad.
@JeffYoung
If I should try a newer version, you’d like me to create an issue or issues on Gitlab for any of the above, or anything else, please let me know. And thank you!!
Application: KiCad
Version: (5.99.0-1730-g52ae0df7a), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Build date: May 20 2020 06:59:36
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013
The rules that involve two objects should be interchangeable (i.e. it should not matter which is “self” and which is “other”). So you could call them A and B, First and Second, etc.
@overthere, the new expression evaluator is not yet in the code. So no condition clauses will be read at present.
@Evan_Shultz, when we do have the expression evaluator, I think it will address many of your issues (or at least allow us to address them more easily).
@JeffYoung
Yes. That would address #1 for sure. Thank you. If an element (‘A’, ‘B’, etc.) can be a track or pad or whatever, then yes, #3 should be addressed too.
I don’t see how expression help #2, but perhaps I’m not grasping it.
Yes, A and B are the two elements in question. They can be pretty much any item, although at present we only run the rules on copper items and edge cuts items.
They would help 2 by allowing A.netclass.group == blah, although such a construct would also need us to have netclass groups defined somewhere.
