← Back to team overview

kicad-developers team mailing list archive

Re: BOM support



On Fri, 30 Jul 2010, Dick Hollenbeck wrote:

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

Understand that for PCBNEW to generate the IPC-2581 file with a BOM
in it (to avoid component and board destruction), PCBNEW must be able
to read the BOM *"from"* file.  I think this must also be *the*
netlist and not some off-line auxiliary netlist that can get out of
sync with the data brought into PCBNEW from EESCHEMA.

Also, consider that neither CVPCB nor EESCHEMA know the final footprint.
Only PCBNEW knows this.  It can be back-annotated from PCBNEW's module
file, but fabrication outputs should never rely on back-annotated
results (again because it is a step that can easily be missed).

For example, a capacitor has CAPC2535L footprint in EESCHEMA, but
I change that to CAPC1005M for a specific component in PCBNEW.  The
BOM says CAPC2535L and the pick and place says CAPC1005M.  So, I get
a component order with monster thick film capacitors that I hope
never gets to be stuffed at the 0402 footprint, destroying BGAs and
other devices on its way down.  Well, something like that...

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

I set the Value to NF. It then appears nicely on the pick and place
under the value heading.

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

Intermediate files should never be used for fabrication or
assembly outputs because of synchronization issues (unless the
program will _always_ update it every time that a regular
netlist is written).  BOM is such an output.

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

Making file format readable and editable is one of the
protections against bugs.  The file can always be manual
corrected for a time as long as it can be read and editted.
If there is no objective to have it readable and editable,
use a binary format.

If the length of the file is not important, why are you not
repeating pin information?

More comments later...


Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@xxxxxxxxxxx    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

Follow ups