Trace too short, not drawn (bug?) — visible on Gerber

[cal-linux]

It was just by looking at the Gerbers as one final review before sending off for manufacturing that I noticed this weird “bump” in one trace. I tracked the issue down to a trace of approx. 2 or 3 nm in length that is not being drawn (it would essentially look like a circle; but my guess/opinion is that it should show). Presumably, it happened while I was adjusting that trace by dragging/push-n-shov’ing.

This is a screenshot:

(it’s the second green trace from the left ― I just noticed that the screenshot only capture the DO of the net name, DONE)

This is the Gerber:

The DRC passes (rightfully so: the “invisible” trace does not get too close to the neighbouring trace; also, its center seems to be inside the other trace segment, so KiCAD determines that it is connected).

If I move it a bit to the left (0.03mm), then the DRC fails (two errors: that “invisible” trace is now disconnected, and it is also too close to the PD28 trace):

In this case, by fluke the ratsnest hints that there must be something there (and in fact, I click in there and can see that something was selected, even if it doesn’t show; and e brings up the properties dialog).

But if the trace was still connected, the tracks too close error would be nearly impossible to figure out / debug (the marker is not at the “right” place — this is actually a quirk in KiCAD that often enough bites me in the behind). What I’m saying is that in general, this behaviour could be problematic — sure, the DRC would flag the violation if there was one; however, if that trace happened to carry a high-speed signal, then the stub created by that “spurious” trace could go unnoticed all the way to the actual physical manufactured board and create serious issues)

Is this a known bug? (or am I missing/misinterpreting something?)

I’m using KiCAD 5.1.9 on Ubuntu 18.04:

Application: KiCad
Version: 5.1.9-73d0e3b20d~88~ubuntu18.04.1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-123-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.5.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[paulvdh]

I find the fact that the rogue track segment is shown in the gerber, but not in Pcbnew quite strange.
Such a short track segment is usually shown as (nearly) a circle.
I would classify Pcbnew not drawing it as a bug.

@cal-linux

sure, the DRC would flag the violation if there was one; however, if that trace happened to carry a high-speed signal, then the stub created by that “spurious” trace could go unnoticed all the way to the actual physical manufactured board and create serious issues)

If you make PCB’s often then it’s wise to make a checklist of things to do before sending out the gerbers.
One of those things is Pcbnew / Edit / cleanup Tracks & Via’s (Does this remove the rogue track segment? How many other things does it delete? )

For this kind of inspection it is also good to draw tracks & via’s in outline mode. Pcbnew / View / Drawing Mode / Sketch tracks (Also an icon in the toolbar on the left).

[cal-linux]

[[ As a side note: Thank heavens for git (well, and in general version control systems that allow me to temporarily revert to old commits) … My first reaction when reading your suggestions was: “D’oh, too late! I already fixed the glitch (i.e., removed the “rogue” track) and saved” … then I realized, wait a minute… :‒) ]]

I’ll go LIFO with your comments:

@paulvdh

For this kind of inspection it is also good to draw tracks & via’s in outline mode

Right! I knew about this, but it didn’t occur to me to use it (because I wouldn’t expect to see anything that I would not see in normal mode — well, putting aside things like figuring out how an interconnection of tracks is arranged).

Incidentally, the sketch mode does show the rogue track:

@paulvdh

One of those things is Pcbnew / Edit / cleanup Tracks & Via’s (Does this remove the rogue track segment? How many other things does it delete? )

Good suggestion. However, it didn’t (or wouldn’t) occur to me to do that, because that usually screws up many of my usual constructs. For example, I use redundant tracks to do “teardrops” from power pins to its decoupling capacitor — it’s not really the “teardrop” effect I’m after, but mostly maximizing the width of the trace connecting to a decoupling capacitor. I know, I know: I should just draw a coarse copper zone and let the clearances take care of everything, filling/expanding the maximum possible, as permitted by the clearance settings.

Now, interestingly, it turns out that Cleanup Tracks & Vias does not remove the rogue track (at first, I ran it leaving only “Remove dangling tracks” checked; but after I saw it did nothing, I left all four checkboxes checked, and it still did not remove it).

Thanks,
Carlos

[Meterman2026]

One thing I tend to do after making revisions is highlighting each trace section, taking out short trace segments left after removing a via, and then dragging the rest of the trace across the resulting gap. I’ve actually found (and removed) more than a few ‘micro trace’ segments that way.

I figure, checking the traces this way helps streamline the number of traces to be defined (saving a bit of space in the file, in addition to giving Murphy that many fewer chances to have his say).

[paulvdh]

KiCad generating lots of very short track segments is one of my small annoyances. It tends to make these for esample when a track segment is pushed off-grid by the interactiver router and then later another existing track is connected to it.

It’s not a real bug and therefore not high on any priority list. Cleaning those small segment up is a bit of a time consuming task though.
I do get the impression though there has also been some progress on this side, and KiCad makes less of these short track segments then it used to.

[qu1ck]

Cleanup tracks and vias dialog can join short colinear segments thus reducing their amount.

[paulvdh]

Yes, it can and it does and that is good.
But it’s not what I meant.
I mean the often multiple very short track segments that get inserted to connect some off-grid item to an on-grid item. KiCad does this even when for example the tracks meet each other under an angle, and it could just use that intersection to connect them.