kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/23/2010 10:43 AM, Brian Sidebotham wrote:
> On 23 September 2010 01:35, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> On 9/22/2010 10:25 AM, Lorenzo Marcantonio wrote:
>>> On Wed, 22 Sep 2010, Dick Hollenbeck wrote:
>>>
>>>> A) I don't find alias support to be particularly valuable, especially in
>>>> the presence of good library browsing capability.
>>>
>>> I actually like it a lot, since I can skip a rename (i.e. 1N4004 alias
>>> for DIODE). Any other kind of indirection, or sharing would be likely
>>> useful if aliasing were considered too 'primitive'.
>>
>> There is nothing preventing you from creating a generic DIODE component.
>>  With proper cut and paste, simply copy the DIODE component and paste it
>> into a library as 1N4004.  You get the best of both worlds.  The
>> advantage of components is that you can define all the relevant fields
>> such as footprint to eliminate the need to us CvPCB to assign footprint
>> to each component.  You could even create manufacturer specific
>> component libraries that include URL's to the data sheets and spice
>> models.  You currently cannot do this with aliases.
> 
> I am also thinking that alias's could be removed. As above, you can
> currently do this copy by opening the generic DIODE component and then
> editing it's value.
> 
> This means that a library of resistors would not have a common symbol
> to edit in order to change all of the component symbols. (I think I
> got the terminology correct there!?). However, most libraries that are
> heavy and contain derivatives of a common part will be generated by
> script anyway. It's very easy to setup a script to do this.
> 
> Previously it was a problem (or psuedo problem) that the value +
> component name fields were inexplicably tied together, but with the
> default fields now available I do not think this is a problem for a
> heavy library system anymore. The value can be the component name
> (e.g. RES_3K3_1206_1PC, etc.) and another field can be used to hold
> the actual value units. The XML intermediate file format for BOM's
> makes that much more workable now. So I think that could stay as is.
> 
>>>
>>>> B) EESCHEMA's library browser needs to be strong.
>>>
>>> At least for picking a part to edit. Is ridiculous to use the browser
>>> and then type the name in the editor.
>>>
>>>> C) Copying is not sharing.  Sharing is when a single edit affects
>>>> multiple parts.  There is not a significant value in "sharing" graphical
>>>> symbols between part specific components, particularly if it were
>>>> possible to simply copy a graphical symbol through the clipboard.
>>>
>>> Sharing is useful for consistency IMHO.
>>
>> Copy and paste minimizes the need for shared components.  Since the
>> library files are plain text, global search and replace in your favorite
>> text editor can be used to make changes to a library with a lot of
>> identical component drawing definitions.
>>
> 
> The only thing to mention about sharing is that it can have an
> advantage, and is the only positive I can think of for aliases. Again
> it is due to a heavy library system. Take for example a library of
> resistors which perhaps contains one parent symbol which has the
> graphical elements of a resistor and a datasheet reference for the
> resistor family, and a list of aliases with different values +
> manufacturer part numbers.

I don't see how aliases can be used for heavy libraries.  Aliases do not have
fields (unless you count the information in the document file) so you cannot
assign different default or user specified field values to them.  Once you add
field support to aliases, you have effectively made them components.  As you
mentioned above, most heavy libraries would be generated by scripts or copy and
paste so any advantage of sharing a symbol largely negated.

> 
> In the schematic, to change the value of a resistor with such a heavy
> library system you need to delete the part, and select another part to
> replace it because other meta data like the manufacturers part number
> will change with the value. With the aliases, it would be possible to
> introduce a substitution rule where changing the value could keep the
> part up to date, or warn that the value is unavailable. Without
> aliases, changing the value of discrete components like this is going
> to be much more cumbersome in heavy library's.

Resistor may not the best example here because it is more likely that you will
use many different resistor values and sizes depending on your design requiring
you to often change the value and footprint fields.  I think this falls under
user preference.  Some folks prefer heavy weight libraries ( fully attributed
components such as R_220K_0805 ) and some prefer light weight libraries(
minimally attributed components such as R ).  I can even envision using both
depending on the type of component.  The advantage of using heavy weight
libraries is most if not all of the field information would be copied into the
schematic eliminating the need to add it manually.  The disadvantage of using
heavy weight libraries is most if not all the field information would be copied
into the schematic requiring you to change it when it is not exactly the
component you want. The beauty of using components is that both use patterns
can be satisfied without adding unnecessary complexity.

Wayne

> 
> It is likely though that this problem could be overcome in other ways
> that do not require the use of aliases. It could for example be a
> library flag that is set to indicate that all parts in the library are
> interchangeable. Like I say, most of these types of library's will be
> generated by script anyway, and not by hand.
> 
> Best Regards,
> 
> Brian.
>