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 :
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
