2016-04-27  Robin Whittle

Please see the parent directory for details of this program:  ../#kpv .

Source code as a gzip file, so it can be compiled for Linux or any other OS:


Source code and a 64 bit Windows executable, made with the TDM version of the mingw Windows adaptation of GCC as a 7zip file:


Source code and a 32 bit Windows executable, made with Microsoft Visual Studio 2013:


Here is the documentation, from the source code.

This program processes the netlist file generated by Eeschema, with the
the modified version to be read into Pcbnew, to acheive these outcomes:

   Normally, the contents of the "value" field in each component in the
   schematic is transferred to the contents of the "value" field of the
   corresponding footprint in the PCB design.  The contents of this
   "value" field in the schematic design is also used for generating the
   the BOM.

   This program helps with scenarios where we want a different piece of
   text, or nothing showing at all, for the value in the PCB design, with
   respect to the value of the matching schematic component.

   In such cases, the schematic component is edited in Eeschema to have an
   extra field whose name is: "PCBVal".  The contents of this field cannot
   be empty, but can contain a single space.

   If the value of the "PCBVal" field has '%' as its first and perhaps
   only character, then there will be no change as described below. 
   Therefore a reasonable approach is to have, as a default for all
   schematic components a "PCBVal" field with its contents set to "%" and
   visibility turned off.  This means that it is impossible to use this
   facility to generate a value for the PCB component whose contents start
   with '%'.

   For those devices ("device" here means a physically and logically
   unique electronic component, as represented by a schematic component in
   the schematic file and by its matching footprint in Pcbnew's board
   design file) where we want the contents of the "value" field in the PCB
   design to differ from that in the schematic, we add this extra field,
   named "PCBVal" to the schematic component and set its value to whatever
   we want to see in the PCB design as the "value" field.  If we want the
   latter to appear empty - so as not to clutter the component legend
   layer with stuff we don't want on the board, or on the screen in gray
   (as occurs when the footprint's value contains printable characters and
   has its visibility attribute set to "invisible") - then we set the
   value of the PCBVal field to a single space. 
   Scenario 1:

       I want the value in the schematic to be the full part number of the
       device, such as "BZT52H-B5V6" which specifies a Zener diode with a
       particular voltage and power handling capacity, in a particular SMT
       package.  This is the full manufacturer's part number - exactly
       what I need in the BOM.  Sophisticated BOM generation typically
       involves further fields for full part numbers, but in this
       scenario, the point is that we want different text in the value
       fields of the schematic and the PCB design.

       It is way too long for the PCB, where the text would take up about
       three times the area of the Zener diode itself.

       For the PCB, "5V6" is all I want.  This is suitable for helping
       with service work and is important since Zener diodes in SMT
       packages typically do not have their voltage marked on them.

       I can make this happen by editing the value field of the diode's
       footprint in Pcbnew, but this will be overwritten next time I
       create an updated netlist in Eeschema, and read this into Pcbnew.

       So I create the new field named "PCBVal" in this diode's parameters
       in Eeschema (right-click > Edit component > Edit) and set its value
       to "5V6" (without these quotes).  Alternatively, if this field
       already exists, with its value consisting of just "%" or "%"
       followed by one or more characters, then I alter it to be just

       If there were no other fields than "PCBVal", then the netlist
       produced by Eeschema would have lines starting with "(fields" and
       "(field (name PCBVal) " for this component:

           (comp (ref DZ1)
                 (value BZT52H-B5V6)
                 (footprint 0RWFP:SOD-123)
                   (field (name PCBVal) 5V6))
                 (libsource (lib 0RW) (part D-ZENER-SOD-123))
                 (sheetpath (names /2-DFR/) (tstamps /57146362/))
                 (tstamp 57179AA3))

       This program processes such a netlist to change the "value" field,
       so the result is:

           (comp (ref DZ1)
                 (value 5V6)
                 (footprint 0RWFP:SOD-123)
                   (field (name PCBVal) 5V6))
                 (libsource (lib 0RW) (part D-ZENER-SOD-123))
                 (sheetpath (names /2-DFR/) (tstamps /57146362/))
                 (tstamp 57179AA3))

       Pcbnew seems to make no use of the fields lines, and the value field
       of the diode's footprint will be set to "5V6".

       Here I have described the change as being at the level of an
       individual component in a schematic.  However, it is possible to do
       the same thing in Eeschema's library editor, so every instance in
       the schematic of some kind of library component will have this extra
       field "PCBVal", with its value set to either "#" so no changes are
       made to the value accepted by Pcbnew, or to some other string which
       will be used to make a change as described above.

       It is also possible to make the text contents of this PCBVal field
       (the value of this field) appear on the schematic with any chosen
       position, orientation and text size.  For me it appears in purple if
       I set to visible.

   Scenario 2:

       In the schematic, I make the value field invisible for a particular
       instance of a component, or in the library representation of such a
       component.  This is fine and good.  For instance, I have a
       symbol (schematic library part AKA component) for a single wire
       solder pad for direct soldering to the PCB.  I may gang these up on
       the PCB for solderning a few wires of a ribbon cable.

       Each library component has a name in the library, determined by the
       contents of its value field.  This one's name is "RIBBON-WIRE".  I
       make this hidden ("T" icon on top toolbar > Value > Visibility:
       Show (not ticked) so I don't have to see this on the schematic.

       If Pcbnew reads the unmodified netlist, the result will be a piece
       of gray text "RIBBON-WIRE" visible in the PCB design, where this
       "value" field has its Visibility attribute set to "Invisible".
       This means it will not appear on the physical board, but it
       still clutters up my screen with gray text.  The only solution
       is to ensure that for these footprints in the PCB design, this
       "value" field is set to either no characters, or to one or more

       This program acheives this, once the schematic component has a
       "PCBVal" field whos contents (value) set to a single space. 
       (It cannot be 0 characters.)  This is represented in the netlist

                   (field (name PCBVal) " "))

       or, more generally, when there is no second parenthesis due to
       one or more fields after the PCBVal field:

                                    << 0 or more lines for other fields.
                   (field (name PCBVal) " ")
                                    << 1 or more lines for other fields.

       This program transfers this to the "value" field:

                 (value " ")

       of the output file - the modified netlist.  Once the modified
       netlist is read into Pcbnew, the matching footprint no longer
       has any annoying gray text.

   The program requires the name of the input and output file names,
   without the .net extension, for instance, for an input file

       kicad-pcb-value xyz xyz-mod

   The program does not report on the actual changes.  These are best
   checked with a diff program or Beyond Compare.  The program will
   stop with assertion errors if unexpected conditions occur.  It
   reports the number of component definitions found and the number