kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Brian,

>From an embellished generic netlist, I believe you can generate
something very similar to the IPC Bom using XSLT.

Thanks for the feedback.  The BOM that I need is in CSV file format. 
Brian is writing python code to generate a BOM *from* what is
essentially a netlist, not a BOM.  I suppose you understood that but I
was not sure. 

For the "Do Not Stuff" support, I typically put in a field called
"Installed" and set it to "NU", meaning Normally Uninstalled, or DNS.  
This ends up in the CSV and in my spreadsheet.  You can now do this
easily with the template fieldname support I added last month.  These
new fields will come along for the ride into the generic netlist
(gnetlist) file.

The gnetlist can have as much information in it that we can find.  If
that information does not exist within the existing eeschema framework,
and cannot be added by a user through "fields" attached to either
components or libparts, then we are out of luck.  Then somebody will
have to volunteer for it.  However from an embellished gnetlist (with
fields), I believe you can generate something very similar to the IPC
Bom using XSLT or python.

The reason for the elaborate <component> element, is that I think
Jean-Pierre may eventually want to put schematic coordinates in there
also.  Remember, I am serving the netlist master there, not exclusively
the BOM master, but the BOM master I think is an easier one to serve and
can be done by doing a good gnetlist.

You may never even have to read a generic netlist file with your eyes. 
It will be read by any number of conversion software tools, and is
basically an intermediate file by definition, something easier to read
than parsing schematic and library files within a project.

So the length of the file is not important, unless you are running out
of disk space, in which case I refer you to newegg.  We can even tell
the software to delete these files after they have been used by the
downstream tool(s).

I do notice some data that I am not including which is known to be
present, such as project name, and perhaps date.  The <fields> data is
instantiated per schematic part.  There is also a like set of <fields>
that can be tied to the library part within EESCHEMA.  That should
probably also be exported, and if it were, then your BOM XSLT stylesheet
could use that information from one place, by matching lib= and part=
attributes on a per component basis.

I think by the time we get done with the generic netlist, I don't really
see a problem supporting most of the XML file you sent, using a good
enough XSLT stylesheet to get there.  Or somebody can do it in python. 
That XML document is of no interest to me personally, so you'd have to
build your own tool to chain on the end of the conversion sequence to
generate it, something that should be relatively easy soon.


Dick




> Dick,
>
> I have between 500 and 1000 0.1uF X5R 0402 bypass capacitors on
> my card.  You are going to have 1000 repetitions of this
> <component> structure in the file, where the only difference is
> the 'ref' attribute in the first line (resplendent with
> repetitions of my user-defined fields (manufacturer's P/N,
> vendor, vendor's P/N, price, price breakpoint, type,
> substitutions, power consumption, thermal resistance) which will
> be the same for all 1000 capacitors.  This is going to be about
> 100,000 lines of XML.  It will be unreadable because I won't be
> able to see other components for the capacitors.  Paging through
> with an editor will be a pain.
>
> Might I suggest that you consider an already tried and true BOM
> format, already specified in XML, such as that from "IPC-2581
> includes Ammendment 1," Section 7. (Google:
> IPC-2581witham1pub.pdf).  Also talk a look at the Approved
> Vendor List in Section 9 of the same document.
>
> IPC's BOM looks like:
>
> <Bom name="TestBoard1">
> <BomHeader assembly="Karens Design" revision="Prototype"
>     stepListRef="KarensBoard"/>
>     <BomItem OEMDesignNumberRef="Fabricated" quantity="1"
>         numberIO="4" category="ELECTRICAL"
>         description="Card EdgeConnector">
>         <RefDes name="J1" populate="FALSE"/>
>         <Characteristics category="ELECTRICAL"/>
>     </BomItem>
>     <BomItem OEMDesignNumberRef"Sample1234" quantity="1"
>         numberIO="8" category="ELECTRICAL"
>         internalPartNumber="Molex 354892"
>         description="Biforcated Thru-Hole connector"
>         packageRef="Connector1">
>         <RefDes name="J2" populate="TRUE"/>
>         <Characteristics category="ELECTRICAL"/>
>     </BomItem>
>     <BomItem OEMDesignNumberRef="SOIC129867" quantity="1"
>         numberIO="8" category="ELECTRICAL"
>         internalPartNumber="Phillips IC2436"
>         description="SOIC 1.27 pitch" packageRef="SOIC12">
>         <RefDes name="U1" populate="TRUE"/>
>         <Characteristics category="ELECTRICAL">
>             <Textual definitionSource="Pretested Logic"
>                 textualCharacteristicName="Per Supplier Data Sheet"/>
>         </Characteristics>
>     </BomItem>
>     <BomItem OEMDesignNumberRef="CAP 24A1846" quantity="1"
>         numberIO="2" category="ELECTRICAL"
>         internalPartNumber="Phillips Cap1235"
>         description="3225 Surface Mount Capacitor"
>         packageRef="Capacitor1">
>         <RefDes name="C1" populate="TRUE"/>
>         <RefDes name="C2" populate="TRUE"/>
>         <RefDes name="C3" populate="TRUE"/>
>         <RefDes name="C4" populate="TRUE"/>
>         <RefDes name="C5" populate="TRUE"/>
>         <RefDes name="C6" populate="TRUE"/>
>         <RefDes name="C7" populate="TRUE"/>
>         <Characteristics category="ELECTRICAL">
>             <Measured measuredCharacteristicName ="Capacitance"
>                 measuredCharacteristicValue="20 Microfarads"
>                 engineeringUnitOfMeasure="Microfarads"
>                 engineeringNegativeTolerance="3 microfarads"
>                 engineeringPositiveTolerance="3 microfarads"/>
>         </Characteristics>
>     </BomItem>
> </Bom>
>
>
> You will notice some necessary features such a whether the
> component is populated at the refdes or not.  Also, real
> electrical properties instead of loosey goosey value field.
> Place for both external OEM and internal part numbers.  Full
> descriptions.
>
> Also, using this format (or at least containing this
> information), I can have PCBNEW read it and place the BOM in the
> generated IPC-2581 file.
>
> The problem with having a BOM that has too little information is
> that the assembler will import it into a spread sheet and start
> changing it.  Loss of sync between the CAD data, spreadsheet and
> CAM system (chip shooters) simply results in rapid and automated
> descruction of parts and boards.  Money can be burnt easier (and
> maybe even safer) with fire.
>
> --brian
> 	
>
>
> On Fri, 30 Jul 2010, Dick Hollenbeck wrote:
>
>   
>> <netlist>
>>
>> <!--one for every component instantiation: -->
>>
>> <component ref="R23">
>>   <fields>
>>      <value>123k</value>
>>
>>      <!-- present only if non blank -->
>>      <footprint>SM0201</footprint> <!-- desired
>>      <datasheet>dontsheetonmydesk.pdf</datasheet>
>>
>>      <!-- user defined fields start here. this user is trying to help
>>           himself in the BOM creation process and has extra fields:
>>       -->
>>      <Manufacturer>TI</Manufacturer>
>>      <Vendor>Digikey ABCD123</Vendor>
>>   </fields>
>>
>>   <tstamp>45DC86E7</tstamp>
>>
>>   <libsource>libname.partname</libsource>
>>
>>   <!-- pins are intentionally not described here since
>>        we really don't want to repeat something verbose
>>        that would need to be duplicated per instance.
>>   -->
>>
>> </component>
>>
>>
>> Then there could be something like specctra's image, one for each unique
>> part:
>>
>> <image libsource="libname.partname">
>>
>>     <!-- image is from specctra, a better name is possible -->
>>
>>     <!-- here could be a full work up on the pins of
>>          the part, and as much
>>          graphical detail as needed.
>>     -->
>>
>>     <pins>  <!--generically speaking -->
>>
>>         help welcomed
>>
>>     </pins>
>>
>> </image>
>>
>> Then one block of nets
>>
>> <nets>
>>
>>   <net name="/cfcard.sch/WAIT#">
>>     <node comp="R23" pin="1"/>
>>     <node comp="U18" pin="12"/>
>>   </net>
>>
>>   <net>
>>      :
>>   </net>
>>
>>   :
>>
>> </nets>
>>
>>
>> </netlist>
>>
>>
>> Please offer any feedback on what you see.  (I don't care as much about
>> what you don't see, since we can and will add more later.)
>>
>> And man, after writing this I went and looked at a specctra DSN file
>> which has the S-expressions and I cannot believe the better readability
>> of the S-expression files.  It is startling, the difference.
>>
>> Dick
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>     
>