I agree with this decision as well but for different reasons.
The more I get into small scale self manufacturing, the more I am
persuaded by the argument that you want to keep as little BoM
information in the Kicad schematic fields as reasonably possible. It
becomes a maintenance nightmare, an external BoM tool is what is needed
which bridges Kicads schematic information and true BoM part
information. If you are making one or two boards you can store it all
inside your schematic, but go to 3 or 4 and you quickly feel like you
are crushing rocks re-entering the same information for the same
components all over again. And if you want to change something, then
you have to do it for every component you have of that part, in every
schematic that uses it. Then you have equivalents, costings, inventory
control, supplier information, etc etc. It quickly becomes unmanageable
if you try and hold this information in a schematic.
If you are trying to generate a CSV or TSV to upload to Mouser for
costing, it will be subtly different to what a contract manufacturer
will want from you, etc. Because of this, no two designers will come up
with the same scheme to specify this BoM information, it will depend
what they want to use it for.
Its better to store an abstract or general piece of information in the
schematic which can be used by an external BoM tool to generate a true
BoM for you, in the format/s you or your manufacturer require. And if
you are going to do that, its just as easy to directly read the
schematic files, as it is to read a BoM exported in CSV format.
See: https://github.com/KiCad/kicad-library-utils for python code to
read a schematic directly.
Steven
On 13/05/17 02:18, jp charras wrote:
Le 12/05/2017 à 13:55, Oliver Walters a écrit :
This feature was IN this branch of code but was vetoed. It was
WYSIWYG BoM with export to:
*SV
XML
HTML
Wayne mentioned that KiCad used to have such a BOM export tool but I
haven't been using KiCad long
enough to have experienced it.
If there is real need for such a feature then I leave that to the
project leads to decide. I have
the code still, and it could be implemented very easily.
Hi Oliver,
As Wayne said, we don't like a BOM export tool *written in C++ inside*
the Kicad code.
Here is the reason:
A few years ago, this code was existing and (as Wayne said) created
the same BOM files (txt, csv...)
as your code.
What was the result:
Roughly ever month, a bug or request was filled to change something in
BOM files.
I am guessing we cannot find 2 guys who want the same BOM format or
option.
Therefore, the C++ code inside the Kicad code was dropped, and
replaced by external scripts (Python
or XSL) to transform the XML netlist created by Kicad to an other list
(BOM, but also other netlist
formats).
*Trust me*, this was a *wise* decision (It was not my decision, but
was a good decision).
Therefore: if you want to create the BOM you like, write a Python
script to do that from a netlist
(it is easy to run from Eeschema: see the BOM or Netlist generator),
but do not try to merge this
code in Kicad C++ sources: your script will never generate the "right"
BOM.
But a Python script is very easy to modify.
There are already many BOM generators written in Python.
_______________________________________________
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
