kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #30799
Re: Questions regarding .sweet format
> On Sep 18, 2017, at 6:27 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>
> On 9/17/2017 2:59 AM, Oliver Walters wrote:
>> Hi Wayne, others,
>>
>> *2. Symbol Variants*
>> *
>> *
>> One of the pressing shortfalls in the current library scheme is that the
>> footprint field is common to all aliases. Thus, if a symbol is made for
>> e.g. a SOIC-8 there cannot be an alias for a DIP-8 version of the
>> symbol. Many components have pin-compatible footprints.
>>
>> In this case, is it as simple as doing the following:
>>
>> (part "MYPART_DIP-8" inherets "MYPART_SOIC-8"
>> (footprint "DIPS:DIP-8"> )
>>
>> That's how I read the specification document. If my reading is correct,
>> then I think that's great.
>
> That is exactly how it's supposed to work. The "inherits" token is very
> powerful.
There has been a lot of discussion about atomic parts over on the user forum. I’m a big fan of them. The only support needed from Kicad to implement them, really, is the ability to add a simple “PN” (part number) field to the symbol. All of the parts in my symbol libraries have this field included and set to something useful). Whether the Kicad symbol format is updated to include that field by default or whether I have to add it doesn’t matter to me, I’ll add it if it doesn’t exist.
If a symbol has aliases which call out different footprints, can those aliases also include different PN fields?
This is necessary because different footprints mean different manufacturer part numbers. If the new format supports this, then it’s brilliant and will work for me (and the other fans of atomic parts).
Thanks, and I apologize for not reading the specification document to see if what I ask for has already been considered.
-a
Follow ups
References