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
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
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
I have worked a bit more on the idea of the “layer based constraints”. We have already argued quite a bit about how one should tell KiCad about different constraints on different layers. But I think, we all more or less agree that there are realistic use cases where a constraint is not only dependent on the net, but also on the layer (and maybe other things). So, the routine getConstraint() (with or without an ‘other’ item passed as argument) should get another argument: LAYER_NUM aLayer, because, as soon as the layer, in one way or the other, influences the minimal acceptable clearance between different nets, I have to distinguish between these nets. For all these connectedItems that are only on one layer (like tracks), the item can just check on which layer it is, and return the appropriate value. But there are also pads and vias. And here, it is not sufficient anymore to just ask “what is the miminal clearance around you”? Instead, I have to ask: What is the minimal clearance around you on layer two?” That’s why I inserted the additional argument aLayer. Of course, I included it on all connectedItems because of subtyping. A track, for example, just ignores it and takes its own layer as a reference. Ok, then, I did another thing: ConnectedItems can show their clearance as a line around the item, which is one of the best features of KiCad, if you ask me. I LOVE this feature! But now, I had a problem with it. Again, if an item is on only one layer, it’s fine. Just show the clearance according to the layer of the track. But what about a pad? A pad can “sit” on all layers. So, which clearance to show? Possible anwers: - none - the net-based clearance (only feasable if we ARE separating net-based and layer-based clearances, and not mixing them in any way) - all clearances, in the respective color - the clearance according to the layer that is currently active, if it is a copper layer, and none if it is a non-copper layer. I, for my personal branch, decided to pick the last solution. But this confronted me with another question: If I am on layer two, and there is a multi-layer pad, a track on layer two and a track on layer one. What do I expect to see? I decided that I would like to see the clearances on layer two. Nothing else. So, the pad shows me the clearance it has on layer two. And the pad, that is on layer two, shows me its clearance, and the track on layer shows no clearance line. I hacked this behavior and must say that I like it. I never checkt “always” at “show tracks clearances”, because it was just too much information. But with my patch, I now think I’m going to stay at this option. It shows my all clearances I have to respect on the layer that is currentla active (a.e. the layer on which I am placing tracks at the moment). After all, I don’t care about a layer two’s clearance if I’m on layer one. I will upload a branch eventually so you guys can have a look at it. Not so much to press my implementation of it into a release (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)
Re: [Kicad-developers] layer based constraints
If this feature would work neither with freerouter, nor Cern's push and shove router, then it would be useless to me. fair enough. Of course it has to be consistent with the whole package! I currently use freerouter in ps mode exclusively, never route in kicad. what? Actually, I've always seen freerouter just as an autorouter (and I don't like autorouters). I never had the idea to manually route with it. Will try this eventually. I think I have seen that freerouter doesn't know layer constraints, but you can tell net classes to be valid on certain layers. I personally still think, my way is the better one. :-) But that's not the point. Because also in this way, as I said, Kicad's constraint handler should be aware of the different layers implement what freerouter does. Tom, if he had time might comment on the likelihood of support for something like this in his ps work for internal pcbnew. Looking forward to that. But acually I don't think there will be a problem. I think, Tom will just ask about clearances and do some (very complex) stuff to avoid violations. How these clearances are calculated, I's suppose, is not of interest to Tom's PS router. Or am I wrong? On 05/07/2013 11:30 AM, Simon Huwyler wrote: I have worked a bit more on the idea of the “layer based constraints”. We have already argued quite a bit about how one should tell KiCad about different constraints on different layers. But I think, we all more or less agree that there are realistic use cases where a constraint is not only dependent on the net, but also on the layer (and maybe other things). So, the routine getConstraint() (with or without an ‘other’ item passed as argument) should get another argument: LAYER_NUM aLayer, because, as soon as the layer, in one way or the other, influences the minimal acceptable clearance between different nets, I have to distinguish between these nets. For all these connectedItems that are only on one layer (like tracks), the item can just check on which layer it is, and return the appropriate value. But there are also pads and vias. And here, it is not sufficient anymore to just ask “what is the miminal clearance around you”? Instead, I have to ask: What is the minimal clearance around you on layer two?” That’s why I inserted the additional argument aLayer. Of course, I included it on all connectedItems because of subtyping. A track, for example, just ignores it and takes its own layer as a reference. Ok, then, I did another thing: ConnectedItems can show their clearance as a line around the item, which is one of the best features of KiCad, if you ask me. I LOVE this feature! But now, I had a problem with it. Again, if an item is on only one layer, it’s fine. Just show the clearance according to the layer of the track. But what about a pad? A pad can “sit” on all layers. So, which clearance to show? Possible anwers: - none - the net-based clearance (only feasable if we ARE separating net-based and layer-based clearances, and not mixing them in any way) - all clearances, in the respective color - the clearance according to the layer that is currently active, if it is a copper layer, and none if it is a non-copper layer. I, for my personal branch, decided to pick the last solution. But this confronted me with another question: If I am on layer two, and there is a multi-layer pad, a track on layer two and a track on layer one. What do I expect to see? I decided that I would like to see the clearances on layer two. Nothing else. So, the pad shows me the clearance it has on layer two. And the pad, that is on layer two, shows me its clearance, and the track on layer shows no clearance line. I hacked this behavior and must say that I like it. I never checkt “always” at “show tracks clearances”, because it was just too much information. But with my patch, I now think I’m going to stay at this option. It shows my all clearances I have to respect on the layer that is currentla active (a.e. the layer on which I am placing tracks at the moment). After all, I don’t care about a layer two’s clearance if I’m on layer one. I will upload a branch eventually so you guys can have a look at it. Not so much to press my implementation of it into a release (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
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
[Kicad-developers] Select layer pair
Hi all, I’ve got another spontanous idea I would like to ask about your oppinion before implementing it. There is the button to select a layer pair, which is a good thing. But I find that it is always a bit tedious to select a layer pair this way when routing. It’s just not as fluent as all the other steps in the workflow of layouting. So, my proposal is an easier way to change the layer pair (if not existant already – I haven’t noticed). I would suggest, for example, to have another indicator at the layer managment toolbar. Maybe another blue triangle like the one that indicates the active layer? Maybe one that is just outlined? And right-clicking on where you have to left-click to select the active layer selects the “alternative” layer. What do you think?___ 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] Select layer pair
I must admit that I hardly use the hotkeys for direct layer selection. I use the VIA button a lot. Of course you should keep layer switching to a minimum But you always have to start at an outer layer. Now, normally, where you want to go, depends on what you route (in 4 layer PCB): Signal: Go to Bottom, if needed. GND: Go to GND, Power: Go to power. I like keeping my hands where they are. Left index finger on the VIA button, right hand on the mouse. I don't like searching for the layer hotkeys. For two layers, everything is great. You're on the wrong layer? Hit the VIA button and go on. Just switched layer and find out you did something wrong and want to start all over again? Cancel, hit VIA button to get back to TOP, start over again. This is very fast. So fast, that I don't care about the layer toolbar. Now there's four layers. I found that I often switch the layer pairs, because I want to work as described above. I still don't often manually change the layer in the manager because I want to keep this feature of just hitting the VIA header and getting to the right layer. But it is tedious. I found myself being reluctant in doing many such pair changes because it's not done with a click. No big deal, I know, but it's all soo easy, and this dialog just contrasts to it. And it's not very intuive, as well, I think. A bit more concrete, what I suggest: If you have only two layers, nothing changes. If you have four layers, and the active layer is a copper layer, there is a very fine, small, discrete little triangle showing the alternative layer. If you're on a non-copper layer, there's only the one active layer triangle. If you select another active copper layer, the alternative layer stays. If you select the alternative layer as active layer (a.e. left-click on the small triangle) the active and alternative switch vice-versa. If you right-click on a copper layer, the alternative layer changes. If you right click on a non-copper layer, nothing happens. If you rigth-click on the active layer, maybe this also switches active --- alternative or does nothing. I know, this sounds a bit complicated, but think about it twice. I really think, this is intuitive and fast. The select layer pair dialog is neither intuitive nor fast, I think. And it doesn't make it more complicated. Two layer print: Nothing changes. Four layer print: I would bet some money that the main reaction would be: What's this second triangle? .. try a bit and then That's cool! :-) Don't you think? About the redesign of the toolbar: I haven't heard of (I'm a freshman here). I'll have a look at it. But I think, this would be a small thing and very useful. -Ursprünliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 01, 2013 1:07 PM To: Kicad Developers Subject: Re: [Kicad-developers] Select layer pair On Wed, May 01, 2013 at 12:59:39PM +0200, Simon Huwyler wrote: I would suggest, for example, to have another indicator at the layer managment toolbar. Maybe another blue triangle like the one that indicates the active layer? Maybe one that is just outlined? And right-clicking on where you have to left-click to select the active layer selects the “alternative” layer. I find that the 'best' layer selectors are the hot keys. However the layer pair is most useful with the Via key. I think that another indicator in the layer bar would be confusing unless really clear. Probably it would be better an hotkey to pop up the pair selector:P However it mostly depends on your tracking style (and how your layers are organized). I often try to keep layer transitions to a minimum (for obvious reasons) and try to keep the same kind of signal on the same layer (this mostly apply for more than 4 layers, of course). A 'different click' to choose the secondary layer could be handy but I personally don't feel is missing. It could be added to the layer bar reworking proposed a while ago (if somebody actually want to do it) -- 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] Select layer pair
I forgot: Of course, if you hit the VIA button, there is also the visible switch between active and alternative layer. You said that this is too complicated. I say: It's much easier and clearer then the actual status quo with the switch layer pairs button chanigng colors. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Wednesday, May 01, 2013 1:07 PM To: Kicad Developers Subject: Re: [Kicad-developers] Select layer pair On Wed, May 01, 2013 at 12:59:39PM +0200, Simon Huwyler wrote: I would suggest, for example, to have another indicator at the layer managment toolbar. Maybe another blue triangle like the one that indicates the active layer? Maybe one that is just outlined? And right-clicking on where you have to left-click to select the active layer selects the “alternative” layer. I find that the 'best' layer selectors are the hot keys. However the layer pair is most useful with the Via key. I think that another indicator in the layer bar would be confusing unless really clear. Probably it would be better an hotkey to pop up the pair selector:P However it mostly depends on your tracking style (and how your layers are organized). I often try to keep layer transitions to a minimum (for obvious reasons) and try to keep the same kind of signal on the same layer (this mostly apply for more than 4 layers, of course). A 'different click' to choose the secondary layer could be handy but I personally don't feel is missing. It could be added to the layer bar reworking proposed a while ago (if somebody actually want to do it) -- 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] Highlithing components with a certain value
Hi Piotr (and others) please find the patch attached, as requested. I've redesigned the find dialog a bit and removed the find next marker in the DRC dialog again, as I found it's not necessery, as on the same dialog, there is the list of markers available. Have fun Simon -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Sunday, April 28, 2013 11:57 AM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I have only now noticed that naming the checkbox mark all components is not so good because there is a button called find marker, and here, marker means something completely different (DRC marker) But I think, the find dialog is not a good place for this. Yes, I want to find a marker. But, as far I can see, this button only finds the next marker, and the search field is ignored. So, it's not a ctrl-f function at all. Ok, here's what I suggest: - Move this function to the DCR dialog. Honestly, this is where you would suppose the button that shows you the next DRC marker. And it's near the remove all markers then. - add a button to the find dialog saying remove all marks - maybe find a new word for mark for this purpose we are discussing about here that is not so near the DRC marker. highligtht? I still think, just highlighting is not enough... This way, everything is where you would expect it. -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 11:46 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value Ok, I was experimenting a little bit. Please see the attached picture. I searched for all components valued with 470 and afterwards supp40. As the marks are not (yet) removed before a new search, you can see both results. The highlighting alone is only visible in high contrast mode. Maybe I did something wrong. But nevertheless, I like the circles. They are very well visible also for small components and show well, where the component is (in the center of the circle. I just decided to set the radius to the arithmetic mean of the x- and y size of the bounding box. Of course, the shape as well as the size can still be optimized. BTW: due to these circles, I named the checkbox mark all matches instead of highlight all matches. What do you think? And then: How do we get rid of the marks again? A button named unmark all? Where? On the search dialog? I have no clue at the moment... -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 6:44 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I don't know. That's why I wanted to experimen. I don't know if you cann see a 0603 footprint on a 100mmx100mm board, if it's highlighted. Maybe yes, then it's fine. But I just looked at a highlighted net. It's perfect for showing a net, but I think, if it was only a tiny 0603 footprint, I would hardly see it. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 6:40 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 06:30:47PM +0200, Simon Huwyler wrote: board. Maybe something completely differen would be better? A circle around the component? ... what do you think? We already have highlighting code *and* the extended palette to support it. Why invent something else? -- 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 ___ 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 find_and_mark_items.patch Description: Binary data ___ 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] Highlithing components with a certain value
I have only now noticed that naming the checkbox mark all components is not so good because there is a button called find marker, and here, marker means something completely different (DRC marker) But I think, the find dialog is not a good place for this. Yes, I want to find a marker. But, as far I can see, this button only finds the next marker, and the search field is ignored. So, it's not a ctrl-f function at all. Ok, here's what I suggest: - Move this function to the DCR dialog. Honestly, this is where you would suppose the button that shows you the next DRC marker. And it's near the remove all markers then. - add a button to the find dialog saying remove all marks - maybe find a new word for mark for this purpose we are discussing about here that is not so near the DRC marker. highligtht? I still think, just highlighting is not enough... This way, everything is where you would expect it. -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 11:46 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value Ok, I was experimenting a little bit. Please see the attached picture. I searched for all components valued with 470 and afterwards supp40. As the marks are not (yet) removed before a new search, you can see both results. The highlighting alone is only visible in high contrast mode. Maybe I did something wrong. But nevertheless, I like the circles. They are very well visible also for small components and show well, where the component is (in the center of the circle. I just decided to set the radius to the arithmetic mean of the x- and y size of the bounding box. Of course, the shape as well as the size can still be optimized. BTW: due to these circles, I named the checkbox mark all matches instead of highlight all matches. What do you think? And then: How do we get rid of the marks again? A button named unmark all? Where? On the search dialog? I have no clue at the moment... -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 6:44 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I don't know. That's why I wanted to experimen. I don't know if you cann see a 0603 footprint on a 100mmx100mm board, if it's highlighted. Maybe yes, then it's fine. But I just looked at a highlighted net. It's perfect for showing a net, but I think, if it was only a tiny 0603 footprint, I would hardly see it. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 6:40 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 06:30:47PM +0200, Simon Huwyler wrote: board. Maybe something completely differen would be better? A circle around the component? ... what do you think? We already have highlighting code *and* the extended palette to support it. Why invent something else? -- 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 ___ 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
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
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
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
[Kicad-developers] Highlithing components with a certain value
Hi folks, while still being in the discussion about the layer based constraints, I would like to propose some other small feature. I will create that for sure, because I will need it eventually, but I’m not sure if it makes sense to give it back to the project, and if, how to implement it so that it “fits” into the project. (even less than the layer based constraints ) First: The motivation: The other day, I did a manual “pick and place” on a PCB, after putting the solder paste via a stencil. To do it more efficiently, I placed the components type by type. Means: I pickt the bag containing the 34 10k-resistors, looked, where they are, placed them on the board, and took the next bag out of the box. Kicad helped me finding the places for the components. But it turned out not to be so easy. I searched for R12 an saw a screen with R12 in the center – but I had no clue where it was. Then are there these banks of 20 times a 10k resistor. In one row. So, I don’t need to search for each and every one. But somewhere, there was another 10k resistor. So how to find it? Search as long as you found the one that is not in this bank you already knew. To finally come to the point: What I missed was a feature that marked all 10k resistors at a time. Very simple, actually. “pleas highlight all components with the value “10k”. Of course, if there are 0603 types of 10k resistors and 1206 types of 10k resistors, both types would show up. But normally I think this is no big deal. These I just have to distinguish from each other – after all, they’re different in size. So, a short thing explained complicated. Really nothing more than “highlight all components with value xxx (where xxx could, preferably include wildcards) What do you think? Does it make sense? As I said, I urgently need it, so I will implement it.. But is it worth an additional menu entry in the release branch?wlEmoticon-winkingsmile[1].pngwlEmoticon-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] Highlithing components with a certain value
Hi Lorenzo, Hi Andreas, I like your ideas! I will somewhen this weekend look into the code (I am completely new to developing for kicad), especially concerning the multiple highlighting. The 0603 were on tapes, but the tapes were in bags. :-) BTW: Andreas, where are you from? I'm from zug. BR Simon -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 5:11 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 04:03:16PM +0200, Simon Huwyler wrote: So, a short thing explained complicated. Really nothing more than “highlight all components with value xxx (where xxx could, preferably include wildcards) Could be useful and should not be intrusive. I see nothing bad in that. What do you think? Does it make sense? As I said, I urgently need it, so I will implement it.. But is it worth an additional menu entry in the release branch? IIRC someone already asked for it. You could extend the 'search' dialog for that (something like a button 'Highlight All'). But I don't know if pcbnew handles multiple component highlighting at the moment (I fear for a g_currentComponent variable or such...) Wildcarding is easy to do, since wx has all the needed functions. Look in the eeschema search routines. PS: resistor *bag*? I hope you're talking about THT resistors, a bag of EIA chips would be awful to handle:D -- 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 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] Highlithing components with a certain value
I will try to get some spare time tonight and experiment a bit with this highlighting thing. After all, we're not talking about a net spreadin accross the board, but about components spotted around the board. Maybe something completely differen would be better? A circle around the component? ... what do you think? -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 5:50 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 05:33:12PM +0200, Tomasz Wlostowski wrote: @Lorenzo: You will probably need adding a per-item HIGHLIGTHED flag (no globals, please). I never *meant* to suggest a global. I only feared there was one in there... In fact, looking closely, there is *no* component level highlighting in pcbnew; it only has net highlighting (in... highlight.cpp, obviously :D) BOARD::DrawHighLight would be a good site to look for how to do the 'highlight' effect (it's simply a flag in the colour type... but it's tricky to pass it correctly to the compositing object draw functions). However storing the parts to be highlighted will require either a) some container in the board or b) a flag in the MODULE object). Don't ask me now what is better... a flag would have no lifecycle issues but a container would be more elegant. Some pondering required on this. -- 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] Highlithing components with a certain value
I don't know. That's why I wanted to experimen. I don't know if you cann see a 0603 footprint on a 100mmx100mm board, if it's highlighted. Maybe yes, then it's fine. But I just looked at a highlighted net. It's perfect for showing a net, but I think, if it was only a tiny 0603 footprint, I would hardly see it. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 6:40 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 06:30:47PM +0200, Simon Huwyler wrote: board. Maybe something completely differen would be better? A circle around the component? ... what do you think? We already have highlighting code *and* the extended palette to support it. Why invent something else? -- 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] Highlithing components with a certain value
Ok, I was experimenting a little bit. Please see the attached picture. I searched for all components valued with 470 and afterwards supp40. As the marks are not (yet) removed before a new search, you can see both results. The highlighting alone is only visible in high contrast mode. Maybe I did something wrong. But nevertheless, I like the circles. They are very well visible also for small components and show well, where the component is (in the center of the circle. I just decided to set the radius to the arithmetic mean of the x- and y size of the bounding box. Of course, the shape as well as the size can still be optimized. BTW: due to these circles, I named the checkbox mark all matches instead of highlight all matches. What do you think? And then: How do we get rid of the marks again? A button named unmark all? Where? On the search dialog? I have no clue at the moment... -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 6:44 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I don't know. That's why I wanted to experimen. I don't know if you cann see a 0603 footprint on a 100mmx100mm board, if it's highlighted. Maybe yes, then it's fine. But I just looked at a highlighted net. It's perfect for showing a net, but I think, if it was only a tiny 0603 footprint, I would hardly see it. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 6:40 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 06:30:47PM +0200, Simon Huwyler wrote: board. Maybe something completely differen would be better? A circle around the component? ... what do you think? We already have highlighting code *and* the extended palette to support it. Why invent something else? -- 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 attachment: searchandmark.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
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
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
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
