While working with Kicad I’ve noticed some peculiar behaviour. Although the schematic clearly shows there’s no connection between any pins on a DIL16, it still connected both power inputs (Ucc and GND) in the rats-nest in PCBnew. I can manually correct it by editing the .net and .xml files, but it shouldn’t happen, IMO. I didn’t test it with other sockets.
Version info:
Application: kicad
Version: 4.0.6 release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1009,GCC 5.3.0,wx containers,compatible with 2.8)
Platform: Linux 4.8.15-1 x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.62.0
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
USE_FP_LIB_TABLE=HARD_CODED_ON
BUILD_GITHUB_PLUGIN=OFF
It sounds like you are fighting the “hidden power pins” feature. To summarize the story, at some time in the past, somebody decided that the behavior you described SHOULD happen. Search this Forum with “hidden power pins” as a search seed if you want to read a lot of discussion and history on this topic.
To verify this, open the schematic symbol in the symbol editor. Look for pin symbols displayed in a light grey color. These are the hidden pins.
To solve your problem, I would create a new schematic symbol. I suppose you could start from scratch, but I’d probably just delete the power pins from the symbol you have. Then - this is a really important part - save the symbol in a different library with a new name.
Add the new library to your library list. Replace the symbol in your schematic with this newly created symbol, generate a new netlist, and import it into PCBNew with “Exchange Footprint” set to “Change”. That should solve your problem.
I kinda understand why this feature was introduced and it can be helpful, but it does then put great responsibility on those creating/maintaining the various libraries to separate the power supply pins to individual nets. This might not have always been the case
As an aside, I had noticed the hidden power pins feature and enabled its visibility in my schematics and subsequently also put ‘no_connect’ on each of the pins (2 units, so 4 power pins). Didn’t stop the described behaviour though.
I’m not looking forward to manually change each/all sets of power pins in the various libraries I use, but it might be the best (and only) option to prevent a jungle of separate libraries for the various projects I have drawn up so far.
I think the hidden power pins were primarily used in the discrete logic libraries (74xx, CMOS4000, etc). Recently, some of those libraries have been edited to remove the hidden pins - you should be able to download the new versions from github. I don’t think I ever found a hidden power pin in the world of opamps, 3-terminal regulators and discrete transistors where I live.
Yes, it was indeed a CMOS IC. I had a look at the relevant library and lo and behold, the only chip in it that has both GND and Vcc marked as VDD was precisely the one I used (FYI: 4027 in the IEEE library)
I’ve now made a copy of this library, edited the 4027 chip and reloaded it in the schematic. The (faulty) connection in PCBnew is now gone
Sadly, I can’t load the Github libraries as the package manager of my distro has not included the Github entries in the make file. (FYI: I use Funtoo, a Gentoo derivative) I may need to put in a request to do so.
These have another trap for the unwary. Duals and quads show power pins repeated on each unit, so it is all too easy to short two power supplies together
It was mentioned briefly in one of the threads about hidden pins. There doesn’t seem to be a fix that everybody agrees is “good”. The problem is really no different than with the multi-gate logic packages: which of the several units should have the power pins attached, or should they appear as a separate (non-interchangeable) unit?
I just did a project for someone that likes to see it laid out the way the chip is laid out. That made it easy because I had to do it the way they wanted it and made my own symbol. I still made it in two units which irritated him slightly. I put the second unit above each chip in this case though so it was fairly obvious. The power pins in the middle of the chip makes a mess when you are interconnecting opamps. Is it my poor memory or years ago, weren’t power and ground at the end of the chip? Made decoupling so much easier. I have an old board laid out that way and the decouple capacitor sits at the head of every chip.
You can download the libraries to your local disk with any browser. Indeed, I always work with local libraries as I think online libs are a potencial issue: they can be updated and break my designs.
Having them in the middle is better for emi reasons. (smaller loop.)
Having them on the end made it easier on two layer pcbs to connect them to power lanes. (That’s why they originally where build this way.)
Sadly for logic chips the middle arrangement never really took of.
Are we talking about symbol or footprint libs?
For footprint libs just run the library wizard, select github and follow the instructions.
(If you want local setup make sure you choose a location where you have write access.)
For symbol libs have a look at the location where your libs are installed by the installer of your operating system. There are much more libs installed than are added to new projects by default. (If you have any symbol libs, you get the libs from github. But the once tagged with your release number.)
More details see: (The first few answers are wrong. I got confused between footprint and symbol libs. If you are asking about footprint libs the first few answers might be a good read for you.)
Many thanks for the additional replies and info gents!
Here’s the error I get regarding the Github libs:
Error loading netlist.
IO_ERROR: BUILD_GITHUB_PLUGIN not enabled in cmake build environment
from /home/portage/tempdir/portage/sci-electronics/kicad-4.0.6/work/kicad-4.0.6/pcbnew/io_mgr.cpp : PluginFind() : line 99
The location /home/portage is owned by root and I’ve changed to this location manually as the original location elsewhere in the tree was too small (60 GB SSD, vs a 2TB HDD for /home). As said, this is (most likely) an issue for the maintainer of the Gentoo package of Kicad rather then a general bug. Having said that, the requested .cpp file itself isn’t present at all and so is most of the path to it. I may need to rerun Portage with additional options to keep or re-instate the build environment.
Using the github plugin is not the same thing as using the github libraries. Anyway, the symbol libraries are not accessed by github plugin.
“Downloading the github libraries” can simply mean downloading a zip of the official libs (which happen to be on github).
If you don’t have the github plugin, then you will need to remove any plugin type=github entries from the footprint library table and replace them with type=KiCad, and location on your disk.
(FYI: 4027 in the IEEE library)