I read through the archives and couldnt find the same trouble.
I used PCAD my entire life and try to see if open source is not similar alternative as PCAD sort of fizzled out. It was really good back then.
What baffles me about KiCAD is that the netlist is completely botched and does not remotely resemble the schematic.
I check with hold ing down G and moving placement parts and see that everything is connected. Unfortunately the netlist leaves out connections in nets and then brutally attach the net to something completely different not even connected in the schematic.
Maybe there is something I misunderstand with passive labels ?
As is KiCad is not usable at all with these netlist problems modulo that I misunderstand something obvious.
First. What version of Kicad are you using and what OS? The problems of things being connected to wrong nets is unlikely. Kicad has a large user base and these things would get picked up. You might try giving nets names/labels so that the netlist is more readable and then it might make more sense.
The trouble I see here in the netlist is that Net 1 connects Sw5 Pins 14 & 18, which is correct but from the schematic it is obvious that Pin 22 is also connected. I did check that it is so by doing G => move
Searching for Pin 22 in the netlist, there is only one entry and it seems to be horrendoulsy misplaced.
If you look close to the end the Net 17 “X1 X1” connects this Pin 22 of switch 5A to completely absurd wrong pins namely Sw4 Pin1 and Sw1 Pin 8 !!! ???
This is clearly incorrect from the schematic.
I tried placing junctions to force reconnect on points it is not really necessary and got rid of some connection error (See Z2 passive Tab) connecting a wire between pins. That one I can understand as pin to pin connections should not really be allowed and the Passive Tab is seemngly defined as just another placement library object rather than a net-class object. So that is understandable why I should do the latter, but the completely wrong netlist generated for SW5 pins 22 14 &18 is really way off.
As far as I checked grid was 50mil.Thanks. That is a bit silly to connect to the grid. It means you shouldnt even have a variable grid. You are probably right. but that kills Kicad for me. I think that is a serious conceptual flaw to do things like that. Pretty bad to have connections take place that is not indicated by the schematic. Probably started as a good idea and then it started to bite later, but could not be removed as it is the basic glue that keeps the concept together. Thanks, I think that points out the conceptual flaw with this. I will have to look for something else. It is nice software otherwise, but with this kind of conceptual problems I dont want to venture into the Router and PCB placement sections. It can only be trouble having a variable grid but required connections on the grid and not the schematic.I just checked and the libraries has the same grid resolution than the schematic canvas at 50mil. Given that they are the same, that imho flawed concept will bite. Absolutes always create problems.
A 50mil grid is advisable but not mandatory. The standard library symbols have their pins on the 50mil grid.
When a connection is made, the tiny square of the wire-end and the tiny circle of the pin-end vanish.
Your Kicad version is pretty old, I can’t remember if it is bugfree version.
You should add the current repository https://kicad.org/download/ubuntu/
ppa:js-reynaud/kicad-4
Well I cant help that it does in a fundamental way. I gave an explicit example of pins physically connected on the schematic but clearly not present and even worse connecting to some random other pin. If that doesnt suck then I dont know what does -sorry. You seem to avoid the explicit example showing why it fails and sucks. Maybe a solution is a better answer rather than beating around the bush (netlist) . I did say that it is otherwise very nice, so you are wrong about that. But the netlist layer and interpreter clearly had a bad issue and I shown that it does,
Thanks pedro I already tried that repo and it gave me a 404. It would be really nice if you are right that it might be an old version issue as it is otherwise a great environment. I will see if I can install the latest version. The repo seems to be a problem. It does connect to the launchpad site and calculates keys. See below, but I get a 404 for the site during apt-get update. There seems to be no /js-reynaud/kicad-4/ubuntu directory on launchpad so it will fail.
I will have to do it from source.
gpg: keyring /tmp/tmphjtnm1bp/secring.gpg' created gpg: keyring /tmp/tmphjtnm1bp/pubring.gpg’ created
gpg: requesting key 910F124E from hkp server keyserver.ubuntu.com
gpg: /tmp/tmphjtnm1bp/trustdb.gpg: trustdb created
gpg: key 910F124E: public key “Launchpad PPA for j2010” imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK
I already added this to apt and it throws a 404. Anyway that is a distro issue and not the Netlist issue but thanks for the help. So what can go wrong if you create a schematic symbol that ends up with this netlist mess ? I mean if you create a symbol, then you do enter pin numbers and the software needs to make sure the pin associated with the number is in fact linkable and active for the netlist. I cant see that I could do anything to effect that.
The bug icon in the symbol editor will check if pins are off grid. So if you set the grid to 50mil in both the symbol editor and eeschema and use the bug tool to check that all pins are on the grid, you should be OK. [I am running the Windows nightly, but I believe the bug tool was already there in 4.07].
I know that. I have been using rule-testing in PCAD since the 80’s. The problem here is that the netlist show connections thats not even made in the schematic !!! That is a huge error past just placement and grids. That must be a bug as it actually adds bogus connections not just leave them out ! Rule testing in this case is completely bogus as the netlist routine adds routes which are not on the schematic !!!
This software us used by a lot of people that don’t experience this kind of trouble. That is why the first item on the agenda is to have you upgrade to a current package so we are all on the same page in trying to troubleshoot this. As this is all volunteer supporting out of date versions is going to be tricky because, being free, everybody upgrades to the current stable release. Or worse, the development version.
Debian Old-Stable (Jessie)
Jessie Backport Version: 4.0.7 (KiCad actual version)
The 2014 stable release bzr4027 of KiCad is available in the official Debian repositories for oldstable/jessie. It is not recommended for new designs. Please use the packages from the backport repository for actual versions. Follow the instructions on the Debian Wiki to add the Backport repository to your sources and install the KiCad packages from jessie-backports-sloppy.
Debian Old-Old-Stable
Sure the sources are compiling for about 1 1/2 hours, currently at [ 37%] Building CXX object common/CMakeFiles/common.dir/validators.cpp.o Beats me why its so slow. Been installing from source since 1998 on Linux and this is the slowest install I ever had ! Yippee it hit 38% just now. Crazy as it has a 24 core machine with 64GB memory.
If it would really do that, all of our pcbs would be defect. I don’t even think there is such a bug in any kicad version. (Such terrible bugs are found during the development cycle. Very early on)
So my guess is there might be a missunderstaning regarding the workflow. (or regarding the interpretation of the netlist.)
I read further up that you talk about passive labels. Kicad does not have something like a passive label. A label connects stuff. Always!
regarding your installation problem: What is your operating system? The exact name of it and it’s version.
The symbol “6P4T_ROTARY_SWITCH_INV” appears to be badly wrong, it has duplicate pins. There is one other thing I noticed, one of the connections needs a junction symbol.
I think GIGO applies here. KiCad is working correctly but if you supply bad data it produces unexpected results, same as any other program.
Or worse, the development version. 