kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Fri, 30 Jul 2010, Brian F. G. Bidulock wrote:

> I have between 500 and 1000 0.1uF X5R 0402 bypass capacitors on
> my card.  You are going to have 1000 repetitions of this

Ever considered a dieletric layer in your board (i.e. power layers
*being* the bypass capacitors)? with that kind of
capacitor number it could be economical :D

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

It was said more than one million times... XML is not actually mean to
be *usefully* readable :P

> able to see other components for the capacitors.  Paging through
> with an editor will be a pain.

Postprocess it. You'll avoid a sort/merge step which would be
unnecessary in most other scenarios without imposing a projection (IIRC
db theory correctly) in most other scenarios (like the 'by reference'
BOMs)

I think this would be a KISS scenario.

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

*That* would be a good idea. Better use an existing standard than
reinventing the wheel. Too bad you have to pay for most IPC standards :(

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

We have completely arbitrary attribute fields... good luck reconciling
the two structures (we're hitting the R.E/O.O. impendance mismatch, as
usual)

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

In my book the source BOM XML/whatever would be contain *everything*
that kicad knows about the component. Postprocessors would then extract
relevant informations from it, depending on the application.

--
Lorenzo Marcantonio
Logos Srl