← Back to team overview

kicad-developers team mailing list archive

Re: Component table improvements

 

Stevn,

My position in term of electronic design is 180 degrees from yours.
When many engineering hours are spent design a manufacturable board,
you do not want some bean counter change the BOM in a whim.
So in order to control the proper life of a design, you want the schematic
to contain the exact parts which were used be the design team to create
a working, manufacturable board. The only way to do that is to have the
purchased part number be part of the design database.
I have seen too many design failing on the field because someone in the supply chain
thought that it would be smart to use a new supplier for a part without
the design team approval of the new part.

But that is just my opinion based on 40 plus years of high and low volume
electronic manufacturing.

My $0.02,
Jean-Paul
N1JPL



> On May 13, 2017, at 8:46 AM, Strontium <strntydog@xxxxxxxxx> wrote:
> 
> 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



References