kicad-developers team mailing list archive

[Heikki Pulkkinen <hei6mail@xxxxxxxxx>]

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" <noxfiregalaxy@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>