← Back to team overview

kicad-developers team mailing list archive

Re: exploiting human readability


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.

    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.


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:

  (columns   # superimposed onto all components contained, as user defined fields
    (column Optional1)
    (column Optional2)
    (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.


Follow ups