kicad-developers team mailing list archive

[Manveru <manveru@...>]

--0015175dda9a11b34e04783c8159 Content-Type: text/plain; charset=UTF-8

2009/11/13 Wayne Stambaugh <stambaughw@...>

>
>
> [...]
>
> Brian,
>
> Thanks for the explanation of heavy versus light libraries. I wasn't
> getting this (I'm a little slow sometimes) from some of the previous
> posts. The weakness I see in this is if for any reason your had to
> change the base component symbols, you would have to update the entire
> library as opposed just changing the library root component. Also the
> libraries could become huge (potentially 10s of thousands of parts for
> resistor and capacitor libraries) which would significantly impact
> performance and memory use. You have also effectively made field 5 a
> part number field which may not work for everyone else. You solution
> sounds like it is better suited for creating user specific component
> information as opposed to a robust set of component libraries that would
> ship with Kicad. I understand what it is you are trying to accomplish.
> I have the same problems when I create BOMs. I am just not sure that
> this is the best way to attack the problem. Maybe this is where some
> type of database implementation would be useful that some of the other
> developers have suggested. That way all your local information, part
> numbers, manufacturers, vendors, cost, etc. would be independent of the
> actual component libraries themselves. If you could separate it out
> that way or by some other method, it would probably be easier for other
> to accept.
>
> Wayne
>
>
I would like to see such functionality as separate tool - it should allow to
manage the parts inventory according to part number and values (for discrete
parts). So it should allow to match netlist/BOM with part numbers from the
suppliers with exact part used on schematics - so you enter such data once,
and you have it. In case of library update the relation between part name
and value and suppliers part name would not change. It is worth consider
adding such tool to KiCad suite.

Going further we can imagine far future, where for example Digikey delivers
the database containing part numbers from their data base matched to part
name (standardized) and value (f.e. resistance). This could be web service
with query/response API.

-- 
Manveru
jabber: manveru@...
gg: 1624001
http://www.manveru.pl
 --0015175dda9a11b34e04783c8159 Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2009/11/13 Wayne Stambaugh <span dir=3D"=
ltr">&lt;<a href=3D"mailto:stambaughw@...";>stambaughw@...</=
a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1p=
x solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">













<div style=3D"background-color: rgb(255, 255, 255);">
<span>=C2=A0</span>


<div>
<div>


<div>
=20=20=20=20=20=20
=20=20=20=20=20=20
<p></p><div><div></div><div class=3D"h5">[...]<br>
<br></div></div>
Brian,<br>
<br>
Thanks for the explanation of heavy versus light libraries. I wasn&#39;t<b=
r>
getting this (I&#39;m a little slow sometimes) from some of the previous<br=
>
posts. The weakness I see in this is if for any reason your had to<br>
change the base component symbols, you would have to update the entire<br>
library as opposed just changing the library root component. Also the<br>
libraries could become huge (potentially 10s of thousands of parts for<br>
resistor and capacitor libraries) which would significantly impact<br>
performance and memory use. You have also effectively made field 5 a<br>
part number field which may not work for everyone else. You solution<br>
sounds like it is better suited for creating user specific component<br>
information as opposed to a robust set of component libraries that would<br=
>
ship with Kicad. I understand what it is you are trying to accomplish.<br>
I have the same problems when I create BOMs. I am just not sure that<br>
this is the best way to attack the problem. Maybe this is where some<br>
type of database implementation would be useful that some of the other<br>
developers have suggested. That way all your local information, part<br>
numbers, manufacturers, vendors, cost, etc. would be independent of the<br>
actual component libraries themselves. If you could separate it out<br>
that way or by some other method, it would probably be easier for other<br>
to accept.<br>
<br>
Wayne<br>


</div><br></div></div></div></blockquote></div><br>I would like to see =
such functionality as separate tool - it should allow to manage the parts i=
nventory according to part number and values (for discrete parts). So it sh=
ould allow to match netlist/BOM with part numbers from the suppliers with e=
xact part used on schematics - so you enter such data once, and you have it=
. In case of library update the relation between part name and value and su=
ppliers part name would not change. It is worth consider adding such tool t=
o KiCad suite.<br>
<br>Going further we can imagine far future, where for example Digikey deli=
vers the database containing part numbers from their data base matched to p=
art name (standardized) and value (f.e. resistance). This could be web serv=
ice with query/response API.<br clear=3D"all">
<br>-- <br>Manveru<br>jabber: <a href=3D"mailto:manveru@...";>manveru=
@manveru.pl</a><br> =C2=A0 =C2=A0 gg: 1624001<br> =C2=A0 <a href=3D"http://=
www.manveru.pl">http://www.manveru.pl</a><br>
 --0015175dda9a11b34e04783c8159--