If this feature would work neither with freerouter, nor Cern's push and shove router, then it would be useless to me.
I currently use freerouter in p&s mode exclusively, never route in kicad. Tom, if he had time might comment on the likelihood of support for something like this in his p&s work for internal pcbnew. 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 xy, tell me, please, how much clearance I have to keep to you. I am > item yz. > - Item yz, on what layer are you? And what’s your net? > - Ok, Item xy, please stay 2mm away from me. > > Oh, I almost forgot: There is another thing that, as I suppose, is quite > connected to this issue: Pads with defined pad-stacks. Say, I want to insert > a pad on the outer layers, but on the inner layers, there should be no > copper (or less copper). This surely influences the clearance. Again, the > clearance strongly depends on the layer on which I am approaching the pad. > > > What do you think? Is this worth a blue-print? > I really really like the idea of implementing such a thing. I am, actually, > now starting to work productively with my patch (but only as a hobbyist) and > up to now, I really like also the slightly changed look-and-feel as > described above. > > - I can define clearance and width constraints for every layer (which is, as > I said, very useful to me because of manufactuer’s constraints) > - I am shown all clearances (max of net-based and layer based) on the active > layer > - when I place a track with the “standard” thickness setting, it gets me the > actual thickness of the net on the layer I am. > - When I switch layers (a.e. place a via) the width changes according to the > new rules (same net, but different layer, again, the max i taken). > - It, of course, also gives me the the updated clearance. > - Pads: It shows me the clearance for the actual layer (or none, of it is > not a copper layer). > - copper fills are taking taking care of the different layer constraints > around pads. > - DRC I didn’t check intensively yet, but should work. > > I am very well aware that it’s a bad idea to just take this first > realization into the main branch instead of really thinking about future > features, and how to do it right. As I said, I don't intend this branch to > be merged as-is, but more as a basepoint for some discussion. > > > Greets > Simon > > > -----Ursprüngliche Nachricht----- > From: Dick Hollenbeck > Sent: Sunday, April 28, 2013 3:12 PM > To: [email protected] > Subject: Re: [Kicad-developers] layer based constraints > > On 04/27/2013 12:10 PM, Lorenzo Marcantonio wrote: >> On Sat, Apr 27, 2013 at 11:11:54AM -0500, Dick Hollenbeck wrote: >>> But how important is that really? Will it result in a reduction in pay? >>> >>> The "common" user has been a hobbyist, and is becoming a corporate >>> employee as the >>> software gets better. >> >> OK, even most of the corporate employees have probably 0% of >> understanding a boolean expression. Unless he's a digital designer :D >> woes on him in that case >> >>> So while I agree, I think the importance of this concern is minimal. >>> Actually zero. >>> If we like it, that should be good enough. We are corporate employees, >>> and are paying to >>> make this software useable for our needs. You said yourself the same >>> thing. >> >> Agree on that. But if it's possible to make it usable for the >> non-programmer people (without too much work) then it's better. >> Otherwise I'd looking for components using grep instead of the component >> browser for example (the sad thing is that often grepping is more >> effective...) >> >>> Great idea, do it. It seems we are all still open to the best ideas. >> >> In a previous message I wrote about how CAM350/gerbtool do DRC. The CAM >> products are for 60% DRC beasts so they know how to do their job:D >> >> Eagle has a simple netclass-to-netclass clearance. I haven't used any >> other of the 'big ones' (Altium, Allegro, PADS or Expedition) so I don't >> really know how they handle it. Many entry level products don't have even >> a netclass notion, so we already are way above them:D >> >>> Is there a way we can provide a python expression, but do most of the >>> work in C++?, by >>> implementing the functions being called in C++ behind the expression, by >>> following the >>> python C API. >>> >>> This is a slight variation on the original idea, which can be a way to >>> turbo charge it, >>> maybe to cut out a few lookups at runtime. >>> >>> Obviously the python expressions can all be "pre-compiled", but I don't >>> think they can be >>> "pre-evalutated" when "both" is in play, since that is a dynamic match >>> maker. >> >> Caching (memoizing, actually) strategies for the python calls would >> depend on the data available to the call. Assuming the function is pure >> (i.e. depending only on the passed parameters) you could cull *a lot* of >> calls. >> >> Example (in C, I don't know python enough): function returning >> the clearance (one of the contended values) between two netclasses and >> the current layer; with only the minimum data we'd have: >> >> int dynamic_clearance(const char *netclass1, const char *netclass2, >> const char *layer); >> >> *iif* the implementation is pure, as from the hypothesis, there are no >> external dependancies and no collateral effects so *every* call with >> a tuple (triplet) would always return the same value. Put it in a map >> (memoize it) and you have just resolved the clearance issues between >> these two classes on that layer with just one python call. AFAIK >> memoizing is a standard idiom in python, too. >> >> More flexibility reduces optimization possibilities. Let's say we pass >> the netnames too (don't ask why, maybe the user wants more granularity >> than netnames, no idea) >> >> int dynamic_clearance(const char *netclass1, const char *netclass2, >> const char *netname1, const char *netname2, >> const char *layer); >> >> Here memoizing is a lot less effective... you only cache clearance >> between two nets (the netclasses are actually redundant and passed as >> convenience). However you would optimize the common case of buses >> wandering around the board. Still a good improvement, probably. >> >> At the other end, if the decision function has the whole segment >> information at hand: >> >> int dynamic_clearance(const char *netclass1, const char *netclass2, >> const char *netname1, const char *netname2, >> const char *layer, int stuff, int other_stuff...) >> >> Then we gain *no* performance since (ideally) every segment is tested >> against any other segment just once. In fact caching overhead would >> probably make it slower than without. >> >> That said, maybe a python call is just so fast that the big time is >> spent computing distances maybe. Or the bottleneck is in the string >> comparison. If it was LUA instead of Python I'd say to directly call the >> function without any doubt (LUA strings are interned so the string >> equality is pointer equality for example, and the byte code interpreter >> is... well, fast). >> >> As you said instrumented profiling is needed, at least to compare the cost >> of a python call to the rest of the stuff in the DRC routines. > > > Caching is an interesting idea to keep in our toolbox. I think C++ has some > great > potential in developing some wrapper classes for making use of python > expessions fairly > painless. It is an area I hope to contribute to when I have some more time. > > Each year we host a large memorial day party here at the ranch, and often > have a pig roast > on a spit. The preparations for that can get overwhelming and start weeks > in advance. So > this has reached full scale as of this weekend. Time is more scarce than > ever. > > Dick > > > >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
