kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@...>]

2009/11/12 Wayne Stambaugh <stambaughw@...>:
> jean-pierre.charras@... 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"
...