Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-04 Thread Chris Pavlina
The assignment of footprints to schematic symbols is largely a KiCad 
quirk. Many other tools consider a component to be a single package 
containing symbol and footprint. In my own library I have a part per 
actual electronic part (one called MMBT3904, for instance), which 
already has the Footprint field set from the very beginning, no mucking 
about with the nightmare that is cvpcb.

Also, footprints are much more critical, in that you have to get all the 
dimensions very correct, so it makes much more sense in terms of being 
less error-prone to have multiple symbols linked to one footprint than 
one symbol linked to multiple footprints.

On Thu, Jun 04, 2015 at 10:23:40PM -0500, Adam Wolf wrote:
> Hi folks,
> 
> I was using KiCad to make a board today (yeah, the novelty of actually
> *using* it!), and I noticed that there's been some changes in schematic
> symbols--and I'm wondering if it was on purpose.
> 
> I was adding a pmos to my schematic, and I noticed there are:
> 
> Q_PMOS_DGS
> Q_PMOS_DSG
> Q_PMOS_GDS
> Q_PMOS_GSD
> Q_PMOS_SDG
> Q_PMOS_SGD
> 
> and the change is basically to change the pin numbers.
> 
> Years ago, I thought it was that the schematic was a "logical"
> representation of your circuit, and the assignment of footprints to
> schematic symbols was where you chose parts, especially for things like
> fets.
> 
> Is this a transitory thing, or is this the way we've chosen to set up the
> official kicad libraries?
> 
> This isn't criticism, more something I was a little confused by and decided
> I'd check on.
> 
> Thanks!
> 
> Adam Wolf

> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-04 Thread Lorenzo Marcantonio
On Thu, Jun 04, 2015 at 10:23:40PM -0500, Adam Wolf wrote:
> Years ago, I thought it was that the schematic was a "logical"
> representation of your circuit, and the assignment of footprints to
> schematic symbols was where you chose parts, especially for things like
> fets.

Yes and no. It depends on how you structure the library (both of them). 
Schematic and footprint are tied by pin number. When you have components
with 'permutations' you have two choices; either

- Call the pins with their official JEDEC pin number (i.e. 1-2-3) and use
  a different schematic symbol for each permutation (NPN-BCE, NMOS-GDS
  and so on); or

- Call the pins with their 'functional' name (E, B, C, G, S, D,
  whatever) and replicate the footprint with the needed permutations
  (TO236-BCE, TO236-GDS and so on)

I can assure you that both solutions have the same problems; they just
shift them from eeschema to pcbnew and back :D

It was simply decided in the library guidelines to follow the first
approach (because it can be somewhat easier to maintain), just that. My
libraries use the second one (I prefer to see the pin name because the
'oh that's the gate must be careful' impression it gives).

Luckily these days packages are mostly standardized (except for the rare
'reverse' part option, which exists *exactly* for layout purposes!)...
in a 3 pin transistor you can be 99% sure that pin 1 is the base/gate
and pin 2 the collector/drain (that's also for heat and die bonding
reasons...)

> Is this a transitory thing, or is this the way we've chosen to set up the
> official kicad libraries?

Official rule, if you want to use the standard libs, that's the way they
are done.

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Vesa Solonen
05/06/15, 06:23, Adam Wolf kirjoitti:

> Years ago, I thought it was that the schematic was a "logical"
> representation of your circuit, and the assignment of footprints to
> schematic symbols was where you chose parts, especially for things like
> fets.

This issue has been discussed for years, but no consensus could be
reached how to do it. The long details are in the archives. Most
developers saw it as a non problem as they always draw schematics with
components, not symbols... Implying that they always know which
particular components they are going to use.

I would like to see a system where one assigns a component to a symbol.
Say the schematic has a NPN symbol which gets PN component assigned
to it meaning also TO-92 footprint and 3D-model.

> Is this a transitory thing, or is this the way we've chosen to set up
> the official kicad libraries?

Because of open source I would consider it transitory :)

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
Hi,
I stumbled about a similar things with double-diodes. I see why it is done,
and this is one acceptable solution to the problem at hand.

But it is hard to navigate.

I have a long-term suggestion (that I am happy to help implement), and a
short-term suggestion to get things out of the door quickly for a stable
release, but helps users to not be confused and gives us a chance to
improve things later.

Longer term (after the next stable release), it makes sense to re-evaluate
data-structures. It would probably be best to simplify the proliferation of
symbols by separating symbol from pin assignments+possible footprints.

So associate the schematic symbol with a number of variant footprints,
which essentially adds a sub-relation, something like

  symbol (generic FET for instance)  ->  (multiple variants of assignment
to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)

(I think this is how it is mostly done in other tools as it helps to have
simple symbol _and_ a way to associate to a number of footprints). So each
symbol can have a number of separate logical to pin-assignment.

Main advantage for the user is, that they can see a tree view: they choose
a symbol, then the sub-variant that applies to their case (pin-assignment).
There or in pcbnew they then finally choose the package.

Anyway, details need to be hashed out and require some discussion. And
certainly not something to change now in preparation for a good next
release.

In the meantime, while that is not in place yet, how about this:

   - we store one optional additional field in a schematic symbol, think of
it as a 'tag' that ties symbols together into one family. In Adams'
example, that could be for instance "Q_PMOS". All the symbols are still
separate, but they have this 'unifying' field that associates things across
symbols. For the younger audience: think of it as a hashtag :).

   - The component chooser (which I have largely contributed in its current
form) can use this additional information to present these components under
one sub-tree. So the tag has no semantic meaning right now, it is only used
to better display things.

That way we have
  1) A much more 'logical' way to present these components to a user
without making their heads explode.
  2) Almost no implementation overhead for an upcoming release (and
importantly: very slim chance to introduce new bugs while stabilizing). No
data structure is fundamentally changed, but we just add another optional
field (most components never set this).
  3) a chance in the future to automatically adapt schematics to a possibly
new long-term data structure later.

If this sounds like an acceptable solution, I am happy to work on it.

-h

On 4 June 2015 at 20:23, Adam Wolf  wrote:

> Hi folks,
>
> I was using KiCad to make a board today (yeah, the novelty of actually
> *using* it!), and I noticed that there's been some changes in schematic
> symbols--and I'm wondering if it was on purpose.
>
> I was adding a pmos to my schematic, and I noticed there are:
>
> Q_PMOS_DGS
> Q_PMOS_DSG
> Q_PMOS_GDS
> Q_PMOS_GSD
> Q_PMOS_SDG
> Q_PMOS_SGD
>
> and the change is basically to change the pin numbers.
>
> Years ago, I thought it was that the schematic was a "logical"
> representation of your circuit, and the assignment of footprints to
> schematic symbols was where you chose parts, especially for things like
> fets.
>
> Is this a transitory thing, or is this the way we've chosen to set up the
> official kicad libraries?
>
> This isn't criticism, more something I was a little confused by and
> decided I'd check on.
>
> Thanks!
>
> Adam Wolf
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Andy Peters

> On Jun 4, 2015, at 9:26 PM, Chris Pavlina  wrote:
> 
> The assignment of footprints to schematic symbols is largely a KiCad 
> quirk. Many other tools consider a component to be a single package 
> containing symbol and footprint. In my own library I have a part per 
> actual electronic part (one called MMBT3904, for instance), which 
> already has the Footprint field set from the very beginning, no mucking 
> about with the nightmare that is cvpcb.
> 
> Also, footprints are much more critical, in that you have to get all the 
> dimensions very correct, so it makes much more sense in terms of being 
> less error-prone to have multiple symbols linked to one footprint than 
> one symbol linked to multiple footprints.

At risk of reiterating myself again, what Chris describes above is how 
professional engineering groups do their libraries. Every company I’ve worked 
for has a vetted parts list and the PCB layout library includes only those 
parts. The symbols and footprints are married to a part number. Under no 
circumstance would someone choose, say, an NPN transistor from a library and 
then later match it to a footprint and to something that can be ordered. The 
chance of an expensive fuck-up happening is way too high.

Pardon my Jersey.

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Andy Peters

> On Jun 5, 2015, at 10:01 AM, Henner Zeller  wrote:
> 
> Hi,
> I stumbled about a similar things with double-diodes. I see why it is done, 
> and this is one acceptable solution to the problem at hand.
> 
> But it is hard to navigate.
> 
> I have a long-term suggestion (that I am happy to help implement), and a 
> short-term suggestion to get things out of the door quickly for a stable 
> release, but helps users to not be confused and gives us a chance to improve 
> things later.
> 
> Longer term (after the next stable release), it makes sense to re-evaluate 
> data-structures. It would probably be best to simplify the proliferation of 
> symbols by separating symbol from pin assignments+possible footprints.
> 
> So associate the schematic symbol with a number of variant footprints, which 
> essentially adds a sub-relation, something like
> 
>   symbol (generic FET for instance)  ->  (multiple variants of assignment to 
> D=pin1 G=pin2 S=pin3; package hints TO92, TO220...) 
> 
> (I think this is how it is mostly done in other tools as it helps to have 
> simple symbol _and_ a way to associate to a number of footprints). So each 
> symbol can have a number of separate logical to pin-assignment.
> 
> Main advantage for the user is, that they can see a tree view: they choose a 
> symbol, then the sub-variant that applies to their case (pin-assignment). 
> There or in pcbnew they then finally choose the package.
> 
> Anyway, details need to be hashed out and require some discussion. And 
> certainly not something to change now in preparation for a good next release.
> 
> In the meantime, while that is not in place yet, how about this:
> 
>- we store one optional additional field in a schematic symbol, think of 
> it as a 'tag' that ties symbols together into one family. In Adams' example, 
> that could be for instance "Q_PMOS". All the symbols are still separate, but 
> they have this 'unifying' field that associates things across symbols. For 
> the younger audience: think of it as a hashtag :).
> 
>- The component chooser (which I have largely contributed in its current 
> form) can use this additional information to present these components under 
> one sub-tree. So the tag has no semantic meaning right now, it is only used 
> to better display things.
> 
> That way we have
>   1) A much more 'logical' way to present these components to a user without 
> making their heads explode.
>   2) Almost no implementation overhead for an upcoming release (and 
> importantly: very slim chance to introduce new bugs while stabilizing). No 
> data structure is fundamentally changed, but we just add another optional 
> field (most components never set this).
>   3) a chance in the future to automatically adapt schematics to a possibly 
> new long-term data structure later.
> 
> If this sounds like an acceptable solution, I am happy to work on it.

That all seems way too complicated.

Footprint pins should be numbered in the standard way. Since a footprint can be 
used for many many completely unrelated devices, there is no point in making 
the pin function part of the footprint. I mean, an SOIC-8 can be used for 
op-amps and SPI DACs, and nobody proposes an op-amp SOIC-8 footprint and an SPI 
DAC footprint, right? So why have a dozen different variants on the TO-220 with 
the attempt to support different voltage regulators and MOSFETs and BJTs and 
what-not? It’s crazy.

The schematic symbols already have the capability of giving a pin both a name 
and a number. So if you want to have your transistor’s pins named E, G and C, 
you can do that, and just make sure that you map the pin function to the 
footprint number. Yeah, I realize that too many people want to place a generic 
NPN on the schematic, but how hard is it to create an MMBT (where part name 
implies both function and footprint), anyway?

I realize that there’s an argument that goes, “Well, the library will be super 
big if we want to support all of the possible transistors out there.” And that 
argument is silly. Does anyone use a generic op-amp symbol instead of placing a 
TL072ACD (there it is again, symbol name calling out footprint!) on the 
schematic? No, of course not. So why is that OK for transistors? 

harrumph. back to work!

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
On 5 June 2015 at 11:00, Andy Peters  wrote:

>
> > On Jun 4, 2015, at 9:26 PM, Chris Pavlina 
> wrote:
> >
> > The assignment of footprints to schematic symbols is largely a KiCad
> > quirk. Many other tools consider a component to be a single package
> > containing symbol and footprint. In my own library I have a part per
> > actual electronic part (one called MMBT3904, for instance), which
> > already has the Footprint field set from the very beginning, no mucking
> > about with the nightmare that is cvpcb.
> >
> > Also, footprints are much more critical, in that you have to get all the
> > dimensions very correct, so it makes much more sense in terms of being
> > less error-prone to have multiple symbols linked to one footprint than
> > one symbol linked to multiple footprints.
>
> At risk of reiterating myself again, what Chris describes above is how
> professional engineering groups do their libraries. Every company I’ve
> worked for has a vetted parts list and the PCB layout library includes only
> those parts. The symbols and footprints are married to a part number. Under
> no circumstance would someone choose, say, an NPN transistor from a library
> and then later match it to a footprint and to something that can be
> ordered. The chance of an expensive fuck-up happening is way too high.
>

Agreed. The way this internally should be represented is something like
   IRFZ44N = (generic PowerMosfet with logic names) + (G=1 D=2 S=3 pin
assignment) + TO220 with pin 1,2,3.

That way, it minimizes the repetition of the symbol definition, but then
ties the important information that makes a particular product the way it
is together.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
On 5 June 2015 at 11:08, Andy Peters  wrote:

>
> > On Jun 5, 2015, at 10:01 AM, Henner Zeller  wrote:
> >
> > Hi,
> > I stumbled about a similar things with double-diodes. I see why it is
> done, and this is one acceptable solution to the problem at hand.
> >
> > But it is hard to navigate.
> >
> > I have a long-term suggestion (that I am happy to help implement), and a
> short-term suggestion to get things out of the door quickly for a stable
> release, but helps users to not be confused and gives us a chance to
> improve things later.
> >
> > Longer term (after the next stable release), it makes sense to
> re-evaluate data-structures. It would probably be best to simplify the
> proliferation of symbols by separating symbol from pin assignments+possible
> footprints.
> >
> > So associate the schematic symbol with a number of variant footprints,
> which essentially adds a sub-relation, something like
> >
> >   symbol (generic FET for instance)  ->  (multiple variants of
> assignment to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)
> >
> > (I think this is how it is mostly done in other tools as it helps to
> have simple symbol _and_ a way to associate to a number of footprints). So
> each symbol can have a number of separate logical to pin-assignment.
> >
> > Main advantage for the user is, that they can see a tree view: they
> choose a symbol, then the sub-variant that applies to their case
> (pin-assignment). There or in pcbnew they then finally choose the package.
> >
> > Anyway, details need to be hashed out and require some discussion. And
> certainly not something to change now in preparation for a good next
> release.
> >
> > In the meantime, while that is not in place yet, how about this:
> >
> >- we store one optional additional field in a schematic symbol, think
> of it as a 'tag' that ties symbols together into one family. In Adams'
> example, that could be for instance "Q_PMOS". All the symbols are still
> separate, but they have this 'unifying' field that associates things across
> symbols. For the younger audience: think of it as a hashtag :).
> >
> >- The component chooser (which I have largely contributed in its
> current form) can use this additional information to present these
> components under one sub-tree. So the tag has no semantic meaning right
> now, it is only used to better display things.
> >
> > That way we have
> >   1) A much more 'logical' way to present these components to a user
> without making their heads explode.
> >   2) Almost no implementation overhead for an upcoming release (and
> importantly: very slim chance to introduce new bugs while stabilizing). No
> data structure is fundamentally changed, but we just add another optional
> field (most components never set this).
> >   3) a chance in the future to automatically adapt schematics to a
> possibly new long-term data structure later.
> >
> > If this sounds like an acceptable solution, I am happy to work on it.
>
> That all seems way too complicated.
>
> Footprint pins should be numbered in the standard way. Since a footprint
> can be used for many many completely unrelated devices, there is no point
> in making the pin function part of the footprint. I mean, an SOIC-8 can be
> used for op-amps and SPI DACs, and nobody proposes an op-amp SOIC-8
> footprint and an SPI DAC footprint, right? So why have a dozen different
> variants on the TO-220 with the attempt to support different voltage
> regulators and MOSFETs and BJTs and what-not? It’s crazy.\
>

Please read what I wrote. I suggested to just use whatever we have now in
the schematic symbol (where the symbol explodes all the variants), but just
tie them together. This will only affect the current generic symbols -
which will have to be there until there is a useful big library that has
all common components in there.

The 'long term solution' is as well only discussing the internal data
structure to help getting to a state where we have a huge library. Ideally
for the user, they choose a specific component.


>
> The schematic symbols already have the capability of giving a pin both a
> name and a number. So if you want to have your transistor’s pins named E, G
> and C, you can do that, and just make sure that you map the pin function to
> the footprint number. Yeah, I realize that too many people want to place a
> generic NPN on the schematic, but how hard is it to create an MMBT
> (where part name implies both function and footprint), anyway?
>

Well, I think if there is a discussion, then it should mostly focus on
re-using parts of what you need. It would be silly to re-draw the same
symbol many times for each transistor. You rather take a generic symbol
(which probably is not even exposed publically to choose from by the user),
and combine it with the necessary information (which pins, which footprint)
to make it MMBT.


> I realize that there’s an argument that goes, “Well, the library will be
> super big if we want to support all of

Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Wayne Stambaugh
On 6/5/2015 2:00 PM, Andy Peters wrote:
> 
>> On Jun 4, 2015, at 9:26 PM, Chris Pavlina  wrote:
>>
>> The assignment of footprints to schematic symbols is largely a KiCad 
>> quirk. Many other tools consider a component to be a single package 
>> containing symbol and footprint. In my own library I have a part per 
>> actual electronic part (one called MMBT3904, for instance), which 
>> already has the Footprint field set from the very beginning, no mucking 
>> about with the nightmare that is cvpcb.
>>
>> Also, footprints are much more critical, in that you have to get all the 
>> dimensions very correct, so it makes much more sense in terms of being 
>> less error-prone to have multiple symbols linked to one footprint than 
>> one symbol linked to multiple footprints.
> 
> At risk of reiterating myself again, what Chris describes above is how 
> professional engineering groups do their libraries. Every company I’ve worked 
> for has a vetted parts list and the PCB layout library includes only those 
> parts. The symbols and footprints are married to a part number. Under no 
> circumstance would someone choose, say, an NPN transistor from a library and 
> then later match it to a footprint and to something that can be ordered. The 
> chance of an expensive fuck-up happening is way too high.
> 
> Pardon my Jersey.
> 
> -a

There is absolutely nothing preventing you from doing this.  The reason
this isn't done is the list of transistor, op-amp, regulator, etc.
symbols would be huge and a maintenance nightmare given our resource
limitations.  The current symbol libraries are a good compromise.  There
are really only a few variations for most 3 pin devices such as
transistors and diode pairs.  Trying to provide a fully defined symbol
for every transistor would be a huge under taking.  Our solution may not
be ideal but I'm not sure I want to sift through thousands (tens of
thousands?) of transistor part numbers to find what I'm looking for.  I
wonder how well Henner's component chooser search code would handle that
number of symbols.  That would probably take longer than just making
sure my transistor symbol and footprint pin out are correct.  However,
I'm betting if you would offer to do this, the library maintainers would
not object.

> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Lorenzo Marcantonio
On Fri, Jun 05, 2015 at 11:00:45AM -0700, Andy Peters wrote:
> At risk of reiterating myself again, what Chris describes above is how 
> professional engineering groups do their libraries. Every company I’ve worked 
> for has a vetted parts list and the PCB layout library includes only those 
> parts. The symbols and footprints are married to a part number. Under no 
> circumstance would someone choose, say, an NPN transistor from a library and 
> then later match it to a footprint and to something that can be ordered. The 
> chance of an expensive fuck-up happening is way too high.

I do this with eeschema aliases and pre-initializing the footprint
field. Since as I said packages are mostly standardized these days
I only need about 3-4 symbol 'duplicates' for each logical symbol (the
MO236-GDS fet, TO220-GDS fet, SC70-GDS fet and so on).

It's hugely important for some ICs where the part number itself changes
the package: while an SN74LVC00AD is a SOIC part, SN74LVC00ADBR is the
same part in SSOP (these are TI part number, I remember NXP uses another
coding...). 

But, even more important, some parts actually *change pinout* when
switching packages; the awfully popular MSP430F5528 has 64 pins in QFN
(they call it RGC), 64 pin in the YFF BGA package (numbering changes
from numeric to coordinates) and even 80 pin in ZQE BGA package (a lot
of reserved balls:P). Other parts have some pin unbonded in the smaller
packages (something like you lose 2 GPIO but have a really smaller
body), and so on...

In these cases is essential to have different schematic parts, in
theory: MSP430F5528IRGC, MSP430F5528IYFF, MSP430F5528IZQE; these would
have the same pin names and drawing, but with different numbers *and*
different footprints associated (of course I only do them on an
as-needed basis, since BGAs are a PITA to handle anyway :D)

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Lorenzo Marcantonio
On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
> There is absolutely nothing preventing you from doing this.  The reason
> this isn't done is the list of transistor, op-amp, regulator, etc.
> symbols would be huge and a maintenance nightmare given our resource
> limitations.  The current symbol libraries are a good compromise.  There

Also I *never* found someone using a cad library as-is... we always
customize the parts to our standards anyway!

Talking about huge symbol lists... IIRC cadstar encodes in the library
*each single resistor part number*. Of course there is a subscription
service for that:P

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Wayne Stambaugh
On 6/5/2015 2:24 PM, Henner Zeller wrote:
> On 5 June 2015 at 11:08, Andy Peters  > wrote:
> 
> 
> > On Jun 5, 2015, at 10:01 AM, Henner Zeller  > wrote:
> >
> > Hi,
> > I stumbled about a similar things with double-diodes. I see why it is 
> done, and this is one acceptable solution to the problem at hand.
> >
> > But it is hard to navigate.
> >
> > I have a long-term suggestion (that I am happy to help implement), and 
> a short-term suggestion to get things out of the door quickly for a stable 
> release, but helps users to not be confused and gives us a chance to improve 
> things later.
> >
> > Longer term (after the next stable release), it makes sense to 
> re-evaluate data-structures. It would probably be best to simplify the 
> proliferation of symbols by separating symbol from pin assignments+possible 
> footprints.
> >
> > So associate the schematic symbol with a number of variant footprints, 
> which essentially adds a sub-relation, something like
> >
> >   symbol (generic FET for instance)  ->  (multiple variants of 
> assignment to D=pin1 G=pin2 S=pin3; package hints TO92, TO220...)
> >
> > (I think this is how it is mostly done in other tools as it helps to 
> have simple symbol _and_ a way to associate to a number of footprints). So 
> each symbol can have a number of separate logical to pin-assignment.
> >
> > Main advantage for the user is, that they can see a tree view: they 
> choose a symbol, then the sub-variant that applies to their case 
> (pin-assignment). There or in pcbnew they then finally choose the package.
> >
> > Anyway, details need to be hashed out and require some discussion. And 
> certainly not something to change now in preparation for a good next release.
> >
> > In the meantime, while that is not in place yet, how about this:
> >
> >- we store one optional additional field in a schematic symbol, 
> think of it as a 'tag' that ties symbols together into one family. In Adams' 
> example, that could be for instance "Q_PMOS". All the symbols are still 
> separate, but they have this 'unifying' field that associates things across 
> symbols. For the younger audience: think of it as a hashtag :).
> >
> >- The component chooser (which I have largely contributed in its 
> current form) can use this additional information to present these components 
> under one sub-tree. So the tag has no semantic meaning right now, it is only 
> used to better display things.
> >
> > That way we have
> >   1) A much more 'logical' way to present these components to a user 
> without making their heads explode.
> >   2) Almost no implementation overhead for an upcoming release (and 
> importantly: very slim chance to introduce new bugs while stabilizing). No 
> data structure is fundamentally changed, but we just add another optional 
> field (most components never set this).
> >   3) a chance in the future to automatically adapt schematics to a 
> possibly new long-term data structure later.
> >
> > If this sounds like an acceptable solution, I am happy to work on it.
> 
> That all seems way too complicated.
> 
> Footprint pins should be numbered in the standard way. Since a
> footprint can be used for many many completely unrelated devices,
> there is no point in making the pin function part of the footprint.
> I mean, an SOIC-8 can be used for op-amps and SPI DACs, and nobody
> proposes an op-amp SOIC-8 footprint and an SPI DAC footprint, right?
> So why have a dozen different variants on the TO-220 with the
> attempt to support different voltage regulators and MOSFETs and BJTs
> and what-not? It’s crazy.\
> 
> 
> Please read what I wrote. I suggested to just use whatever we have now
> in the schematic symbol (where the symbol explodes all the variants),
> but just tie them together. This will only affect the current generic
> symbols - which will have to be there until there is a useful big
> library that has all common components in there.
> 
> The 'long term solution' is as well only discussing the internal data
> structure to help getting to a state where we have a huge library.
> Ideally for the user, they choose a specific component.
>  
> 
> 
> The schematic symbols already have the capability of giving a pin
> both a name and a number. So if you want to have your transistor’s
> pins named E, G and C, you can do that, and just make sure that you
> map the pin function to the footprint number. Yeah, I realize that
> too many people want to place a generic NPN on the schematic, but
> how hard is it to create an MMBT (where part name implies both
> function and footprint), anyway?
> 
> 
> Well, I think if there is a discussion, then it should mostly focus on
> re-using parts of what you need. It would be silly to re-draw the same
> 

Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Lorenzo Marcantonio
On Fri, Jun 05, 2015 at 11:08:19AM -0700, Andy Peters wrote:
> I realize that there’s an argument that goes, “Well, the library will be 
> super big if we want to support all of the possible transistors out there.” 
> And that argument is silly. Does anyone use a generic op-amp symbol instead 
> of placing a TL072ACD (there it is again, symbol name calling out footprint!) 
> on the schematic? No, of course not. So why is that OK for transistors? 

I do that actually before chosing the op amp:D industry standard pinouts
are useful, and the dual amp is the perfect example!

-- 
Lorenzo Marcantonio
Logos Srl

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
On 5 June 2015 at 11:31, Wayne Stambaugh  wrote:
>
> On 6/5/2015 2:00 PM, Andy Peters wrote:
> >
> >> On Jun 4, 2015, at 9:26 PM, Chris Pavlina  wrote:
> >>
> >> The assignment of footprints to schematic symbols is largely a KiCad
> >> quirk. Many other tools consider a component to be a single package
> >> containing symbol and footprint. In my own library I have a part per
> >> actual electronic part (one called MMBT3904, for instance), which
> >> already has the Footprint field set from the very beginning, no mucking
> >> about with the nightmare that is cvpcb.
> >>
> >> Also, footprints are much more critical, in that you have to get all the
> >> dimensions very correct, so it makes much more sense in terms of being
> >> less error-prone to have multiple symbols linked to one footprint than
> >> one symbol linked to multiple footprints.
> >
> > At risk of reiterating myself again, what Chris describes above is how 
> > professional engineering groups do their libraries. Every company I’ve 
> > worked for has a vetted parts list and the PCB layout library includes only 
> > those parts. The symbols and footprints are married to a part number. Under 
> > no circumstance would someone choose, say, an NPN transistor from a library 
> > and then later match it to a footprint and to something that can be 
> > ordered. The chance of an expensive fuck-up happening is way too high.
> >
> > Pardon my Jersey.
> >
> > -a
>
> There is absolutely nothing preventing you from doing this.  The reason
> this isn't done is the list of transistor, op-amp, regulator, etc.
> symbols would be huge and a maintenance nightmare given our resource
> limitations.

+1

> The current symbol libraries are a good compromise.  There
> are really only a few variations for most 3 pin devices such as
> transistors and diode pairs.  Trying to provide a fully defined symbol
> for every transistor would be a huge under taking.  Our solution may not
> be ideal but I'm not sure I want to sift through thousands (tens of
> thousands?) of transistor part numbers to find what I'm looking for.  I
> wonder how well Henner's component chooser search code would handle that
> number of symbols.

Well, I wouldn't worry about that, I can make that fast :)

Main problem is, that it still takes the human to find longer if you
just browse. Also: overwhelming.
So this is only workable if there is some other layer of pre-filtering
(things available to me, available in my stash of components, company
stash of components etc).

-h

>
> That would probably take longer than just making
> sure my transistor symbol and footprint pin out are correct.  However,
> I'm betting if you would offer to do this, the library maintainers would
> not object.
>
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Chris Pavlina
On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
> On 6/5/2015 2:00 PM, Andy Peters wrote:
> > 
> > *snip *
> 
> *snip* Trying to provide a fully defined symbol
> for every transistor would be a huge under taking.  Our solution may not
> be ideal but I'm not sure I want to sift through thousands (tens of
> thousands?) of transistor part numbers to find what I'm looking for.

You should never have to sift! We need to create a standardized way to 
write description that is easily searched. This is how I manage my 
library - it's quite large, but I know how the descriptions work and I 
can just start typing what I'm looking for.

> I wonder how well Henner's component chooser search code would handle 
>that
> number of symbols.

Optimize it if it can't! Searching through even *millions* of data 
points is a solved problem in computing. Ideally we'd have optional 
wildcard and regex search too - something I might be willing to 
contribute to in the near future. These can all be quite fast if done 
right.

--
Chris


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Wayne Stambaugh
On 6/5/2015 2:44 PM, Lorenzo Marcantonio wrote:
> On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
>> There is absolutely nothing preventing you from doing this.  The reason
>> this isn't done is the list of transistor, op-amp, regulator, etc.
>> symbols would be huge and a maintenance nightmare given our resource
>> limitations.  The current symbol libraries are a good compromise.  There
> 
> Also I *never* found someone using a cad library as-is... we always
> customize the parts to our standards anyway!

Exactly!  If you took 50 engineers and told them to each make a fully
defined symbol library for any set or subset of components, you would
likely end up with 50 different libraries.  Generally speaking everyone
has different requirements so designing fully qualified symbol libraries
is a tricky business.  KiCad has opted to provide generic symbol
libraries for our users since we have no idea how they prefer to use them.

> 
> Talking about huge symbol lists... IIRC cadstar encodes in the library
> *each single resistor part number*. Of course there is a subscription
> service for that:P
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
On 5 June 2015 at 11:54, Chris Pavlina  wrote:
> On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
>> On 6/5/2015 2:00 PM, Andy Peters wrote:
>> >
>> > *snip *
>>
>> *snip* Trying to provide a fully defined symbol
>> for every transistor would be a huge under taking.  Our solution may not
>> be ideal but I'm not sure I want to sift through thousands (tens of
>> thousands?) of transistor part numbers to find what I'm looking for.
>
> You should never have to sift! We need to create a standardized way to
> write description that is easily searched. This is how I manage my
> library - it's quite large, but I know how the descriptions work and I
> can just start typing what I'm looking for.
>
>> I wonder how well Henner's component chooser search code would handle
>>that
>> number of symbols.
>
> Optimize it if it can't! Searching through even *millions* of data
> points is a solved problem in computing.

As I said, I wouldn't worry about that. In my day-job I am working
with billions of things to search from, so this is peanuts.

-h

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Wayne Stambaugh
On 6/5/2015 2:57 PM, Henner Zeller wrote:
> On 5 June 2015 at 11:54, Chris Pavlina  wrote:
>> On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
>>> On 6/5/2015 2:00 PM, Andy Peters wrote:

 *snip *
>>>
>>> *snip* Trying to provide a fully defined symbol
>>> for every transistor would be a huge under taking.  Our solution may not
>>> be ideal but I'm not sure I want to sift through thousands (tens of
>>> thousands?) of transistor part numbers to find what I'm looking for.
>>
>> You should never have to sift! We need to create a standardized way to
>> write description that is easily searched. This is how I manage my
>> library - it's quite large, but I know how the descriptions work and I
>> can just start typing what I'm looking for.
>>
>>> I wonder how well Henner's component chooser search code would handle
>>> that
>>> number of symbols.
>>
>> Optimize it if it can't! Searching through even *millions* of data
>> points is a solved problem in computing.
> 
> As I said, I wouldn't worry about that. In my day-job I am working
> with billions of things to search from, so this is peanuts.
> 
> -h
> 

If only we could create the symbol libraries that fast.  Now that would
useful!


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Henner Zeller
On 5 June 2015 at 12:00, Wayne Stambaugh  wrote:
> On 6/5/2015 2:57 PM, Henner Zeller wrote:
>> On 5 June 2015 at 11:54, Chris Pavlina  wrote:
>>> On Fri, Jun 05, 2015 at 02:31:06PM -0400, Wayne Stambaugh wrote:
 On 6/5/2015 2:00 PM, Andy Peters wrote:
>
> *snip *

 *snip* Trying to provide a fully defined symbol
 for every transistor would be a huge under taking.  Our solution may not
 be ideal but I'm not sure I want to sift through thousands (tens of
 thousands?) of transistor part numbers to find what I'm looking for.
>>>
>>> You should never have to sift! We need to create a standardized way to
>>> write description that is easily searched. This is how I manage my
>>> library - it's quite large, but I know how the descriptions work and I
>>> can just start typing what I'm looking for.
>>>
 I wonder how well Henner's component chooser search code would handle
 that
 number of symbols.
>>>
>>> Optimize it if it can't! Searching through even *millions* of data
>>> points is a solved problem in computing.
>>
>> As I said, I wouldn't worry about that. In my day-job I am working
>> with billions of things to search from, so this is peanuts.
>>
>> -h
>>
>
> If only we could create the symbol libraries that fast.  Now that would
> useful!

:) Yes, this is why I'd like to see DigiKey, Mouser, Farnell (or even
the manufacturers themself: TI, Atmel, Microchiop, Analog Devices...)
have a standardized way to export their portfolio.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-05 Thread Chris Pavlina
Thank you for saying this - op amps are the perfect example of why 
relying on standard pinouts is a *terrible* idea!

Let's look at a few eight-pin DIP/SOIC/TSSOP dual op amps, shall we?

TL072?  out in- in+ v- in+ in- out v+
LM358?  out in- in+ v- in+ in- out v+
MC33078?out in- in+ v- in+ in- out v+
NE5532? out in- in+ v- in+ in- out v+
MCP6002?out in- in+ v- in+ in- out v+
AD8552? out in- in+ v- in+ in- out v+
LF353?  out in- in+ v- in+ in- out v+
LT1013*N?   out in- in+ v- in+ in- out v+
LT1013*S?   in+ v- in+ in- out v+ out in-

See the problem?

On Fri, Jun 05, 2015 at 08:46:26PM +0200, Lorenzo Marcantonio wrote:
> On Fri, Jun 05, 2015 at 11:08:19AM -0700, Andy Peters wrote:
> > I realize that there’s an argument that goes, “Well, the library will be 
> > super big if we want to support all of the possible transistors out there.” 
> > And that argument is silly. Does anyone use a generic op-amp symbol instead 
> > of placing a TL072ACD (there it is again, symbol name calling out 
> > footprint!) on the schematic? No, of course not. So why is that OK for 
> > transistors? 
> 
> I do that actually before chosing the op amp:D industry standard pinouts
> are useful, and the dual amp is the perfect example!
> 
> -- 
> Lorenzo Marcantonio
> Logos Srl
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Eldar Khayrullin
Maybe add new file format "components library" that consist something 
like that:


##
EESchema-COMP-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as 
components library format.


Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load sch 
symbol and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS and 
footprint field with footprint name].


I think this is easy way to add part and add new possibility.

 * Английский - определен
 * Английский
 * Русский

 * Английский
 * Русский

<#>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Eldar Khayrullin

Fix previous:

Maybe add new file format "_parts_ library" that consist something like 
that:


##
EESchema-_PARTS_-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as _parts_ 
library format.


Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load sch 
symbol and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS and 
footprint field with footprint name].


I think this is easy way to add part and add new possibility.

06.06.2015 11:44, Eldar Khayrullin пишет:
Maybe add new file format "components library" that consist something 
like that:


##
EESchema-COMP-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as 
components library format.


Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load 
sch symbol and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS and 
footprint field with footprint name].


I think this is easy way to add part and add new possibility.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Eldar Khayrullin

Addition.
New cache component assignments:

PART_SYMBOL -> component symbol
PART_ID -> component field "Value"
PART_FOOTPRINT ->component field "Footprint"
[PART_PINS] -> [components pins] // accordance part PINS table


06.06.2015 11:49, Eldar Khayrullin пишет:

Fix previous:

Maybe add new file format "_parts_ library" that consist something 
like that:


##
EESchema-_PARTS_-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as _parts_ 
library format.


Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load 
sch symbol and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS and 
footprint field with footprint name].


I think this is easy way to add part and add new possibility.

06.06.2015 11:44, Eldar Khayrullin пишет:
Maybe add new file format "components library" that consist something 
like that:


##
EESchema-COMP-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as 
components library format.


Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load 
sch symbol and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS 
and footprint field with footprint name].


I think this is easy way to add part and add new possibility.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Vesa Solonen
06/06/15, 11:44, Eldar Khayrullin kirjoitti:
> Maybe add new file format "components library" that consist something
> like that:
> 
> ##
> EESchema-COMP-LIBRARY Version x.x
> 
> PART "part_id"
> SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
> FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
> PINS
> #sch_symb_pinpcb_footprint_pin// pins assignment
> 12
> 24
> 4A
> ENDPINS
> ENDPART

This kind of structure will be needed and abit more to manage pin and
gate swapping... Please guys spend some time searching the archives, I
promise it pays off by saving poor keyboards ;)

Pin and gate swapping means swapping equivalent function pins (multiple
inputs of a AND gate or MCU ports) in a part/component and gate swapping
meand swapping equivalent funtion units in multi-part component (e.g.
dual opamp or quad NAND gate) to optimize layout.

Currently such is completely manual in Kicad.

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Eldar Khayrullin

Not fullyunderstood. I meant that part libs is complement component libs
but don't change current components using. Part libs are optional for using.

06.06.2015 15:19, Vesa Solonen пишет:

06/06/15, 11:44, Eldar Khayrullin kirjoitti:

Maybe add new file format "components library" that consist something
like that:

##
EESchema-COMP-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

This kind of structure will be needed and abit more to manage pin and
gate swapping... Please guys spend some time searching the archives, I
promise it pays off by saving poor keyboards ;)

Pin and gate swapping means swapping equivalent function pins (multiple
inputs of a AND gate or MCU ports) in a part/component and gate swapping
meand swapping equivalent funtion units in multi-part component (e.g.
dual opamp or quad NAND gate) to optimize layout.

Currently such is completely manual in Kicad.

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-06 Thread Andy Peters

> On Jun 6, 2015, at 1:44 AM, Eldar Khayrullin  wrote:
> 
> Maybe add new file format "components library" that consist something like 
> that:
> 
> ##
> EESchema-COMP-LIBRARY Version x.x
> 
> PART "part_id"
> SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
> FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
> PINS
> #sch_symb_pinpcb_footprint_pin// pins assignment
> 12
> 24
> 4A
> ENDPINS
> ENDPART
> 
> # next parts
> # ...
> ##
> 
> Schematic will can understand as current sch library format as components 
> library format.
> 
> Process to add part to schema:
> Click "Place component" -> select part from list -> [schematic load sch 
> symbol and add to cache library
> new component with reassign pins in accordance fields PINS-ENDPINS and 
> footprint field with footprint name].
> 
> I think this is easy way to add part and add new possibility.

What problem is this trying to solve?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-07 Thread Eldar Khayrullin

No copy sch symbols, no copy pcb footprints,
more ready parts with same sch symbol and footprint, but different
pins assignment.

07.06.2015 05:11, Andy Peters пишет:

On Jun 6, 2015, at 1:44 AM, Eldar Khayrullin  wrote:

Maybe add new file format "components library" that consist something like that:

##
EESchema-COMP-LIBRARY Version x.x

PART "part_id"
SYMBOL "sch_symbol_lib_name" "sch_symbol_name"
FOOTPRINT "pcb_footprint_lib_name" "pcb_footprint_name"
PINS
#sch_symb_pinpcb_footprint_pin// pins assignment
12
24
4A
ENDPINS
ENDPART

# next parts
# ...
##

Schematic will can understand as current sch library format as components 
library format.

Process to add part to schema:
Click "Place component" -> select part from list -> [schematic load sch symbol 
and add to cache library
new component with reassign pins in accordance fields PINS-ENDPINS and 
footprint field with footprint name].

I think this is easy way to add part and add new possibility.

What problem is this trying to solve?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Andy Peters

> On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin  wrote:
> 
>> What problem is this trying to solve?

> No copy sch symbols, no copy pcb footprints, 
> more ready parts with same sch symbol and footprint, but different
> pins assignment.

I still don’t understand why you think there are problems.

Let’s talk op-amps for the moment.

Does your schematic library have a generic op-amp which you place on every 
design? Do you then go into the schematic and modify the symbol you placed so 
that it calls out TL072 and the correct unit, and then do you go in and also 
add the desired footprint?

If so, for the love of G-d, WHY? That is a recipe for disaster.

Why not just have in your library a few of your favorite op-amps: TL072ACD, 
OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers 
and as such have the footprint encoded into them. And, each symbol has the 
correct footprint embedded in it. 

Do you consider this “unnecessary duplication” in that each of these dual 
op-amps has the same symbol and uses the same footprint (SOIC-8)?

It is MUCH harder to make an expensive mistake if the symbol — the “component” 
— is “complete,” in that it has the correct pin-out which matches the footprint.

Your suggestion of a "components library” solves a problem which doesn’t 
actually exist.

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Adam Wolf
Hi folks!

This is just to say my original question has been answered quite a few
replies up, which was that KiCad still supports both philosophies, and the
library team is going this way.

Thanks everyone!  I'm certain there's a bunch more discussion we can do on
this, but I'm glad I got the clarification from Wayne that I did.

Adam Wolf

On Mon, Jun 8, 2015 at 11:42 AM, Andy Peters  wrote:

>
> > On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin 
> wrote:
> >
> >> What problem is this trying to solve?
>
> > No copy sch symbols, no copy pcb footprints,
> > more ready parts with same sch symbol and footprint, but different
> > pins assignment.
>
> I still don’t understand why you think there are problems.
>
> Let’s talk op-amps for the moment.
>
> Does your schematic library have a generic op-amp which you place on every
> design? Do you then go into the schematic and modify the symbol you placed
> so that it calls out TL072 and the correct unit, and then do you go in and
> also add the desired footprint?
>
> If so, for the love of G-d, WHY? That is a recipe for disaster.
>
> Why not just have in your library a few of your favorite op-amps:
> TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor
> part numbers and as such have the footprint encoded into them. And, each
> symbol has the correct footprint embedded in it.
>
> Do you consider this “unnecessary duplication” in that each of these dual
> op-amps has the same symbol and uses the same footprint (SOIC-8)?
>
> It is MUCH harder to make an expensive mistake if the symbol — the
> “component” — is “complete,” in that it has the correct pin-out which
> matches the footprint.
>
> Your suggestion of a "components library” solves a problem which doesn’t
> actually exist.
>
> -a
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Adam Wolf
Andy,

Regardless of the technical merits of the above replies, I want to make
something clear.

When I use eeschema, sometimes I am making sketches to send to remote team
members, and I definitely don't know the part number at that point.

This is what I was doing for the original email.  I was laying out a
schematic with a pfet and an opamp.  I knew what opamp I wanted to use, but
I didn't know what pfet I wanted, because I was creating a sketch of a
circuit so I could send to a collaborator.

I'm not suggesting we change the public library footprints, or even make
any changes to anything.  I was mostly wondering if a feature I use
frequently was going away.

Adam Wolf
Cofounder and Engineer
Wayne and Layne

On Mon, Jun 8, 2015 at 11:53 AM, Adam Wolf 
wrote:

> Hi folks!
>
> This is just to say my original question has been answered quite a few
> replies up, which was that KiCad still supports both philosophies, and the
> library team is going this way.
>
> Thanks everyone!  I'm certain there's a bunch more discussion we can do on
> this, but I'm glad I got the clarification from Wayne that I did.
>
> Adam Wolf
>
> On Mon, Jun 8, 2015 at 11:42 AM, Andy Peters  wrote:
>
>>
>> > On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin 
>> wrote:
>> >
>> >> What problem is this trying to solve?
>>
>> > No copy sch symbols, no copy pcb footprints,
>> > more ready parts with same sch symbol and footprint, but different
>> > pins assignment.
>>
>> I still don’t understand why you think there are problems.
>>
>> Let’s talk op-amps for the moment.
>>
>> Does your schematic library have a generic op-amp which you place on
>> every design? Do you then go into the schematic and modify the symbol you
>> placed so that it calls out TL072 and the correct unit, and then do you go
>> in and also add the desired footprint?
>>
>> If so, for the love of G-d, WHY? That is a recipe for disaster.
>>
>> Why not just have in your library a few of your favorite op-amps:
>> TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor
>> part numbers and as such have the footprint encoded into them. And, each
>> symbol has the correct footprint embedded in it.
>>
>> Do you consider this “unnecessary duplication” in that each of these dual
>> op-amps has the same symbol and uses the same footprint (SOIC-8)?
>>
>> It is MUCH harder to make an expensive mistake if the symbol — the
>> “component” — is “complete,” in that it has the correct pin-out which
>> matches the footprint.
>>
>> Your suggestion of a "components library” solves a problem which doesn’t
>> actually exist.
>>
>> -a
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Eldar Khayrullin

I agree with you. Too loudly that this is a problem.
I only suggested own idea as a new feature.

P.s.In my work we use a narrow specific range of parts and make cvpcb 
looks excessive.
For me, it'snot difficult. But for simple users that use pcad it is 
difficult.

They say: whatto dorethe same thing(you can make mistakes).

It was an offer, do not judge strictly.

08.06.2015 19:42, Andy Peters пишет:

On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin  wrote:


What problem is this trying to solve?

No copy sch symbols, no copy pcb footprints,
more ready parts with same sch symbol and footprint, but different
pins assignment.

I still don’t understand why you think there are problems.

Let’s talk op-amps for the moment.

Does your schematic library have a generic op-amp which you place on every 
design? Do you then go into the schematic and modify the symbol you placed so 
that it calls out TL072 and the correct unit, and then do you go in and also 
add the desired footprint?

If so, for the love of G-d, WHY? That is a recipe for disaster.

Why not just have in your library a few of your favorite op-amps: TL072ACD, 
OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers 
and as such have the footprint encoded into them. And, each symbol has the 
correct footprint embedded in it.

Do you consider this “unnecessary duplication” in that each of these dual 
op-amps has the same symbol and uses the same footprint (SOIC-8)?

It is MUCH harder to make an expensive mistake if the symbol — the “component” 
— is “complete,” in that it has the correct pin-out which matches the footprint.

Your suggestion of a "components library” solves a problem which doesn’t 
actually exist.

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


 * Английский - определен
 * Английский
 * Русский

 * Английский
 * Русский

<#>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Heiko Rosemann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/08/2015 06:42 PM, Andy Peters wrote:
> 
>> On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin
>>  wrote:
>> 
>>> What problem is this trying to solve?
> 
>> No copy sch symbols, no copy pcb footprints, more ready parts
>> with same sch symbol and footprint, but different pins
>> assignment.
> 
> I still don’t understand why you think there are problems.
> 
> Let’s talk op-amps for the moment.
> 
> Does your schematic library have a generic op-amp which you place
> on every design? Do you then go into the schematic and modify the
> symbol you placed so that it calls out TL072 and the correct unit,
> and then do you go in and also add the desired footprint?
> 
> If so, for the love of G-d, WHY? That is a recipe for disaster.
> 
> Why not just have in your library a few of your favorite op-amps:
> TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the
> vendor part numbers and as such have the footprint encoded into
> them. And, each symbol has the correct footprint embedded in it.
> 
> Do you consider this “unnecessary duplication” in that each of
> these dual op-amps has the same symbol and uses the same footprint
> (SOIC-8)?
> 
> It is MUCH harder to make an expensive mistake if the symbol — the
> “component” — is “complete,” in that it has the correct pin-out
> which matches the footprint.
> 
> Your suggestion of a "components library” solves a problem which
> doesn’t actually exist.

The "components library" is the approach Eagle uses, and I have a bit
of Eagle experience, so let me try to explain...

In that approach, you do _not_ place just a symbol in a schematic, but
an entire component (maybe a TL072ACD) or a component for which there
are several variants (maybe a TL072A with the variants CD and DE, one
a SOIC8, the other a PDIP8, but same symbol).

This makes the creation of new components and variants very easy, as
long as the symbol and the package (Eagle speak for footprint) exist.
All you have to do is to give it a name and "connect" symbol pins to
footprint pads. This last step is basically what you used to do with
CVPCB, only you do it only once, when you create the component. You
don't have to do it for every TL072ACD in your schematic (where I
agree it's very error prone), and it's more flexible than CVPCB,
because it can connect pin 1 (symbol) to pin 3 (footprint) or pin E
(symbol) to pin 3 (footprint) - so you don't need the
TO220BCE/ECB/CBE/123 footprints.

So you have a single "canonical" version of each footprint and symbol.
No need to copy symbols for creating new components, no need to update
or even touch all your OP-Amps when the one you based your symbol on
shows a bug.

Or in other words: It takes your "library with a few of your favourite
OP-Amps, each with the correct footprint embedded" one step further:
The components only link to symbols and footprints. If you place a
component in a schematic, it shows the symbol linked from it, and
stores the information of available footprints to be used when you
create a PCB from the schematic. If you place a component on a PCB, it
shows one of the footprints it links to (or a selection dialogue).

Maybe this clears the mud a little?

Heiko
- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlV16sQACgkQ/Vb5NagElAVh+ACfQIRaQ6+LJqjxQFOYGQUA7ssp
zOsAn1tT8g+a+25dzAdqQ3nAH8muUksb
=hzJ/
-END PGP SIGNATURE-


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Andy Peters

> On Jun 8, 2015, at 12:19 PM, Heiko Rosemann  wrote:
> 
> The "components library" is the approach Eagle uses, and I have a bit
> of Eagle experience, so let me try to explain...
> 
> In that approach, you do _not_ place just a symbol in a schematic, but
> an entire component (maybe a TL072ACD) or a component for which there
> are several variants (maybe a TL072A with the variants CD and DE, one
> a SOIC8, the other a PDIP8, but same symbol).
> 
> This makes the creation of new components and variants very easy, as
> long as the symbol and the package (Eagle speak for footprint) exist.
> All you have to do is to give it a name and "connect" symbol pins to
> footprint pads. This last step is basically what you used to do with
> CVPCB, only you do it only once, when you create the component. You
> don't have to do it for every TL072ACD in your schematic (where I
> agree it's very error prone), and it's more flexible than CVPCB,
> because it can connect pin 1 (symbol) to pin 3 (footprint) or pin E
> (symbol) to pin 3 (footprint) - so you don't need the
> TO220BCE/ECB/CBE/123 footprints.

For the record: I’ve never used CvPCB, and I’ve always thought that it was a 
mistake. I have always embedded footprint (and custom part numbers) into my 
schematic symbols.

> So you have a single "canonical" version of each footprint and symbol.
> No need to copy symbols for creating new components, no need to update
> or even touch all your OP-Amps when the one you based your symbol on
> shows a bug.
> 
> Or in other words: It takes your "library with a few of your favourite
> OP-Amps, each with the correct footprint embedded" one step further:
> The components only link to symbols and footprints.

OK, so this “component” library is something that maps symbols (from a symbol 
library) and footprints (from a footprint library) into a third library, in 
much the same was as Altium does with their Integrated libraries. 

> If you place a
> component in a schematic, it shows the symbol linked from it, and
> stores the information of available footprints to be used when you
> create a PCB from the schematic.

A given component should have exactly ONE available footprint. If your opamp 
comes in PDIP-8 and SOIC-8, those are two different components.

> If you place a component on a PCB, it
> shows one of the footprints it links to (or a selection dialogue).

Here’s a question: why would you place a component on a PCB? That component has 
no connectivity information, and Kicad won’t (and IMHO, shouldn’t) let you edit 
the netlist in pcbnew. (How should it regenerate the schematic when you do 
that?)

So I see what you’re saying … the “symbol” library should contain symbols only, 
and have no connection to a footprint, and you need a component library to map 
a symbol with a footprint (and a 3D model, and a custom part number for the 
BOM). The engineer doing the design interacts only with the component library; 
only the librarian needs to be concerned with the symbol and the footprint 
libraries.

Gotcha.

From the perspective of the user who considers each symbol to be a component 
(again, that is: embedded footprint, embedded custom part number, different 
symbols for TL072ACD and TL072ACP) and ignores the CvPCB crap, there’s not much 
benefit to a separate component library. That is especially true given the 
inability to edit a netlist in pcbnew.

-a
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Heiko Rosemann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/08/2015 10:41 PM, Andy Peters wrote:
> 
>> On Jun 8, 2015, at 12:19 PM, Heiko Rosemann
>>  wrote:
>> 
>> So you have a single "canonical" version of each footprint and
>> symbol. No need to copy symbols for creating new components, no
>> need to update or even touch all your OP-Amps when the one you
>> based your symbol on shows a bug.
>> 
>> Or in other words: It takes your "library with a few of your
>> favourite OP-Amps, each with the correct footprint embedded" one
>> step further: The components only link to symbols and
>> footprints.
> 
> OK, so this “component” library is something that maps symbols
> (from a symbol library) and footprints (from a footprint library)
> into a third library, in much the same was as Altium does with
> their Integrated libraries.

Yes, it is for Eagle (although components, footprints and symbols were
all saved in the same file when I last used Eagle, but still during
the schematic and PCB design phase you only interact with components)
and I guess that's what Eldar tried to achieve too.

>> If you place a component in a schematic, it shows the symbol
>> linked from it, and stores the information of available
>> footprints to be used when you create a PCB from the schematic.
> 
> A given component should have exactly ONE available footprint. If
> your opamp comes in PDIP-8 and SOIC-8, those are two different
> components.

Why? There's a good point for the opposite: Making different PCBs (SMD
for series production/no SMD for prototyping/hobbyists or different
casings) from a single - consistent - schematic. Otherwise you are
going to run into trouble because you'll have multiple schematics of
the same system and you need to change something on the logical
(schematic) side.

Of course the different "variants" of a single component would also
need different BOM numbers, different 3D models etc. and stuff like
the BOM needs to be generated from the PCB, not from the schematic, in
this use case.

>> If you place a component on a PCB, it shows one of the footprints
>> it links to (or a selection dialogue).
> 
> Here’s a question: why would you place a component on a PCB? That
> component has no connectivity information, and Kicad won’t (and
> IMHO, shouldn’t) let you edit the netlist in pcbnew. (How should it
> regenerate the schematic when you do that?)

1) For very simple layouts, you may not need a schematic at all, but
need a PCB file for manufacturing the board, so you just place the
components and draw lines for tracks.
2) Other software (and maybe also kicad someday?) can do
back-annotation, i.e. netlist editing from the PCB editor. That's
where adding a component on a PCB really comes into play (and deleting
is still more relevant than adding)

> So I see what you’re saying … the “symbol” library should contain
> symbols only, and have no connection to a footprint, and you need a
> component library to map a symbol with a footprint (and a 3D model,
> and a custom part number for the BOM). The engineer doing the
> design interacts only with the component library; only the
> librarian needs to be concerned with the symbol and the footprint
> libraries.
> 
> Gotcha.

True, the big advantage would be on the librarian's side - much easier
to keep all the components correct and on the same up-to-date symbol
and footprint set when you only have to do pin-to-pad mappings instead
of copying/drawing symbols. Imagine just 20 OP-Amps, and then for some
reason you (or your customers) want a different font size in the
schematic - in a non-component-embedded-footprint-symbol approach
you'd need to touch every single symbol, in a
component-as-symbol-footprint-pin-pad-mapping approach there's only
one file to touch: The OP-Amp symbol.

> From the perspective of the user who considers each symbol to be a
> component (again, that is: embedded footprint, embedded custom part
> number, different symbols for TL072ACD and TL072ACP) and ignores
> the CvPCB crap, there’s not much benefit to a separate component
> library. That is especially true given the inability to edit a
> netlist in pcbnew.

If there was a library for every part the user would ever want to use,
that would be true. I have yet to meet a PCB designer who never
created any library components (as in: Choosing symbol, footprint,
doing pin association) though...

But this topic has crept up on this list about every other year (I'd
say) and nobody (me included) is putting any coding effort (or similar
contribution to kicad) behind it, so we might as well drop the
conversation here - I just wanted to drop in because I felt you and
Eldar weren't really discussing the same thing ;)

Good night from Germany,
Heiko
- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlV2COgACgkQ/Vb5NagElAUL4gCgoAWeazdFoUnB85HN/aQ20EYb
WRwAoI1ZsTrhAR0qlu14e2fpHoqc6y/A
=b0yI
-END PGP SIGNATURE-


__

Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Chris Pavlina
On Mon, Jun 08, 2015 at 11:28:08PM +0200, Heiko Rosemann wrote:
> > A given component should have exactly ONE available footprint. If
> > your opamp comes in PDIP-8 and SOIC-8, those are two different
> > components.
> 
> Why? There's a good point for the opposite: Making different PCBs (SMD
> for series production/no SMD for prototyping/hobbyists or different
> casings) from a single - consistent - schematic. Otherwise you are
> going to run into trouble because you'll have multiple schematics of
> the same system and you need to change something on the logical
> (schematic) side.

I explained this already. Look at the pinouts for the different 
footprints of LT1013. Only a very inexperienced person would claim that 
assuming different footprints have the same pinout is a good idea.

--
Chris

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-08 Thread Andy Peters

> On Jun 8, 2015, at 2:28 PM, Heiko Rosemann  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 06/08/2015 10:41 PM, Andy Peters wrote:
>> 
>>> On Jun 8, 2015, at 12:19 PM, Heiko Rosemann
>>>  wrote:
>>> 
>>> So you have a single "canonical" version of each footprint and
>>> symbol. No need to copy symbols for creating new components, no
>>> need to update or even touch all your OP-Amps when the one you
>>> based your symbol on shows a bug.
>>> 
>>> Or in other words: It takes your "library with a few of your
>>> favourite OP-Amps, each with the correct footprint embedded" one
>>> step further: The components only link to symbols and
>>> footprints.
>> 
>> OK, so this “component” library is something that maps symbols
>> (from a symbol library) and footprints (from a footprint library)
>> into a third library, in much the same was as Altium does with
>> their Integrated libraries.
> 
> Yes, it is for Eagle (although components, footprints and symbols were
> all saved in the same file when I last used Eagle, but still during
> the schematic and PCB design phase you only interact with components)
> and I guess that's what Eldar tried to achieve too.
> 
>>> If you place a component in a schematic, it shows the symbol
>>> linked from it, and stores the information of available
>>> footprints to be used when you create a PCB from the schematic.
>> 
>> A given component should have exactly ONE available footprint. If
>> your opamp comes in PDIP-8 and SOIC-8, those are two different
>> components.
> 
> Why? There's a good point for the opposite: Making different PCBs (SMD
> for series production/no SMD for prototyping/hobbyists or different
> casings) from a single - consistent - schematic. Otherwise you are
> going to run into trouble because you'll have multiple schematics of
> the same system and you need to change something on the logical
> (schematic) side.

Maybe the hobbyist will do a through-hole prototype and then an SMD version for 
“production,” but here in the real world, we never do that. Really. It just 
doesn’t happen. Stuffing boards with SMD parts is a solved problem.

And, as Chris Pavlina has noted in a reply on this thread, it’s folly to assume 
that a part that is available in different packages has the same pinout for all 
of those packages. LT1371, for example, has an 20-pin wide SO package in 
addition to two 7-pin packages (TO-220 and DDR).  

> Of course the different "variants" of a single component would also
> need different BOM numbers, different 3D models etc. and stuff like
> the BOM needs to be generated from the PCB, not from the schematic, in
> this use case.

Right, and that argues AGAINST having one schematic for wildly-different 
implementations. It’s bad enough trying to keep track of stuffing options, 
which only affect the BOM and assembly, but to add in the option for a 
different PCB with different footprints? That’s a new design.

> 
>>> If you place a component on a PCB, it shows one of the footprints
>>> it links to (or a selection dialogue).
>> 
>> Here’s a question: why would you place a component on a PCB? That
>> component has no connectivity information, and Kicad won’t (and
>> IMHO, shouldn’t) let you edit the netlist in pcbnew. (How should it
>> regenerate the schematic when you do that?)
> 
> 1) For very simple layouts, you may not need a schematic at all, but
> need a PCB file for manufacturing the board, so you just place the
> components and draw lines for tracks.

If the layout is that simple, shouldn’t drawing the schematic be equally 
simple? How hard is it, really? 


> 2) Other software (and maybe also kicad someday?) can do
> back-annotation, i.e. netlist editing from the PCB editor. That's
> where adding a component on a PCB really comes into play (and deleting
> is still more relevant than adding)

So let’s say you are doing your layout and you add an inverting op-amp circuit, 
so you need the op-amp, two resistors, and maybe two decoupling caps. You add 
the parts to the artwork, then you edit the netlist to connect those parts, and 
then you add values to the resistors and capacitors. Now to back-annotate to 
the schematic.

Imagine what kind of mess will be made of the schematic when you do that. How 
is the back-annotation thing supposed to know what looks best to the human? I 
mean, even in the “we need this feature” case where you are simply changing the 
connections to an FPGA by moving some traces around, the back-annotation would 
look like crap.

And, seriously, that’s FASTER than just editing the schematic properly in the 
first place, regenerating and importing the netlist, then moving the parts to 
where the need to be and routing? It’s really just crazy.

The only back-annotation I want to see is where once place and route is 
finished, you just tell the tools to renumber the reference designators in a 
geographical fashion and update the schematic with those new values.

>> From the perspective of the user who consi

Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-09 Thread Heiko Rosemann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/08/2015 11:36 PM, Chris Pavlina wrote:
> On Mon, Jun 08, 2015 at 11:28:08PM +0200, Heiko Rosemann wrote:
>>> A given component should have exactly ONE available footprint.
>>> If your opamp comes in PDIP-8 and SOIC-8, those are two
>>> different components.
>> 
>> Why? There's a good point for the opposite: Making different PCBs
>> (SMD for series production/no SMD for prototyping/hobbyists or
>> different casings) from a single - consistent - schematic.
>> Otherwise you are going to run into trouble because you'll have
>> multiple schematics of the same system and you need to change
>> something on the logical (schematic) side.
> 
> I explained this already. Look at the pinouts for the different 
> footprints of LT1013. Only a very inexperienced person would claim
> that assuming different footprints have the same pinout is a good
> idea.

Different footprints for the same component are not required to have
the same pinout. You don't have to touch the schematic (there you only
see IN1+, IN1-, OUT1 etc. - no information about actual pinout), when
you change footprints on the PCB without breaking the connectivity as
defined in the schematic.

Simplest use case: Transistor in SOT23. Existing variant connects pin
B in symbol to pad 1 in footprint, pin C in symbol to pad 2 in
footprint, pin E in symbol to pad 3 in footprint. Now you would save a
few vias with a different alignment and your transistor is available
in reverse, so you create a second variant, connect pin B to pad 3,
pin C to pad 2, pin E to pad 1. Don't need to copy symbols, don't need
to copy footprints to match pin and pad numbers - and when you route
the PCB, you right-click on the footprint and say "change variant",
done. In the kicad-model this use case leads to SOT23-123, SOT23-321,
SOT23-BCE, SOT23-ECB etc. cluttering the footprint list. It's there
already...

Again, I'm explaining how Eagle does it (though it doesn't go all the
way - if you have different footprints with different pad numbers,
like a PDIP40 and a TQFP44, you need to create two components) and
where I have actually used it. I'm not saying "that's how kicad needs
to do it" (not my place to say this, with no code contributions from
myself...), but I do believe the options should be clear.

BR, Heiko
- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlV2kPIACgkQ/Vb5NagElAWq0gCdETr2IauqQ+IvvQLb9dfAT6M4
FG4AoLOg+ejINxTgLGhTtNZP010IBBOF
=rE20
-END PGP SIGNATURE-


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Kicad-developers] Schematic Symbol Philosophy?

2015-06-09 Thread Eldar Khayrullin

Thank you Heiko.
Sorry for my broken english.
Heiko understood what I mean.

I add. For example:
I have OPAMP. I use 2 symbols OPAMP2 (2 in body), OPAMP4 and I use 3 
footprints.
I make 6 components (6 files only with different pin assignment). And if 
I'll be want to add new

opamps I only add components files.
You should have 6 different symbols (a different only with pins 
assignment). If you want to add

new opamps you should be add new symbols (copy old symbols, rename pins).

Thanabstractioncloser to the real objectthen the easier it isto operate.
Symbol and footprint are only abstractions. Component is it more closer 
to real object.
Need to try operate with real objects (object oriented developing). 
Simple users are like that,

because it is more simple for them.



09.06.2015 00:28, Heiko Rosemann пишет:
Yes, it is for Eagle (although components, footprints and symbols were 
all saved in the same file when I last used Eagle, but still during 
the schematic and PCB design phase you only interact with components) 
and I guess that's what Eldar tried to achieve too.


 * Английский - определен
 * Английский
 * Русский

 * Английский
 * Русский

<#>
для них
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp