Re: [Kicad-developers] on incorrect polygon behavior

[Tomasz Wlostowski]

On 02.06.2015 20:32, Wayne Stambaugh wrote:
>> > I'm almost done with SHAPE_POLY_SET class for the geometry library, a
>> > Clipper wrapper adding some missing Clipper features needed in Kicad
>> > (e.g. polygon fracturing). I'll send a patch soon (affecting only
>> > AddClearanceAreasPolygonsToPolysList), so that we can compare how well
>> > it performs wrs to Boost.Polygon.
>> > 
>> > Cheers,
>> > Tom
> Great work Tom.  Thanks.
> 
> Wayne
> 
Hi,

It took me a bit longer than initially anticipated to write the
fracturing (polygon with holes -> single outline conversion) algorithm
that was missing in Clipper. I managed to generate correct zones and the
algorithm does not crash on the test cases that were crashing
Boost.Polygon. My plan is now to:
- clean SHAPE_POLY_SET code and send the patch asap (perhaps Monday, I'm
out for the weekend),
- optimize fracturing, which is taking most of the calculation time. To
my surprise, Clipper performs calculations faster than BPL,
- look into possibility of having a single polygon set class, merging
the functionality of CPolyLine, CPOLYGONS_LIST and all BPL-derived classes,
- keep "fallback" BPL zone code which could be switched on in the
preferences.
- add an option to dump zone geometry (outline, holes, thermals, full
poly) to a text file while refilling zones.

The last two options are temporary - to gather confidence in Clipper,
compare the performance of BPL/Clipper and, in case of trouble, obtain
test cases for both backends.

Cheers,
Tom

___
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?

[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?

[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?

[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?

[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?

[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?

[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

[Kicad-developers] Default page layout

[Rick]

When one has made a new page layout using Pl_Editor, how does one make
this the new default? The Pl_Editor reference manual is silent on this
issue.
-- 
Rick Jenkins 
Hartman Technica   http://www.hartmantech.com
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

___
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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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