Hi Torsten,
Regarding the side effects, the patch actually eliminates a side effect,
and introduces no others. As it stands, if a via/track is changed to
unassigned, it has an impact on fill zones and then it IS possible for
those zones to not fill properly and you can end up with disconnected
islands or thin traces, as they try and avoid the newly "unassigned"
vias. There is no warning/error for this, and it doesn't necessarily
cause a DRC violation. The board will change to something the designer
didn't draw, and they have no way of knowing it, other than a visual
inspection of every fill zone.
It will continue to reassign any nets that it can, that doesn't change,
and is essential. All it does is recover the nets that would change to
unassigned after the reassignment pass, back to what they were before
the reassignment pass started.
If a designer wanted to find these stubs, all they need to do is hide
the fill zones and they become easy enough to see.
Basically, with this patch, if you drew it, that's how it stays. If you
put a GND stub track in the middle of a GND fill plane, it will have no
effect on the fill zone, the fill will just cover it.
Its because this patch allows the board to remain "as drawn" that it
becomes easier to Manually fill vias and Manually stitch vias (both
through hole and micro). Without it, you either need to use pads as
vias, and do without microvias and have to place many redundant
components in the process, or you need to lay redundant tracks to every
single via to make them retain the net.
As for my python scripts, they are quick and dirty hacks, at best, to
solve the problems I had. They are essentially just assistance to
manually placing the vias. I don't for a second promote them as a
working solution to via filling/stitching. And I would be keen to work
with others who have an interest in this for a good solution to that
problem.
Steven
On 16/12/15 20:23, "Torsten Hüter" wrote:
Hi Steven,
my question are the side-effects of this patch, do you have checked
all possible cases?
For instance if I'm retaining the nets, what happens if I've forgotten
to erase tracks or vias in my design, would that create copper islands?
How can I discriminate between the intentional and nonintentional
placement of free vias?
--
I've seen that you have startet your own python script for stitching.
Please have a look at my code, I'd really like that we don't have too
many implementations of the same feature (Ben has also announced
another version). I'm using single pad components for the vias, but
should be relative easy to adapt.
http://bazaar.launchpad.net/~torstenhtr/kicad/kicad_via_stitching/files/head:/pcbnew/scripting/tools/viastitching/
--
I like the idea of a special via class. I could imagine that the
pcbnew/class_pad.h could be extended or a new class is derived from
that. The reason is, that DRC and zone calculations work already well
for it and a free via is for manufacturing the same as having a
through hole pad. Just a start/stop layer needs to be added for
burried/blind vias.
Thanks,
Torsten
*Gesendet:* Mittwoch, 16. Dezember 2015 um 02:49 Uhr
*Von:* Strontium <strnty...@gmail.com>
*An:* kicad-developers@lists.launchpad.net
*Betreff:* Re: [Kicad-developers] PATCH: To facilitate easier Via
Curtain/Filling
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
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp