kicad-developers team mailing list archive
Mailing list archive
Re: BOM support
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.
> 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
> 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.
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
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
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.
<!-- This is the proposed generic netlist format for Kicad's EESCHEMA
format version B.
<!--one comp for every component instantiation: -->
<!-- present only if non blank -->
<footprint>SM0201</footprint><!-- desired, not actual -->
<!-- present only if non blank -->
<!-- user defined fields start here. this user is trying to help
himself in the BOM creation process and has extra fields:
<field name="Vendor">Digikey ABCD123</field>
<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.
<!-- 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 -->
<!--Then one block of nets-->
<!-- many net elements will be present here -->
<node ref="R23" pin="1"/>
<node ref="U18" pin="12"/>