I still do not see that to be honest. Why would introducing a third
element make anything saver? (Why would a verified triplet be superior
to a verified fully specified symbol?)
Don't get me wrong the current (version 5) system has its weaknesses but
i simply do not see how the proposed solution would be superior to what
is already included in the new symbol file format (of version 6). Other
than maybe making it more familiar to people coming from tools that went
a similar way. But to users really care about the files or could this
familiarity be better created with an improved GUI? I personally am kind
of against doing something just because it is familiar. There should be
a really good technical reason for it.
By the way i really do not understand why even the current v5 system
would not allow for your use case. Make a library of fully specified and
verified symbols. The only thing that i see it improving is that one can
assign differing bom info or footprint connections to similar parts
without duplicating symbols. But i kind of assumed the inheritance stuff
of the new file format will do the same.
On 23/05/19 23:18, Drew Van Zandt wrote:
The benefit is that once you have verified a triplet works on a board,
you can use it again without fear of error. The current system is not
ideal for re-use/production engineering.
On Thu, May 23, 2019, 4:06 PM Rene Pöschl <[email protected]
<mailto:[email protected]>> wrote:
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
<https://launchpad.net/%7Ekicad-developers>
> Post to : [email protected]
<mailto:[email protected]>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : [email protected]
<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
