← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema library editor - seperate value + name


Wayne Stambaugh a écrit :

Brian Sidebotham wrote:
> 2009/11/12 Wayne Stambaugh <stambaughw@verizon. net <mailto:stambaughw%40verizon.net>>: >> jean-pierre. charras@gipsa- lab.inpg. fr <mailto:jean-pierre.charras%40gipsa-lab.inpg.fr> wrote:
>>> Brian Sidebotham a écrit :
>>>> Hi Everyone,
>>>> I want to provide a patch to seperate the use of "Name" and "Value" in
>>>> eeschema's library editor for a couple of reasons:
>>>> (1) It is confusing.
>>>> (2) The library format, as Wayne pointed out can support these two
>>>> things seperately and indeed eeschema does.
>>> In fact, "Name" and "Value" are confusing because in Libedit there is no
>>> value (or, if you prefer, name and value are the same thing).
>>> Only Name is relevant, and the field "Value" must be replaced by "Name"
>>> The change that must be done is just change Value to Name in the Libedit
>>> dialog editor.
>> Brian,
>> JP has the right idea here. Just don't expose the value field to the
>> user as it has no meaning to the library editor. If you need to clarify
>> the source code for developers, add a Doxygen comment to the m_Name
>> member in "class_libentry. h". There may also be some other places (
>> message panel for instance ) where it is also referred to as "value"
>> instead of "name". If you happen to find any other places where this
>> occurs, please change the wording to "name" to avoid any confusion.
>> Keep up the good work. This is the kind of refinement that makes for
>> better user experience.
>> Wayne
>>> Of Course, in schematic, the name refers to the library component (said >>> resistor, or NPN ...) and is used to retrieve the component description >>> (shape) in library, and the value is specfic to an instance of the given
>>> component in schematic.
>>> Or, if we are talking in C++, the Value/Name in libedit is the name of a >>> given class, and the Value is (in schematic) the name of an instance of
>>> this class.
> Thank you for taking the time to respond. Firstly sorry for the long
> email that follows!
> If the value is not exposed seperately to the name it prevents KiCAD
> from supporting heavy symbol libraries. I appreciate that most people
> seem to prefer a light symbol library as this is easiest for DIY and
> small projects.
> A heavy symbol library would have all parts and values defined, and a
> light symbol library would have a generic resistor symbol where the
> package and/or the resistance is filled in from the schematic. From
> your analogy JP, a heavy symbol library would mean that I want a
> different class for every resistor type and every resistor value for
> those types. It is not called a heavy system for nothing it would
> seem!
> To explain my situation a bit further, I can give you an outline
> example. We use several dialectrics of capacitor, lets say NPO, X5R,
> X7R and Y5V. In our inventory we stock we these capacitors, and hence
> you can imagine that there are a lot of part numbers. I prefer to use
> the heavy "symbol library" mentality to get around the headache of
> trying to work out the part numbers after schematic entry is complete.
> I want to edit the schematic so that the schematic has all the
> information I require.
> If I do another revision of the board, I want to press the BOM button
> and get the right results for stores to kit the components. I don't
> want to go through the hassle of having to manually edit the BOM to
> include information again; and I certainly don't want to try and input
> our part numbers into the schematic for every component!
> Further to this, a resistor library would contain a part number for
> every resistor in the series. All resistors in the library would have
> a footprint and company part number defined.
> Lastly, I realise that I may be the only person to use KiCad that
> wants to use a heavy symbol system. But the file format can support it
> and I'm sure the code virtually supports it already, it just needs a
> few tweaks to seperate the two fields in the library editor.
> Below is an extract from a heavy symbol library that I think should
> work (I removed the drawing sections as they are a bit needless):
> #
> # CX7R_0805_100R
> #
> DEF ~CX7R_0805_100R C 0 0 N N 1 F N
> F0 "C" 0 100 50 H V C CNN
> F1 "100R" 0 -300 50 H I C CNN
> F2 "C0805" 0 -200 50 H I C CNN
> F5 "SMT-4078-1001" 0 -400 50 H I C CNN "PN"
> ...
> #
> # CX7R_0805_1K
> #
> DEF ~CX7R_0805_1K C 0 0 N N 1 F N
> F0 "C" 0 100 50 H V C CNN
> F1 "1K" 0 -300 50 H I C CNN
> F2 "C0805" 0 -200 50 H I C CNN
> F5 "SMT-4078-1002" 0 -400 50 H I C CNN "PN"
> ...
> #
> # CX7R_0805_10K
> #
> DEF ~CX7R_0805_10K C 0 0 N N 1 F N
> F0 "C" 0 100 50 H V C CNN
> F1 "10K" 0 -300 50 H I C CNN
> F2 "C0805" 0 -200 50 H I C CNN
> F5 "SMT-4078-1003" 0 -400 50 H I C CNN "PN"
> ...
> #
> # CX7R_0805_100K
> #
> DEF ~CX7R_0805_100K C 0 0 N N 1 F N
> F0 "C" 0 100 50 H V C CNN
> F1 "100K" 0 -300 50 H I C CNN
> F2 "C0805" 0 -200 50 H I C CNN
> F5 "SMT-4078-1004" 0 -400 50 H I C CNN "PN"
> ...


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.


Schematic libraries handle ALIASes of basic components (called ROOT components)
Aliases can be seen has a derived class of the root component.
They share the component shape and, at this time, all fields but value/name.

This is a good way to spare space and time to create them.

They are owner of the their keyword and the documentatoon file.

So if we want to have a separate Name and Value, alias handling must also modified
(to make them owner of these fields)

Because the .DCM file that store the alias data must be merged with the .lib file, this other change could be a good enhancement. But just modify the Root component to separate Name and Value does not work currently for aliases.
(And for this problem, aliases are very useful )

But an other method could be a retroannotation.
This feature exists in Eeschema to fill the footprint field using a .stf file created by Cvpcb from info in the .equ files. Moreover, Cvpcb is able to automatically associate components and footprints from these files (in fact the .stf is a .equ file with only the relevant dato for the current schematic)

Could be used for others fields ?

- this kind of file is easy to create for a given application, and is very short - It is easy to modify for and other application or by an other guy to change (for all component) dealers or other info
- The full schematic can be easily updated by re-reading a .stf file
for instance I created 2 .equ files: one when i am using SMD components and one for usual components.
From the same schematic, i can easily switch from a technology to the

Have a look to these .equ files that can be found in the modules repertory ( and are created by a text editor)

Jean-Pierre CHARRAS
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
Grenoble France

Follow ups