kicad-developers team mailing list archive

[Martijn Kuipers <martijn.kuipers@xxxxxxxxx>]

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)

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

Perhaps you already mentioned this, but I just did not understand it.
There is a base-component library. These are just files with components, 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.

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.

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

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.

Probably you just parse the base-components first and then the personal ones. 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).

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

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 (schema/pcb) ?

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

/Martijn

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