> > The other problem is that when I run a DRC check it says a number of > pads are unconnected which are not unconnected. I did not have this > problem when I ran a DRC a little while back, and the only thing I've > done since then is increase the size of my vias and move some runs > around. It would also plot without problems before. > > So how do I tell PCBNew that the pads are connected which have traces > going to them?
The Nov-2007 release has the "Selection Clarification" menu which you get when you click over your pad/track combo, right above the pad. In this menu you can see all the track segments which are under the mouse. (Using the hollow track display mode also helps see all the segments at or near the pad.) But back to the menu, your choices will show the net number and/or name next to any track segment. If you see a net number of 0 this means that segment is not connected as far as pcbnew is concerned. (Your disagreement with its understanding does not change its interpretation.) The segment has been lost to the scrap heap and should be deleted and re-entered. You have to delete that segment and re-enter it. The problem is that pcbnew uses segment end point testing to detect continuity, rather than "visual overlapping". During track entry, "visual overlapping" is sufficient to cause the injection of small segments behind the scenes to actually achieve precise "end point equality". End point equality is when pointA.x == pointB.x && pointA.y == pointB.y exactly. So the end point of one segment must *exactly* match the endpoint of the next segment for there to be continuity. During track entry, things are happening behind the scenes to add small short segments to tie all the segments together *exactly*. However, if just one of those segments is moved later, or a pad as a result of a suttle footprint move, then there is no similar support for *repairing* the "end point equality". This small segment injecting is only during track entry. A similar discussion relates to the last segment on a track, the one that "connects" to the pad. Here the exact (x,y) match also must be true for one of the last segment's 2 end points as it compares to the centerpoint of the pad. I am only the messenger, please don't shoot me. There has been some discussion about relaxing the "end point equality" checking and going with a "do they overlap" type test. I am in favor of that now that computers are faster. The computer should work for us, not the other way around. And to me, if it looks like two track segments are overlapping, then I'll bet that the same thing in copper would conduct electrons :). The original design was done to speed up the ratsnest algorithms, where the "end point equality" test was the fastest among any other alternative test. With upcoming zone re-design, this "end point equality" test is back on the table for discussion. Dick Hollenbeck SoftPLC Corporation http://softplc.com
