kicad-developers team mailing list archive

[Russell Oliver <roliver8143@xxxxxxxxx>]

Maybe it can be implemented as not a new library format, but through
enhancements to the existing workflow and new symbol format.

If there was an ability to
a) filter symbols in eeschema that have a valid footprint that can be found
in the footprint library.
b) run a dfm check that flags symbols being used that aren't fully
defined.

Another idea i can think of is using hashes to link footprints and symbols.
Each symbol alias could have a linked footprint and a hash to verify that
the footprint is correct.

Cheers
Russ

On Fri, 24 May 2019, 9:29 am Seth Hillbrand, <seth@xxxxxxxxxxxxx> wrote:

> Hi Rene-
>
> That's a fair critique.  The main benefits are ones that could be
> incorporated as separate tools (import/export, ability to switch between
> atomic and not, etc) once the new format is implemented.  In my use
> case, it is useful to separate the definitions from the libraries and
> switch between atomic libraries, but that might not be sufficiently
> common as to require an extra format.  Hence the request for feedback on
> the workflow.
>
> -Seth
>
> Am 2019-05-23 16:06, schrieb Rene Pöschl:
> > Hi Seth
> >
> > What is the benefit compared to having lets say a more powerful
> > aliasing
> > system that allows bom specific things to be more easily included in
> > the
> > kicad internal library without introducing something different?
> > (especially as i assume the new file format will provide a more
> > powerful
> > option in this regard anyways.)
> >
> > On 23/05/19 21:41, Seth Hillbrand wrote:
> >> Hi All-
> >>
> >> After some discussion, we are trying to decide whether implementing a
> >> basic atomic library support would be useful during v6 or would cause
> >> more headache than worth while trying to work with the solution.
> >>
> >> Background: "Atomic" libraries are ones that have unique names for
> >> symbol+footprint+properties combinations.  These are also referred to
> >> as
> >> "Fully-specified" libraries or sometimes "house libraries".
> >>
> >> The paradigm is outlined in a google document[1].  This is meant to
> >> provide an explicit option for users to create/utilize atomic library
> >> components without affecting the symbol or footprint formats.  It is
> >> also meant to be zero impact to the current, official KiCad libraries.
> >>
> >> The major limitations of the specification are:
> >> - No editing of the atomic library file within KiCad
> >> - The atomic library does not contain symbol or footprint data
> >>
> >> Folks are welcomed to weigh in on whether this approach presents a
> >> viable work flow for them.  I'm happy to take suggestions on the
> >> approach, I may ask you offline for some additional details of how you
> >> use KiCad and/or other tools with libraries at the moment.
> >>
> >> Best-
> >> Seth
> >>
> >>
> >> [1]
> >>
> https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
>