kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/24/2010 9:59 AM, Dick Hollenbeck wrote:
> On 09/24/2010 03:41 AM, Lorenzo Marcantonio wrote:
>> On Fri, 24 Sep 2010, Martijn Kuipers wrote:
>>
>>   
>>> I would be very happy with an export function, doing: Export all used components into a project library.
>>> This way I can send the schematics on to the next person and (s)he can adjust where needed, without having to look for some components/footprint differences.
>>> Of course, its export, so the component would still live in the system library to be re-used.
>>>     
>> You just described the current 'cache' library system :D
>>   
> 
> 
> I would like to introduce a new term to describe the concept that I am
> trying to convey:  "parts list".
> 
> parts list:  is a eeschema collection of unique parts that are used
> within a particular schematic and is very much like a library, very much
> like the existing cache library.  However, a parts list is a far more
> visible and accessible list that *must* hold the programmatic factory
> mechanism for instantiating any component on that schematic.  The parts
> list holds no duplicates, only a single description of each unique
> part.  When a component is *instantiated*, it's genesis *must* reside in
> the parts list for the schematic, and the *only* things that get
> assigned to the component instance during instantiation are reference
> designator and location.  There are no additional, instance specific
> fields or properties.  Please read that again.  The only things that
> gets set during instantiation are the reference designator and the location.
> 
> A parts list could have a spreadsheet like editor, for columns that are
> for the various properties within a parts list.  We should add the
> concept of template field names to the parts list.  (The parts list
> exists *within* the schematic.)  The parts list could have its own field
> names, aka properties, aka columns in the spreadsheet editor, that would
> be applicable to all parts in the parts list.
> 
> Yes I know requiring a parts list to be built up before instantiation
> can take place is arguably an extra step, depending on the UI.  However
> some injection into the parts list could be automated, at least on the
> first usage of a particular part, but there could be more obvious ways
> to manipulate a parts list, and ultimately the UI determines the ease of
> usage.  Drag and drop has been mentioned, in this case from any library
> to the parts list.
> 
> In summary a parts list is basically a built in library, but one with a
> special face on it.  Its presence ensures that any EESCHEMA schematic is
> fully self describing, and it allows easy BOM creation because the
> schematic components get stripped of all their current
> fields/properties.  They only need to hold reference, location and part
> id.  A part id is a navigator into the schematic's internal parts list,
> such as a pointer.
> 
> 
> The loss of component instance specific properties is actual a gain in
> this case, because any edit to a part in the parts list will apply to
> all component instances that are based on that part.
> 
> 
> So the flow of design information is:
> 
>   library symbol -> parts list part ->  schematic component
> 
> 
> Just curious, has then been done before in any other schematic
> software?  (The answer to that question will not necessarily determine
> if this is a good idea.)

I'm not sure it has been done in this manner, but Orcad (at least version 10
did ) had a similar feature that was embedded in the schematic file.  The
editing mode could be changed from the schematic (graphical) to a component
properties (spreadsheet).  By adding a new column in the property editor mode,
it would add a new field to every component using the new column name.  This
made wholesale field editing in the schematic very easy.  Although it wasn't
clever enough to automatically update the field values of all the other
identical components.  You had to manually copy and paste value using the
editor.  It is the only feature I can think of in Orcad that I miss in EESchema.

Is there anything here that we need to add to the current library structure (
I'm assuming by structure you mean file format and the object code to support
it. ) to support this that doesn't already exist?  I want to avoid too many
side discussions and stay focused on the component library structure.

I have one possibly controversial change that I would like to see made to the
current library structure.  I would like to do away with the concept of
alternate body styles (DeMorgan) and create a separate library for them.  My
rationalization for this is that it would simplify the library file format and
the code required to support it.  Does anyone even use DeMorgan component
representations in their schematics any more?  It's been a long time since I
have seen one.  Visibility is also an issue.  It is not readily apparent that
these alternate body styles are even available at the user level.  I actually
discovered them when I was digging around in the component object code.  The
only issue I can see is if someone mixed DeMorgan and standard body styles for
different parts of a multiple part component (I'm not sure why someone would do
this but I try to avoid underestimating users) is that it could cause problems
for the DRC.

Wayne

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