In the lower-left corner of the PCBnew, it says this:
So, it says “Unconnected 0”, and below that, it says “not conn 1”. What is the difference?
Do you have an unused pin that doesn’t have a blue X (NC) symbol in your schematic? My guess, and it is only a guess, is that everything that is connected in the schematic is connected in PCBnew but there may be pins that simply aren’t accounted for?
What does DRC say?
Run DRC and after that press list unconnected. Only the result of this tool can be fully trusted.
I don’t think so. My schematic passes ERC.
The “unconnected” tab of DRC is always blank gray, whether I have unconnected nets or not. I was just assuming this was another one of the things in KiCad that doesn’t work. (I’m using KiCad 4.0.6 on OS X 10.9.5.)
You need to click the list unconnected button after you click the run DRC button
1 Like
Thanks, I see now! That was totally non-intuitive…
But, it looks like I don’t have any unconnected net. So I guess I can just ignore the “not conn 1”.
And to further confuse things, DRC reports “No problems found”.
I went through that for half a day yesterday. Actually, I had “Unconnected” reporting " 3 ". So I looked very carefully, nudged a few footprints, dragged a few tracks, and couldn’t find the missing connections. Then I ran DRC, and it didn’t find any errors! So at that point I don’t know if I can trust DRC. I went over the board several more times, with various combinations of layers active, in both OpenGL and Legacy graphics.
I finally DID find one error - two trace segments that overlapped nicely, but their end points were not coincident by a few mils. Corrected that, and “Unconnected” dropped to " 2 ". Ran DRC again, and “Unconnected” dropped to " 1 ". Losing confidence in the tools, I went back to sifting through the whole board with the finest tooth combs I had.
I never found that “Unconnected” link. Grasping at straws, I went back to the schematic, re-generated the netlist, and imported it to PCBNew. Did it once in the “Dry run” mode, displaying ALL of the “Info” messages, going through them line-by-line to make sure all of the components were accounted for, and none were missing. Then I imported the netlist “for real”. Finally, I clicked the “Rebuild Board Connectivity” button in the Netlist dialog window.
I don’t know if “Rebuild Connectivity” was the magic formula or not, but after I closed the Netlist window, the “Unconnected” count was " 0 ", and DRC reported no errors.
Dale
People say that, but it isn’t true. “Start DRC” also checks unconnected…it’s even in the message list.
The various issues around unconnected pads are a bit of pain, especially after I discovered that in OpenGL moving a segment can disconnect it. It would be great if the bad segments/pads weren’t highlighted instead of just arrowed
It seems to be necessary for me. If I click “Start DRC” and then click the “Unconnected” tab, the tab is just blank gray. But if I click “Start DRC” and then “List Unconnected”, then the unconnected tab is populated. (Even if there are no unconnected nets, it is now blank white, instead of the blank gray I get if I don’t click “List Unconnected”.)
That’s weird, in Windows; 4.0.6 on Legacy or OpenGL canvas I’ve never found it to work like that!
I seem to have in the past found that DRC’s “List Unconnected” has worked when traces physically have space between their copper areas, but if the copper overlaps (even if the trace endpoints are not exactly coincident) sometimes it will not report any unconnected nets. This is technically correct even if there are some “unconnected” lines per the ratsnest. I can’t guarantee this behavior is correct 100% of the time, but as of yet I have not had “List Unconnected” let through any physically unconnected nets.
2 Likes
I understand that situation, and can live peacefully with it. The “Unconnected” net that I DID locate was physically quite acceptable, even if it didn’t satisfy the rigorous mathematical requirements for “connectedness”. At some time in the not-too-distant future I will probably have a few tricks up my sleeve for locating that kind of situation more efficiently, or else a way to identify cases where it’s safe to ignore the reported lack of connection. (On more than one occasion I have temporarily put an attenuator in-line with a spectrum analyzer input, to determine whether a signal on the display was “real”, or a piece of corruption created within the instrument.)
It’s the other two cases - the one that cleared itself while investigating, and the one that vanished for no reason at all - that bother me. I’d like to have at least a suggested procedure for resolving the contradictory reports coming from the DRC, and the layout software itself.
Dale
Did you try the option under edit, “Clean up Tracks and Vias”? Just curious. It’s never worked the way I thought it would anyhow in as much as it didn’t seem to really ‘merge’ segments.
1 Like
Well, the pie is on MY face! No, I didn’t think to try that feature.
My experience is similar to yours. A couple years ago, when I was just starting with KiCAD, I experimented with that feature. I formed the same impression that you did: it not only didn’t seem to help very much, but it sometimes “cleaned up” work that should have been left intact. There has been a LOT of code development, and changes, since then so it may be time to reconsider “Clean up Tracks and Vias”. Especially if it should become a preferred tool for resolving the kind of confusion that spawned this thread.
(Aren’t you surprised, dear reader? I bet you thought we were about to veer off onto another topic!)
Perhaps somebody who is familiar with “Clean up Tracks and Vias” will join in, tell us what the tool does, and whether or not it will help resolve cases where the DRC disagrees with the “Unconnected” count.
Dale
1 Like
Today, I can’t figure out how to make the second line of text appear. I’m just getting the blue “Unconnected 0”, but without the line of black text below that contained the “not conn” number.
Anyway, since DRC agrees with the blue “Unconnected 0”, I decided to send the board off to the fab.
I discovered a similar issue when creating a multi board panel. If you do not have the line ends of the edge cut out exactly matched the 3D viewer does not calculate the internal cut outs correctly. I don’t know if it effects any other process.
This is an old bug; that I found happens in OGL.
Switch from OGL, to Legacy, and back to OGL, and the numbers should match up.