Re: [Kicad-developers] layer based constraints
I think I do something wrong, since my responses are only seen in the "date" view, but not in the "thread" view. Maybe it has something to do with the fact that I don't see any "response depth level" greater than "response-to-response-to-response"? So, I just once try responding at a "higher" level. Sorry for being an absolute noob in mailing lists! :) As I said in the response that is not visible here, I made a patch which I'll attach to this mail. It's based on the stable_2013-03-31_BZR4008 release and it's far from finished (no saving of the constraints, no intializing, DRC doesn't care abot layer width constraints yet). But it gives you a nice look-and-feel of how this helps layouting, if you have different constraints on different layers. I kinda like it, I am very sure it will save me a LOT of time layouting, because it always switches to the right width and clearance whenever I place a via to switch the layer. Therefore I will patch new versions of kicad, when they arrive, for my personal use. After I fininished the job, of course. When finished, I would like (uhm - no, I MUST, that's GPL ;-) ) to contribute my work, although I understand that you guys don't quite like either layer based constraints at all or at least my approach to implementing them. Because I REALLY believe that it can be very helpful. But I don't wan to be importunate. So what do you suggest? I am a noob not only in mailing lists, but also in contributing to open source projects. Can/should I create a branch, send you a patch or just shut up and keep my work at my place? I seriously ask because I just don't know. One more word about how to handle different constraint types, say: Constraints on nets, layers, (area, net-pairs): I think it's very important to think extremely carefully about how to combine them. And I think "overriding" constraints are very dangerous and/or difficult to handle. I think Dick's Question about which constraint "overrides" which one, is not the right question to ask. At least as long as we don't have very complex constraint structures which must be coded and for which one has to really think a lot not to screw something up. I really think, constraints should be seen as: They MUST be satisfied! Each of them. So, for width and clearance constraints, it's always the one with the highest number of all applicable constraints. No matter what type they are. I stress this again because I really think this is VERY important. Regards Simon -Ursprüngliche Nachricht- From: Dick Hollenbeck Sent: Friday, April 26, 2013 3:22 PM To: kicad-developers@lists.launchpad.net 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 doc
Re: [Kicad-developers] layer based constraints
On Fri, Apr 26, 2013 at 08:48:52PM -0500, Dick Hollenbeck wrote: > It will definitely be a bottleneck. Maybe we should measure how bad soon, > otherwise this > is a suggestion which serves as a roadblock to progress, and the roadblock > itself it not > currently a solution. I don't trust much python speed... however some heavy caching could help, if needed. OTOH if you have ever seen the speed of the CAM350 'streams' checker:P I have to admit it's designed to be a pre-production final check but 40 minutes for a small 4 layers board (about 500 nets) are a little too much > The idea is innovative, and if it is not like watching snails race, it may > have some merit. I fear that could be unapproachable for the 'common' user. What about surveying what other cads are using and pick the more useful/less esoteric ones? For example, different clearances on different parts of the board would a) need some kind of partitioning tool and b) only of really specialistic use (AFAIK only for multideposition or hybrid boards...) Instead of booleans we could use some kind of truth table to check the needed conditions (like for syslog-ng filtering or apache httpd ACLs), that would be a lot more usable. Some thinking about use cases is needed here. The result is actually equivalent to a sum-of-product normal form, so I think we would not lose flexibility. Also this kind of 'programmable' clearance (be it done in python or in tabular form) would implement interclass clearance. Before of this I think that some better way to assign netclasses is needed (preferably from eeschema, thru the netlist, maybe). Having to crosscheck between pcbnew and labels on eeschema is way too error prone. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
On 04/26/2013 09:43 AM, Tomasz Wlostowski wrote:
> On 04/26/2013 04:08 PM, Simon Huwyler wrote:
>> 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"?
>
> Hi Simon,
>
> I agree that such constraints are very useful, I use them frequently in
> Altium, but this is only a small piece of the whole DRC machinery that
> needs to be rewritten. A makeshift patch to the current DRC code will
> only make it more difficult to fix properly in the future, for instance
> by keeping these extra rules hardcoded in PCB files (that any newer
> release will have to parse to keep compatibility).
>
> For example, what about area-bound clearance/width constraints (i.e.
> different clearance values for different parts of the PCB?). Why not
> just insert another checkbox named "Use area based constraints" next to
> yours and store a few more parameters in the .kicad_pcb file? Then
> someone else comes up with yet another specialized constraint, and we'll
> end up with bloated GUI and mess in code.
>
> What about simply letting users specify a set of boolean expressions
> that return the clearance for a pair of objects to be checked. For example:
>
> 1. both.GetLayer() in ['Top', 'Bottom']: 10 mil
> 2. not both.GetLayer() in ['Top', 'Bottom']: 14 mil
> 3. first.InArea ('My area'): 20 mil else: 10 mil
> 4. any.InComponent ('Some BGA that needs smaller clearance'): 5 mil
> 5. default: 10 mil
>
> and so on, and so forth, for any DRC check.
>
> These can be python expressions, evaluated through the scripting engine
> for each item before starting the DRC.
>
> The advantages are:
> - no need to change DRC's C++ code and/or GUI whenever somebody requests
> a fancy constraint configuration
> - rule expressions can be stored in .kicad_pcb files without risk of
> being deprecated (unless somebody changes the API of the scripting engine).
> - P&S must follow design rules as well. I would prefer get the clearance
> value for any pair of objects directly via scripting engine instead of
> parsing and analyzing all specialized constraints again in P&S code.
> - automatic trace impedance calculation via python expressions:
>
> both.IsDiffPair() && both.GetLayer() == 'Top' :
> DifferentialMicrostrip(first, second).Gap
>
> Regards,
> Tom
both is a python object that is visible to C++ that is stuffed at each distance
test point
in the DRC? At least one of the two members would need to be updated on each
compare.
It will definitely be a bottleneck. Maybe we should measure how bad soon,
otherwise this
is a suggestion which serves as a roadblock to progress, and the roadblock
itself it not
currently a solution.
The idea is innovative, and if it is not like watching snails race, it may have
some merit.
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Proposal: Move to C++11
On 04/26/2013 04:50 PM, Felix Morgner wrote: > Hi there > > I think I haven't introduced myself yet. I'm a hobbyist programmer and > mechanic by trade. I got into electronics about 2-3 years back with my first > micro controller experience using an Arduino. Since then I've been searching > for a good free open-source tool to draw schematics and pcb layouts. I > quickly found KiCad and I really do like it. Since I am using mostly Apple > Macintosh systems to do my programming and designing, I'm currently focusing > my efforts on the OS X side of things regarding KiCad (I did some work on the > KicadOSXBuilder script that was created by Miguel - Thanks again btw!). Most > of my programming in the last couple of years was focused on Objective-C, but > I'm moving back to C++ more and more. I hope to be able to contribute a good > amount of work to KiCad. > > Now on to my proposal/question. I propose to move forward and start using > modern C++11 techniques to, for example, replace the BOOST_FOREACH with the > range based for loop available in C++11. There might be other things where > C++ might be of interest in KiCad. My question regarding this proposal is, if > there are any reasons NOT to move to C++11. > > Greetings, Felix Hi Felix, I thought we tried that about 7 months ago and we ran into problems. IIRC it was that not everyone is using a new enough compiler? In any case you may want to search the commit logs for that keyword, then use the date to go search the mailing list archives. I introduced the command line option, that then forced us to switch to std::unique_ptr to avoid getting yelled at by the compiler. In the end, we scampered back to previous status quo and seem to be living happily ever since. So the answer to your question is definitely yes. But I cannot tell you specifically. You can find that yourself from the mailing list archives. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 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@lists.launchpad.net 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 (h... 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@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints On 4/26/2013 10:41 AM, Simon Huwyler wrote: hm... 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 d
[Kicad-developers] Proposal: Move to C++11
Hi there I think I haven't introduced myself yet. I'm a hobbyist programmer and mechanic by trade. I got into electronics about 2-3 years back with my first micro controller experience using an Arduino. Since then I've been searching for a good free open-source tool to draw schematics and pcb layouts. I quickly found KiCad and I really do like it. Since I am using mostly Apple Macintosh systems to do my programming and designing, I'm currently focusing my efforts on the OS X side of things regarding KiCad (I did some work on the KicadOSXBuilder script that was created by Miguel - Thanks again btw!). Most of my programming in the last couple of years was focused on Objective-C, but I'm moving back to C++ more and more. I hope to be able to contribute a good amount of work to KiCad. Now on to my proposal/question. I propose to move forward and start using modern C++11 techniques to, for example, replace the BOOST_FOREACH with the range based for loop available in C++11. There might be other things where C++ might be of interest in KiCad. My question regarding this proposal is, if there are any reasons NOT to move to C++11. Greetings, Felix ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
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 (h... 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@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints On 4/26/2013 10:41 AM, Simon Huwyler wrote: hm... 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@lists.launchpad.net 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@lists.launchpad.net 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
Re: [Kicad-developers] layer based constraints
On 4/26/2013 10:41 AM, Simon Huwyler wrote: hm... 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@lists.launchpad.net 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@lists.launchpad.net 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 y
Re: [Kicad-developers] layer based constraints
Very cool idea!
Concerning the potential mess in the pcb file, I absolutely agree.
Concerning the potential mess I partly agree. Of course, this check-box
would be in the layer stack dialog, not in the constraint dialog.
I really like your idea of an arbitrary list of constraints of any "sort".
And I like the thought that complex constraint sets could be scripted.
But I still think that for the "normal user" it has to be kept simple. I
could imagine a gui based helper for the simpler constraints.
add constraint --> dialog with - how are they called? "folder indexes" on
top of the dialog for: Layer constaint, net constraint, area constraint,...
and for more complex constraints: Just script them. :-) Or load them from a
normal text file produced for a similar project.
Hmmm... Is it realistic? I really kinda like this idea! I also like mine ;-)
but this would be even better!
-Ursprüngliche Nachricht-
From: Tomasz Wlostowski
Sent: Friday, April 26, 2013 4:43 PM
To: Simon Huwyler
Cc: Dick Hollenbeck ; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] layer based constraints
On 04/26/2013 04:08 PM, Simon Huwyler wrote:
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"?
Hi Simon,
I agree that such constraints are very useful, I use them frequently in
Altium, but this is only a small piece of the whole DRC machinery that
needs to be rewritten. A makeshift patch to the current DRC code will
only make it more difficult to fix properly in the future, for instance
by keeping these extra rules hardcoded in PCB files (that any newer
release will have to parse to keep compatibility).
For example, what about area-bound clearance/width constraints (i.e.
different clearance values for different parts of the PCB?). Why not
just insert another checkbox named "Use area based constraints" next to
yours and store a few more parameters in the .kicad_pcb file? Then
someone else comes up with yet another specialized constraint, and we'll
end up with bloated GUI and mess in code.
What about simply letting users specify a set of boolean expressions
that return the clearance for a pair of objects to be checked. For example:
1. both.GetLayer() in ['Top', 'Bottom']: 10 mil
2. not both.GetLayer() in ['Top', 'Bottom']: 14 mil
3. first.InArea ('My area'): 20 mil else: 10 mil
4. any.InComponent ('Some BGA that needs smaller clearance'): 5 mil
5. default: 10 mil
and so on, and so forth, for any DRC check.
These can be python expressions, evaluated through the scripting engine
for each item before starting the DRC.
The advantages are:
- no need to change DRC's C++ code and/or GUI whenever somebody requests
a fancy constraint configuration
- rule expressions can be stored in .kicad_pcb files without risk of
being deprecated (unless somebody changes the API of the scripting engine).
- P&S must follow design rules as well. I would prefer get the clearance
value for any pair of objects directly via scripting engine instead of
parsing and analyzing all specialized constraints again in P&S code.
- automatic trace impedance calculation via python expressions:
both.IsDiffPair() && both.GetLayer() == 'Top' :
DifferentialMicrostrip(first, second).Gap
Regards,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
On 04/26/2013 04:08 PM, Simon Huwyler wrote:
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"?
Hi Simon,
I agree that such constraints are very useful, I use them frequently in
Altium, but this is only a small piece of the whole DRC machinery that
needs to be rewritten. A makeshift patch to the current DRC code will
only make it more difficult to fix properly in the future, for instance
by keeping these extra rules hardcoded in PCB files (that any newer
release will have to parse to keep compatibility).
For example, what about area-bound clearance/width constraints (i.e.
different clearance values for different parts of the PCB?). Why not
just insert another checkbox named "Use area based constraints" next to
yours and store a few more parameters in the .kicad_pcb file? Then
someone else comes up with yet another specialized constraint, and we'll
end up with bloated GUI and mess in code.
What about simply letting users specify a set of boolean expressions
that return the clearance for a pair of objects to be checked. For example:
1. both.GetLayer() in ['Top', 'Bottom']: 10 mil
2. not both.GetLayer() in ['Top', 'Bottom']: 14 mil
3. first.InArea ('My area'): 20 mil else: 10 mil
4. any.InComponent ('Some BGA that needs smaller clearance'): 5 mil
5. default: 10 mil
and so on, and so forth, for any DRC check.
These can be python expressions, evaluated through the scripting engine
for each item before starting the DRC.
The advantages are:
- no need to change DRC's C++ code and/or GUI whenever somebody requests
a fancy constraint configuration
- rule expressions can be stored in .kicad_pcb files without risk of
being deprecated (unless somebody changes the API of the scripting engine).
- P&S must follow design rules as well. I would prefer get the clearance
value for any pair of objects directly via scripting engine instead of
parsing and analyzing all specialized constraints again in P&S code.
- automatic trace impedance calculation via python expressions:
both.IsDiffPair() && both.GetLayer() == 'Top' :
DifferentialMicrostrip(first, second).Gap
Regards,
Tom
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
hm... 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. 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@lists.launchpad.net 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@lists.launchpad.net 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 wo
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@lists.launchpad.net 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@lists.launchpad.net 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.
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@lists.launchpad.net 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 ma
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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] layer based constraints
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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
