netlist import choice to fetch Lib Value

[PCB Wiz]

Testing in V5 rc, but common in all releases.

Background: more flows are using netlist driven designs, and below are various design efforts around this.
This means users need control over what appears in the PCB, via netlist.
Right now, this works quite well, but In testing I also observe that NET import with no-value-line, (edited net list) into a blank sheet works, BUT does not apply the LIB value, instead it blanks value.

I would instead expect similar behaviour to other CAD tools which is
a) Value defined in NET ? - Easy, that is applied to part. Includes defined as "" for blank

b) Value not present in NET ? This should use LIB defined value (NOT force blank)

Because PcbNew already tolerates a missing value line, this should be easy to fix.
Suggested remedy is instead of blanking value by default, to instead apply the Lib-value as default.
Outcome: A NET missing-value line, leaves lib-value in place, but any present value line, will replace the value string.

Use cases: where designs have a library order code design, that includes the value.
Example -
Digikey part number order code RMCF0805FG1K00-ND
That's RES 1K OHM 1% 1/8W 0805

Appendix:

Useful No-net/minimal tutorial NET link:
http://home.mircad.nl/md/KiCad_without_Eeschema_or_CvPcb.html

SKiDL scripts
https://forum.kicad.info/t/skidl-a-python-based-schematic-design-language/3743

No-SCH
https://forum.kicad.info/t/pcbnew-without-eeschema-again/3306

[Jeff Young (jeyjey)]

@Devs, any other opinions on this? (It's a simple one-liner to change.)

[Jeff Young (jeyjey)]

diff --git a/pcbnew/board_netlist_updater.cpp b/pcbnew/board_netlist_updater.cpp
index 0066e2771..3c78753d5 100644
--- a/pcbnew/board_netlist_updater.cpp
+++ b/pcbnew/board_netlist_updater.cpp
@@ -277,7 +277,8 @@ bool BOARD_NETLIST_UPDATER::updateComponentParameters( MODULE* aPcbComponent, CO
     }

     // Test for value field change.
- if( aPcbComponent->GetValue() != aNewComponent->GetValue() )
+ if( !aNewComponent->GetValue().IsEmpty()
+ && aPcbComponent->GetValue() != aNewComponent->GetValue() )
     {
         msg.Printf( _( "Change symbol %s value from %s to %s.\n" ),
                     GetChars( aPcbComponent->GetReference() ),

[jean-pierre charras (jp-charras)]

@Jeff,
Here is my opinion:

Changing anything in netlist handling *now* (unless fixing a serious bug), now, just before the V 5.0 is not reasonable (both in Eeschema and Pcbnew).

And, to be honest, I do not understand the issue to fix
(and especially I do not understand the meaning of "LIB defined value" in Pcbnew).

And what is the meaning of "NET ?"
Is it the netlist file?
Or something else?

[Jeff Young (jeyjey)]

@JP,

Currently when reading a netlist we create new modules from the footprint libraries based on the LIBIDs in the netlist, and then overwrite all their fields with the info found in the netlist. The change would be to not overwrite the value if it is empty in the netlist.

I share your concerns regarding timing. The one caveat is that it would only change processing for externally-generated netlists (as we always write a non-empty value).

Cheers,
Jeff.

> On 19 Jun 2018, at 11:47, jean-pierre charras <email address hidden> wrote:
>
> @Jeff,
> Here is my opinion:
>
> Changing anything in netlist handling *now* (unless fixing a serious
> bug), now, just before the V 5.0 is not reasonable (both in Eeschema and
> Pcbnew).
>
> And, to be honest, I do not understand the issue to fix
> (and especially I do not understand the meaning of "LIB defined value" in Pcbnew).
>
> And what is the meaning of "NET ?"
> Is it the netlist file?
> Or something else?
>
> --
> You received this bug notification because you are a member of KiCad Bug
> Squad, which is subscribed to KiCad.
> https://bugs.launchpad.net/bugs/1777362
>
> Title:
> netlist import choice to fetch Lib Value
>
> Status in KiCad:
> New
>
> Bug description:
> Testing in V5 rc, but common in all releases.
>
> Background: more flows are using netlist driven designs, and below are various design efforts around this.
> This means users need control over what appears in the PCB, via netlist.
> Right now, this works quite well, but In testing I also observe that NET import with no-value-line, (edited net list) into a blank sheet works, BUT does not apply the LIB value, instead it blanks value.
>
> I would instead expect similar behaviour to other CAD tools which is
> a) Value defined in NET ? - Easy, that is applied to part. Includes defined as "" for blank
>
> b) Value not present in NET ? This should use LIB defined value (NOT
> force blank)
>
> Because PcbNew already tolerates a missing value line, this should be easy to fix.
> Suggested remedy is instead of blanking value by default, to instead apply the Lib-value as default.
> Outcome: A NET missing-value line, leaves lib-value in place, but any present value line, will replace the value string.
>
> Use cases: where designs have a library order code design, that includes the value.
> Example -
> Digikey part number order code RMCF0805FG1K00-ND
> That's RES 1K OHM 1% 1/8W 0805
>
>
> Appendix:
>
> Useful No-net/minimal tutorial NET link:
> http://home.mircad.nl/md/KiCad_without_Eeschema_or_CvPcb.html
>
> SKiDL scripts
> https://forum.kicad.info/t/skidl-a-python-based-schematic-design-language/3743
>
> No-SCH
> https://forum.kicad.info/t/pcbnew-without-eeschema-again/3306
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1777362/+subscriptions

[jean-pierre charras (jp-charras)]

I am thinking this is a problem that must be fixed in the externally-generated netlist, not by Kicad.
If a empty value is *specified* in the netlist, I am expecting Pcbnew uses this specified (empty) value.
If a value is expected in the board, it must appears in the netlist.
I am seeing this issue as trying to use a incorrectly build netlist.

[Wayne Stambaugh (stambaughw)]

I'm curious as to why the behavior is different when using the internal
netlist versus using an external netlist. Was this an oversight or
intentional? I would think they should be the same.

On 6/19/2018 8:59 AM, jean-pierre charras wrote:
> I am thinking this is a problem that must be fixed in the externally-generated netlist, not by Kicad.
> If a empty value is *specified* in the netlist, I am expecting Pcbnew uses this specified (empty) value.
> If a value is expected in the board, it must appears in the netlist.
> I am seeing this issue as trying to use a incorrectly build netlist.
>

[Jeff Young (jeyjey)]

I think /this/ behaviour is the same between Read Netlist and Update PCB, but there are definitely differences (such as how much control you have over resetting things).

[Wayne Stambaugh (stambaughw)]

I tend to agree with JP. This seems like an issue with the reporters netlist generation script rather than KiCad's netlist importer. I don't understand how the value field defined in a footprint makes sense as the value of a component placed on a PCB but maybe I'm not seeing the use case here. I'm not opposed to the idea but not for v5 because there could be unexpected issues that I would rather not risk. Before I would approved something like this, I would like a clearer picture of the use case to make sure I understand what it is we are trying to accomplish.

[PCB Wiz (1-pcb-wiz)]

@ JP > If a empty value is *specified* in the netlist, I am expecting Pcbnew uses this specified (empty) value.

Yes, I agree, however there are two meanings for 'empty' here.
I should have included an example - here are 3 example netlist parts

    (comp (ref J1)
      (footprint Pin_Headers:Pin_Header_Angled_1x10_Pitch2.54mm))
    (comp (ref J2)
      (value TI_BOOSTER_40_J2)
      (footprint Pin_Headers:Pin_Header_Angled_2x05_Pitch2.54mm))
    (comp (ref J3)
      (value "")
      (footprint Pin_Headers:Pin_Header_Straight_1x10_Pitch2.54mm))

Here, J3 is empty (null string), so yes, that should, and currently does, make Value = ""
Next, Look carefully at J1 entry
There, the value line is missing entirely, (also called empty).
On other CAD tools this loads the LIBRARY stores value.

Right now, PcbNew reads this NET file fine, and fetches the Library part, BUT clears the library value as it does so. It is that decision path this fixes. It should KEEP the library default.

It does NOT affect any user who defined (value "")

This change should be a quite safe one, as it only applies when a (value 10k) entry is missing entirely.
That does not happen from SCH, it _only_ happens with Script/generated netlists flows.

WS: > I don't understand how the value field defined in a footprint makes sense as the value of a component placed on a PCB but maybe I'm not seeing the use case here.

The use case is for when someone is using script generated NET files, _and_ a BOM centric library.
ie the library has part codes for each value already defined and placed.

Some users do this, because it makes Pick and Place and stores/handling much easier, but it does cost them a little more effort at library create time.
In larger companies, they prefer the 'fewer mistakes' path, over the 'simpler'.

Key point: This breaks nothing, as anyone who wants to define a value, simply does so in the NET file.
Those users have no idea this change exists.

What this fix allows, is for users to access the Value field, they defined in the LIB.
(which is how other CAD flows work now)

QC managers like that, as they know someone cannot accidentally (via NET) over-rule their master library.
The footprint becomes a master part number.

JY> (It's a simple one-liner to change.)
I was hoping it was a simple decision-fix.

Thanks for looking at this.

[jean-pierre charras (jp-charras)]

Therefore the proposed fix does not work (and creates a potential bug).
And a full fix is more than one line change.

Any change can create a bug and especially when related to netlist, needs to be carefully tested.

This is the reason I am thinking it cannot be added to the 5.0 version, a just week before the stable version is out.
(Moreover, this is more a new feature than a bug fix)

Still, it looks to me curious the component value exists (to create a BOM) and a other value it used on the board, regardless the way the netlist is created.
Yet again, I think this is a flaw in external netlist generation, because I do not understand why the footprint name is known, and not its value.

[PCB Wiz (1-pcb-wiz)]

JP> Any change can create a bug and especially when related to netlist, needs to be carefully tested.

I agree. The testing here is covered by 3 cases,

    (comp (ref J1)
      (footprint Pin_Headers:Pin_Header_Angled_1x10_Pitch2.54mm))
    (comp (ref J2)
      (value TI_BOOSTER_40_J2)
      (footprint Pin_Headers:Pin_Header_Angled_2x05_Pitch2.54mm))
    (comp (ref J3)
      (value "")
      (footprint Pin_Headers:Pin_Header_Straight_1x10_Pitch2.54mm))

JP> And a full fix is more than one line change.

I do not have full source here, so cannot comment on how many lines, but the fix is to skip a bad choice, and leave the (presumably) loaded Lib-value intact, so should be minimal..

JP > Still, it looks to me curious the component value exists (to create a BOM) and a other value it used on the board, regardless the way the netlist is created.
Yet again, I think this is a flaw in external netlist generation, because I do not understand why the footprint name is known, and not its value.

A BOM really requires only a full part order code - example : Digikey RMCF0805FG1K00-ND
The value is included in that part order code.
This is to support those flows who want to work that way, and the script based flows can use this.
- plus, other CAD pgms have this facility, where they import all info from the libary, when it is not over-ruled by netlist info.

[PCB Wiz (1-pcb-wiz)]

I also tested Python script part fetch, and this is the current operation table

* Add part manually -> Lib.Value is applied in PCB
* Add part via Python -> Lib.Value is applied in PCB
* Add part via custom NET line, like this (removed (value) line from NET file)
    (comp (ref J1)
      (footprint Pin_Headers:Pin_Header_Angled_1x10_Pitch2.54mm))
  -> Part adds from lib, _BUT_ the Lib.Value has been blanked. (with no user directive to do so)
wanted instead in this special case is
  -> Lib.Value is applied in PCB
which then makes the pathways all the same outcome. Consistent & more usable.
If someone really wants an empty value, they likely already do this explicit define.
    (comp (ref J1)
      (value = "")
      (footprint Pin_Headers:Pin_Header_Angled_1x10_Pitch2.54mm))

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2157