kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 10.10.2016 15:49, Strontium wrote:
> On 10/10/16 19:59, Tomasz Wlostowski wrote:
>> Hi all,
>>
>> There's been another long thread on stitching vias/net propagation. Let
>> me add my 3 cents.
>>
>> The whole subject is more complex, as Wayne and JP already mentioned
>> many times.
> I disagree, I think the issue is portrayed to be far more difficult than
> the reality.
> 
> The problem is a designer can lay a Via using standard Kicad tools, and
> then Kicad will change that Via from the net it was assigned to, to
> Unassigned.
> 
> Thats the problem.

Steven,

If you read my e-mail more carefully, you would have noticed that I'm
not writing about rewriting the DRC but the connectivity calculation
algorithm. Maybe you should study pcbnew's code in more detail?

All the drawbacks and modifications I mentioned do not concern the DRC.
>From the users's perspective, the new algo will never un-assign any nets
unless they're completely removed from the netlist.

I tried your patch. It indeed does make vias/tracks retain their nets,
but also breaks things. If you stitch several zones which altogether
have no connection to any pad, your patch will cause Kicad to treat them
as connected and pass the DRC. This may result with broken PCBs.

And please stop shouting and using F-words.

Tom

> 
> There is a solution, just make sure any Via (or track stub) that is
> Unassigned after a DRC pass is reverted back to the Net it had BEFORE
> the DRC pass.  It works, is simple, and does not require any changes to
> the way Kicad works in the face of the user.
> 
> There may be 100's of reasons why DRC is not great at the moment, and it
> should be re-written, etc, etc. But that just kicks this BUG down the
> road to a never never future, and meanwhile, designers using Kicad,
> maybe for the first time have a very jarring WTF moment when they lay a
> via, and suddenly at some seemingly random point, and without warning,
> it goes from being a GND Via, to being "Unassigned" and Oh, don't forget
> nothing highlights this to them, except a visual inspection.
> 
>> The root of the problem is the legacy's connectivity calculation/check
>> algorithm (class CONNECTIONS), which:
>> - propagates track/via net codes from the pads they're connected to,
>> - participates in finding isolated copper islands in zones,
>> - performs a connectivity check.
>>
>> It has several drawbacks, though:
>> - Doesn't handle zones properly when checking board's connectivity. This
>> is the reason why allowing the user to select a net for a via/track is
>> *dangerous*. See the attached drawing - the top two zones are assigned
>> the net GND, same as the via that stitches them together. They are not
>> connected to any pad, though, but the board passes the DRC without any
>> error.
> That's a different problem to the existing one.  The VIA has a GND Net,
> KiCad shouldn't (in my lonely opinion) change that to Unassigned, just
> because its not capable of dealing with it automatically.
>> - Doesn't handle overlapping zones. The rightmost zone has the net GND,
>> but it's not filled at all!
> Again a different problem.  The problem is not anything about Kicads DRC
> not handling fills.  Even if it did, it would not be able to reassign
> the vias through some magic, because overlapping fill planes could be
> "ANY" or "None" of the intended net for the stitching Via.  Its why I
> say, once a via is placed, if KiCad can not UNAMBIGUOUSLY determine its
> connectivity it should leave the net assigned to it alone.
> 
> Changing it to "Unassigned" only makes the problem WORSE and doesn't in
> any way make it better.
>> - It's difficult to extend. We'd like to have arcs/other shapes on
>> copper layers with proper connectivity check sooner or later!
> Again, different problem, the maintainability of the DRC code is not the
> issue at hand.
>> - It's slow. Net propagation on Chris's motherboard takes ~6 seconds.
> Again, different problem, the speed of the DRC code is not the issue at
> hand.
>>
>> Therefore, I've decided to rewrite the algorithm. My assumptions were:
>>
> Tom, rewriting the DRC code is probably a worthy goal, and I would be
> the last one to defend the existing code base,  but, unless someone can
> resolve the issue of backtracking a isolated Via to its intended Net
> based on connectivity ALONE, then the ONLY solution is not to change it
> to unassigned in the first place.
> 
> Which is EXACTLY what the patch I proposed oh so long ago achieves. You
> will need to do the same thing, otherwise you will have the same
> problem, you will rip up all the net assignments, like the existing DRC
> code, You will rebuild all the unambiguous connectivity, and then you
> will be left with a bunch of entities (lets say they are vias) and you
> will not be able to UNAMBIGUOUSLY decide what net they SHOULD be
> assigned to based on board connectivity alone, and you will end up with
> "Unassigned Vias".
> 
> So while rewriting the DRC code is probably a fantastic idea, what's
> actually preventing the application of the patch I proposed, strictly on
> its technical merits, and not on the basis that one day we might have
> different DRC code which somehow (How, no one can actually say) handles it.
> 
> More importantly, has anyone actually applied the patch I proposed to
> KiCad and given it a try, before declaring the problem as unsolvable, or
> much more complex than it really is.  Because I was never given a single
> instance of a technical problem that it introduces and I never came
> across any after extensive use.
> 
> Steven