kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre charras - INPG wrote:
> 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"
>>> ...
>> 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
>>
> 
> 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 ?
> 
> Advantages:
> - 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 
> other.
> 
> Have a look to these .equ files that can be found in the modules 
> repertory ( and are created by a text editor)

JP,

Great information. Is this documented anywhere? If not, it needs to
put somewhere in the documentation. I've seen equ and stf files before.
I never really understood what they were used for.

Wayne