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 ; [email protected] 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: [email protected] 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 ; [email protected] 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 ; [email protected] 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 thingis 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: [email protected] 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, DimitrisHi 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 thiscase I think we can all see a certain discomfort in blurring what the layersetup 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developersMore help : https://help.launchpad.net/ListHelp
LayerConstraints_patch.rar
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
