kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

...yes. All of this.

On Oct 10, 2016 01:25, "Strontium" <strntydog@xxxxxxxxx> 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
>
>
>
> _______________________________________________
> 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
>