Hi Wayne,
If I can add my thoughts, I think Steven has a fair point that tracking
zones in the DRC is non trivial, so a 'real' solution in that direction
is not around the corner, and will never be perfect either.
The proposed change has as side effect that unconnected tracks without a
zone connection also will keep their net, until another net is forced
upon them. This in my opinion is good, as it makes it easier to
reconnect erroneously disconnected tracks. So even when tracking zones
is included in DRC this behaviour is still useful.
I even think the proposed behaviour should be extended to net conflicts:
when a track is connected to multiple nets, the track should keep its
original net, so the DRC error will point to the location with the
problem, and not to some random location in the middle of a track.
It might be useful to list the unconnected tracks in the DRC besides the
unconnected pads, but that's only slightly related.
Cheers, Piers
2015-12-16 15:19 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx
<mailto:stambaughw@xxxxxxxxx>>:
Steve,
You have written a well thought out argument for fixing the DRC. If we
fix the DRC via checking code, your patch would be unnecessary. This is
why I am reluctant to commit it. If I commit your patch, when we
finally do get around to fixing the DRC, someone will have to remember
to remove it because it will no longer serve any purpose. The root
cause of the problem is the DRC. The DRC via checking should include
checking for an electrical connection between zones (and/or footprint
pads for heat sinking purposes) having the same net name as the via not
just trace segments which is the current DRC behavior. This would have
the added advantage of not having to draw traces in a zone (which is
silly) in order to add stitching vias. The problem is that fixing the
DRC is not a simple patch which is why it hasn't been done yet. I would
fix it myself but I am up to my eyeballs fixing Eeschema and trying to
be project leader. I hope you understand why I am reluctant to commit
your patch. I understand why you are pushing your patch. Any developer
who has been around long enough is guilty of quick hacks to solve their
immediate problem. Myself included. As project leader, I have to look
at the big picture.
Cheers,
Wayne
On 12/15/2015 8:49 PM, Strontium wrote:
> Hi Wayne, Everyone,
>
> This is the process now. If you have a fill zone, and you start
to lay
> a track within it, KiCad will assign that track/via to the net of the
> zone of the layer you are on. AND, as a board Designer, that's
exactly
> what you would expect. But then, following this design process, you
> press the DRC button.
>
> All of a sudden the Track/Via you just laid in the fill zone, and
which
> KiCad gave you a Net for, loses its net assignment, and becomes
> "unconnected". Now the fill area flows around it, avoiding it by the
> distance of the fill clearance.
>
> Its a case of Kicad Giving with one hand (the net from the fill) and
> then taking away with the other (net reassignment). All my patch
does,
> is align these so that once the net has been given by KiCad, it wont
> needlessly be taken away. It might be reassigned because of a pad
> connection, but it wont otherwise be "lost".
>
> This "misalignment" between the DRC Net reassignment and the laying
> code, causes multiple problems, on real boards:
>
> 1. If you do this, and it doesn't cause a DRC. You may not
notice it,
> because a "unconnected" track/via is not a DRC error or warning.
So the
> design intent of your board is thwarted, you may have fill planes now
> disconnected at certain points and not enough vias connecting them,
> disconnected islands of fill, etc. This board goes to
production, and
> is actually flawed. All because the designer ran "DRC" check before
> sending it AND there is nothing obvious to highlight the change KiCad
> made to the board, to the designer. The only way to find them is a
> detailed visual inspection, after every DRC Check.
>
> 2. To work around point 1, you need need to criss cross your
board with
> interconnecting tracks from pads with that net to the vias, so
they keep
> their assignment. This causes a problem that if you now edit,
you have
> all of these tracks, which you are only using to keep nets
assigned to
> your vias, making it very difficult to edit/relay, etc. In many
cases
> the nearest pad may be on the other side of the board, requiring
you to
> manually lay a track to it.
>
> OR Place a single pad component which simulates a VIA, but then
you cant
> use microvias, and you need to now manage the "extra" components.
>
> 3. Changing vias/tracks to "unassigned" may introduce "DRC" errors on
> the board that weren't there before the DRC pass. So, in effect,
KiCad
> is actually generating these DRC errors with the DRC check Pass, they
> didn’t exist BEFORE the DRC check, but do after. Which, as a board
> designer, is surprising and off-putting.
>
> Basically, and at its core, this patch makes the net reassignment
code
> compatible with the code that lets you place a track/via on a
fill plane
> and pick up its net. Without it, its like KiCad telling you what you
> are doing while editing is OK. But then changing its mind later.
>
> And while my patch allows me to much more easily, manually, lay
GND vias
> for filling, etc, its utility is not limited to "Via Curtains" or
"Via
> Fills". For example, you may simply want to put a few extra vias
> between two VCC planes to share the current load. This patch
makes that
> easy and consistent.
>
> I can certainly understand the desire not to implement "quick fixes"
> that increase "cruftiness", I wouldn't want that either. And
while this
> patch is small, I don't think this patch increases cruftiness but
> actually reduces cruftiness and makes the board design DRC
process less
> surprising to a board designer and more consistent with the way the
> layout tools work.
>
> Steven
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
<mailto: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
<mailto: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
