Hi, If you want via stitching tool, why not try my tool. I have sended suggestion on it few days ago to kicad developers mailing list. Not many codelines, so it is easy to look what it do.
Regards, Heikki 10.10.2016 19.35 "Nox" <noxfiregal...@gmail.com> kirjoitti: > Wayne, > > This sound very resonable and I am totally with you that the proposed > solutions have their drawbacks like the currently implemented one. Actually > I would love to see a perfectly working connection recognition algorithm > like Tomasz suggested (if I got him correctly) but I guess we all agree > that although this solution would be the best, it will mostlikely the > solution taking the most time. Additionally I assume nobody can garantee > that a new solution will cover every single case perfectly. > > I think you made there a very important comment regarding "power users" vs > "careful users" and I totally see your point. What do you think about > adding an option which defaults to the current behavior (apperently > floating elements are set as unassigned) and a "let me shoot my self if i > want to" option which leaves the label of floating elements unchanged > (maybe adding a warning in the DRC what floating elements exists)? What > would be your concern regarding this approach? > > > Am 10.10.2016 um 17:36 schrieb Wayne Stambaugh: > >> On 10/10/2016 1:25 AM, Strontium wrote: >> >>> On 09/10/16 23:11, Wayne Stambaugh wrote: >>> >>>> On 10/8/2016 1:20 PM, Nox wrote: >>>> >>>> There is nothing here that has not been discussed before. The reason >>>> that freely assigning nets to vias has not been implemented is that >>>> every implementation is a compromise. If we allow random net naming of >>>> vias, all manner of bad things can happen that are completely out of the >>>> control of kicad. Instead of your wtf moment being some tracks and vias >>>> with no associated net being ripped up when you import a new netlist, >>>> your wtf moment is a stack useless pcbs that you just spend money on. I >>>> >>> Wayne, respectfully this is where I believe you have missed the point. >>> If a designer assigns a net to a via, then THEY are responsible for the >>> WTF moment. IF Kicad rips up the nets the designer assigned to vias >>> then KICAD is responsible for the WTF moment. In one case the designer >>> screwed up and in the other Kicad screwed the designer over. >>> >>> Its as simple as that. >>> >>> My original patch, posted many moons ago, fixed this problem neatly. It >>> did not allow a user to assign arbitrary nets, but if you plonked a via >>> on a GND fill, it had a GND net, and that via would ALWAYS have a GND >>> net until you did something explicitly to change it. What is wrong with >>> that, HOW is that Kicads fault if the user should have plonked it on the >>> VCC plane. Its not. Kicad shouldn't go along behind you ripping up >>> your design for the hell of it. I, in fact, laid boards out, which i >>> believe would be impractical, if not impossible to lay out without this >>> patch, and i have to keep a version of that kicad around simply because >>> kicad isn’t up to the task of following my instructions without later >>> destroying my design intent. >>> >>> It is not obvious and NOT a DRC violation to have a via go from being >>> assigned to GND and suddenly being assigned to UNASSIGNED. Boards could >>> be made like that without the designer knowing they are being messed >>> with by the DRC pass. Now the result is the plane it was supposed to >>> stich is no longer stitched, AND the design intent has been destroyed by >>> Kicad. >>> >>> MY opinion, and I know it doesnt count for much, is DRC should NEVER >>> reassign an net unless it can UNAMBIGUOUSLY PROVE the nets >>> connectivity. IF it cant prove the nets connectivity it should leave >>> the damn net assignment alone. Throw a DRC Error FINE, but dont change >>> my design. And it should NOT ASSUME IT KNOWS BETTER THAN THE PERSON WHO >>> LAID IT. To be completely fair, the whole "Reassign the nets pass" of >>> Kicad should be able to be disabled, it should generate DRC violations >>> for net conflicts, but a designer should be able to tell Kicad, HEY DONT >>> CHANGE MY DESIGN JUST DO WHAT YOU ARE TOLD. >>> >>> If a user wants to manually assign a net, problem belong them, but i >>> think its worse for Kicad to insist it knows better than the designer >>> and that is precisely the situation we have now. >>> >>> Show a case where leaving the via on the net the user assigned when it >>> was placed causes a design fault VS reassigning to UNASSIGNED (and that >>> fault is kicads and not the stupidity of the designer) and i will change >>> my position, but no one has ever been able to show that except for >>> "Beware monsters" type replies. >>> >>> AND if one wanted to proceed "Cautiously" just have a global option >>> "Preserve nets on DRC" which selectively enables my proposed patch, then >>> users who dont use via stitching can "proceed cautiously" and other who >>> actually want to get a design out the door can do some work, and not >>> have to lay tons of superfluous, difficult to manage, and easily screwed >>> up stitching tracks. >>> >>> Stront >>> >>> I wish it were that simple. How many times have we been beat over the >> head about zone refilling? If you had been part of these discussions, >> you would understand why I approach changes like this cautiously. We >> have a large group of users who think kicad shouldn't let them shoot >> themselves in the foot and equally large group of power users like >> yourself and myself who are willing to accept that responsibility. It's >> balancing act that as project leader I end up being responsible for. >> >> The other reason I have been reluctant to use your patch is that almost >> the exact same behavior can be duplicated with single pad footprint >> which you can arbitrarily place on a board, specify a net, set per pad >> solder masking, per pad connection type(thermal, solid, etc.), and >> prevent from being ripped up by using the correct settings during net >> import. The only thing this solution doesn't cover is blind/buried vias >> so you get a win there. >> >> If you provide a solution for vias, that forces the user to assign a >> valid net then I would be more receptive to your solution. I'm fine if >> you default the net assignment to a copper feature that also has an >> assigned net that intersects with the via but the user should always >> have to select a valid net for a via. I will not accept a patch that >> assumes the via is attached to some copper feature that the via >> currently intersects. These types of assumptions are too dangerous. >> >> That still leaves the issue of the drc and connectivity algorithm >> behavior when the via's net is no longer valid. I'm ok with asking the >> user if they want to change to a valid net and/or ripping them up. I'm >> not ok with just leaving vias with undefined nets floating around and >> assuming they are connected. >> >> If your code meets the criteria above, then I would consider adding it. >> >> >>> _______________________________________________ >>> 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