Low Cost PCB's Low Cost Components

Author Topic: Hacking the KiCAD Libaray system to be actually useful  (Read 6017 times)

0 Members and 1 Guest are viewing this topic.

Offline homebrew

  • Regular Contributor
  • *
  • Posts: 204
  • Country: ch
Hacking the KiCAD Libaray system to be actually useful
« on: April 23, 2017, 07:24:52 PM »
So KiCads Library management system ist not free of controversy and has been criticized A LOT. Thus let’s see if we can do anything about that …

Let’s for example take a capacitor. The symbol in the shipped library offers you to set its value after it has been placed in the schematic and in the later process steps add a footprint to your taste. But that has a serious drawback: You practically need to design your stuff with the ordering system of your supplier at hand – use their parametric search to see if the desired properties are actually available in the package. BOM-creation becomes a pain in the ass and so on ...

Hence let’s do something different. Using the library editor, let’s load the “C” symbol and add some fields to it. I simply ‘abused’ the value field for the part-name. Yes – there is a designated footprint field – so let’s use that. And create additional fields for tolerance, ratings and dielectric material. However instead of typing in values directly I used placeholders instead. Here is what the result looks like:



I can export the single component and name the file ‘C_template.lib’. It now has the following content:

#encoding utf-8
#
# ###PARTNAME###
#
DEF ~###PARTNAME### C 0 10 N Y 1 F N
F0 "C" 25 100 50 H V L CNN
F1 "###PARTNAME###" -150 0 39 V I C CNN
F2 "###FOOTPRINT###" 50 -200 39 H I L CNN
F3 "###DATASHEET###" 50 -400 39 H I L CNN
F4 "###VALUE###" 50 -100 60 H V L CNN "P_Value"
F5 "###RATING###" 50 -250 39 H I L CNN "P_Rating_U"
F6 "###TOLERANCE###" 50 -300 39 H I L CNN "P_Tolerance"
F7 "###MATERIAL###" 50 -350 39 H I L CNN "P_Material"
DRAW
P 2 0 1 20 -80 -30 80 -30 N
P 2 0 1 20 -80 30 80 30 N
X ~ 1 0 150 110 D 50 50 1 1 P
X ~ 2 0 -150 110 U 50 50 1 1 P
ENDDRAW
ENDDEF
#
#End Library

Ok, now let’s get to the real deal. Let’s create the library. Of course, as a good engineer, we start with Excel :-) Or rather with OOCalc, if you prefer. And now I cant put all the parameters in it, like so:



… and save it as plain csv.

Convenient Bash-skills are convenient …
Code: [Select]
echo "EESchema-LIBRARY Version 2.3" > Capacitors_SMD.lib; echo "EESchema-DOCLIB  Version 2.0" > Capacitors_SMD.dcm; for i in $(cat Capacitors_SMD.csv); do IFS='; ' read -r -a array <<< "$i"; cat ${array[2]}_template.lib | tail -n +3 | head -n -2 | sed -e "s/###PARTNAME###/${array[0]}/g" -e "s/###FOOTPRINT###/${array[3]}/g"  -e "s/###VALUE###/${array[4]}/g" -e "s/###RATING###/${array[5]}/g" -e "s/###TOLERANCE###/${array[7]}/g" -e "s/###MATERIAL###/${array[6]}/g" -e "s,###DATASHEET###,${array[8]},g" >> Capacitors_SMD.lib; echo "\$CMP ${array[0]}" >> Capacitors_SMD.dcm; echo "K ${array[3]} ${array[4]} ${array[5]} ${array[6]}" >> Capacitors_SMD.dcm; echo "\$ENDCMP" >> Capacitors_SMD.dcm;  done
This transforms the csv into KiCad library format using the template. The result looks like this:

~/kicad_partlib$ head Capacitors_SMD.dcm
EESchema-DOCLIB  Version 2.0
$CMP 0603N1R0C500CT
K SMD0603 1p0 50V NP0
$ENDCMP
$CMP 0603N1R5C500CT
K SMD0603 1p5 50V NP0
$ENDCMP
$CMP 0603N1R8C500CT
K SMD0603 1p8 50V NP0
$ENDCMP


~/kicad_partlib$ head -n 24 Capacitors_SMD.lib
EESchema-LIBRARY Version 2.3
#
# 0603N1R0C500CT
#
DEF ~0603N1R0C500CT C 0 10 N Y 1 F N
F0 "C" 25 100 50 H V L CNN
F1 "0603N1R0C500CT" -150 0 39 V I C CNN
F2 "SMD0603" 50 -200 39 H I L CNN
F3 "http://www.passivecomponent.com/document/MLCC/MLCC_catalog_200503.pdf" 50 -400 39 H I L CNN
F4 "1p0" 50 -100 60 H V L CNN "P_Value"
F5 "50V" 50 -250 39 H I L CNN "P_Rating_U"
F6 "0.25p" 50 -300 39 H I L CNN "P_Tolerance"
F7 "NP0" 50 -350 39 H I L CNN "P_Material"
DRAW
P 2 0 1 20 -80 -30 80 -30 N
P 2 0 1 20 -80 30 80 30 N
X ~ 1 0 150 110 D 50 50 1 1 P
X ~ 2 0 -150 110 U 50 50 1 1 P
ENDDRAW
ENDDEF
#
# 0603N1R5C500CT
#
DEF ~0603N1R5C500CT C 0 10 N Y 1 F N

Loading this library and you get a nice search frontend in eeschema:



Or you can search by other parameters.



Placing the component and you have an innocent looking capacitor…



Or you can go full tilt and set everything to visible …



So what do you think? Could that be a viable way to work with components in KiCAD? Suggestions?

« Last Edit: April 23, 2017, 07:30:31 PM by homebrew »
 
The following users thanked this post: alexanderbrevig

Offline rs20

  • Super Contributor
  • ***
  • Posts: 1894
  • Country: au
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #1 on: April 23, 2017, 09:53:50 PM »
OK, I was ready to dismiss this post based on the title; but I stand corrected -- I really rather like this idea. Not sure if I'll actually do it, but kudos for the inspirational effort at the very least!
 
The following users thanked this post: alexanderbrevig

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1764
  • Country: fr
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #2 on: April 23, 2017, 10:33:25 PM »
Well, so basically you have turned the Kicad library system into a copy of Eagle's, where every value/footprint variant/voltage rating has its own symbol/footprint in the library, duplicating the stuff all over the place.

Now imagine that there is a mistake in that symbol or footprint. With the original Kicad way of doing things you fix a single symbol/footprint and all parts using it will be correct. With yours? Good luck fixing few thousands parts each time - even if you automate the job.

The entire point of the Kicad's design is that you are not supposed to do this. Add the fields to the components, but do that per project, as you need them, not creating entire libraries of 0603 and 0805 capacitors that differ only in a value of a field or two.
 

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 270
  • Country: au
  • http://blog.julian1.io
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #3 on: April 23, 2017, 11:04:00 PM »
I have always tried to keep part information out of the schematic symbols - so I can use them generically and freely. I even go so far as to avoid creating new symbols for common parts - for example variations on different op-amps - if they follow known pin-outs such as 741. Ideally I can then simply associate a TH or SOIC footprint for PCB layout, and the schematic and footprint are kept loosely coupled. The end goal is a PCB and I only do enough work for that - rather than try to capture all the detail of a circuit and component values. I find the Kicad library model works well using this approach.
 
 
The following users thanked this post: ar__systems

Offline homebrew

  • Regular Contributor
  • *
  • Posts: 204
  • Country: ch
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #4 on: April 23, 2017, 11:23:49 PM »
Well, so basically you have turned the Kicad library system into a copy of Eagle's, where every value/footprint variant/voltage rating has its own symbol/footprint in the library, duplicating the stuff all over the place.

Now imagine that there is a mistake in that symbol or footprint. With the original Kicad way of doing things you fix a single symbol/footprint and all parts using it will be correct. With yours? Good luck fixing few thousands parts each time - even if you automate the job.

The entire point of the Kicad's design is that you are not supposed to do this. Add the fields to the components, but do that per project, as you need them, not creating entire libraries of 0603 and 0805 capacitors that differ only in a value of a field or two.

That is interesting to hear from a super contributor. When I started using CAD-Systems, I probably had the same mindset but people from here and some professionals I know have changed my point of view over the time: The schematic is the place (and the only one) where everything is specified - except layout of course. Till now, the only consistent way of doing that I know is to have a separate symbol for every part ("part" == orderable, specific component). For some designs the parameters of a component are important. Even with simple DC/DC converters it can matter if it is a low ESR type of capacitor or not. Where would you specify that?
For other components special symbols are required as the pinout changes with the packages (i.e. BGA != SOIC etc ...). Then also I can auto-generate the BOM directly from the schematic without further effort ...

What I did was not to copy the eagle system ... Eagle really has separate footprints for every component. I'm not doing that. Deliberately! For the capacitor example I just specify that is is an 0603 footprint. I still have them in a single place. That footprint can be altered according to the particular needs of the project (i.e. hand-soldering vs, reflow ...)

And come on ... a general and severe mistake in a capacitor component?
« Last Edit: April 23, 2017, 11:32:33 PM by homebrew »
 

Offline oldnewb

  • Contributor
  • Posts: 13
  • Country: 00
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #5 on: April 24, 2017, 05:31:39 AM »
Keeping every last design detail in the schematic is a nice idea, but in practice you can easily end up with an enormous and/or unreadable schematic if each symbol includes a list of specifications next to it.  Furthermore, there are too many components and too many manufacturers and too many part numbers (all subject to change) to make the job of compiling a comprehense library worth the hassle.

Eeschema allows you to set additional symbol fields (via Preferences->Schematic Editor Options->Template Field Names in v4.0).  These fields are always present in the component properties dialog; they only get saved to the schematic's file if their value is changed from your specified default.  For example, I have eeschema configured to add "SPEC" and "NOTE" fields.

My current preferred workflow is to create a schematic with text notes in the corner regarding default component assumptions (e.g., "All caps are 20% X7R MLCC unless otherwise specified.").  Components with special needs have their "SPEC" and "NOTE" fields defined accordingly.  I create a separate BOM spreadsheet for all of the manufacturer- and vendor-specific details, which I fill out as I shop for parts online.  KiField (https://github.com/xesscorp/KiField), a third-party Python script, transfers component data between eeschema files and an Excel spreadsheet file (in both directions), which makes the job much simpler.
 

Online miceuz

  • Frequent Contributor
  • **
  • Posts: 350
  • Country: 00
    • chirp - a soil moisture meter / plant watering alarm
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #6 on: April 24, 2017, 03:48:35 PM »
Thanks for sharing @homebrew. It's inspirational, but also not compatible with my work flow.

If I need a special tolerance for a component, I will add it in the value field. Like "10k 0.1%". I also have fields for manufacturer part number, manufacturer name and distributor id. Usually I source components as I am drawing the schematics, so I fill those fields as a part of schematic capture and I can generate a BOM that is compatible with elecrow, seeed and the like. I keep all the project documentation in the schematic.

KiCad has a patch proposed where it adds a dialog that allows to do a bulk edit all the fields - this would be a huge improvement for me. It's not in the nightly yet though. KiField looks like a very useful script for now, thanks!

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1764
  • Country: fr
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #7 on: April 24, 2017, 06:05:00 PM »

That is interesting to hear from a super contributor. When I started using CAD-Systems, I probably had the same mindset but people from here and some professionals I know have changed my point of view over the time: The schematic is the place (and the only one) where everything is specified - except layout of course. Till now, the only consistent way of doing that I know is to have a separate symbol for every part ("part" == orderable, specific component). For some designs the parameters of a component are important. Even with simple DC/DC converters it can matter if it is a low ESR type of capacitor or not. Where would you specify that?

In the schematics, of course.

However, that doesn't mean I would generate/maintain huge libraries containing every possible part variation. I don't know how people do with more advanced tools like Altium, perhaps there is a more efficient way there but with Kicad I do prefer the approach with the separate tool to maintain that info en masse - it is much faster to assign the information there than to click on every single component in the schematic to set it (or to be sure that the correct one was picked from a library) and none has been forgotten. Right now CvPCB handles only footprints but I can imagine a similar table-based approach for other fields too. By default the footprint info is stored in a separate file but recent versions of Kicad import it back into the fields in the schematics.

In the absence of field support in CvPcb a bit of scripting to modify the values in the schematics would do the job. That has also the advantage that if I need to change the values (e.g. to change from 0805 parts to 0603 ones), I can quickly rerun the script and don't need to replace the components (which could leave them disconnected if the symbol is not exactly the same size, etc.).


For other components special symbols are required as the pinout changes with the packages (i.e. BGA != SOIC etc ...). Then also I can auto-generate the BOM directly from the schematic without further effort ...

For ICs that's a bit different, there I tend to create a separate symbol for each package variant too because the support for alternative packages in Kicad is rather limited, indeed. So there is not really a choice there.


What I did was not to copy the eagle system ... Eagle really has separate footprints for every component. I'm not doing that. Deliberately! For the capacitor example I just specify that is is an 0603 footprint. I still have them in a single place. That footprint can be altered according to the particular needs of the project (i.e. hand-soldering vs, reflow ...)

And come on ... a general and severe mistake in a capacitor component?

Yes, that has been a little exaggeration on my part. I was more referring to the fact that every possible part variant is a separate part in the symbol libraries, because Eagle (and other PCB packages) does that too if I remember correctly (haven't used Eagle in a while).

And come on ... a general and severe mistake in a capacitor component?

You mean like symbols changing between different releases of Kicad? Have you never had the messages about parts being replaced or "rescued" when loading an old project because the parts have been replaced in the libraries in the meantime? Sometimes only the shape of the parts changes slightly, sometimes there is a larger change that could break your diagram. Of course, if you generate all your libraries yourself, you may not care, on the other hand you are missing out on any improvements in the stock library files as well (which may not be always visible outright - like the footprint fields that were added relatively recently).

 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: ca
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #8 on: April 24, 2017, 10:36:00 PM »
Well, so basically you have turned the Kicad library system into a copy of Eagle's, where every value/footprint variant/voltage rating has its own symbol/footprint in the library, duplicating the stuff all over the place.

This is actually not correct. Eagle libraries for RCL do not have values and are not linked to manufacturers. They are very generic, only symbol and footprint.
 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: ca
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #9 on: April 24, 2017, 10:45:27 PM »
For some designs the parameters of a component are important. Even with simple DC/DC converters it can matter if it is a low ESR type of capacitor or not.

You are right, for some. It depends on what you do. Maybe if you are doing high speed analog designs inductance of resistors will matter, and you will have to specify mfg part number for it, and ESR of a cap might matter for voltage regulator. But for the most part RC parts are very generic. I think there was only one time I had to specify high voltage/pulse withstanding resistors, and another time I needed 0.1% resistors. Otherwise as far as I'm concerned resistor is fully specified by the value, package and tolerance and I don't provide part numbers for them. So those 1% of cases I will find the suitable component at circuit design time and include its p/n in schematics.

I work on Eagle btw. 
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 347
  • Country: gb
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #10 on: April 25, 2017, 12:34:20 AM »
Otherwise as far as I'm concerned resistor is fully specified by...

The trouble is there is often someone else who is concerned, such as the assembly sub-contractor who like to have components fully specified with manufacturer and their PN.
IMHO every part should be specified by its manufacturer and PN in the libraries, which then makes automatic BOM generation much easier.
If you have to make a BOM you need to do that work anyway, so it may as well be in the libraries for easy reuse.
But each to their own I guess.
 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: ca
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #11 on: April 25, 2017, 12:44:36 AM »
It does make BOM generation easier, but it makes everything else worse. Many contract assemblers stock certain common components and you can have them for cheap. If you specify some other components instead of the ones they could use, your assembly cost goes up.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 347
  • Country: gb
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #12 on: April 25, 2017, 01:03:58 AM »
OK, so specify those parts in your library and BOM.
If you leave it up to your assembly house to substitue whatever they think is a good match for your spec you could be in for trouble.
When you start having batch problems due to components they fitted you are in a world of hurt. You may not even know how many boards were produced with a particular substituted part.
 

Offline homebrew

  • Regular Contributor
  • *
  • Posts: 204
  • Country: ch
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #13 on: April 25, 2017, 01:41:50 AM »
You mean like symbols changing between different releases of Kicad? Have you never had the messages about parts being replaced or "rescued" when loading an old project because the parts have been replaced in the libraries in the meantime? Sometimes only the shape of the parts changes slightly, sometimes there is a larger change that could break your diagram. Of course, if you generate all your libraries yourself, you may not care, on the other hand you are missing out on any improvements in the stock library files as well (which may not be always visible outright - like the footprint fields that were added relatively recently).

Yes, that would be BAD! But I really strive to generate / create everything on my own. Because I want to make all the decisions. Maybe I want elongated pads to ease hand assembling ... or small ones for high density stuff. And I don't like the default silk-screens anyway :-)
And think of the symbols for ICs provided. LOTS of problems like invisible power pins, power pins of zero length, duplicated power pins (i.e. on every opamp in a package) and whatnot... Using such symbols, at least for me doesn't cut it ...

And apart from that, I'll only create a symbol once. The rest will be done by scripts and OOCalc ...

Keeping every last design detail in the schematic is a nice idea, but in practice you can easily end up with an enormous and/or unreadable schematic if each symbol includes a list of specifications next to it.  Furthermore, there are too many components and too many manufacturers and too many part numbers (all subject to change) to make the job of compiling a comprehense library worth the hassle.

Exactly - That's why I've set them to invisible by default. The information is there but not visible / printed. As for the second remark - that is the very purpose of scripting it...

It does make BOM generation easier, but it makes everything else worse. Many contract assemblers stock certain common components and you can have them for cheap. If you specify some other components instead of the ones they could use, your assembly cost goes up.

Then I would STRONGLY recommend to also document this in the schematics. And yes - you are all correct - changing parts on a global scale would be a PITA with the method I proposed. However as the components only vary in their field values, the problem could probably be solved with a script. I'll look into this ...

I think in the end everybody has to pay a price. Either one goes fast and ugly with the default symbols and modules (which I couldn't because I would make too much errors for sure!) or pays the price in terms of hours spent ... I'll go for the latter as do electronics mainly in my spare time for fun and pleasure. Hence I can do everything to the level of precision that I like and enjoy ...
 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: ca
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #14 on: April 25, 2017, 02:24:44 AM »
OK, so specify those parts in your library and BOM.
If you leave it up to your assembly house to substitue whatever they think is a good match for your spec you could be in for trouble.
When you start having batch problems due to components they fitted you are in a world of hurt. You may not even know how many boards were produced with a particular substituted part.

At the design stage, when you are doing design for someone else, you don't even know which assembly place the customer is going to use. And then they can switch it as well. Yes it is theoretically possible that replacing part can create a problem, but in reality it does not happen very often. Did not happen to me even once on about 20+ projects currently in mass production that I designed.

Another side of the problem is that if you over-specify generic parts, you will be constantly bugged by the customer ("this resistor is out of stock! what else can we use?").
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 347
  • Country: gb
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #15 on: April 25, 2017, 02:35:55 AM »
So it looks like you are in a market where you are happy not knowing exactly what you have produced. Lucky you.
I'm not, we need documentation for every board produced along with test certs.
But we are going off topic now, these are manufacturing issues.
 

Offline ar__systems

  • Frequent Contributor
  • **
  • Posts: 317
  • Country: ca
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #16 on: April 25, 2017, 04:55:39 AM »
So it looks like you are in a market where you are happy not knowing exactly what you have produced. Lucky you.
I'm not, we need documentation for every board produced along with test certs.
But we are going off topic now, these are manufacturing issues.
Lol, I do know, various hospital equipment. Let's just say I don't care about what brand 100K pull up resistor they use, it will still work whether it is 10K or 200K ;) Of course you can specify the most expensive ones.
 

Offline homebrew

  • Regular Contributor
  • *
  • Posts: 204
  • Country: ch
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #17 on: April 25, 2017, 05:03:27 AM »
Just to show a real screw-up I managed to do as a result of lazily mapping footprints to symbols. I had two of these regulators in my design:

Component 1: TPS63001 (VSON-10) http://www.ti.com/lit/ds/symlink/tps63001.pdf
Component 2: TPS63031 (VSON-10) http://www.ti.com/lit/ds/symlink/tps63031.pdf

Although the same manufacturer, the same schematic representation in the datasheet, apparently the same series (well not really) and actually THE SAME name of the package in the overview "VSON (10)" these chips do NOT share the same footprint. Of course I wacked in the same footprint  :palm:   

It was just a prototype and the component could still be mounted somehow creatively it was not a nice experience ...

Clearly my fault - no one else to blame! But nevertheless this got me into rethinking my workflow ...
 
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 347
  • Country: gb
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #18 on: April 25, 2017, 05:50:40 AM »
Lol, I do know, various hospital equipment. Let's just say I don't care about what brand 100K pull up resistor they use, it will still work whether it is 10K or 200K ;) Of course you can specify the most expensive ones.
Your answer is nonsensical.
You cannot know exactly what you have built when you don't care whether you have fitted 50V One-Hung-Low resistors with poor quality terminations and big TC...or name brand items, IMHO.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 12419
  • Country: nl
    • NCT Developments
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #19 on: April 25, 2017, 06:44:10 AM »
There is only one way which works: a component should be split into a symbol, part information and a footprint. This is best brought together through a database. I like the initiative but please look at how Orcad Capture CIS works. Creating a correct BOM is a matter of one click with the mouse button.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: janoc

Offline julian1

  • Frequent Contributor
  • **
  • Posts: 270
  • Country: au
  • http://blog.julian1.io
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #20 on: April 25, 2017, 11:51:47 AM »
Some other sources of component variation - that don't require schematic or pcb revision might be,

- If you discover a de-rated or competitor op-amp or comparator works just as well, and decide to switch
- corresponding changes to RC op-amp compensation component values with changes to op-amps/GBW.
- different pcb fabricators with different layer thickness, means different decoupling cap choices are necessary
- different customers that have different 0R jumper configurations
- modules that are entirely populated/de-populated based on product version/need
- upgrading to better components with standard pinouts - eg. power Mosfets to take advantage of lower RDS(on)/ and heat generation - as they become available to the market and at lower prices

That's a lot of part specification to try to bake in at the schematic level or PCB level.

I have only ever used Kicad. But I think it makes sense to track the bom independently of the cad package - perhaps with date,revision,customer, board fabricator details included. That is - assuming there is enough product volume/complexity to justify the bother of tacking it in the first place.

Offline Paul Bryson

  • Contributor
  • Posts: 7
  • Country: us
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #21 on: May 17, 2017, 04:41:28 AM »
Thanks, Homebrew.  I had rejected Kicad because I thought it could not do this - i.e. tie the footprint and the manufacturer's part number to the schematic library symbol.  The typical workflow (as I understand it) used for Kicad seems so error prone - personally I find it unacceptable.  I will now reconsider using Kicad.

Specifying the footprint and part number later seems to make sense because it is modular.  But every time you use that symbol you have to risk making a mistake in choosing the wrong part number or footprint.   That is just asking for errors.  I prefer to create a schematic symbol once and never have to worry about it again.  All of the arguments against this approach seem to focus on making it easier for the designer - instead of minimizing errors.

One of the primary goals of engineering documentation is to minimize errors.  Anything unspecified can be a source of error.  I always specify specific part numbers and I do not allow contract manufacturers to make any part substitutions without written permission - even resistors. This usually involves a single communication where the CM suggests a list a substitutes which I either allow or disallow.  A small price to pay for knowing exactly how your product is built.
 
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 1764
  • Country: fr
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #22 on: May 17, 2017, 05:07:54 AM »
Specifying the footprint and part number later seems to make sense because it is modular.  But every time you use that symbol you have to risk making a mistake in choosing the wrong part number or footprint.   That is just asking for errors.  I prefer to create a schematic symbol once and never have to worry about it again.  All of the arguments against this approach seem to focus on making it easier for the designer - instead of minimizing errors.


That is why you have footprint filters in the schematic symbol. When you are creating the part, you can specify which footprints you want to permit and only those will show when selecting the footprints in CvPCB. The UI could use a bit of work, but it works. CvPCB will use that info and automatically associate the part with the footprint if there is a unique match for you. Of course, you can override it and associate any footprint, but the system isn't designed to handle users trying to break it.
 

Offline ehughes

  • Regular Contributor
  • *
  • Posts: 245
  • Country: us
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #23 on: May 17, 2017, 09:53:07 AM »
The library system is what drives me crazy about Kicad.    The developers ignore industry best practices and it will be a toy until they get out of the NIH mindset.        This idea of associating a footprint after the schematic is complete is ridiculous.   

A library *is* a database and should be treated a such.    It makes non-trivial designs manageable.         

Industry has solved this problem by using a complete manufacturer part number as a root key for a part.   This ensures a 1:1 relationship between the part and footprint.    Cases where you can substitute multiple manufacturers is handled by abstracting the part with an internal part number.     In this case you become the manufacturer as  there has been a value added step inserted into the supply chain.     This approach is the only way that has been proven to solve long term PLM/PDM issues.

This approach of course requires some engineering discipline. 


« Last Edit: May 17, 2017, 09:57:35 AM by ehughes »
 

Offline Bassman59

  • Frequent Contributor
  • **
  • Posts: 473
  • Country: us
  • Yes, I do this for a living
Re: Hacking the KiCAD Libaray system to be actually useful
« Reply #24 on: May 17, 2017, 10:50:45 AM »
Thanks, Homebrew.  I had rejected Kicad because I thought it could not do this - i.e. tie the footprint and the manufacturer's part number to the schematic library symbol.  The typical workflow (as I understand it) used for Kicad seems so error prone - personally I find it unacceptable.  I will now reconsider using Kicad.

Specifying the footprint and part number later seems to make sense because it is modular.  But every time you use that symbol you have to risk making a mistake in choosing the wrong part number or footprint.   That is just asking for errors.  I prefer to create a schematic symbol once and never have to worry about it again.

It is again worth noting that you can use Kicad without using CvPCB's symbol/footprint matching. It does require that you create and maintain your own libraries, but that's standard for professional use anyway.

When you create symbols for your schematic libraries, populate the footprint field. Also create a custom "part number" field which you should populate with manufacturer part number, or perhaps house part number which would be a key into an external database.

Once you do this, you're on your way. You vet your parts as you create the symbols (and possibly footprints, if they don't already exist), so you know that when you place a part on a schematic, you know it has the correct footprint, a correct part number for your BOM, and there is no need to re-do that every single time you do a design.

I agree with ehughes below -- a proper database-driven library system would be a boon to professional users who find such a thing necessary. The question is, who will architect it and implement it?

Quote
All of the arguments against this approach seem to focus on making it easier for the designer - instead of minimizing errors.
I think that the arguments against this approach seem to focus on making it easier for the hobbyist who doesn't care about maintaining a rational parts inventory system. The voices of support for CvPCB seem to be very loud, though.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf