← Back to team overview

kicad-developers team mailing list archive

Re: Component table improvements

 

Agree, a csv file option should be available.

Would be nice if there were 2 flavors, grouped and ungrouped.
That's all a general user might want.

Asking a general user to deal with python is unreasonable, and it took me a
while to figure out how the current plug in system works and even longer to
find the right plugin to get grouped results.

On Sun, May 14, 2017 at 12:39 PM, Kristoffer Ödmark <
kristofferodmark90@xxxxxxxxx> wrote:

> Well I think these reasons are strange, I think that having a built in way
> of exporting the BoM from the software is reasonable. Since not everyone
> are the same.
>
> The component table is what a user expects to see when wanting to generate
> a BOM. I can assure you that no EE or student expects to be presented with
> a weirdly formatted command-line interface as is the current way.
>
> The current BOM generating is a settings interface more than a BOM export
> tool.
>
> CSV files are also a lot easier to parse than parsing a kicad schematic
> file,
>
> - Kristoffer
>
>
>
> On 05/13/2017 02:46 PM, Strontium 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
>>
>
>
> _______________________________________________
> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandrey89@xxxxxxxxx
Live Long and Prosper,
Andrey

Follow ups

References