PCBNew disconnecting tracks during DRC

[Robert]

I've had problems with the DRC reporting pads as being disconnected even though I was sure I had connected them. I've now managed to do this in a repeatable fashion. Please see the attached screen capture. The left image shows a part of a LED module. The green pad is on the bottom layer only and is connected to a net (it's the anode). The red pad (just visible on the right) is on the top layer only and is used purely to support the through-hole plating for a hole through which the LED shines (so it is not connected); the cyan ring around it is silk screen. The cyan tracking is on an inner layer connected to GNDPWR and is used for shielding. Note that PCBNew is reporting on the left-hand image that the ground mesh over the green pad has been fully connected to GNDPWR. The right-hand image shows what happened during the DRC test. The outer loop of the ground mesh has been transferred to NC (Not Connected) during the DRC test and the DRC is reporting that it is overlapping the central track which is still on GNDPWR. This spurious transfer of a track to NC is something I have seen many times but this is the first time I've seen when it happens. Clearly it renders the DRC test unusable.

Application: PCBnew
Version: (2011-04-29 BZR 2986)-stable
Build: wxWidgets 2.8.12 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.0,wx containers,compatible with 2.6)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

[jean-pierre charras (jp-charras)]

Le 16/09/2011 10:38, Robert a écrit :
> Public bug reported:
>
> I've had problems with the DRC reporting pads as being disconnected even
> though I was sure I had connected them. I've now managed to do this in
> a repeatable fashion. Please see the attached screen capture. The
> left image shows a part of a LED module. The green pad is on the
> bottom layer only and is connected to a net (it's the anode). The red
> pad (just visible on the right) is on the top layer only and is used
> purely to support the through-hole plating for a hole through which the
> LED shines (so it is not connected); the cyan ring around it is silk
> screen. The cyan tracking is on an inner layer connected to GNDPWR and
> is used for shielding. Note that PCBNew is reporting on the left-hand
> image that the ground mesh over the green pad has been fully connected
> to GNDPWR. The right-hand image shows what happened during the DRC
> test. The outer loop of the ground mesh has been transferred to NC
> (Not Connected) during the DRC test and the DRC is reporting that it is
> overlapping the central track which is still on GNDPWR. This spurious
> transfer of a track to NC is something I have seen many times but this
> is the first time I've seen when it happens. Clearly it renders the
> DRC test unusable.
>
> Application: PCBnew
> Version: (2011-04-29 BZR 2986)-stable
> Build: wxWidgets 2.8.12 (no debug,Unicode,compiler with C++ ABI 1002,GCC 4.4.0,wx containers,compatible with 2.6)
> Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW
>
> ** Affects: kicad
> Importance: Undecided
> Status: New
>

A track must always be connected to a pad or an other track that is connected to a pad.
Otherwise Pcbnew does not know the net of the track, because only pads handle nets names.
A track that is only inside a zone but not connected to a pad (or an other track with a known net name) is therefore seen as NC.
DRC rebuild the connectivity data, so if tracks have a connectivity problem, DRC shows it
(re-read the netlist does the same thing).

Please test how these tracks are connected.
If they are connected to a pad, please send us your board.
If not, add a track to the near pad.

--
Jean-Pierre CHARRAS
KiCad Developers team.
KiCad Developers <email address hidden>

[Robert (birmingham-spider)]

The ground track is connected to a pad on the GNDPWR net. Since posting I've found that if I rotate the central track in the mesh through 90 degrees the problem goes away; Connected.jpg (attached) shows the connectivity after a DRC test. It also goes away if the incoming track and the horizontal track on the mesh do not cross at the same point, ie if one half of the horizontal track is offset by as little as 0.025mm. So this is triggered by having two connected tracks crossing each other, the tracks connecting at the crossing point.

I can't send you the board (it's being created for someone else) but I could create a dummy board if that helps.

[Dick Hollenbeck (dickelbeck)]

On 09/16/2011 05:00 AM, Robert wrote:
> The ground track is connected to a pad on the GNDPWR net. Since
> posting I've found that if I rotate the central track in the mesh
> through 90 degrees the problem goes away; Connected.jpg (attached) shows
> the connectivity after a DRC test. It also goes away if the incoming
> track and the horizontal track on the mesh do not cross at the same
> point, ie if one half of the horizontal track is offset by as little as
> 0.025mm. So this is triggered by having two connected tracks crossing
> each other, the tracks connecting at the crossing point.
>
> I can't send you the board (it's being created for someone else) but I
> could create a dummy board if that helps.
>
> ** Attachment added: "Connected.jpg"
> https://bugs.launchpad.net/kicad/+bug/851670/+attachment/2411986/+files/Connected.jpg

Robert,

Consider me a believer. I have been suspecting this bug for some time also.
The most simplest dummy board that exemplifies the problem is appreciated.

Since Jean-Pierre mentioned zones, I'd avoid them in your example. For what its
worth, I've suspected the direction of the traces plays a role in this, or the
sequence of the traces in memory (even though the traces associated with a
single net are all neighboring in the linked list).

But I am inclined to rate this as a high priority suspicion, and likely to be
valid. I see it coming back from freerouter from time to time. So there's a
small chance it could be a rounding error on a coordinate, but I highly doubt that.

Can't wait for your *simple* dummy board. As I would rate this the highest
priority bug.

Dick

[jean-pierre charras (jp-charras)]

Le 16/09/2011 12:00, Robert a écrit :
> The ground track is connected to a pad on the GNDPWR net. Since
> posting I've found that if I rotate the central track in the mesh
> through 90 degrees the problem goes away; Connected.jpg (attached) shows
> the connectivity after a DRC test. It also goes away if the incoming
> track and the horizontal track on the mesh do not cross at the same
> point, ie if one half of the horizontal track is offset by as little as
> 0.025mm. So this is triggered by having two connected tracks crossing
> each other, the tracks connecting at the crossing point.
>
> I can't send you the board (it's being created for someone else) but I
> could create a dummy board if that helps.
>
> ** Attachment added: "Connected.jpg"
> https://bugs.launchpad.net/kicad/+bug/851670/+attachment/2411986/+files/Connected.jpg
>

Please, send us a dummy board that shows this issue.

--
Jean-Pierre CHARRAS

[Robert (birmingham-spider)]

I created a dummy board yesterday using two LEDs and a resistor just to get a net, but no matter what I did the DRC behaved itself. I'll keep trying until I can recreate the problem; please bare with me.

One minor irritation I have with kicad is that during tracking when I click on a track to make a connection the two tracks quite often get connected with an effectively invisible track 0.003mm long, even though I'm using (say) a 0.05mm grid. Maybe that's what stops the problem from showing itself more often, in which case you may be right about rounding errors, Dick, but it might be a rounding error that stops it from showing itself.

[Robert (birmingham-spider)]

The attached board reproduces the problem. However, it seems to be fussy about how the ground mesh is created if you want the problem to trigger. I had to create the meshes as follows:

1) Turn off Tracks Auto Del in the options!
2) Create a long (GNDPWR) vertical track from top to bottom crossing all the LED pads that are to be covered with a mesh.
3a) For each mesh click on the top centre point of the LED pad (anchoring the new track to the GNDPWR vertical track).
3b) Click on the top right-hand corner (of the LED pad).
3c) Click on the bottom right-hand corner.
3d) Click on the bottom-centre point (anchoring to the GNDPWR vertical track).
3e) Click on the bottom-left corner.
3f) Click on the top-left corner.
3g) Click on the start point.
3h) End the track.

You may need to click twice on a corner to get the corner to stick. The Net highlight tool will confirm that the mesh is all on GNDPWR, but a DRC test will disconnect the outer loop.

If I created the outer loop of the mesh in two sections by ending the track bottom-centre, the problem didn't show. That said, I couldn't recreate the problem on my first dummy board no matter what I did. This board is the board I was working on when I first noted the problem, but with as much removed as possible (the netlist being recreated for this test).

I tried to save the board so that the mesh on D69 is pre-DRC, but I have noticed something interesting. As created the entire mesh is on GNDPWR (verified with the Highlight net tool). If I exit PCBNew and reload the board, the outer loop of the mesh is disconnected from GNDPWR just as it would have been if I had run a DRC.

[Martin Errenst (imp-d)]

partial fix in r3207 stable

[xzcvczx (xzcvczx)]

As there has been a partial fix what is still missing, changing to incomplete until more information as to whether this issue is still reproducible is occuring

[Launchpad Janitor (janitor)]

[Expired for KiCad because there has been no activity for 60 days.]