DRC ignores accidently deleted parts

[Stephen]

Most people run DRC prior to manufacture. I was alarmed to find a missing footprint in the finished board.

I ran the DRC again - it passed...

I think I must have accidently deleted a footprint. Because upon re-importing the netlist, the footprint appeared.

If the footprint exists in PcbNew, the DRC checks it against the netlist. Thus, once I re-imported the netlist (no changes to the netlist since the baord was manufactured, just a re-import), the offending footprint tripped a DRC fail. This is correct.

However, if I (accidently) delete a footprint, the DRC passes.

So it seems the DRC corectly checks footprint pads for connectivity, but ignores the total number of net nodes, and merrily passes a board which is completely missing entire footprints - despite the netlist import.

Application: pcbnew
Version: 4.0.4-stable release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW
Boost version: 1.59.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[Chris Gibson (chris-w-gibson)]

It also ignores duplicate and additional parts.

[Nick Østergaard (nickoe)]

Can you reproduce this issue in the nightlies?

[Jeff Young (jeyjey)]

Reproduces easily for me.

Seems like a pretty big flaw -- or is this something we don't check for a reason?

[Wayne Stambaugh (stambaughw)]

Exactly how are we to determine if the footprint was intentionally
deleted or accidentally deleted?

Also, the high priority status should only be used when kicad causes
data loss not the user. I would mark this as opinion or wishlist at
best. I do not want to add self inflicted accidental warnings to the
point where it's easy to miss real design errors.

On 1/22/2018 4:04 PM, Jeff Young wrote:
> Reproduces easily for me.
>
> Seems like a pretty big flaw -- or is this something we don't check for
> a reason?
>
> ** Changed in: kicad
> Status: New => Confirmed
>
> ** Changed in: kicad
> Importance: Undecided => High
>

[Nick Østergaard (nickoe)]

This does not sound like a bug, but rather a wish to make the DRC able to check if the netlist and the board are not in sync.

[Jeff Young (jeyjey)]

I think the “accidental” term in the bug report is a red herring. Shouldn’t DRC report mismatches between the board and the netlist, no matter how they came about?

We check connections against the netlist, right? Why presume that some of the netlist info is important (what connects to what), but other info is not (what things are present)?

> On 22 Jan 2018, at 21:41, Nick Østergaard <email address hidden> wrote:
>
> This does not sound like a bug, but rather a wish to make the DRC able
> to check if the netlist and the board are not in sync.
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1685516
>
> Title:
> DRC ignores accidently deleted parts
>
> Status in KiCad:
> Confirmed
>
> Bug description:
> Most people run DRC prior to manufacture. I was alarmed to find a
> missing footprint in the finished board.
>
> I ran the DRC again - it passed...
>
> I think I must have accidently deleted a footprint. Because upon re-
> importing the netlist, the footprint appeared.
>
> If the footprint exists in PcbNew, the DRC checks it against the
> netlist. Thus, once I re-imported the netlist (no changes to the
> netlist since the baord was manufactured, just a re-import), the
> offending footprint tripped a DRC fail. This is correct.
>
> However, if I (accidently) delete a footprint, the DRC passes.
>
> So it seems the DRC corectly checks footprint pads for connectivity,
> but ignores the total number of net nodes, and merrily passes a board
> which is completely missing entire footprints - despite the netlist
> import.
>
> Application: pcbnew
> Version: 4.0.4-stable release build
> wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW
> Boost version: 1.59.0
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> USE_FP_LIB_TABLE=HARD_CODED_ON
> BUILD_GITHUB_PLUGIN=ON
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1685516/+subscriptions

[Nick Østergaard (nickoe)]

I am not sure about the internals here, but there are two things in place here. The kicad_pcb file and the netlist file. I don't think the DRC currently reads the netlist, but I may be wrong here.

[Jeff Young (jeyjey)]

DRC is a bit of a hybrid. The main function is to test if the board meets fabrication and electrical tolerances. But it also has the List Unconnected feature, which wanders more into Netlist land.

And then we have various checks (like Test Footprints) in the Read Netlist dialog, which can provide the rest of the info, even if they aren't normally used that way.

So I think we have all the functionality, it's just not all presented in a coherent fashion.

We could add a "Strict Netlist" mode to DRC, which added in the rest of the checks, or perhaps a third button "Check Netlist".

Or we could move the "List Unconnected" feature *out* of DRC, and have a Schematic Checker or something which did the Unconnected stuff and the other Netlist stuff.

[Wayne Stambaugh (stambaughw)]

I've never used an EDA tool that does this but I haven't used them all.
I suppose we could be the first as long as I can disable it. I would
reject any patch that didn't make this warning optional.

On 01/22/2018 05:30 PM, Jeff Young wrote:
> I think the “accidental” term in the bug report is a red herring.
> Shouldn’t DRC report mismatches between the board and the netlist, no
> matter how they came about?
>
> We check connections against the netlist, right? Why presume that some
> of the netlist info is important (what connects to what), but other info
> is not (what things are present)?
>
>
>> On 22 Jan 2018, at 21:41, Nick Østergaard <email address hidden> wrote:
>>
>> This does not sound like a bug, but rather a wish to make the DRC able
>> to check if the netlist and the board are not in sync.
>>
>> --
>> You received this bug notification because you are a member of KiCad Bug
>> Squad, which is subscribed to KiCad.
>> https://bugs.launchpad.net/bugs/1685516
>>
>> Title:
>> DRC ignores accidently deleted parts
>>
>> Status in KiCad:
>> Confirmed
>>
>> Bug description:
>> Most people run DRC prior to manufacture. I was alarmed to find a
>> missing footprint in the finished board.
>>
>> I ran the DRC again - it passed...
>>
>> I think I must have accidently deleted a footprint. Because upon re-
>> importing the netlist, the footprint appeared.
>>
>> If the footprint exists in PcbNew, the DRC checks it against the
>> netlist. Thus, once I re-imported the netlist (no changes to the
>> netlist since the baord was manufactured, just a re-import), the
>> offending footprint tripped a DRC fail. This is correct.
>>
>> However, if I (accidently) delete a footprint, the DRC passes.
>>
>> So it seems the DRC corectly checks footprint pads for connectivity,
>> but ignores the total number of net nodes, and merrily passes a board
>> which is completely missing entire footprints - despite the netlist
>> import.
>>
>> Application: pcbnew
>> Version: 4.0.4-stable release build
>> wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
>> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW
>> Boost version: 1.59.0
>> USE_WX_GRAPHICS_CONTEXT=OFF
>> USE_WX_OVERLAY=OFF
>> KICAD_SCRIPTING=ON
>> KICAD_SCRIPTING_MODULES=ON
>> KICAD_SCRIPTING_WXPYTHON=ON
>> USE_FP_LIB_TABLE=HARD_CODED_ON
>> BUILD_GITHUB_PLUGIN=ON
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/kicad/+bug/1685516/+subscriptions
>

[jean-pierre charras (jp-charras)]

There is already this option:
Netlist->Test Footprints

This test needs to reread the netlist, and lists missing / duplicate and extra footprints.

Missing footprints is not the only one useful test.

[Maciej Suminski (orsonmmz)]

I guess the hardest step here is getting a netlist before one starts board verification. It is easy if you had imported a netlist during the layout session, as it might be stashed somewhere, but otherwise you need to bother the user to give you one. The exception is when you run KiCad in the project mode, as then you can request it directly from eeschema.

[Jeff Young (jeyjey)]

Test Footprints looks for the netlist with the board name in the board's directory (ie: were it would be if you used a project), and if it doesn’t find it there simply reports an error. Seems reasonable.

> On 23 Jan 2018, at 08:09, Maciej Suminski <email address hidden> wrote:
>
> I guess the hardest step here is getting a netlist before one starts
> board verification. It is easy if you had imported a netlist during the
> layout session, as it might be stashed somewhere, but otherwise you need
> to bother the user to give you one. The exception is when you run KiCad
> in the project mode, as then you can request it directly from eeschema.
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1685516
>
> Title:
> DRC ignores accidently deleted parts
>
> Status in KiCad:
> Confirmed
>
> Bug description:
> Most people run DRC prior to manufacture. I was alarmed to find a
> missing footprint in the finished board.
>
> I ran the DRC again - it passed...
>
> I think I must have accidently deleted a footprint. Because upon re-
> importing the netlist, the footprint appeared.
>
> If the footprint exists in PcbNew, the DRC checks it against the
> netlist. Thus, once I re-imported the netlist (no changes to the
> netlist since the baord was manufactured, just a re-import), the
> offending footprint tripped a DRC fail. This is correct.
>
> However, if I (accidently) delete a footprint, the DRC passes.
>
> So it seems the DRC corectly checks footprint pads for connectivity,
> but ignores the total number of net nodes, and merrily passes a board
> which is completely missing entire footprints - despite the netlist
> import.
>
> Application: pcbnew
> Version: 4.0.4-stable release build
> wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.2.0,wx containers,compatible with 2.8)
> Platform: Windows 7 (build 7601, Service Pack 1), 32 bit, Little endian, wxMSW
> Boost version: 1.59.0
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> USE_FP_LIB_TABLE=HARD_CODED_ON
> BUILD_GITHUB_PLUGIN=ON
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1685516/+subscriptions

[Jeff Young (jeyjey)]

I might look into this for 6.0, but I'm lowering the priority for now as it doesn't look like something that would fit into 5.0.

[Wayne Stambaugh (stambaughw)]

@Jeff, thanks for thinking long term. If we are going to head down this
path, we really need to rethink the DRC design. I have a few ideas
about this that I can share with you after the v5 stable release.

On 1/23/2018 6:41 AM, Jeff Young wrote:
> I might look into this for 6.0, but I'm lowering the priority for now as
> it doesn't look like something that would fit into 5.0.
>

[Jeff Young (jeyjey)]

See also https://bugs.launchpad.net/kicad/+bug/1522474 .

[Rene Poeschl (poeschlr)]

I think this but is related to my wishlist for adding a check for pcb is up to date with schematic: https://bugs.launchpad.net/kicad/+bug/1809293

[KiCad Janitor (kicad-janitor)]

Fixed in revision a1c162e59fa8f4c206bcaf22bece58404e0614db
https://git.launchpad.net/kicad/patch/?id=a1c162e59fa8f4c206bcaf22bece58404e0614db