kicad-developers team mailing list archive

[Seth Hillbrand <seth.hillbrand@xxxxxxxxx>]

​Examples always work better than words.  :)

Here is an example board that incorrectly lists unconnected tracks in
previous DRC but is correctly listed as connected using the proposed
patch.  This was created by user eelik on the forums while they were trying
to copy/paste a specific track layout.​

-S

Am Di., 29. Mai 2018 um 14:59 Uhr schrieb Seth Hillbrand <
seth.hillbrand@xxxxxxxxx>:

> Hi Jeff-
>
> By DRC, I meant the DRC problems/markers.  The unconnected count, like the
> status bar count, is based on the connectivity search that this patch
> affects.
>
> As you note, the unconnected count has been potentially different between
> the status bar and the DRC dialog.  This was primarily an issue in the v4
> connectivity algorithm that Tom fixed last year.  There are still a couple
> of corner cases that are corrected by DRC fully clearing and re-building
> the connectivity net and some that are not.
>
> The proposed patch modifies how we do the coarse check but not how we do
> the fine-grain check.  In other words, this does not change how we
> determine that items are definitely connected.  It does change whether we
> check that a specific pair of items are definitely connected.
>
> The coarse check is changed from an x-axis proximity of the anchors to a
> rectangular bounding box collision between the full items.  One side-effect
> of the patch is to make the unconnected count more accurate by checking for
> connections between tracks and other items (tracks/vias/pads) where the
> anchors are are separated than the search proximity but the track crosses
> the item's anchor.
>
> -S
>
> Am Di., 29. Mai 2018 um 13:36 Uhr schrieb Jeff Young <jeff@xxxxxxxxx>:
>
>> Since you say it doesn’t impact DRC I assume you mean the status bar
>> unconnected count rather than the DRC unconnected count.
>>
>> FWIW, we recently renamed the status bar on “unrouted” because it’s
>> already known to be less accurate than the DRC unconnected count (even
>> before any of Seth’s changes).
>>
>> On 29 May 2018, at 17:59, Seth Hillbrand <seth.hillbrand@xxxxxxxxx>
>> wrote:
>>
>> Am Di., 29. Mai 2018 um 08:55 Uhr schrieb Wayne Stambaugh <
>> stambaughw@xxxxxxxxx>:
>>
>>> On 5/28/2018 11:21 AM, Tomasz Wlostowski wrote:
>>> > On 25/05/18 18:53, Seth Hillbrand wrote:
>>> >> Hi Tom-
>>> >>
>>> >> For a particularly large board I'm working on (32 layers, 124k
>>> tracks),
>>> >> current master takes 2.4s per connectivity update (clicks, moving
>>> >> footprints, enable layers, etc).  With the patch, connectivity search
>>> is
>>> >> 10ms per click.
>>> >>
>>> >> I did a merge with your tom-background-connectivity branch but I
>>> needed
>>> >> to rebase it to master before doing that.  The conflicts were with
>>> >> inserting the aWorker-CheckInterrupt() conditional in the itemList
>>> search.
>>> >>
>>> > Hi Seth,
>>> >
>>> > I don't plan to use the background connectivity branch before 6.0 (as
>>> > it's incompatible with the legacy canvas). Your R-Tree patch though
>>> > looks very nice. I vote for merging it if Wayne's OK.
>>>
>>> What's our risk exposure here?  I didn't get a chance to look at the
>>> patch over the weekend.  If the risk is low, then I'm OK with merging it
>>> but we need to have high confidence.  Otherwise, we should push it off
>>> to the first v5 point release so we can get some additional testing.
>>>
>>
>> ​The risk surface for this patch is in the unconnected count.  This
>> doesn't impact DRC or file generation.  Unconnected count risk is primarily
>> in the negative (we list it as unconnected but it is really connected) as
>> this doesn't change the item<->anchor HitTest routine.  That said, the
>> expected change in unconnected count is zero.
>>
>> I've gone through my library of designs and a few from GitHub and don't
>> find issues but I would appreciate if someone had a chance to run this and
>> look for any discrepancies in their boards.
>>
>> -Seth
>>
>>
>>> >
>>> > Tom
>>> >
>>> >> -S
>>> >>
>>> >> Am Fr., 25. Mai 2018 um 08:35 Uhr schrieb Tomasz Wlostowski
>>> >> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>>:
>>> >>
>>> >>     On 25/05/18 05:16, Seth Hillbrand wrote:
>>> >>     > Here's an updated patch for working with large, complex boards
>>> in v5.
>>> >>     >
>>> >>     Hi Seth,
>>> >>
>>> >>     Thanks for the patch.
>>> >>
>>> >>     How much faster is it compared to the current master branch?
>>> >>
>>> >>     > Tom, I took your advice and put a light layer over an RTree for
>>> the
>>> >>     > connectivity search.  Since this gets us bounding box
>>> collisions,
>>> >>     we can
>>> >>     > do commutative hits by using both items in the collision,
>>> eliminating
>>> >>     > the need to iterate over the full list.
>>> >>
>>> >>     Great!
>>> >>     >
>>> >>     > I also did a test merge with your dev tree and had only a
>>> couple minor
>>> >>     > conflicts, so I think our approaches will compliment well.
>>> >>
>>> >>     Did you try to merge it with tom-background-connectivity branch?
>>> >>
>>> >>     Tom
>>> >>
>>> >
>>>
>> _______________________________________________
>> 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
>>
>>
>>

Attachment: connectivity_problems.kicad_pcb
Description: application/kicad-pcb