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

/Martijn


These are good questions.  I will answer them when I have more time.

Email is a far cry from a conference room situated brainstorming session.

Sometimes the reading is difficult to follow.  But at least it is all
inherently documented.  Printouts can be made, and higher quality
documents can be made from the postings.

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