I have worked a bit more on the idea of the “layer based constraints”. We
have already argued quite a bit about how one should tell KiCad about
different constraints on different layers. But I think, we all more or
less
agree that there are realistic use cases where a constraint is not only
dependent on the net, but also on the layer (and maybe other things).
So, the routine getConstraint() (with or without an ‘other’ item passed
as
argument) should get another argument: LAYER_NUM aLayer, because, as soon
as
the layer, in one way or the other, influences the minimal acceptable
clearance between different nets, I have to distinguish between these
nets.
For all these connectedItems that are only on one layer (like tracks),
the
item can just check on which layer it is, and return the appropriate
value.
But there are also pads and vias. And here, it is not sufficient anymore
to
just ask “what is the miminal clearance around you”? Instead, I have to
ask:
What is the minimal clearance around you on layer two?” That’s why I
inserted the additional argument aLayer. Of course, I included it on all
connectedItems because of subtyping. A track, for example, just ignores
it
and takes its own layer as a reference.
Ok, then, I did another thing: ConnectedItems can show their clearance as
a
line around the item, which is one of the best features of KiCad, if you
ask
me. I LOVE this feature! But now, I had a problem with it. Again, if an
item
is on only one layer, it’s fine. Just show the clearance according to the
layer of the track. But what about a pad? A pad can “sit” on all layers.
So,
which clearance to show? Possible anwers:
- none
- the net-based clearance (only feasable if we ARE separating net-based
and
layer-based clearances, and not mixing them in any way)
- all clearances, in the respective color
- the clearance according to the layer that is currently active, if it is
a
copper layer, and none if it is a non-copper layer.
I, for my personal branch, decided to pick the last solution. But this
confronted me with another question: If I am on layer two, and there is a
multi-layer pad, a track on layer two and a track on layer one. What do I
expect to see?
I decided that I would like to see the clearances on layer two. Nothing
else. So, the pad shows me the clearance it has on layer two. And the
pad,
that is on layer two, shows me its clearance, and the track on layer
shows
no clearance line.
I hacked this behavior and must say that I like it. I never checkt
“always”
at “show tracks clearances”, because it was just too much information.
But
with my patch, I now think I’m going to stay at this option. It shows my
all
clearances I have to respect on the layer that is currentla active (a.e.
the
layer on which I am placing tracks at the moment). After all, I don’t
care
about a layer two’s clearance if I’m on layer one.
I will upload a branch eventually so you guys can have a look at it. Not
so
much to press my implementation of it into a release (there's no chance
for
it, either ;-), but more to let you get a feeling of it, because I really
think this is an issue. I think, a good CAE tool should take the layer
into
account when it comes to constraints. And as KiCad IS a very good tool,
it
is proven by induction, that KiCad should be able to handle this! :-)
Just
kidding....
Now, there are still other things, like, for example, constraints between
two defined nets, area based constraints... all the fancy stuff. Of
course,
we could add also these things as additional parameters... or we could
pass
an object containing all important parameters an item has to know to
calculate the clearance. Or... hmmm... just a reference to the caller
item:
- Item xy, tell me, please, how much clearance I have to keep to you. I
am
item yz.
- Item yz, on what layer are you? And what’s your net?
- Ok, Item xy, please stay 2mm away from me.
Oh, I almost forgot: There is another thing that, as I suppose, is quite
connected to this issue: Pads with defined pad-stacks. Say, I want to
insert
a pad on the outer layers, but on the inner layers, there should be no
copper (or less copper). This surely influences the clearance. Again, the
clearance strongly depends on the layer on which I am approaching the
pad.
What do you think? Is this worth a blue-print?
I really really like the idea of implementing such a thing. I am,
actually,
now starting to work productively with my patch (but only as a hobbyist)
and
up to now, I really like also the slightly changed look-and-feel as
described above.
- I can define clearance and width constraints for every layer (which is,
as
I said, very useful to me because of manufactuer’s constraints)
- I am shown all clearances (max of net-based and layer based) on the
active
layer
- when I place a track with the “standard” thickness setting, it gets me
the
actual thickness of the net on the layer I am.
- When I switch layers (a.e. place a via) the width changes according to
the
new rules (same net, but different layer, again, the max i taken).
- It, of course, also gives me the the updated clearance.
- Pads: It shows me the clearance for the actual layer (or none, of it is
not a copper layer).
- copper fills are taking taking care of the different layer constraints
around pads.
- DRC I didn’t check intensively yet, but should work.
I am very well aware that it’s a bad idea to just take this first
realization into the main branch instead of really thinking about future
features, and how to do it right. As I said, I don't intend this branch
to
be merged as-is, but more as a basepoint for some discussion.
Greets
Simon
-----Ursprüngliche Nachricht-----
From: Dick Hollenbeck
Sent: Sunday, April 28, 2013 3:12 PM
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints
On 04/27/2013 12:10 PM, Lorenzo Marcantonio wrote:
On Sat, Apr 27, 2013 at 11:11:54AM -0500, Dick Hollenbeck wrote:
But how important is that really? Will it result in a reduction in
pay?
The "common" user has been a hobbyist, and is becoming a corporate
employee as the
software gets better.
OK, even most of the corporate employees have probably 0% of
understanding a boolean expression. Unless he's a digital designer :D
woes on him in that case
So while I agree, I think the importance of this concern is minimal.
Actually zero.
If we like it, that should be good enough. We are corporate employees,
and are paying to
make this software useable for our needs. You said yourself the same
thing.
Agree on that. But if it's possible to make it usable for the
non-programmer people (without too much work) then it's better.
Otherwise I'd looking for components using grep instead of the component
browser for example (the sad thing is that often grepping is more
effective...)
Great idea, do it. It seems we are all still open to the best ideas.
In a previous message I wrote about how CAM350/gerbtool do DRC. The CAM
products are for 60% DRC beasts so they know how to do their job:D
Eagle has a simple netclass-to-netclass clearance. I haven't used any
other of the 'big ones' (Altium, Allegro, PADS or Expedition) so I don't
really know how they handle it. Many entry level products don't have
even
a netclass notion, so we already are way above them:D
Is there a way we can provide a python expression, but do most of the
work in C++?, by
implementing the functions being called in C++ behind the expression,
by
following the
python C API.
This is a slight variation on the original idea, which can be a way to
turbo charge it,
maybe to cut out a few lookups at runtime.
Obviously the python expressions can all be "pre-compiled", but I don't
think they can be
"pre-evalutated" when "both" is in play, since that is a dynamic match
maker.
Caching (memoizing, actually) strategies for the python calls would
depend on the data available to the call. Assuming the function is pure
(i.e. depending only on the passed parameters) you could cull *a lot* of
calls.
Example (in C, I don't know python enough): function returning
the clearance (one of the contended values) between two netclasses and
the current layer; with only the minimum data we'd have:
int dynamic_clearance(const char *netclass1, const char *netclass2,
const char *layer);
*iif* the implementation is pure, as from the hypothesis, there are no
external dependancies and no collateral effects so *every* call with
a tuple (triplet) would always return the same value. Put it in a map
(memoize it) and you have just resolved the clearance issues between
these two classes on that layer with just one python call. AFAIK
memoizing is a standard idiom in python, too.
More flexibility reduces optimization possibilities. Let's say we pass
the netnames too (don't ask why, maybe the user wants more granularity
than netnames, no idea)
int dynamic_clearance(const char *netclass1, const char *netclass2,
const char *netname1, const char *netname2,
const char *layer);
Here memoizing is a lot less effective... you only cache clearance
between two nets (the netclasses are actually redundant and passed as
convenience). However you would optimize the common case of buses
wandering around the board. Still a good improvement, probably.
At the other end, if the decision function has the whole segment
information at hand:
int dynamic_clearance(const char *netclass1, const char *netclass2,
const char *netname1, const char *netname2,
const char *layer, int stuff, int other_stuff...)
Then we gain *no* performance since (ideally) every segment is tested
against any other segment just once. In fact caching overhead would
probably make it slower than without.
That said, maybe a python call is just so fast that the big time is
spent computing distances maybe. Or the bottleneck is in the string
comparison. If it was LUA instead of Python I'd say to directly call the
function without any doubt (LUA strings are interned so the string
equality is pointer equality for example, and the byte code interpreter
is... well, fast).
As you said instrumented profiling is needed, at least to compare the
cost
of a python call to the rest of the stuff in the DRC routines.
Caching is an interesting idea to keep in our toolbox. I think C++ has
some
great
potential in developing some wrapper classes for making use of python
expessions fairly
painless. It is an area I hope to contribute to when I have some more
time.
Each year we host a large memorial day party here at the ranch, and often
have a pig roast
on a spit. The preparations for that can get overwhelming and start
weeks
in advance. So
this has reached full scale as of this weekend. Time is more scarce than
ever.
Dick
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
