As you can see, the resistor’s pad (the left one) is not connected anywhere, but it’s actually supposed to connect to the trace on the other layer. However, the status bar (on the bottom) is deceptively saying “Unconnected: 0” (which is something I actually rely on when drawing boards). A DRC check detects the lacking connection, but doesn’t even update the status bar. I’m guessing the status bar has different “unconnected net” checking mechanism than the DRC does (as I had false positives earlier, just not false negatives as I do now). This is quite concerning to me; while I could just run the DRC check all the time to make sure, the fact that the feature is there but provides incorrect information made me rely on it for a long time and now I’m not sure it hasn’t influenced any of the boards I’ve designed =( I zipped up the PCB files as they are now, so I can share them if necessary.
I noticed for my self that the status-bar info is not reliable enough to replace DRC in any way. Sometimes it shows a count > 0 while DRC says there are no unconnected pads. Sometimes it shows 0 while DRC shows unconnected.
Most of the time this happened to me i could get DRC and status-line to agree by restarting pcb_new.
I assume (not a programmer) that the status line info is a simple counter that does no real connectivity check. DRC goes through your board and really checks if everything is ok.
Could you move the end of the red trace so that it doesn’t end exactly at the centre of Pad 1 and let me know whether or not the connectivity count now shows it?
The connectivity count reflects the number of lines in the ratsnest. It’s possible we don’t generate a ratsnest line here because it would be 0 length and so wouldn’t appear.
The “Unconnected” field in the status bar has been unreliable in the OpenGL canvas for a very long time. It has been mentioned on this forum many times. I would be very surprised if there is not already a bug report.
When the two end points of a ratsnest line are on different layers it should not have a zero length. Of course if it were rendered it would be a single pixel but at the very least it should be counted.
However, this doesn’t explain why the status bar often displays a value >0 when DRC reports 0.
I just did a DRC check on: A64-OlinuXino_Rev_C.kicad_pcb and it took 64 seconds to complete on my trusty old dualcore.
To me the “status bar” is just that. A global estimation of status / progress and information that does not bog down your system, but nothing to rely on.
Hi! Unfortunately, a restart does not help - it’s pretty consistent. Thank you for the FAQ link, for some reason, I haven’t looked in the FAQ - will file a bug report, then =)
As for “it’s just unreliable” - it also seems dangerous, since the “Unconnected” thing is both a convenience thing and a failsafe. I have the same problem with push&shove recently - even though it’s set to “not allow DRC violations”, I routinely get plenty of these after routing a board, which makes me wonder whether the option is actually useful (as in, I can rely on it in any way).
Okay, so there’s an important thing I’ve just noticed I left out - there are two resistors on top of each other, one on the bottom and one on the top, and the two pads that need to be connected lay on top of each other (they also need to be connected with the red trace that’s on the top layer, that one of the resistors is already connected to). Here’s a screenshot of the current arrangement as it’s done, from the top layer ( I added a via in the meantime, but it doesn’t yet connect to the bottom resistor).
So, the bottom (green) resistor is still not connected when I start - and the trace is snapped to the center of the top (red) resistor’s pad, which is directly above the bottom resistor’s pad. First, I tried just moving the resistor - it did show a grey ratsnest line and finally increased the statusbar count (which is fun, because it didn’t when I tried it 10 minutes before and moved the resistor vertically, oh well). Then, I move the resistor back - it shows 0 again. I add a trace from the via to the green resistor - it shows 0, as it did before. Now I remove the top trace - and it’s still at 0. I remove the bottom trace too, then it’s at 1 (which is interesting, because at this point there should technically be two different overlaying ratsnest lines).
At the very least, the “remove redundant tracks” feature doesn’t remove the top resistor-via track when I add the same track on the bottom - now that would be an explosive combination =D
Seems like that should be fixed, as ‘0 length’ is not true if you include PCB thickness
I think that’s in the semantics and details.
Kicad DRC connection requires the CL of the trace is inside the PAD for a pass.
That allows there to be some short unroutes, inside pads, that will increment the status counter, but pass the DRC
My suggestion would be to change the semantics of the Status label, so it says “unroutes” not “unconnected”, and adding a sum of unroutes length also gives users hints of what to look for.
The only time i got problems is when placing vias with coarse grid settings in a space where it does not quite fit. (when the via jumps around a lot even if you have the mouse stable you are a bit too close.)
It seems there might be a rounding error somewhere.
I have not played with current nightlies long enough to know if this has been fixed already.
What does it show with an unrouted segment, that does not end on a pad ?
Each PAD unroute, to me, should increment unroute counter by 1, so your example ideally would report 1, then 2, as you say.
A non-pad terminating segment is trickier to count. because it increments the total unrouted length, it probably should also increment the unrouted counter ?
I’ve checked this in a V5 RC2 oldish now (Version: (5.0.0-rc2-dev-44-gde6b32d23), release build)
If you exactly flip a part, the F11 display mode changes to two large white crosses, so those are quite visible, and it does report 2 unconnected.
If I move .0001mm, the large white crosses go away, and I can see either one, or none, white pixels, depends on Zoom.
It would be nice if the single pixel decision could always round UP, so you can always see at least one pixel, at any zoom level ?
If I overlap 2 parts on the same side, provided the ratsnest is within the pad outline, it does not display and reports at 0 unconnected. Move so the ratsnest is not within the outline, and it appears.
That’s simple to code, but the boundary here is not actually when a real disconnect will happen.
Probably better to code this for speed, than strict correct reporting. (this way is conservative)
Unrouting a distant segment, increments the unconnect by 1.
Overall, I’d call that quite good.
Only fix would be to change the ‘unconnected’ status wording, to ‘unroutes’, since that’s what it actually counts, and that permits some creepage between DRC unconnected and status unroutes, as the names are not the same.
In addition to a name change (it’s hard to love “unroutes”, but I assume “unrouted” would be fine?), I think we could also move the “if zero-length” test from ratsnest-line-creation to ratsnest-line-display so that the status line count would be a bit more accurate.
But that would be too risky for 5.0 at this point, so would have to wait for 6.0.
yes, agreed, and “unrouted” is probably better for non-English users…
I’m unclear here ?
The status line count looked fine to me, (slightly older V5 rc2) : a flipped part with zero length, was showing 2, as expected.
It also displayed large white crosses on those 2 pads, maybe 75% of pad size that trigger on the ‘zero-length but actually thru board’ case.
If I moved the part .0001mm, the large crosses go away, and become the line (which sometimes vanishes due to display artifacts). On the same side, overlapping parts have no rats nest until you move half a pad width - above that, rats nest shows, and unrouted number increments = OK.
Apart from the label change to “unrouted”, the only fix I can see needed, is to round-up display zoom handling, so single pixel connections, do not vanish/reappear at various zooms.
However, that’s not a biggie…
