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"
> ...
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
