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
