Alias-specific footprint filters

[Neal A Hollingsworth]

Symbols can be aliased in the library and have different descriptions, documentation, etc. but they cannot currently have different footprint filter lists, of values for the footprint field. This makes it harder to manage the libraries, and they end up bigger than they need to be, for many common components. E.g., transistors, where the schematic symbol is the same for almost every one, but different parts are only available in a limited selection of packages. This leads to many, many completely separate components, where any change to the symbol drawing must be copied by hand since they are all independent. Making it so that the alias only requires the symbol to be the same, and everything else could be different, would reduce the amount of needless redundancy in the libraries. It would simplify the task of maintaining them, and shrink the file size.

Expanding on that, the option to have fields "inherit" the parent parts values, be completely independent, or inherit with additions (in some cases) could be nice. The behaviors I'm thinking of would be that an inherited value is simply a reference to the parent symbols value, so it is always the same and updates as the parent value is updated. Completely independent is just that, the value of that parameter is not linked between the parent and alias what so ever. inherited with additions would only make sense for lists, like the FP filter. In this case, the alias would have an inherited copy of the FP filter list, which is just a reference to the parent part, as well as it's own list that is added to that.

Hopefully that makes sense and wasn't too long winded!

[Chris Pavlina (pavlina-chris)]

Allowing aliases to have their own values for other fields would also be nice. I have, for instance, an MPN (manufacturer's part number) field on most of my parts. One of these parts is ADP151AUJZ-v.v, which is a fixed voltage regulator that comes in multiple voltages. Aliases include ADP151AUJZ-1.2, ADP151AUJZ-3.3, etc. I've been forced to leave a {vout} placeholder in the MPN field to be edited by the user. It would be very nice if each alias could include the full MPN for that part!

This all being said - there are some library management changes in the upcoming sch/lib file format that may already include this, but I don't remember. Wayne, any comments?

[Wayne Stambaugh (stambaughw)]

On 1/30/2017 9:01 AM, Chris Pavlina wrote:
> Allowing aliases to have their own values for other fields would also be
> nice. I have, for instance, an MPN (manufacturer's part number) field on
> most of my parts. One of these parts is ADP151AUJZ-v.v, which is a fixed
> voltage regulator that comes in multiple voltages. Aliases include
> ADP151AUJZ-1.2, ADP151AUJZ-3.3, etc. I've been forced to leave a {vout}
> placeholder in the MPN field to be edited by the user. It would be very
> nice if each alias could include the full MPN for that part!
>
> This all being said - there are some library management changes in the
> upcoming sch/lib file format that may already include this, but I don't
> remember. Wayne, any comments?
>

Yes, there is support for properties in the new library file format
which can be used to create "fully defined" symbols that inherit from a
base symbol. It's slightly different than the current alias scheme that
we currently use but much more versatile. Although this will most
likely change somewhat before the spec is finalize.

[Neal A Hollingsworth (nealaholl)]

Great, thanks for the response. I knew there was a new file format in the works, but wasn't sure what was/was not going into it so I figured I would go ahead and put this out there. I appreciate y'all's work and prompt consideration of this.