Net not created in PCB

I’m creating a PCB and some nets do not appear to be created in the PCB. I normally use the update PCB from schematic icon to perform the task but after several attempts check that connections actually did exist I decided to try a netlist export/import for more information.

The nets actually exist in the net file (two of them extracted below)

(net (code 20) (name "Net-(J3-Pad-)")
  (node (ref K1) (pin Tip1))
  (node (ref J3) (pin -)))
(net (code 21) (name "Net-(K1-PadTip2)")
  (node (ref K2) (pin Tip1))
  (node (ref K1) (pin Tip2)))

But the nets don’t show up in the PCB when I import the netlist. They don’t show up visually (even when moving components) and if a route from an involved pin all no-net pins highlight.

There are no errors on the import (either from netlist or from schematic). I’m at a loss as to what to check for.

Robert

Are you able to share the project? Might be the quickest way to help to understand this.

KiCad version might also help.

Additional info: The netlist import stuff is not really how one should syncronize between eeschema and pcb_new under version 5. Use the update pcb from schematic tool for that. (found in the top toolbar for v5.1 or in the tool menu for all v5 releases)

Yeah, the using netlist import was simply a second check.

Version
Application: kicad
Version: (5.1.0)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013

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

I managed to reduce it to a simple example with two components. I suspect a footprint issue

test.zip (5 KB)

Robert

Please, reload the test.zip project including a new test-cache.lib

Since the current test-cache.lib has no symbols at all, it is not possible to check the K1 and K2 symbols.

Pin numbers must have 4 alphanumeric digits at most. Coil1 and Coil2 have 5 digits.

This limitation has been removed with the v5 release.

It shows a symbol when I load it into notepad?
Nonetheless, a refreshed version.

test.zip (5.0 KB)

Coil1 and Coil2 don’t show an issue. Tip1 and tip2 do.

Robert

BTW, the footprint is there in the MB60.kicad_mod file and the symbol in the 80-100005-00 file(s), I’m not sure about the dcm/lib difference.

Both together make up a symbol library. The lib file holds the symbol information (graphics plus fields) and the dcm file is for documentation stuff. Things in the dcm file can be different between aliases of a symbol. (This is there for legacy reasons as in the past this meant one could see crude info about all symbols in a lib without needing to download the full library file.)

Sorry Robert, I have not been able to find out where the error is.

I have edited both symbol and footprint, regenerated the netlist…

Even changing the connections in the schematic the result is worse than the original one.

The only problem here is total lack of RTFM.

Pin numbers ain’t no pin names !!!

It is definitively a strange way of doing things but the pin number can be any string you like. (KiCad 4 had the limitation of 4 characters but that is lifted with version 5.)

KiCad is case sensitive. You use TIP1 as the footprint pin number and Tip1 in the symbol. What is strange however is that the import tool does not report this as an error like it would if the pin numbers are completely different. This is clearly a bug.


Another strange thing is to use a filled polygon for the courtyard definition. It seems to work but is not how it is expected to be done. (Use the normal graphical tool to draw it instead of the polygon tool.)

2 Likes

Pin/pad number case sensitivity is handled wrong by KiCad in some place. Change TIP1 pad to Tip1 etc. as they are in the symbols. Problem solved.

2 Likes

The bug has been fixed but was too late for 5.1.3, it should be part of 5.1.4.

1 Like

@pedro Thanks for trying and @Rene_Poschl ahHa! thanks. Yes if it had complained about a mismatch I might have found it and it certainly would have been easier to narrow down. Clearly a bug as you pointed out and @eelik confirmed. No matter why a net isn’t formed when importing from the schematic it should obviously be reported even if it is net not created for unknown reason, it’s otherwise easy to miss a missing net. Maybe a DRC rule could check for consistency between schematic and board?

And, yes @jos it’s not the most common usage to have a non-numeric pin number but it’s not unheard of, even in IC packages. And this is not an IC package but an electromechanical one and those packages sometimes have no designation at all. So as an exercise to make this easier for other people to read I used a more verbose designation in this case.

Robert

I didn’t know that about the courtyard, how then does it then deal with objects that have inner areas that are not forbidden for placement?

I have noticed that KiCAD’s checks in this area are rather limited, there’s no equivalent to the courtyard for traces and vias for instance. Some packages require that vias not be placed in certain areas and some have areas where no Cu should be placed… There does not appear to be a way to check for violations of these restrictions currently.

Robert

First of all the polygon does not support cutouts so how would you make it with polygons?

And it works easily with normal lines by simply placing an outline for the cutout inside. see the rf_shielding footprints as an example. (Laird_Technologies_97-2002_25.40x25.40mm)

No, it is not a problem of reading the manual. By the way, I translated the manual into Spanish, I had to read all the lines of the manuals.

So please, be positive in your comments giving solutions and helping people or don’t say anything.

Pin names are irrelevant to match symbols and footprints. Only the pin number matters.

On the other hand, I’m glad @eelik and @Rene_Poschl found the bug. Kicad used to be non-case sensitive.

In relation to the polygon courtyard, I deleted it from the footprint to be sure it was not the problem.

1 Like

Don’t think so.

The documentation spells it out in section ‘Electrical Rules Check tool’.

A bit down this page there is a table ‘Option:’ with regards to ‘Test simlar labels’. It clearly lays it out.

… Net names are case-sensitive therefore such labels are treated as separate nets.

From google translate

… Los nombres de red distinguen entre mayúsculas y minúsculas, por lo tanto, dichas etiquetas se tratan como redes separadas.