Hi Seth.
On 24.05.2019 16:13, Seth Hillbrand wrote:
Am 2019-05-24 02:36, schrieb Sergey A. Borshch:
Major limitation is that your proposal still does not provide mapping
between symbol pins and footprints pins, so user has to keep separate
footprints for, say, sot23 bipolar, FET, Zenner and IC
Hi,
Am 24/05/2019 um 13:32 schrieb Wayne Stambaugh:
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint.
Yes, so would mine, on any level that is more detailed than "footprint".
The main problem I see with atomic libraries is that "fu
Hi,
the symbols mentioned by simon are the generic ones. Sadly not all
manufacturers use the same mapping not even for the same package.
(especially not for to-92 and sot-23)
Right now the best option is to have one symbol per possible arrangement
in the generic lib. We also have a full tran
> On May 24, 2019, at 2:54 AM, Simon Richter wrote:
>
> Hi,
> transistor symbols (BCE, BEC, CBE, CEB, EBC, ECB) into one and allow
> switching mappings during PCB design?
Why is that even necessary? The footprints (TO-92, SOT-23, etc etc) all have
standard pin numbers. The symbol for the
Seth Hillbrand kirjoitti 23.5.2019 klo 22.41:
> 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.
It would be, but please do not reinvent
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 h
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 no
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 w
Am 2019-05-24 02:36, schrieb Sergey A. Borshch:
Major limitation is that your proposal still does not provide mapping
between symbol pins and footprints pins, so user has to keep separate
footprints for, say, sot23 bipolar, FET, Zenner and IC which differ in
pins names only.
Hi Sergey-
Can yo
Just as an FYI in case it wasn't obvious, Seth's proposal uses library
IDs to define the symbol and footprint. This means that in order for
the atomic libraries as proposed to be portable, the symbol, footprint,
and 3D model would have to be available on the host machine. Otherwise,
any missing s
Hi,
On Thu, May 23, 2019 at 03:41:20PM -0400, Seth Hillbrand wrote:
> 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.
I have a counte
On 23.05.2019 22:41, Seth Hillbrand wrote:
The major limitations of the specification are:
...
- The atomic library does not contain symbol or footprint data
It's not a limitation, i's a great benefit - you can use same single
footprint/symbol file to many components and fix it in one place wit
Thanks Russ, that's helpful feedback.
Those actions are called out in the specification, so we should be able
to work within the new format to allow the abilities regardless of the
underlying file format.
The idea of footprint correctness is an interesting one. That might fit
nicely under a
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 b
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 soluti
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 wrote:
> Hi Seth
>
> What is the benefit compared to having lets say a
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
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
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+footp
19 matches
Mail list logo
