kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/08/2010 03:36 AM, Martijn Kuipers wrote:
> On Oct 8, 2010, at 8:00 AM, Dick Hollenbeck wrote:
>
>   
>> I got my mind around the parts list tonight.
>>
>> Conceptual clarifications below:
>>
>>
>>     
>>> The component is located and rotated [and mirrored] when it is
>>> instantiated within a part.
>>>
>>>
>>> class PART
>>> {
>>>    COMPONENT* component        // points into the parts list
>>>
>>>    POINT pos;
>>>
>>>    wxString  reference;
>>>
>>>    int angle;
>>> }
>>>
>>>
>>>       
>>
>> The class PART needs to have the (x,y,angle) coordinates for the fields,
>> which reside in the parts_list components.  So you can move the fields,
>> but not edit them.
>>
>> You want unique fields? Then make a new parts list entry.
>>
>> This ensures the BOM falls out clean as a whistle.
>>
>>
>> class FIELD_USAGE
>> {
>>    int xoffset;
>>    int yoffset;
>>    int angle;
>>    bool visible
>>    font type ?
>>    color ?
>> }
>>
>>
>> Add a std::vector<FIELD_USAGE>  to class PART above.  This gives you an
>> instantiation specific ability to move the fields, spin them, hide them,
>> and change font.  You cannot change the field values in the instance,
>> except for the reference, which is technically no longer a field.
>>
>>
>>
>>
>> Parts List, further clarifications:
>> ----------------------------------
>>
>> A parts list is an internal spread sheet, with columns, and has a
>> spreadsheet UI in eeschema.
>>
>>
>> The columns dictate the fields within all the components in the parts list.
>> If a user adds a column, all components get that field in the same
>> sequence.  All fields are in the same sequence.  All components have the
>> same number of fields.
>>
>> Some columns are mandatory to mimic the current mandatory fields.
>>
>> We add a new boolean mandatory field called DNS. It only takes true or
>> false as a value, say a check box.
>>
>> The parts list is a spreadsheet, with columns.  It is is a library
>> source, but for this particular schematic, it is an instantiation factory.
>>
>> Nothing can be instantiated in a schematic that is not in the parts list.
>>
>> All schematic pages/sheets are in one file, along with the parts list.
>>
>> Fields cannot be inherited as they are dragged from another library
>> source into the parts list, they are copied, along with their initial
>> values.  So the sweet little language we have been dreaming up cannot
>> support (field_delete) or (field_swap) or anything like that with
>> respect to fields.
>>
>> Why?
>>
>> The only fields that are actually in affect at any point in time are
>> those belonging to components in the parts list.  Because you cannot
>> instantiate anything else.  You first have to drag your component into
>> the parts list.  The origin can be any library or another row in the
>> same parts list.  The latter situation arises when you have multiple
>> resistor values and want the same resistor symbol but with a different
>> value.  Using the spread sheet UI, you can add fields instantaneously to
>> all components in the parts list simply by adding another column.
>>
>> When the parts list is saved as part of the schematic, you see a region
>> in the massive, multi-sheet schematic file called a parts_list:
>>
>> (parts_list
>>  (columns   # superimposed onto all components contained, as user defined fields
>>    (column Optional1)
>>    (column Optional2)
>>  )
>>  (library
>>    (component (stuff true) (field datasheet rj11.pdf) (field value RJ11)..(field Optional1 digikey) (field Optional2 ABC))
>>    (component (stuff true) (field datasheet Yageo.pdf) (field value 33ohm) (field Optional1 mouser) (field Optional2 DEF))
>>  )
>> )
>>
>>
>> The coolest thing about the parts list, other than direct BOM creation,
>> is that you will probably use them to house your library source(s).  You
>> can create a dummy schematic, maybe use sheets therein to categorize
>> visible instances of the components within the parts list.  That dummy
>> schematic can then be loaded as a library source while editing a
>> functional other schematic file, but the first is a read only library
>> source in such a situation.
>>
>>
>> This was the last conceptual hole that I had to fill.  If you can
>> already see that I am missing something that will lead to this being
>> unworkable, please yell.  I will start on the *.h file soon.  It might
>> shine light on other holes, but also make things clearer for some.
>>
>>
>> Dick
>>     
>
> My understanding is that a:
> - components are those things you find in the catalogues, e.g., 74LS00
> - parts are those things you find in your schematic, e.g., IC1 (which could be 74LS00)
>   

Well the eeschema generic XML export uses components for the stuff in
the schematic, and parts in the library.

I just wanted to be sure we were not contradicting ourselves (too much).

How much is too much?  When folks start demanding their money back, I
guess, or asking too many questions.


> Perhaps we should not talk about parts-list, but use BOM instead.
>   

This certainly would be easier, less typing.  But it would be like
calling a recipe a meal.  Using a recipe to create a meal is only one
usage of a recipe. 
In English, the term "parts list" is actually quite common, and extends
well outside the realm of electronics.  Bill of Materials is a more
restricted term that comes into play when you are about to buy something.


> Perhaps you already mentioned this, but I just did not understand it.
> There is a base-component library. 

Yes, any number of component libraries.  But on this thread of this
mailing list, a library is a memory cache.  Can we also talk about
library sources? 

Components flow from a library source into a library (the memory
cache).  When in the cache, they are instantaneously available.

> These are just files with components, 

There were 5 library sources mentioned, maybe you can find that posting.

> that are maintained at kicad-website, but it is ok to have a local copy. Since this is a central repository, local copies are read-only or you will loose all additional information on an update.
>   

Yes.
> Is there a way to maintain local information with the components that is not lost after an update? Is this even possible? I think it is.
>   

You can do that several ways.  You can have a library source that is a
file directory with individual component files in them.  A component
file will typically inherit from a particular version of the kicad
supplied component.

(component R33 extends GUID
   (value 33ohm)
   (field Manufacturer Yageo)
)


The disk file might actually be that small.  Now you have your own R33
component in your library source.


GUID is a place holder for something like kicad:passives/R/rev279

All the sexpr keywords are lower case.  So if you see an uppercase
letter in any of these examples, you know it is a variable, not a keyword.

Lets plugin a real value for the place holder called GUID:


(component R33 extends kicad:passives/R/rev279
   (value 33ohm)
   (field Manufacturer Yageo)
)

That's now a real component file in your library source.


"kicad:" points to the library source, passives is a navigator within
the source, R is the component you are inheriting, and rev279 is
specific version you are dependent on.


"kicad" is a logical library name, you will be given a table on your
disk that maps that to a LIBRARY_SOURCE mechanism used to fill a LIBRARY
cache, a cache dedicated to handle only "kicad:" in any GUID.


So you now have a better R called R33 and in *your* library source,
which has say a logical name "mylib".


You have to drop the R33 into your parts list, which resides as a
spreadsheet in your schematic.  At that time you can further extend it to:

(component R33 extends mylib:R33
  (footprint 0805)
  (field Vendor digikey)
)

mylib:R33 is a GUID also.

"mylib" is like kicad in the previous GUID, it points to a different
LIBRARY cache.

mylib points to a LIBRARY cache filled by a LIBRARY_SOURCE which reads
from your library directory on your disk.

In this example the "value" was assigned in your myulib library source. 
A more common case would be to assign "value" after you drop the
component into your parts list.

But in truth I don't think it matters, because once in the spreadsheet,
you can copy a row and give the component a new name. All rows need a
unique component name, other than R33. Once you have copied the row to a
new name, say R100, you can then assign a new value there also.  You
have changed the value in the parts list copy (of a copy of a copy).


> I have my preferred footprints with most components, so it would be nice if I could add the preferred footprint property to a component. I could even add properties, such as supplier art-number and price (together with a date).  Of course, this makes only sense to have locally...
>   

Can be done in the parts list spreadsheet.

> Following the discussion, I would derive my personal components (personal library) from the centrally controlled one. When using the component I even could get a warning asking if I want the updated base component, or the one I was using for my personal component.
>   

Ug, warnings, it was not planned.  There are no updates in this example
since we have pegged the inherited (i.e. extended) part to rev279. 
rev279 was once good enough, it should always be good enough.

Other, newer parts that you extend can use newer versions.  And I think
you can leave off the /revXYZ meaning take the newest.  If you do this,
it leaves you vulnerable to changes in the kicad libary source. 


> Probably you just parse the base-components first and then the personal ones. 

Yes.  And the kicad components are read only, and won't ever change
within a specific revision.

> You could even have a switch to show personal and base components if the are the same (i.e., only show derived components or show all).
>   

I'll leave that for you to code.

> Again, perhaps this is what you want to do. I was not clear to me, but this could be useful (for me personally).
>   

For me too.

> Also, will there be 2 copies of the derived component? One sparse-version (with only the additions/changes to the base-component) and one flat one to be used in the BOM for the particular project 

s/project/schematic/   # pcbnew is not part of this discussion.

> (schema/pcb) ?
>   


Yes, there can be, and in the example above there was.  However, you can
put something into your parts list that comes directly from the kicad
library, skipping the intermediate mylib.


(parts_list
 (columns....)

(library

(component R33 extends kicad:passives/R/rev279
   (value 33ohm)
   (footprint 0805)
   (field Manufacturer Yageo (at...) )
   (field Vendor digikey (at...) )
)

))


It might be that 3rd party has a LIBRARY_SOURCE that is also remote, or
it could be an inhouse corporate resource.


> Thanks for putting your efforts on Kicad. It has taken some great leaps in the last years.
>   


Thanks for thanking.   Frankly, the ROI is too low to be sure we'll get
all this done. 

But my goal is to break it up into well documented byte (oops bite)
sized pieces that can be coded by any of a number of folks.  And we have
not even begun to talk about the UI behaviors yet.  Keeping the UI easy
to use will require a lot of thought.  But I feel that the underlying
document models will hold water, at least conceptually.


Dick

P.S. I was reminded while writing this about the need for uniquely named
rows in the parts list.  This means we'll have to move the "stuff" (aka
DNS) attribute into the component instance, class COMPONENT in previous
emails, and out of the parts list.  I had contemplated two parts list
entries for a stuffed and not stuffed version, but that looks silly now.