← Back to team overview

kicad-developers team mailing list archive

Re: layer based constraints

 

Hi,

in case you are interested, you can find a diff attached. It's of course a very basic version, the constraints are neither saved nor initialized at startup, and only track width and track clearance are handled yet.

But imagine being in the position where you have such different layer constraints as with seeedstudio and want to make use of the finer constraints on the outer laysers - then you must admit that this little helper will make one's life much easier! To try, just open an example, set i.e. front/back width/clearance constraints to some numbers and create/extend a track, swiching from front to back and vice versa.

I like it much and I will finish this little helper to get my PCB done. And of course I will provide the code (after all, this is mandatory, as told by the GPL :-) ).

I must admit that I am happy as can be about this very first success of mine in improving open source software at least for myself! :-D Until now I really thought that the advantage of open source SW of enabling personal enhancments was just a theoretical one, because in real life, this would not be realistic for "normal" people without having kneeled into the code for months - but this seems not to be true!

But as you don't seem to like (this realization of) layer based constraints that much, I think I will just keep this diff an patch the new kicad versions as they arrive for my personal use. :-)

Best regards
Simon

-----Ursprüngliche Nachricht----- From: Simon Huwyler
Sent: Friday, April 26, 2013 5:30 PM
To: Wayne Stambaugh ; kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints

It's not quite that clear.  Which constraint has precedence?

The one that is more restrictive. I think it doesn't make sense to give one
constraint precedence over the other. They're separate.
It's like:

The voltage over the resistor must not be higher than 100 Volts because of
the power dissipation. And the voltage of the resistor must not be higher
than 1000 volts because of break-through. Both have the same weight.

Same here: The clearance must not be less than 6 mils because i want this
NET not be closer to anythin other (uuuuh... here, we could again do fancy
things with python :-) ) than this. And it must not be less than 8 mils
becauls the manufacturer of the board can not handle less clearance on this
layer. They are independent and I never-ever want a constraint to disable
any other constraint. That's the point about constraints: they ara
mandatory. If I am able to allow exceptions to constraints by other
constraints (as the mentioned BGA from Tomasz) then it gets more complicated
and must be handled in a script, as he proposed.


-----Ursprüngliche Nachricht----- From: Wayne Stambaugh
Sent: Friday, April 26, 2013 5:06 PM
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints

On 4/26/2013 10:41 AM, Simon Huwyler wrote:
hmmmmm... me again! Sorry about that, but I just had another thought I
would like to tell you:

Taking the layer constraints into the (net) constrain dialog would mean
that somehow, I have to tell for each constraint, to which layer it is
applicable.
One problem with this approach I have already mentioned: How is the
"logic" behind? What, if I am on a layer, to which no constrain is
applicable to? I think, I could tell a dozen other configuration, that
would make us all scratch our head and think: So, WHAT is no the actual
with constraint for THIS net on THAT layer?
In my approch: Simple. Net says: 6 mil. Layer says: 8 mil. Without
thinking, it's clear that it's 8 mils.

It's not quite that clear.  Which constraint has precedence?  If memory
serves (someone correct me if I'm wrong), currently all constraints are
superseded as you go down the stack.  In other words:

global -> zone -> net class -> footprint -> pad

where each item below the previous one takes precedence.

In your proposal we end up with:

global -> layer -> zone -> net class -> footprint -> pad
            |                  ^
            |                  |
            +------------------+

where the layer constraints bypass the zone and net class constraints.

Maybe a cleaner solution would be to extend the net classes to have
separate constraints for inner layers and outer layers.  The only
remaining question is would there ever be a need for a net class to have
different constraints for different inner layers.

Wayne


But there is another thing. Applicable to what? layer number? layer
name? What, if I change this? What if I (and i DID this in this very
project) decide to rename the layers, in a way that the naming increades
from top to bottom instead of from bottom to top (or vice versa, I don't
know anymore). What if I remove some layers? What happens to the entries
already done?
Of course, these are all issues that can be managed. But I as a user
then asks myself: Hmmm. What about a net constraint applicable to a
layer that doesn't exist?

See what I mean? You can explain hot it is to be understood. But i think
it's WAY more difficult than just say:

Both net and layer constraint must be satisfied. Remove a layer? So,
that layer constraint is not used anymore. And therefore, it is removed
from the dialog. Very intuitive.

-----Ursprüngliche Nachricht----- From: Simon Huwyler
Sent: Friday, April 26, 2013 4:08 PM
To: Dick Hollenbeck ; kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints

One more thing: I agree that the additional numbers may confuse a bit. So,
why not just insert a check box named: "Use layer based constraints"?

Still one more thing (I'm a bit sarcastic now, but I don't mean it bad,
don't get me wrong): Why is the layer stack in the menu "constraints"? ;-)

-----Ursprüngliche Nachricht----- From: Simon Huwyler
Sent: Friday, April 26, 2013 4:01 PM
To: Dick Hollenbeck ; kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints

Hi!

Only a quite short anwer for the moment - maybe I have more time this
evening...

a) in my opinion, this should not be tied to layers. Instead it should
be part of a "net class" in the design rules. This would allow the user
to keep separate inner/outer constraints per net class. When
creating/modifying a net class, the user will be able to specify the
applicable layers (eg. [2-4,7,12]). This approach is also cleaner, since
all constraints will be in the same dialog window.

I'm not so sure about that, but maybe I just have to think again. The thing
is that we're NOT talking about NET constraints. Let's suppose I have the
following netclasses:

Power
50Ohm_Transmission_line
default

Now, in addition to the constraints based on these nets, we must apply
constraints based on the layers. So, what should we do?


default_inner: 8 mils, applicable to layers 2 and 3
default_outer: 6 mils, applicable to layers 1 and 4

What about Power? Say, we have (unrealistically) set this to 6 mils. What
now, if we place a power track on layer 3? What is the right constraint?
I still think, it's much more obvious to just say:

We have NET constraints.
We have LAYER constraints.

We must satisfy BOTH of them
The logical consequence is: They must be defined separately.

But as I said: Maybe I just have to think again.

b) why don't you make a "blueprint" in launchpad for this? I'm no expert
in how launchpad works, but it looks like the right tool for submitting
ideas and technical details.

Neither am I! :-) but I try to do it this week-end!


*) is the benefit of using the smallest clearance and spacing on the
outer copper layers
worth the this trouble in general?  Are your boards really that busy
on these outer
layers?  Seeqstudio is forcing you down a path that you do not have to
take.  You can use
them by using the wider spacing in the inner layers, on all layers.
What are you gaining
really?  Or is it just one part with narrow pad spacing pushing you
down this path?

In fact, the idea rised upon an urge! Yes, it's definitively a HUGE issue.
Not that I have such a dense design, but I have a fine pitch device!
Nothing
special, just a 0.5mm QFP. But it won't fit into the inner constraints for
seeedstudio. So I could set the constraints to 8mils and live with the
errors. And with the fact that I don't use what I pay for.
An what is the trouble? As in C++ vs C: You don't pay for what you don't
need. Don't care about layer constrants? Leave them at 0. And, after all,
that's in the tradition of Kicad: Don't care about individual solder paste
clearance? Just leave it at 0.

*) next question is, who else needs this?

everyone that places a QFP device on a 4 layer print produced by
seeedstudio. :-)

*) the documentation would need to be updated if we were to go down
this path.  Otherwise
we might get bug reports when somebody sees a different spacing on a
different layer for
the same net.

The beauty about my approach would be, that, if you don't acively insert a
number, nothing changes.
But I agree, this would need an update of the documenation. But I could do
this, too. And - after all - most additional features need to be
documented,
aren't they? :-) And

To finish this response, I just want to stress again, that this was not
just
an idea after thinking about what may bee a cool feature, but really the
result of some frustration that my real problem could not be solved
satisfactionally by the actual version of kicad.

Greets
Simon


-----Ursprüngliche Nachricht----- From: Dick Hollenbeck
Sent: Friday, April 26, 2013 3:22 PM
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] layer based constraints

On 04/26/2013 03:02 AM, Dimitris Lampridis wrote:
On 04/25/2013 02:22 AM, Simon Huwyler wrote:
As some PCB manufacturers (i.e. seeedstudio) have different clearance-
an width constraints for outer- and inner layer, I had the idea to teach
Kicad to manage “layer based” constraints.
 >
Ok, for the moment, I chatted enough. What do you think about it?

Hi Simon,

We use Kicad at work and we would like to get involved in the
development process, not only as a means to return something to this
excellent community, but also to actively improve the tools we are using.

To this end, I've also just subscribed to this list (hi everyone!), and
I'm keeping a list of features/fixes that I would like to start
proposing for implementation. I'm responding to your idea because it was
already on our list.

Now, back to your suggestion, here's my two pennies' worth:

a) in my opinion, this should not be tied to layers. Instead it should
be part of a "net class" in the design rules. This would allow the user
to keep separate inner/outer constraints per net class. When
creating/modifying a net class, the user will be able to specify the
applicable layers (eg. [2-4,7,12]). This approach is also cleaner, since
all constraints will be in the same dialog window.

b) why don't you make a "blueprint" in launchpad for this? I'm no expert
in how launchpad works, but it looks like the right tool for submitting
ideas and technical details.

Cheers,
Dimitris


Hi Simon,

I was thinking what Dimitris is thinking, before I read his post.  Clearly
you took the
path that allowed you to get it working.  And usually that is the best
path.
But in this
case I think we can all see a certain discomfort in blurring what the layer
setup dialog
is for.

The first question I have is this:

*) is the benefit of using the smallest clearance and spacing on the outer
copper layers
worth the this trouble in general?  Are your boards really that busy on
these outer
layers?  Seeqstudio is forcing you down a path that you do not have to
take.
You can use
them by using the wider spacing in the inner layers, on all layers.  What
are you gaining
really?  Or is it just one part with narrow pad spacing pushing you down
this path?


*) next question is, who else needs this?


*) the documentation would need to be updated if we were to go down this
path.  Otherwise
we might get bug reports when somebody sees a different spacing on a
different layer for
the same net.  Of course this happens on spin 2 of the board, after you
have
forgotten
about the layer specific override and cannot figure out why that layer is
different.


As you can see, I am not taking a stand on need, only trying to see if it
exists.


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



_______________________________________________
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


_______________________________________________
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


_______________________________________________
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

_______________________________________________
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




_______________________________________________
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


_______________________________________________
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

Attachment: LayerConstraints_patch.rar
Description: Binary data


References