kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I've thought about this for a while and I'm going to try a different
approach.  Please bear with me, this is going to be lengthy but in the
interest of resolving the via stitching issue properly, I think it needs
to be done.  I'm going to expand on JP's idea that we first define the
problem we are trying to solve before we can arrive at a sound solution.
 It may turn out that there may be a reasonable solution that isn't
terribly difficult to implement without completely rewriting the drc
code or ignoring net connections which have undesirable side effects.

First and foremost is the definition of a via.  A via is a feature that
electrically connects two or more copper features (not just tracks) on
different board layers having the same net.  If we are in agreement with
that, then we should be able to agree that any via that has less than
two connections on different planes to the same net or that connect
copper features on different layers with different nets are design rule
errors.  Have I missed anything here?  I can't think of any valid case
where you would want unconnected (floating) or partially connected (1
connection) vias or vias that short different nets together.  If you can
think of one, please elaborate.

Once this is established, we should fix both the connection algorithm
and the drc to reflect this criteria.  How much work would this be?  I
didn't write either of these pieces of code so I'm going to have to rely
on some feedback here.  I'm not asking for a full rewrite of the drc
code even though that is a noble long term goal.  I'm asking for what it
would take to accommodate the criteria above with the existing code.

If this can be resolved with a reasonable amount of effort, the only
thing that would be left would be implementing the board editor features
to place the vias.  I'm guessing most of the proposed patches address
that issue or a reasonably close facsimile thereof.  At a minimum I
would think a via placement tool with associated hotkey and a dialog to
select the via properties from the list of netclass or global via
settings and select the net name from the netlist.  I don't believe any
board file changes would be required.  Once again, if I missed something
please elaborate.

The only drawback I can see doing it this way would be if someone
inadvertently opened the board with a stable 4 version of kicad the vias
would automatically get rip up.  Please remember, new features don't get
back ported to stable releases.

I think the crucial element is the drc and connection algrithm code.  If
this is too much effort, we could try Nox's suggestion of a user option
to enable or disable Strontium's ignore orphaned via code.  I would
prefer if that we investigate my suggestion before we fallback to this.
If anyone has any useful feedback or has any objections with this, feel
free to comment.

Cheers,

Wayne

On 10/10/2016 12:24 PM, Nox wrote:
> 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
>