kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/31/2010 03:32 AM, Dick Hollenbeck wrote:
> 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.
>   

You can now do a fairly good export.  Only the <libpart>s are missing now.

Here is format revision C.  It basically adds:

1) <netlist> project & date

2) <libpart> fields which will be very useful for a good BOM.  If
desired, somebody can do what is basically a relational table lookup
from <comp>/<libsource>(lib, part) to <libparts> based on matching "lib"
and "part".  A python dictionary would make this easy.

A logical_lib is a simple short string which for now is the library name
minus path and extension.  Later it should be a key in a two column
tuple within eeschema, and that tuple should be a configuration option
instead of the library search path that we have now.


Dick


<?xml version="1.0"?>

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

<netlist version="C" project="CFCARD" date="will try to get time here too">
  <components>

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

      <!-- present only if non blank -->
      <footprint>SM0201</footprint><!-- actual bound footprint -->

      <!-- 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>

      <libsource lib="logical_libname" part="partname"/>

      <sheetpath tstamps="/47BA261A/" names="/serial.sch/"/>

      <tstamp>45DC86E7</tstamp>

      <!-- 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">

      <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>

      <!-- 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>