kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/30/2010 12:03 PM, Dick Hollenbeck wrote:
>> I am trying to reach the right comprise between clarity and lack of
>> verbosity, and to avoid situations where we have to change ' ' with
>> '_' by keeping things wrapped with proper XML syntax.
>>     
>
> The attached file is a revision that actually passes through xmllint.  
> I am calling it "version A" format.
> We can switch to version="1" after it stabilizes, using letters until then.
>
>
> Changes:
>
> 1) Promoted <value>, <footprint> <datasheet> outside <fields> so they
> are easier to reference with xpath and faster to find.
>
> 2) Wrap the fields in a <field> element so the names can have spaces in
> them.
>
> 3) Separated the libsource element's value up into two attributes, lib
> and part.
>
> 4) changed <image> to <libpart>
>
> 5) added <sheetpath> to <component>.
>
> 6) added attributes lib and part to <libpart>.
>
> 7) changed <nodes>'s part to ref.
>
>
> As I say, this passes xmllint now so Brian you can see if your python
> code can start to load it, and of course you can add additional records
> with a text editor.
>
> And for others, feedback is still welcomed.
>
> I am not totally comfortable with the name <component> as it is a bit
> too long for my taste.
>   

Brian S:

I revised the format again, now up to format version B:

Attached is a sample, with comments in it, of format version B. 

Also, you can now generate partial forms of these files yourself from
eeschema:

I have checked in a some xml code that you can use to generate this
generic netlist, format version B.  To generate the file, select after
loading your schematic, Netlist -> Add Plugin.  Then provide a dummy
post processor command, i.e. plugin, since we are not ready for that
yet, or maybe you are.  I supplied "ls" as the post processor, i.e.
plugin.  Give the plugin tab a name, such as "Generic".  The actual file
is XML file is saved with a *.tmp extension even though the file
selection dialog is has you believing *.net in the file save dialog when
you go to run it.  Of course the reason for that was to anticipate the
plugin being run on the *.tmp file to generate the *.net file.

For eventual BOM generation, we may have to provide even more
flexibility, so this may not be the final behavior, but with this email
I am trying to get you the ability to generate these files here, nothing
more yet.

The main changes from format version A to B were:

1) <component> is now <comp>

2) added a single <components> element to identify a "section" within
which all <comp>s can reside.

3) added a single <libparts> within which all <libpart>s can reside.


When generating the *.xml from eeschema using the above technique, you
will not see populated <libparts> or <nets> yet.  But I don't think this
affects our initial python code which is more interested in handling the
<comp> elements for BOM generation.

I will be adding more support to the xml export Saturday.


Thanks,

Dick


<?xml version="1.0"?>

<!-- This is the proposed generic netlist format for Kicad's EESCHEMA
     format version B.
-->

<netlist version="B">
  <components>

    <!--one comp for every component instantiation: -->
    <comp ref="R23">
      <value>123k</value>
      <sheetpath>cfcard.sch</sheetpath>

      <!-- present only if non blank -->
      <footprint>SM0201</footprint><!-- desired, not actual -->

      <!-- present only if non blank -->
      <datasheet>dontsheetonmydesk.pdf</datasheet>

      <fields>
        <!-- user defined fields start here. this user is trying to help
              himself in the BOM creation process and has extra fields:
          -->
        <field name="Manufacturer">TI</field>
        <field name="Vendor">Digikey ABCD123</field>
      </fields>

      <tstamp>45DC86E7</tstamp>
      <libsource lib="logical_libname" part="partname"/>

      <!-- pins are intentionally not described here since
           we really don't want to repeat something verbose
           that would need to be duplicated per instance.
      -->

    </comp>
  </components>

  <libparts>

    <!-- Then there could be something like specctra's image,
         one for each unique library part, actually used within
         the schematic, called libpart:
    -->

    <libpart lib="logical_libname" part="partname">
      <!-- here could be a full work up on the pins of
         the part, and as much
         graphical detail as needed.
      -->
      <pins> <!--generically speaking for the libary part -->
        help welcomed
      </pins>
    </libpart>

  </libparts>

  <!--Then one block of nets-->
  <nets>

    <!-- many net elements will be present here -->
    <net name="/cfcard.sch/WAIT#">
      <node ref="R23" pin="1"/>
      <node ref="U18" pin="12"/>
    </net>
  </nets>
</netlist>