> > 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 < [email protected]> 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 <[email protected]> > wrote: > >> On 2/7/2017 1:15 PM, Andy Peters wrote: >> > >> >> On Feb 7, 2017, at 8:16 AM, Nox <[email protected]> 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 : [email protected] >> > Unsubscribe : https://launchpad.net/~kicad-developers >> > More help : https://help.launchpad.net/ListHelp >> > >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
