kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Keeping the current behavior is fine for users who want to use it.  The
connecting to invisible pins issue needs to be looked at.  The real
issue is the libraries.  We have to decide if we want to make the effort
to convert our symbols away from hidden power pins.  I don't think it's
a good idea to force the user to accept your visibility preference.

On 2/7/2017 2:27 PM, Kristoffer Ödmark wrote:
>>> Invisible pin support has to be maintained.  I'm guessing some users
>>> still prefer it and there are legacy designs which cannot be broken.
> 
> Couldn't invisible pins become visible? As a transition make them grey
> or something?
> 
> Just changing how they are displayed would not break any designs. Not in
> its current implementation. But some support for stacked pins would be
> needed before that.
> 
> - Kristoffer
> 
> 
> On 2017-02-07 20:15, Chris Pavlina wrote:
>> On Tue, Feb 07, 2017 at 01:57:53PM -0500, Wayne Stambaugh 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.
>>
>> And yet, mistakes still do happen, no matter how much checking is done.
>> Software that is intelligently designed in a way that reduces the chance
>> of mistakes is a very good thing, particularly when a lot of money is on
>> the line.
>>
>>>
>>>>
>>>> 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
>>
>> _______________________________________________
>> 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