kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@...>]

2009/11/13 jean-pierre charras - INPG <jean-pierre.charras@...r>:
>
> Schematic libraries handle ALIASes of basic components (called ROOT
> components)
> Aliases can be seen has a derived class of the root component.
> They share the component shape and, at this time, all fields but value/name.
>
> This is a good way to spare space and time to create them.
>
> They are owner of the their keyword and the documentatoon file.
>
> So if we want to have a separate Name and Value, alias handling must
> also modified
> (to make them owner of these fields)
>
> Because the .DCM file that store the alias data must be merged with the
> .lib file, this other change could be a good enhancement.
> But just modify the Root component to separate Name and Value does not
> work currently for aliases.
> (And for this problem, aliases are very useful )

Hi Jean-Pierre,

Thanks for that explanation. I didn't realise the aliases were stored
in the .dcm files. I was hoping to impliment the libraries with
aliases as it would be a much better solution as you say, but I didn't
want to complicate the first stage if I could help it.

A couple of things would need to be looked at then:

(1) Merge the .dcm and .lib files together (I saw that someone was
already looking into this, so I will check with them)
(2) Aliases should support field overloading (explained below)
(3) Name and Value seperated in the eeschema code where necessary

I think it would be important for aliases to support field
overloading. So if the field is not defined in the Alias the Root
component's field value is used, but if the Alias defines the field
then the Aliase's value should be used. In my case, I would need to be
able to define a company part number per component which would use a
user field (In my previous example, field 5). This needs to be unique
to each alias.

> But an other method could be a retroannotation.
> This feature exists in Eeschema to fill the footprint field using a .stf
> file created by Cvpcb from info in the .equ files.
> Moreover, Cvpcb is able to automatically associate components and
> footprints from these files
> (in fact the .stf is a .equ file with only the relevant dato for the
> current schematic)
>
> Could be used for others fields ?
>
> Advantages:
> - this kind of file is easy to create for a given application, and is
> very short
> - It is easy to modify for and other application or by an other guy to
> change (for all component) dealers or other info
> - The full schematic can be easily updated by re-reading a .stf file
> for instance I created 2 .equ files: one when i am using SMD components
> and one for usual components.
>  From the same schematic, i can easily switch from a technology to the
> other.
>
> Have a look to these .equ files that can be found in the modules
> repertory ( and are created by a text editor)

I have not used the retroannotation before, and I've never noticed the
.equ files before so I will have a look at those and see if they could
be utilised in some way. Thanks for the suggestion.

Best Regards,

Brian.