Re: [Kicad-developers] layer based constraints
I have uploaded a branch. It’s still the version with simple constraints for layers which won’t probably be what we want. But if you feel like getting a hands-on-experience of how the however-layer-dependent constraints could “look and feel” like, feel free to try it out. Select the option to show clearances for all tracks. I really like it this way. Unfortunately I haven’t had much time to do more investigations of how the constraints should and could look like (5 months old twins, Mummy is out of house, Daddy has to look after...) But I will have a look at it asap! Best regards Simon From: Dick Hollenbeck Sent: Wednesday, May 08, 2013 2:42 PM To: Simon Huwyler Cc: KiCad Developers ; Lorenzo Marcantonio Subject: Re: [Kicad-developers] layer based constraints On May 8, 2013 7:31 AM, Dick Hollenbeck d...@softplc.com wrote: On May 8, 2013 7:24 AM, Simon Huwyler simon.huwy...@bluewin.ch wrote: Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. So, if I get you right, the whole KiCad repository is merely a huge collection of branches each one created for personal needs (as in my case the very special need to deal with _fabrication_ layer constraints), and only time will show what turns out to be a feature that should be taken into the main branch? So, my approch was not that bad, indeed! :-) Therefore, I should upload this branch, even knowing that it is useful for _me_ and probably no one else? Sorry for these newbie-ish questions. But this is really a whole new world for me. :-) I was quite reluctant doing so, because I thought I should only contribute things that are really useful to others and have a chance to eventually make it to the main branch. This approach is now common in launchpad hosted projects and at github. Your blueprint idea is worth a try. I don't know how good its UI is. A forum with topic specific threads might be more useful. Rate of improvement in launchpad is slow at this point. Shuttleworth is chasing bigger fish. No sign of the $100, 000, 000 investment at github either. They still cannot even display source lines wider than about 80 characters. But free only buys you so much. But often great ideas are lost in the stream of the mailing list. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 2:12 PM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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 ___ 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 wlEmoticon-smile[1].png___ 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
bzr branch lp:~simon-huwyler/kicad/layerConstraints From: Simon Huwyler Sent: Tuesday, May 14, 2013 11:48 AM To: Dick Hollenbeck Cc: KiCad Developers Subject: Re: [Kicad-developers] layer based constraints I have uploaded a branch. It’s still the version with simple constraints for layers which won’t probably be what we want. But if you feel like getting a hands-on-experience of how the however-layer-dependent constraints could “look and feel” like, feel free to try it out. Select the option to show clearances for all tracks. I really like it this way. Unfortunately I haven’t had much time to do more investigations of how the constraints should and could look like (5 months old twins, Mummy is out of house, Daddy has to look after...) But I will have a look at it asap! Best regards Simon From: Dick Hollenbeck Sent: Wednesday, May 08, 2013 2:42 PM To: Simon Huwyler Cc: KiCad Developers ; Lorenzo Marcantonio Subject: Re: [Kicad-developers] layer based constraints On May 8, 2013 7:31 AM, Dick Hollenbeck d...@softplc.com wrote: On May 8, 2013 7:24 AM, Simon Huwyler simon.huwy...@bluewin.ch wrote: Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. So, if I get you right, the whole KiCad repository is merely a huge collection of branches each one created for personal needs (as in my case the very special need to deal with _fabrication_ layer constraints), and only time will show what turns out to be a feature that should be taken into the main branch? So, my approch was not that bad, indeed! :-) Therefore, I should upload this branch, even knowing that it is useful for _me_ and probably no one else? Sorry for these newbie-ish questions. But this is really a whole new world for me. :-) I was quite reluctant doing so, because I thought I should only contribute things that are really useful to others and have a chance to eventually make it to the main branch. This approach is now common in launchpad hosted projects and at github. Your blueprint idea is worth a try. I don't know how good its UI is. A forum with topic specific threads might be more useful. Rate of improvement in launchpad is slow at this point. Shuttleworth is chasing bigger fish. No sign of the $100, 000, 000 investment at github either. They still cannot even display source lines wider than about 80 characters. But free only buys you so much. But often great ideas are lost in the stream of the mailing list. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 2:12 PM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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 ___ 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 wlEmoticon-smile[1
Re: [Kicad-developers] layer based constraints
After sleeping over it, I see the whole thing a little bit differently. In contrast to what I always said about how layer-based constraints should work (in terms of UI), I now think, that, while my approach is perfect for my problem to solve, it may, as you folks said, not be perfect for other users. I learned that these layer-dependent manufacturing constraints are quite unusual, and the well-known way to handle layer-based constraints, the way specctra does it, appears to be more complicated to solf my problem, but is on the other hand WAY more flexible. And it appears to be the standard. Then, a layer based constraint is often motivated by impedance matching. And from this point of view, it must be connected to the net class, of course. Now, still another thing: It’s been a while when I was working with Protel (now Altium designer), but I mean to remember that there you could enter three different widths: A minimal, a maximal and “standard”. This seems to be a good thing to me, because it is normally a bad idea to always stress the constraints to the limit, because of the yield. So, why not implement this also? And how about clearance? Standard vs minimal clearance (max doesn’t make sense). Normally KiCad guides you to keep the standard clearance, but you may reduce the clearance. This is not quite as easy as the “standard width—minimal width” feature in terms of how to present the feature to the user, but, it may still bee very cool. From the technical point of view, I was quite surprised how easy it was to implement what I implemented. Of course I know about the 80-20 roule, but I certainly have 80% of functionality implemented, therefore 20% time effort. – Very cool things are very well achievable! Maybe “layer based constraints” is not any more a good term, but I would really like to start a blueprint on this. Maybe called something like “constraint system” or so...? I just think that now that There will be the push-n-shove router, KiCad becomes even more sophisticated, and I think the constraint possibilities become too limited compared to the overall project features. uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. But I’m still not quite sure about where I, you, we stand about the motivation to do something like this. I have the impression that there is a reluctance in accepting new features at the moment because the main effort is based on getting/keeping the whole package stable and consistent. I myself woul be very eager to help implementing such a thing, but if it is just the wrong time now, I would understand that, of course. On the other hand, if you folks don’t think there should be an improvement on the constraint system at all, then I disagree but – of course – accept that, too. Even so, KiCad is great! And then, I must admit, that I have absolutely no “hands-on-experience” in working for an open-source project and I have no clue about the “work-flow”. I had the somewhat naïve impression that everyone could just contribute something and everyone was happy to take it. Of course this would lead to a complete mess. Greets Simon From: Dick Hollenbeck Sent: Wednesday, May 08, 2013 4:09 AM To: Simon Huwyler Cc: KiCad Developers Subject: Re: [Kicad-developers] layer based constraints Load source specctra_import.cpp. In the comments near the top, look for specctra.pdf. tells where. On May 7, 2013 6:20 PM, Simon Huwyler simon.huwy...@bluewin.ch wrote: A short google consultation showed me this: SPECCTRA FOR ORCAD AUTOROUTER SPECCTRA for OrCAD is well known for its comprehensive feature set. The extensive rule set can control a wide range of constraints from default board-level rules to rules by net and net class. default board-level rules sounds to me like something like this. But unfortunately I didn't find anything yet, and since it's twenty past one I'll call it a day for now. :-) Dick, could you tell me where I can find this pdf? Thanks! -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Wednesday, May 08, 2013 1:09 AM To: Dick Hollenbeck Cc: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. What PDF file? I didn't get any. But of course I should find some information about this. ___ 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 wlEmoticon-smile[1].png___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad
Re: [Kicad-developers] layer based constraints
On Wed, May 08, 2013 at 09:37:53AM +0200, Simon Huwyler wrote: Now, still another thing: It’s been a while when I was working with Protel (now Altium designer), but I mean to remember that there you could enter three different widths: A minimal, a maximal and “standard”. This seems to be a good thing to me, because it is normally a bad idea to always stress the constraints to the limit, because of the yield. For impedance matching too... however checking 'maximum' distance would be a little complex/expensive. Maybe only if explicity requested. I just think that now that There will be the push-n-shove router, KiCad becomes even more sophisticated, and I think the constraint possibilities become too limited compared to the overall project features. Layer constraint *could* be useful for some applications; the 'programmable' constraint interface could also be considered (either in table or in python call form). uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. At least netnames without polluting the sheet with label should be the minimum. Netname to netname association would be useful but not truly essential. It's more or less shifting the dialog from pcbnew to eeschema and extending the netlist, anyway. -- 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
uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. At least netnames without polluting the sheet with label should be the minimum. Netname to netname association would be useful but not truly essential. It's more or less shifting the dialog from pcbnew to eeschema and extending the netlist, anyway. What about (I'm just brain-storming now) some graphical way? For example right click on a wire, then add to net class..., remove from netclass... - something like that? -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 10:17 AM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 09:37:53AM +0200, Simon Huwyler wrote: Now, still another thing: It’s been a while when I was working with Protel (now Altium designer), but I mean to remember that there you could enter three different widths: A minimal, a maximal and “standard”. This seems to be a good thing to me, because it is normally a bad idea to always stress the constraints to the limit, because of the yield. For impedance matching too... however checking 'maximum' distance would be a little complex/expensive. Maybe only if explicity requested. I just think that now that There will be the push-n-shove router, KiCad becomes even more sophisticated, and I think the constraint possibilities become too limited compared to the overall project features. Layer constraint *could* be useful for some applications; the 'programmable' constraint interface could also be considered (either in table or in python call form). uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. At least netnames without polluting the sheet with label should be the minimum. Netname to netname association would be useful but not truly essential. It's more or less shifting the dialog from pcbnew to eeschema and extending the netlist, anyway. -- 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 ___ 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 Wed, May 08, 2013 at 12:41:37PM +0200, Simon Huwyler wrote: Does it have to be online? It would be very nice. But I would also like to see an easy graphical way to assign nets to netclasses, and to check them (highlighting). The 'graphical' way is right click/assign to netclass :D if netlist handling is not realtime at least a warning to regenerate it should be given (like when trying to do a netlist without annotation) If both are assigned to net classes, but not to the same ones, a dialog appears. The user could then check whether the new, merged net should be assigned to: - The first net's classes - The second net's classes - no classes (not very useful, I guess) - All classses involved. Please stop: one net, one class; one net many classes is *way* too much complicated. AFAIK nobody does that and sincerely I can't see a useful way to use this. Otherwise that's just a policy; these defaults (keep the assigned classes otherwise clarify/remove it) seems fine to me. -- 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 May 8, 2013 3:26 AM, Simon Huwyler simon.huwy...@bluewin.ch wrote: uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. At least netnames without polluting the sheet with label should be the minimum. Netname to netname association would be useful but not truly essential. It's more or less shifting the dialog from pcbnew to eeschema and extending the netlist, anyway. What about (I'm just brain-storming now) some graphical way? For example right click on a wire, then add to net class..., remove from netclass... - something like that? Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. Building some credibility here will take some time. But quality develooment skills are easily recognized by a quality developer. Pushing to your own branch early, before investing too much, may be the best way to avoid wasting your efforts. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 10:17 AM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 09:37:53AM +0200, Simon Huwyler wrote: Now, still another thing: It’s been a while when I was working with Protel (now Altium designer), but I mean to remember that there you could enter three different widths: A minimal, a maximal and “standard”. This seems to be a good thing to me, because it is normally a bad idea to always stress the constraints to the limit, because of the yield. For impedance matching too... however checking 'maximum' distance would be a little complex/expensive. Maybe only if explicity requested. I just think that now that There will be the push-n-shove router, KiCad becomes even more sophisticated, and I think the constraint possibilities become too limited compared to the overall project features. Layer constraint *could* be useful for some applications; the 'programmable' constraint interface could also be considered (either in table or in python call form). uh, another thing, I think this has also been mentioned before: It should be an absolute must to be able to define net classes in eeschema. I think, from the technical point of view, this should be easy. At least netnames without polluting the sheet with label should be the minimum. Netname to netname association would be useful but not truly essential. It's more or less shifting the dialog from pcbnew to eeschema and extending the netlist, anyway. -- 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 ___ 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 Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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
Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. So, if I get you right, the whole KiCad repository is merely a huge collection of branches each one created for personal needs (as in my case the very special need to deal with _fabrication_ layer constraints), and only time will show what turns out to be a feature that should be taken into the main branch? So, my approch was not that bad, indeed! :-) Therefore, I should upload this branch, even knowing that it is useful for _me_ and probably no one else? Sorry for these newbie-ish questions. But this is really a whole new world for me. :-) I was quite reluctant doing so, because I thought I should only contribute things that are really useful to others and have a chance to eventually make it to the main branch. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 2:12 PM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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 ___ 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 May 8, 2013 7:24 AM, Simon Huwyler simon.huwy...@bluewin.ch wrote: Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. So, if I get you right, the whole KiCad repository is merely a huge collection of branches each one created for personal needs (as in my case the very special need to deal with _fabrication_ layer constraints), and only time will show what turns out to be a feature that should be taken into the main branch? So, my approch was not that bad, indeed! :-) Therefore, I should upload this branch, even knowing that it is useful for _me_ and probably no one else? Sorry for these newbie-ish questions. But this is really a whole new world for me. :-) I was quite reluctant doing so, because I thought I should only contribute things that are really useful to others and have a chance to eventually make it to the main branch. This approach is now common in launchpad hosted projects and at github. Your blueprint idea is worth a try. I don't know how good its UI is. But often great ideas are lost in the stream of the mailing list. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 2:12 PM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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 ___ 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 May 8, 2013 7:31 AM, Dick Hollenbeck d...@softplc.com wrote: On May 8, 2013 7:24 AM, Simon Huwyler simon.huwy...@bluewin.ch wrote: Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. So, if I get you right, the whole KiCad repository is merely a huge collection of branches each one created for personal needs (as in my case the very special need to deal with _fabrication_ layer constraints), and only time will show what turns out to be a feature that should be taken into the main branch? So, my approch was not that bad, indeed! :-) Therefore, I should upload this branch, even knowing that it is useful for _me_ and probably no one else? Sorry for these newbie-ish questions. But this is really a whole new world for me. :-) I was quite reluctant doing so, because I thought I should only contribute things that are really useful to others and have a chance to eventually make it to the main branch. This approach is now common in launchpad hosted projects and at github. Your blueprint idea is worth a try. I don't know how good its UI is. A forum with topic specific threads might be more useful. Rate of improvement in launchpad is slow at this point. Shuttleworth is chasing bigger fish. No sign of the $100, 000, 000 investment at github either. They still cannot even display source lines wider than about 80 characters. But free only buys you so much. But often great ideas are lost in the stream of the mailing list. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 08, 2013 2:12 PM To: Kicad Developers Subject: Re: [Kicad-developers] layer based constraints On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: Alfons, in munich, worked for zucken (spelling), an eda company, for 15 years, well bfore writing freerouter. His UI includes netclass features. It is not obvious that they merely mimic the specctra spec. If not, is this his experience being injected to trump something he thought was imperfect? I can't say... SPECCTRA was a pre-existing product, and simply became the defacto interface. Maybe it's simply well engineered for the things it needs to do, but then every company will 'personalize' it depending on the requirements (so they can say our specctra is better than yours!). The same freerouter AFAIK don't implement it in full (no arcs, for example, seeing the kicad code). Or maybe the author of freerouter simply added the extra features because they were convenient (and to hell with the specctra standard). Kicad evolves based on individual need. Try and stay close to your individual use cases, else you may end up creating something few will use. Einstein: as simple as possible, but not simpler. That's why we are discussing if/how enhanced rules can be applied. -- 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 ___ 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
) 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@lists.launchpad.net 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
Re: [Kicad-developers] layer based constraints
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@lists.launchpad.net 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
Re: [Kicad-developers] layer based constraints
(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@lists.launchpad.net 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
Re: [Kicad-developers] layer based constraints
A short google consultation showed me this: SPECCTRA FOR ORCAD AUTOROUTER SPECCTRA for OrCAD is well known for its comprehensive feature set. The extensive rule set can control a wide range of constraints from default board-level rules to rules by net and net class. default board-level rules sounds to me like something like this. But unfortunately I didn't find anything yet, and since it's twenty past one I'll call it a day for now. :-) Dick, could you tell me where I can find this pdf? Thanks! -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Wednesday, May 08, 2013 1:09 AM To: Dick Hollenbeck Cc: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. What PDF file? I didn't get any. But of course I should find some information about this. ___ 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
Load source specctra_import.cpp. In the comments near the top, look for specctra.pdf. tells where. On May 7, 2013 6:20 PM, Simon Huwyler simon.huwy...@bluewin.ch wrote: A short google consultation showed me this: SPECCTRA FOR ORCAD AUTOROUTER SPECCTRA for OrCAD is well known for its comprehensive feature set. The extensive rule set can control a wide range of constraints from default board-level rules to rules by net and net class. default board-level rules sounds to me like something like this. But unfortunately I didn't find anything yet, and since it's twenty past one I'll call it a day for now. :-) Dick, could you tell me where I can find this pdf? Thanks! -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Wednesday, May 08, 2013 1:09 AM To: Dick Hollenbeck Cc: kicad-developers@lists.**launchpad.netkicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Page 17 of the specctra.pdf file I sent you a couple of weeks ago shows the class_descriptor. What PDF file? I didn't get any. But of course I should find some information about this. __**_ Mailing list: https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers Post to : kicad-developers@lists.**launchpad.netkicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-**developershttps://launchpad.net/~kicad-developers More help : https://help.launchpad.net/**ListHelphttps://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/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
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 documentation would
Re: [Kicad-developers] layer based constraints
Le 27/04/2013 08:52, Simon Huwyler a écrit : 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. Simon, Thanks to take the time to work on Kicad code. For this kind of feature, the best solution is not always the first found, or the more beautiful dialog. Therefore, response-to-response-to-response is not surprising. Which could be surprising is a lack of response-to-response-to-response! The first response was (obviously) is it worth. This is not surprising. Ideas to enhance DRC are also not surprising, and are welcome. The best decision is always taken after collecting many ideas, and sometimes differs from the first idea. Many options is DRC are not always good, so we always make compromise between the power and the easy to use features. In this case, having layers constraints is not bad. But remember your issue come from SeedStudio, and my board house do not have these constraints. The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. The answer (remember : having both power and easy to use features is not easy: you often should choose between them) is very important: In Design Rules we have already one constraint. Just a second constraint will fix your issue. Remember we have constraints for minimal values for: clearances, tracks, vias, microvias, and should have also minimal annular ring for pads and vias. Having values for each layer in a 16 layer board is a serious constraint... for users. I know you said: leave these values to 0 when not used. Yes, but I am not convinced: For the user, they are in a major dialog, For the user, the Design rule dialog have already these constraints. when these values are not to 0, which value is used ? Local masks clearance are set to 0 to use the global value. Is it the case for clearance ? Your answer was use the more restrictive value. But the rule you want to use is not same as masks clearance rules! Not so easy to explain and understand. The best decision must be taken before creating/modifying dialogs, the code and the file format. Remember also the calculation time is a major constraint in DRC. By the way I had a look to your patch, and i believe the minimal track width defined in layers silently overrides the track width set in net classes. This is not good. You can just set a DRC error. In some cases (namely for tracks having a specific impedance) you should have to use the defined width. -- Jean-Pierre CHARRAS ___ 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 Sat, Apr 27, 2013 at 10:49:52AM +0200, jp charras wrote: The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. This is one of the 'esoteric' feature I talked about in another message. Usually (i.e. in 99% of the board) I'd say you are correct. It's mostly a technological contraint for alignment during lamination. Or maybe for drilling (for example our fabricator has different clearance/annulus requirement for NPTH, since another set of tools is being used and so on: I set it in the per-pad clearance...not optimal but effective). However there are special stackup where this would be needed. Usually it's set during padstack definition but since pcbnew hasn't the padstack concept we have to define this as clearance. What we call clearance by the way is overlapping with the antipad concept (which is *very* important in multilayer boards). Some fabricators also like removal of pads in layers where there is no electrical pickup, other one need them for the plating processing... this is another feature that would be useful, by the way. So is different spoke width depending on expected current (this is too currently addressed by pad properties). Or even selectively untented vias (thermal vias). There are lot of application specific 'tricks' that with many cads are difficult or impossible do apply. One process where different layers would have different process clearance (*not* electrical clearance: electrical clearance is designed knowing potentials and stuff, process clearance is needed by technology limitations and board manufacturing yield) is with with metal cores or embedded distributed capacitance. Both of them are for somewhat specialized applications (high current and high frequency, respectively) but *could* be useful if not too difficult to implement. Your answer was use the more restrictive value. It's like the 'track width' rule: in fact there should be a minimum and a maximum width to check for a class. The minimum for fabrication purposes, the maximum for design correctness. True tale: I had some solenoid drivers with fuse protection and stuff. One section of track was reduced to 0,2mm (I wasn't probably aware that was one of *these* tracks). Guess what burns first with the output shorted :D The best decision must be taken before creating/modifying dialogs, the code and the file format. Remember also the calculation time is a major constraint in DRC. Final DRC (i.e. the one you call from the dialog) could be slow. DRC when laying track shouldn't (I suppose I could wait, like, maximum one second to accept/reject the whole thing). In some cases (namely for tracks having a specific impedance) you should have to use the defined width. Right, another use for the min/max track limits. I hate impedance controlled routing, but it seems these days people like to move megahertzes instead of amperes :D Another thing while we're wishlisting for the drc: there should be a way (in the component) to specify that same-pin pads are actually tied together in the component (without having to tie them explicitly with 'copper'); this would cover two important cases: the tactile switch which can be often used to bridge the 'common' and the board stiffener/busbar which is actually a big piece of conductive metal (i.e. an 'external' trace part). At the moment the workaround is using a fake jumper layer (not exactly elegant). This would also fix the nuisance of having to tie together irregularly shaped pads. -- 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
Hi Jean-Pierre, see my responses below. -Ursprüngliche Nachricht- From: jp charras Sent: Saturday, April 27, 2013 10:49 AM To: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Therefore, response-to-response-to-response is not surprising. Which could be surprising is a lack of response-to-response-to-response! Actually, I was just wundering why I canNOT see more than response-to-respone-to-response This is the deepest level my browser shows me. This has nothing to do with the topic, but with the way, the messages show up - at least on my browser (chrome). In this case, having layers constraints is not bad. But remember your issue come from SeedStudio, and my board house do not have these constraints. right. -But - don't get me wrong, i consider Kicad a tool that can easily compete with professional tools - but it is used by many hobbyists. An without wanting to do some advertising, seeedstudio (among with another supplyer having exactly the same constraints - actually the same fabs, I suppose) is by far the cheapest provider of prototype PCBs I know. The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. I also thought about that. Would also be good, yes. The answer (remember : having both power and easy to use features is not easy: you often should choose between them) is very important: In Design Rules we have already one constraint. Just a second constraint will fix your issue. yup. Remember we have constraints for minimal values for: clearances, tracks, vias, microvias, and should have also minimal annular ring for pads and vias. Having values for each layer in a 16 layer board is a serious constraint... for users. agree. In most cases, you just repeat numbers. Max flexibility, at a price. I know you said: leave these values to 0 when not used. Yes, but I am not convinced: For the user, they are in a major dialog, For the user, the Design rule dialog have already these constraints. when these values are not to 0, which value is used ? well, here a disagree. For me it's clear that it must be the one that is more restrictive. And a very short pop up explainer (don't know the term) could tell you this. Remember also the calculation time is a major constraint in DRC. I know. That's why I wanted to keep it simple. By the way I had a look to your patch, and i believe the minimal track width defined in layers silently overrides the track width set in net classes. Very well possible. As I said, it's just something to get the look and feel for it. Not tested, hacked somwhere between midnight and morning... :-) This is not good. You can just set a DRC error. yup. I'd say, it's even very bad! :-) In some cases (namely for tracks having a specific impedance) you should have to use the defined width. Yes. But in these cases, the constraints for these must be greater than the layer constraint. Why? Because the layer constraint is intended to represent a manufacturing limint. So, I can not place a 0.05mm track on a PCB with width constraint of 0.15mm just because it has to match the impedance. That's why I keep stressing that I stongly believe that always the most restrictive constraint should be taken. Actually, no need to say thank you for working on Kicad! I honestly did this thing for myself. And I can use it very well. It's me who must not only say thank you for providing kicad, but to enable me as user to enhance it for my (special) needs by providing it open source! I agree with you that it's not a good idea to just pack anything on the release branch without discussing about alternatives. ___ 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
Le 27/04/2013 11:40, Simon Huwyler a écrit : Hi Jean-Pierre, see my responses below. ... right. -But - don't get me wrong, i consider Kicad a tool that can easily compete with professional tools - but it is used by many hobbyists. An without wanting to do some advertising, seeedstudio (among with another supplyer having exactly the same constraints - actually the same fabs, I suppose) is by far the cheapest provider of prototype PCBs I know. The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. I also thought about that. Would also be good, yes. It could fix some of issues created by multiple constraints. Because there is no more multiple constraints. The answer (remember : having both power and easy to use features is not easy: you often should choose between them) is very important: In Design Rules we have already one constraint. Just a second constraint will fix your issue. yup. Remember we have constraints for minimal values for: clearances, tracks, vias, microvias, and should have also minimal annular ring for pads and vias. Having values for each layer in a 16 layer board is a serious constraint... for users. agree. In most cases, you just repeat numbers. Max flexibility, at a price. This is the kind of decision we should always take: Max flexibility or price. I know you said: leave these values to 0 when not used. Yes, but I am not convinced: For the user, they are in a major dialog, For the user, the Design rule dialog have already these constraints. when these values are not to 0, which value is used ? well, here a disagree. For me it's clear that it must be the one that is more restrictive. And a very short pop up explainer (don't know the term) could tell you this. Remember also the calculation time is a major constraint in DRC. I know. That's why I wanted to keep it simple. By the way I had a look to your patch, and i believe the minimal track width defined in layers silently overrides the track width set in net classes. Very well possible. As I said, it's just something to get the look and feel for it. Not tested, hacked somwhere between midnight and morning... :-) Good programmers never sleep. (I am not a good programmer) This is not good. You can just set a DRC error. yup. I'd say, it's even very bad! :-) In some cases (namely for tracks having a specific impedance) you should have to use the defined width. Yes. But in these cases, the constraints for these must be greater than the layer constraint. Why? Because the layer constraint is intended to represent a manufacturing limint. So, I can not place a 0.05mm track on a PCB with width constraint of 0.15mm just because it has to match the impedance. This is a DRC error. You have to match the impedance (otherwise the signal integrity is broken). Therefore you have to fix this issue: change PCB width constraint and board price (i.e. manufacturing limit), or the track width and epoxy thickness ... but only the designer knows what is good or can be made. Pcbnew just should set a DRC error. That's why I keep stressing that I stongly believe that always the most restrictive constraint should be taken. Actually, no need to say thank you for working on Kicad! I honestly did this thing for myself. And I can use it very well. It's me who must not only say thank you for providing kicad, but to enable me as user to enhance it for my (special) needs by providing it open source! I agree with you that it's not a good idea to just pack anything on the release branch without discussing about alternatives. Perhaps this is a good idea: you can show a demo or a proof of your idea. This is very important. With a demo, discussing about alternatives or enhancements is more productive. More work, and more benefit. -- Jean-Pierre CHARRAS ___ 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
The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. I also thought about that. Would also be good, yes. It could fix some of issues created by multiple constraints. Because there is no more multiple constraints. ok, I see that I didn't understand what you meant. Am i right that you mean that your idea is constraints for NETxxx on outer layers, NET xxx on inner layers, NETyyy on outer layer, NETyyy on inner layers... ? This I think is not a good idea. I thought about just removing all numbers for each layer an having just a set for outer and one for inner layers. When you say that it fixes the issue of multiple constrains i completely disagree. In this context, having multiple constrains is NOT an issue, but a feature. Or, put differently, it's in the nature of the physics behind it. I think, Lorenzo has also written about it. We have to distinguish between the sources of the constrains, and we MUST NOT mix them. Why do you place a net constraint? Because you want a NET to have certain constraints. Why? Because this net carries much current, has high voltage, whatsoever. Now, why do you have layer constraints? Because your manufacturer wants them. Therefore, it is a fact that we have to deal with multiple constraints. This is in most cases not an issue, because we can create a net constraint for all the rest. But actually, calling this a net constraint is wrong. It works well, but it's wrong. It's not a net constrain, but it's a physical constraint. Why does it work most of the time? Because there is only one set for all layers. But what if it's not? Then, trying to model this physical constraint by a set of net constraints (which are applicable to outer, or inner, or both layers) is not the right way to go, I think. That's why I put it in the layer stack dialog. The constraint dialog is really a net constraint dialog. And the layer stack dialog tells about the PCB itself. And therefore, the layer constraints are not so wrongly placed there, are they? Good programmers never sleep. (I am not a good programmer) :-) so, neither am I. This is a DRC error. You have to match the impedance (otherwise the signal integrity is broken). Therefore you have to fix this issue: change PCB width constraint and board price (i.e. manufacturing limit), or the track width and epoxy thickness ... but only the designer knows what is good or can be made. Pcbnew just should set a DRC error. Right. It should (and does, when I have finished it) set a DRC error if one of the following is true: 1. the width or clearance is lower than the constrain on that layer. -- The manufacturer will reject your design. 2. The width (or clearance) is lower (hmmm... or higher???) than it must be. -- your impedance will be wrong Perhaps this is a good idea: you can show a demo or a proof of your idea. This is very important. With a demo, discussing about alternatives or enhancements is more productive. More work, and more benefit. I'm a bit reluctant sending a built pcbnew.exe, because it's huge, and it's only working on Windows. So, I think, the patch is better. Actually, the one I attached should be fine for this purpose. It's not finished yet, as I said, but you can try what the idea is. I must say again, for my particular problem with different constraints on inner layers, this is the most intuitive and elegant way I could imagine. Mixing these constraints with layer constraints would seem couner-intuitive to me because it wouldn't reflect the problem to be solfed. ___ 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
Thinking about it, I think, there are, indeed situation, when it makes sense to define constraints for NETxxx on layer yyy. This would be, for example, impedance controlled tracks. They have to have a defined width which is different on each layer and only applicable to certain nets. But now, that we're talking about keeping it simple, we must ask ourselves: - How many impedance controlled lines are there? - On how many different layers do I place them? So, the most flexible way, would indeed be sort of a matrix. Each net has a set of constrains for each layer. I'm still not quite sure, if this is, what you want to do, simplified to outer and inner layer instead as for each layer. But even then, you have to define a set of constraints for each net twice. And I think, the strange cases emerge much more if you're doing it this way. What if you forget to define the high curren net constraint on inner layers? Then you're routing this net and switch to the inner layer. Which is to take? default? See what I mean? Actually, I think the really clean way would be that you HAVE TO defin net constraints. And only for the nets you want to apply ADDITIONAL constraints, you add a net constraint. But as we have the default constraint, we can prevent us from forcing the user to do it that way, which is of course a good thing. But as soon as there ARE different layer constraints, we can't handle this any more with net constraints in an elegant way. The logical step would be the matrix I mentioned above. But this is pain in the a** to configure. And in most cases it would be again copying numbers. And, I can't imagine a simple user interface for that. That's why I said to myself: Instead of a matrix, I want these two indipendent constraints. Because most of the time, (and in my particular case) this is, what I want to model. -Ursprüngliche Nachricht- From: jp charras Sent: Saturday, April 27, 2013 12:57 PM To: Simon Huwyler Cc: kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] layer based constraints Le 27/04/2013 11:40, Simon Huwyler a écrit : Hi Jean-Pierre, see my responses below. ... right. -But - don't get me wrong, i consider Kicad a tool that can easily compete with professional tools - but it is used by many hobbyists. An without wanting to do some advertising, seeedstudio (among with another supplyer having exactly the same constraints - actually the same fabs, I suppose) is by far the cheapest provider of prototype PCBs I know. The first question I am thinking is: Why a by layer constraints. Why do not have only 2 min clearance values: one for outer layers, one for inner layers. I also thought about that. Would also be good, yes. It could fix some of issues created by multiple constraints. Because there is no more multiple constraints. The answer (remember : having both power and easy to use features is not easy: you often should choose between them) is very important: In Design Rules we have already one constraint. Just a second constraint will fix your issue. yup. Remember we have constraints for minimal values for: clearances, tracks, vias, microvias, and should have also minimal annular ring for pads and vias. Having values for each layer in a 16 layer board is a serious constraint... for users. agree. In most cases, you just repeat numbers. Max flexibility, at a price. This is the kind of decision we should always take: Max flexibility or price. I know you said: leave these values to 0 when not used. Yes, but I am not convinced: For the user, they are in a major dialog, For the user, the Design rule dialog have already these constraints. when these values are not to 0, which value is used ? well, here a disagree. For me it's clear that it must be the one that is more restrictive. And a very short pop up explainer (don't know the term) could tell you this. Remember also the calculation time is a major constraint in DRC. I know. That's why I wanted to keep it simple. By the way I had a look to your patch, and i believe the minimal track width defined in layers silently overrides the track width set in net classes. Very well possible. As I said, it's just something to get the look and feel for it. Not tested, hacked somwhere between midnight and morning... :-) Good programmers never sleep. (I am not a good programmer) This is not good. You can just set a DRC error. yup. I'd say, it's even very bad! :-) In some cases (namely for tracks having a specific impedance) you should have to use the defined width. Yes. But in these cases, the constraints for these must be greater than the layer constraint. Why? Because the layer constraint is intended to represent a manufacturing limint. So, I can not place a 0.05mm track on a PCB with width constraint of 0.15mm just because it has to match the impedance. This is a DRC error. You have to match the impedance (otherwise the signal integrity is broken). Therefore you
Re: [Kicad-developers] layer based constraints
On Sat, Apr 27, 2013 at 03:09:11PM +0200, Simon Huwyler wrote: layer stack dialog tells about the PCB itself. And therefore, the layer constraints are not so wrongly placed there, are they? Ouch this is so much complicatea to explain :D Now I'm about to go algebric and defing the 'intersection of constraint'... something like: - Netclass A has to be at least 1mm wide and at least 0.2 clearance - Layer 1 needs at least 0.5 clearance == - Netclass A on layer 1 has to be at least 1mm wide and at least 0.5 clearance (it's simple interval arithmetic) - Netclass B has to be exactly 0.5mm wide and clearance of exactly 0.3mm == - Netclass B can't live on layer 1 (due to conflicting rules) (Empty intersection) It's done that way in safety relevant systems... you get all the conditions and they *all* need to be true. It works the same in fuzzy logic too :P The UI would be something like a QBE grid or a mail filter setup. In fact it could everything done with intervals: 'lesser than y' becomes 'between -inf and y', 'equal to x' becomes 'between x - epsilon and x + epsilon' for example. PLEASE NOTE that, for example, checking for 'maximum clearance' would be *very* difficult, so it's only an example! Rule resolution would be done that way: given a set of rules (DRC database or whatever) extract all the rules which apply to the current check (a single track check of course would extract the track size rules, while a track-to-track would ignore them, for example). This involves browsing the database and 'filtering' on the conditions (i.e. I'm checking a track of class B, the rules must apply to all classes or at least to class B). Compute the intersection of all the constraint from these rules. Check if everything fits. Given an 'adequate' (i.e. to be thought about:D) predicate set I think that all the conceivable (useful) constraints could be built. After that we hit the turing limit i.e. need some user written python function (as already proposed). The minimal 'functional' constraint I would use are something like: 1) Width in (range) 2) Clearance in (range) (as said before most probably has to be thinked about) 3) Pad size in (range) 4) Thermal spoke width in (range) 'Manufacturing' constraint are like (I'll list the CAM350/gerbtool ones) 5) Track-to-track distance (dist) 6) Track-to-pad distance (dist) 7) Pad-to-pad distance (dist) (I have no idea if it's useful to differentiate clearances in this way. IMHO copper-to-copper is the manufacturing limit to be checked i.e. condition 2) 8) Pad-to-drill (size) (annulus check) 9) Track width =(size) (same as 1) 10) Pad width =(size) (same as 3) 11) Plated holes to copper (dist) (*other* copper) 12) Unplated holes to copper (dist) 13) Copper to border (dist) (milling tolerance) 14) Drill to border (dist) (milling *and* drilling tolerance) 15) Border-to-border (size) (minimum cutter size, especially for card egdes) 16) Plated drill size (size) 17) Unplated drill size (size) We already do some of these, of course. There are others but not applicable for pcbnew (like 'plated drills without a pad') or advanced ones that are maybe too much CAM-specific (like copper slivers, acid traps and pin holes). These are also very heavy to check since you need to convert to a polygon a whole net (not a track!) and then analyze the subpolygons and the angle between edges. Nice but I can live without them :D Plated and unplated drills are separated because they are often done on different machines, maybe with different features (expecially embedded vias which can be laser evaporated...). In a conventional (non-HDI) flow the 'first drilling' i.e. the plated holes is sometimes more precise than the 'second drilling' (unplated) which is sometimes done by the same machine that does the edge milling or scoring. Buried and blind vias are much more complicated to handle because it depends on the exact stackup of the board (no experience with that). There are also more specific checks for solder mask/paste and silkscreen (like: you can't have paste without a mask and copper underneath) or even modification (solder mask ganging for fine pitch, but then there is a different clearance for the copper below since it has no more damming). These are really, really, really CAM issues and often you don't even know the reference values. You *could* add checks for silk thickness and clearance to the mask if you wanted (well, it would be better to enlarge the silk scraping during plot). Also, for example, minimum/maximum pad size could be applied (with different values) to the paste masks: I had to recut a mask since paste didn't detach properly, for example (it's called design for fabrication: it must be fabricable but it must be *easily* fabricable, to give better yield). Conditions would be like: A) In netclass (set of classes) (the set could be 'any class') B) Between netclass (class1) and (class2) (where there could be an 'any class' indicator to mean 'between class A
Re: [Kicad-developers] layer based constraints
On Sat, Apr 27, 2013 at 03:36:17PM +0200, Simon Huwyler wrote: - How many impedance controlled lines are there? - On how many different layers do I place them? Stop there. *If* you do impedance controlled lines then you *need* different constraint for each layer, because: a) I know, and that's what I wanted to say. This WOULD be a case. But I don't care about this one because it gets too complicated. So, the most flexible way, would indeed be sort of a matrix. Each net has a set of constrains for each layer. Actually each class would have a constraint with each other class and this for each layer. And I hope you don't want to do cross layer DRC No, that's what I said. Again. This would be the ultimate freedom - and the ultimate pain. :-) With these examples I wanted to point out why I chose for my personal patch this way. It does what is used mostly, and it does it easily. ___ 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
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. Hi Dick, I'm not sure, it might be the case if a single matching expression refers to both items. A crude solution would be to input two expressions (one for each object), and calculate their values prior to running the actual DRC. Am works this way and its DRC is maybe not the fastest in the world (~20 secs for a moderately complex 12-layer board), but certainly quite flexible. 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. PS is currently the top priority for me, I can't spend time evaluating DRC speed. Another bottleneck in the DRC is the lack of spatial indexing and numerically unstable clearance calculations. There's a lot of stuff to be improved there. The idea is innovative, and if it is not like watching snails race, it may have some merit. Thanks. 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 Sat, Apr 27, 2013 at 05:44:22PM +0200, Tomasz Wlostowski wrote: PS is currently the top priority for me, I can't spend time evaluating DRC speed. Another bottleneck in the DRC is the lack of spatial indexing and numerically unstable clearance calculations. There's a lot of stuff to be improved there. Something similar popped up with Vesa benchmarking the drawing code... often things are computed and not even assigned (because of optional parameters). Something about 4 square roots for each line to be drawn:P As for the spatial indexing I already suggested some trials with the boost rtree library. I'm not too sure of the reject ratio with the typical track packing on a modern board, especially with long diagonal tracks. Maybe some better indexing structure would be needed (I'm not an expert on these... but at least on some GIS rtrees works well only for small/pointiform features) -- 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/27/2013 12:56 AM, Lorenzo Marcantonio wrote: 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. 100% agreed. 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. 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. What about surveying what other cads are using and pick the more useful/less esoteric ones? Great idea, do it. It seems we are all still open to the best ideas. 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. Tom's idea is still on the table AFAIAC.Some benchmarking of this concept should not be that hard. We have instrumentation/timing code for that now. Tom, let's talk about this class called both. Can it be written in C/C++? (Its results are dynamic, so I don't see where all this stuff can be pre-evaluated.) 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. 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
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. -- 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/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
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
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 make
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. Now
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 would need
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).
- PS 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 PS 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
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).
- PS 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 PS 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 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 you gaining really
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 doesn't exist
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).
- PS 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 PS 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
