Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » KiCAD
  • » [Kicad-developers] library structure [RSS Feed]

#1 Sept. 22, 2010 14:58:27

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


I'd like to emphasize:

1) the need to think this through now, right when we are contemplating a
new file format, and

2) we need to define terms early, so we can actually have a conversation
that can be understood.


-------------


My opinions, for a program like EESCHEMA in general:

A) I don't find alias support to be particularly valuable, especially in
the presence of good library browsing capability.

B) EESCHEMA's library browser needs to be strong.

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.

D) Project specific library support is important, and could be the
domain where symbols become part specific.


----------

To me, 2) should be our highest priority, and it could almost read like
a few entries from a dictionary.


Dick



_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#2 Sept. 22, 2010 15:25:27

Lorenzo M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


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'.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.D) Project specific library support is important, and could be the
domain where symbols become part specific.I simply classify special part when the need arise. Why make it project
specific if I can use it next week on another thing?

--
Lorenzo Marcantonio
Logos Srl

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#3 Sept. 22, 2010 17:50:01

Karl S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


Dick Hollenbeck wrote:My opinions, for a program like EESCHEMA in general:

A) I don't find alias support to be particularly valuable, especially inthe presence of good library browsing capability.I agree - but SPICE-heads might still want this?B) EESCHEMA's library browser needs to be strong.For the record, I spend more time making/tweaking lib parts and modules than any other task whilecreating a PCB. I imagine some libraries that specialize in symbols, others for parts and stillother for spice.C) Copying is not sharing.Thus an edit of a part within eeschema/edit_component needs three options - this part only, thisschematic only, and update the lib?What if a part field can be of two types - a file pointer for doc files or just text? A filepointer could start with some special character or a button?(is the Datasheet field connected to anything at all right now? )






Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#4 Sept. 23, 2010 01:09:55

Wayne S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


On 9/22/2010 9:58 AM, Dick Hollenbeck wrote:
>
> I'd like to emphasize:
>
> 1) the need to think this through now, right when we are contemplating a
> new file format, and

Since I already have a preliminary component library file format
document nearly complete, now would be a good time to get as much input
up front as possible to prevent wasting time and effort doing things over.

>
> 2) we need to define terms early, so we can actually have a conversation
> that can be understood.

I suggest we use the term symbol to reference what we currently refer to
as a component and use component to reference what we currently refer to
as an alias. I think it more accurately describes the current file
format and certainly anything I would propose for the new file format.
I always felt the term alias was not very clear. To me 74LS00, 74HCT00,
7400, etc. are components. I've never used a 74HCT00 alias on a board
before. I like the term symbol to represent how a component is drawn
including pins, lines, arcs, etc. Until we agree on terminology, I
suggest we continue to use the terms alias and component as they are
currently defined to avoid confusion.

>
>
> -------------
>
>
> My opinions, for a program like EESCHEMA in general:
>
> A) I don't find alias support to be particularly valuable, especially in
> the presence of good library browsing capability.

Doing away with the concept of aliases would certainly simplify the code
for component library and component object. The current design of
having multiple aliases referencing a single component makes adding them
to and removing them from the library way more complicated than it
should be. I also think it would be clearer to the user.

>
> B) EESCHEMA's library browser needs to be strong.
>
> 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.

If we implement proper copy and paste into the component library editor,
supporting shared components becomes much less important. The down side
is that it will make the file size larger. Given that the typical hard
drive size for a laptop is 500MB I just don't see that as an issue.

>
> D) Project specific library support is important, and could be the
> domain where symbols become part specific.
>
>
> ----------
>
> To me, 2) should be our highest priority, and it could almost read like
> a few entries from a dictionary.

I have a few:

symbol - The graphical and/or electrical representation of a component.
Think everything between DRAW/ENDDRAW in the current file format.

field - The default and user defined text values that describe a
component such as value, reference designator, footprint, etc.

component - The combination of default and user defined fields and a
symbol that get imported into a schematic.

library - One or more components along with some meta-data to describe
the library.

Wayne

>
>
> Dick
>
>
>
> _______________________________________________
> Mailing list:https://launchpad.net/~kicad-developers> Post to : kicad-develop***@*ists.launchpad.net
> Unsubscribe :https://launchpad.net/~kicad-developers> More help :https://help.launchpad.net/ListHelp>

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#5 Sept. 23, 2010 01:36:12

Wayne S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


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.

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

Wayne

>
>> D) Project specific library support is important, and could be the
>> domain where symbols become part specific.
>
> I simply classify special part when the need arise. Why make it project
> specific if I can use it next week on another thing?
>

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#6 Sept. 23, 2010 07:17:43

jean-pierre c.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


Le 23/09/2010 02:09, Wayne Stambaugh a écrit :On 9/22/2010 9:58 AM, Dick Hollenbeck wrote:I'd like to emphasize:

1) the need to think this through now, right when we are contemplating a
new file format, andSince I already have a preliminary component library file format
document nearly complete, now would be a good time to get as much input
up front as possible to prevent wasting time and effort doing things over.2) we need to define terms early, so we can actually have a conversation
that can be understood.I suggest we use the term symbol to reference what we currently refer to
as a component and use component to reference what we currently refer to
as an alias. I think it more accurately describes the current file
format and certainly anything I would propose for the new file format.
I always felt the term alias was not very clear. To me 74LS00, 74HCT00,
7400, etc. are components. I've never used a 74HCT00 alias on a board
before. I like the term symbol to represent how a component is drawn
including pins, lines, arcs, etc. Until we agree on terminology, I
suggest we continue to use the terms alias and component as they are
currently defined to avoid confusion.I also like terms symbols ( for drawings description only )
and components (to define a library item having specific fields values: name,
value users fields, links to docs, key word..)Besides, currently libedit can export/import drawings description already called symbols in doc(the .sym files which are librariescontaining one component). So using symbol has more sense.--
Jean-Pierre CHARRAS




_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#7 Sept. 23, 2010 09:13:56

Martijn K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote:
> symbol - The graphical and/or electrical representation of a component.
> Think everything between DRAW/ENDDRAW in the current file format.
>
> field - The default and user defined text values that describe a
> component such as value, reference designator, footprint, etc.
>
> component - The combination of default and user defined fields and a
> symbol that get imported into a schematic.
>
> library - One or more components along with some meta-data to describe
> the library.
>


When drawing a schematic everything is easy when using components, especially
using user-defined libraries. Does this mean that Kicad will ship with a large
set of (component-) libraries? Or, will every user need to start creating his
own, from symbols (is there a symbol-library foreseen?)?

Will the component-library also have a reference to (default) footprint(s)?
Related to this, if a component is available with different footprints are they
different components, or the same component with a reference to multiple
footprints? If the latter is true, then one could easily choose another
footprint in newPCB, for instance.

/Martijn
P.S. What is the preferred option regarding the mailing-list. Do I reply to the
author and CC the list or just reply to the list (if someone is not subscribed
to should then ask to be CC-ed) ?





_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#8 Sept. 23, 2010 13:29:45

Wayne S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


On 9/23/2010 4:12 AM, Martijn Kuipers wrote:
>
> On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote:
>> symbol - The graphical and/or electrical representation of a component.
>> Think everything between DRAW/ENDDRAW in the current file format.
>>
>> field - The default and user defined text values that describe a
>> component such as value, reference designator, footprint, etc.
>>
>> component - The combination of default and user defined fields and a
>> symbol that get imported into a schematic.
>>
>> library - One or more components along with some meta-data to describe
>> the library.
>>
>
>
> When drawing a schematic everything is easy when using components, especially
> using user-defined libraries. Does this mean that Kicad will ship with a
> large set of (component-) libraries? Or, will every user need to start
> creating his own, from symbols (is there a symbol-library foreseen?)?

I doubt Kicad will ever ship with a large set of manufacturer specific
component libraries. I think the main goal is to provide a quality set of
generic libraries and hope that as users create more complete component
libraries that they make them freely available for others use and/or modify.
Once these libraries mature, they could be added to the list of libraries
included with Kicad. As for symbol only libraries, I'm not sure we will need
them if we provide copy/paste into the component library editor.

>
> Will the component-library also have a reference to (default) footprint(s)?
> Related to this, if a component is available with different footprints are
> they different components, or the same component with a reference to multiple
> footprints? If the latter is true, then one could easily choose another
> footprint in newPCB, for instance.

I don't see any reason why the footprint field could not used to define wild
cards for pattern matching or multiple footprints when creating generic
components such as 7400 or RESISTOR similar to what we have already. You could
just as easily create manufacture specific component using the full part number
as the value field which would be tied to a specific footprint.

>
> /Martijn
> P.S. What is the preferred option regarding the mailing-list. Do I reply to
> the author and CC the list or just reply to the list (if someone is not
> subscribed to should then ask to be CC-ed) ?

Generally speaking you should reply to the list. I only email someone directly
regarding a matter that does not require input from all the Kicad developers.

Wayne

>
>
>
>
>

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#9 Sept. 23, 2010 13:35:27

Martijn K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


On Sep 23, 2010, at 13:29 PM, Wayne Stambaugh wrote:

> On 9/23/2010 4:12 AM, Martijn Kuipers wrote:
>>
>> On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote:
>>> symbol - The graphical and/or electrical representation of a component.
>>> Think everything between DRAW/ENDDRAW in the current file format.
>>>
>>> field - The default and user defined text values that describe a
>>> component such as value, reference designator, footprint, etc.
>>>
>>> component - The combination of default and user defined fields and a
>>> symbol that get imported into a schematic.
>>>
>>> library - One or more components along with some meta-data to describe
>>> the library.
>>>
>>
>>
>> When drawing a schematic everything is easy when using components,
>> especially using user-defined libraries. Does this mean that Kicad will ship
>> with a large set of (component-) libraries? Or, will every user need to
>> start creating his own, from symbols (is there a symbol-library foreseen?)?
>
> I doubt Kicad will ever ship with a large set of manufacturer specific
> component libraries. I think the main goal is to provide a quality set of
> generic libraries and hope that as users create more complete component
> libraries that they make them freely available for others use and/or modify.
> Once these libraries mature, they could be added to the list of libraries
> included with Kicad.
That was what I was hoping for.


> As for symbol only libraries, I'm not sure we will need
> them if we provide copy/paste into the component library editor.
Sounds good.

>
>>
>> Will the component-library also have a reference to (default) footprint(s)?
>> Related to this, if a component is available with different footprints are
>> they different components, or the same component with a reference to
>> multiple footprints? If the latter is true, then one could easily choose
>> another footprint in newPCB, for instance.
>
> I don't see any reason why the footprint field could not used to define wild
> cards for pattern matching or multiple footprints when creating generic
> components such as 7400 or RESISTOR similar to what we have already. You
> could
> just as easily create manufacture specific component using the full part
> number
> as the value field which would be tied to a specific footprint.
Ok.

>
>>
>> /Martijn
>> P.S. What is the preferred option regarding the mailing-list. Do I reply to
>> the author and CC the list or just reply to the list (if someone is not
>> subscribed to should then ask to be CC-ed) ?
>
> Generally speaking you should reply to the list. I only email someone
> directly
> regarding a matter that does not require input from all the Kicad developers.
Done!

Thanks,
Martijn
_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#10 Sept. 23, 2010 15:43:27

Brian S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] library structure


On 23 September 2010 01:35, Wayne Stambaugh <stambau***@*erizon.net> 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.

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.

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.

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

  • Root
  • » KiCAD
  • » [Kicad-developers] library structure [RSS Feed]

Board footer

Moderator control

Enjoy the 23rd of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support