kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Dear Brian F. G. Bidulock,

This work of mine started out with me volunteering to fix a bug, which
was reported by someone who took the time to report it.

I extended my commitment behind that considerably, in the sense that I
was able to come up with something that will be useful for other
purposes also.

If you are unhappy with some aspect of Kicad then there are a number of
avenues available to you.  Usually persuasion is the angle that most
users first attempt.  That normally only works when the volunteer, the
fixer, has the same problem and time to fix it.  However we have to
remember that we are not all gifted with the same ability to persuade,
some can be more persuasive than others.

I am not persuaded, and seem to have different needs.  Unfortunately, I
do not have unlimited time to work voluntarily work on Kicad.

You might want to file an enhancement request on the bug tracker if you
run out of other options, and I would suggest doing it in a persuasive
and inspirational way.


Dick


> Dick,
>
> 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.
>
> -X--snip--X--
>   
>> 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
>
>