kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

Hi,

just a possibly stupid idea. Maybe it could be an option to move part of 
the ideas of the new library system into your third entity. Particularly 
the inheritance stuff might not really be required if your atomic entity 
is used.

I seem to remember there was talk that this would be quite hard to 
implement anyways. So if that would make implementation easier then this 
might be a good way to go.
(But maybe i simply missed the point of why inheritance or your system 
is useful as i kind of thought the inheritance stuff was in there to 
fulfill exactly what your third file would now do.)

---

You state in the format definition that you do not intent to change 
anything regarding 3d models. Maybe your file could really go a bit 
further than you first envisioned and could take care of all possible 
connections in one system. So lets say it includes not only symbol 
footprint and bom information but also an optional overwrite for the 3d 
model as well as a way to define spice models. And possibly also a way 
to define the symbol pin to footprint and spice model pin mappings. (I 
would assume that this might be a bit too far so feel free to reject 
this outright as i must admit i have not yet fully convinced even myself 
that this would be a good idea. This could even be something that is 
moved to a second iteration.)

On 24/05/19 18:25, Seth Hillbrand wrote:
> Hi Rene-
>
> These are good points, thanks for helping me clean this proposal.
>
> One design goal of this system was to make it transparent for both
> librarians and users who do not want to use it.  To that end, the
> existing design of both the current and new formats is not affected.
> Users who do not enable this option would see no change in their
> workflow.
>
> This does mean that there are potentially two different places where the
> same key can be defined.  As envisioned, no fields from the symbol
> library will be used when an atomic part is placed on the schematic.
> All properties from the symbol library are cleared and the atomic
> library fields are populated.
>
> I will clarify this in the usage section.
>
> Best-
> Seth
>
> Am 2019-05-24 09:42, schrieb Rene Pöschl:
> > Hi again,
> >
> > A few clarification questions:
> >
> > Would your proposed solution replace the way of defining footprints in
> > the symbol file format of the future or would this be in parallel to
> > it. (I lean towards the fact that it should replace it as i fear we
> > otherwise end up with something similar to what we had with the
> > datasheet being stored in either dcm or lib files. But i can also
> > imagine that this would not be very well liked by the community)
> > Similarly with footprint filters. In the official lib we use it for
> > fully specified symbols to allow adding manufacturing specific
> > variations. (Inclusion of thermal vias, hand soldering alternative,
> > ...) How would that come into play?
> >
> > Your system would take care of adding bom info via properties. Right
> > now such fields can already be added to a symbol directly or via
> > eeschema. Again something where we might want to either limit it to
> > one place in the library or have clear rules which place takes
> > precedence. (An interesting case is if there are different fields in
> > the symbol compared to the new part specifier. Should the result be a
> > union of both sets of properties or should only the part properties be
> > used?)
> >
> > 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