kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

>
> As I understand it, CvPCB is slated for removal anyway, and the
> filter-by-pin-count functionality only exists there.


I have been informed that I may not be correct on this point. Disregard
this if this is the case - the other points still stand.

On Wed, Feb 8, 2017 at 9:35 AM, Oliver Walters <
oliver.henry.walters@xxxxxxxxx> wrote:

> As for our standard libraries, we would have to get the buy in of our
>> library developers
>
>
> As one of the librarians, there are three current uses of invisible pins
> in the standard libs:
>
> a) Invisible power pins - especially the 74 series libs. This is not a
> behaviour that I like necessarily, and there have been a few discussions on
> github as to how to proceed with improving these libs. No action yet.
>
> b) Stacking multiple pins - Instead of having to connect duplicate pins,
> this allows many schematic pins to be mapped to a single footprint pin. In
> lieu of proper one-to-many mapping (let's get v5 already!!) then this is a
> somewhat acceptable way of achieving this.
>
> c) Marking NC pins - To get the "match by pin-count" functionality (e.g.
> CvPCB) to work, the number of symbol pins must match the number of unique
> nets on the footprint. If the NC pins are not added to the symbol, this
> feature does not work. Making the NC pins visible clutters the symbol.
>
> It is mostly point c) that is the issue here. The functionality achieved
> in b) is not quite so "invisible" to the user as there is at least one
> visible pin to connect to. However under no circumstance should a hidden NC
> pin be able to be connected to "accidentally".
>
> Here are my suggestions for action:
>
> 1) Take no action.
> 2) Remove hidden NC pins as per c). This will break match-by-pin-number,
> and require that fp filters be changed to match the pin count based on the
> name of the footprint. Personally I think this is a good idea as
> match-by-pin-count can be hit-and-miss and requires lots of extra pin data
> added to the symbols.
> 3) Amend the patch I have attached to only ignore pins that are both
> *invisible* and have electrical type *nc*. Perhaps this should be done
> anyway, I cannot fathom a use case for silently connecting invisible nc
> pins.
>
> Personally I like 2) as it means that symbols become less messy. When the
> .sweet format is implemented, and one-to-many is available, I don't see a
> need for invisible pins at all.
>
> Both 2) and 3) could be implemented simultaneously. 2) is a library
> management issue, 3) is a source issue.
>
> As I understand it, CvPCB is slated for removal anyway, and the
> filter-by-pin-count functionality only exists there.
>
> Cheers,
> Oliver
>
> On Wed, Feb 8, 2017 at 5:57 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
> wrote:
>
>> On 2/7/2017 1:15 PM, Andy Peters wrote:
>> >
>> >> On Feb 7, 2017, at 8:16 AM, Nox <noxfiregalaxy@xxxxxxxxx> wrote:
>> >>
>> >> From a user point of perspective I would claim that the issue only
>> raises because there is the possibility to make pins invisible. Maybe
>> someone can explain to me the semantically need of invisible pins in
>> general (beside the fact that kicad needs it to solve n pads: 1 pin and
>> global label issues)? Would be changing the "invisible" flag to a
>> "hide-if-stacked" flag feasable?
>> >
>> > Professional electronics engineers and experienced layout people agree:
>> invisible pins are a stupid idea and they should be banished. If you
>> haven’t been screwed by invisible pins on a schematic, it’s only a matter
>> of time.
>>
>> Maybe the reason I've never been bit by this in 30+ years is that I'm
>> not a professional.  I've never found it particularly dangerous except
>> for new users who don't understand that electronics require power to
>> operate.  Once you get over that hurdle, it's pretty obvious when your
>> footprint power pins aren't connected.  That being said *always* check
>> you symbols and footprints.  I don't care how much you paid from them or
>> from what vendor you got them from, there is always a chance that they
>> are incorrect.  If they are incorrect and you did not check them, that
>> is *your* fault.  That is something I learned my first year out of
>> college.  AFAIK, it still applies.
>>
>> >
>> > I suppose that the original idea for invisible pins began back in the
>> days of SSI and MSI logic, where everything had one power rail called VCC
>> and also a ground rail, and to avoid cluttering up the schematic, it was
>> convenient to make the power pins on each part hidden and give them
>> appropriate net names.
>>
>> It was done so you didn't need to wire a whole bunch of pins in you
>> schematic that you knew needed to be connected to power.  For us old
>> timers, this was obvious.  Maybe they don't teach that in engineering
>> school any more.  It also required less screen real estate.  There were
>> no 28" high resolution monitors way back when.
>>
>> Almost every board I've ever designed has multiple supply rails because
>> I've mostly worked with analog I/O so the multiple supply argument is
>> weak.
>>
>> >
>> > Of course, that’s an immediate fail, as TTL has a +5V rail, and
>> 4000-series CMOS parts could have whatever rail (within reason) the
>> designer deemed appropriate.
>> >
>> > Nowadays, with multiple rails on even simple designs, simply calling a
>> power pin VCC and giving it the netname VCC and hiding it doesn’t work.
>> >
>> > And I see in this thread that there’s a use case — stacking power pins
>> and hiding all but one, so when a wire is added to that one visible power
>> pin it is added to all of them. That one can make a connection to an
>> invisible pin baffles me.
>>
>> Both of these things baffle me.  Stacking pins (visible or not) is much
>> scarier than invisible power pins.  Connecting a wire to an invisible
>> pin just seems confusing to me.  I'm guessing this is something that
>> just got overlooked but fixing it could be tricky.
>>
>> >
>> > Also, consider the technician who is bringing up a new board, or is
>> trying to repair something. S/he wants to see power pins on the schematic,
>> otherwise how can anyone begin to start debugging?
>> >
>> > I understand the desire to avoid cluttering up a schematic by hiding
>> pins. I mean, we deal with monster FPGAs and CPUs here, and generally
>> there’s a page on the schematic just for FPGA power connections (and the
>> decoupling caps and all that). But hiding those pins has zero benefit and
>> increases the chances of an expensive screwup.
>> >
>> > By all means, leave the capability for invisible pins in Kicad. But the
>> standard libraries should never use them (for reasons Chris has mentioned)
>> and their general use should be discouraged.
>>
>> Invisible pin support has to be maintained.  I'm guessing some users
>> still prefer it and there are legacy designs which cannot be broken.  As
>> for our standard libraries, we would have to get the buy in of our
>> library developers.  I'm not sure how receptive they would be to the idea.
>>
>> >
>> > -a
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>