Skip to content

P-CAD import: Imported zones don't avoid copper polygons

Polygons can be drawn in P-CAD. They normally are 'dead' copper which can be used to short nets (or maybe other uses), but since they do not avoid other shapes or require re-pouring sometimes they're helpful to use instead of the normal copper pour in P-CAD (the same as a zone in KiCad).

When a netlist is re-imported with polygons covering pins or tracks with a net name, the 'Reconnect Copper' option during netlist import will assign that net name to the polygon. Once this happens, the polygon is exactly like a pour (zone) except it doesn't avoid other copper.

Here is a P-CAD board with a small squarish polygon on NET00001 inside a larger copper our on NET00000: image

Notice the polygon has no thermal spokes while the copper pour does. And there is a track between L1 and L2 on NET00001 which is part of getting P-CAD to understand the net name of the polygon when the netlist is re-imported.

If you don't have P-CAD here is a zoomed-in shot of the two right-side pins of L1: image

KiCad imports the polygon and copper pour, including their net names, and it results in this: image

Here is the zoomed-in version: image

The polygon and pour are both converted to zones and now both have thermal spokes. They also retain their unique nets. And you can see the trace between L1 and L2 is still there.

But the zone converted from the polygon is totally flooding the area of it's boundary and does not avoid the zone converted from a pour: image

So the two nets are being shorted in KiCad when they certainly shouldn't be and they aren't in P-CAD. I can't say if using polygons for copper pours is common for other P-CAD users, but it certainly makes for a poor import experience. And a scary one when seeing a huge mass of connected copper when clearly multiple nets are involved! If the ground is a pour in P-CAD and otherwise polygons are used, this ends up a frightening mess with everything shorted!

At least a 'Copper area inside copper area' DRC error is generated using the default DRC settings.

I see all imported zones have a priority of 0. I didn't catch on that this was potentially the root cause earlier so I hadn't considered it when writing up the issue above. However, I'll leave that alone for posterity and because it shows the user experience. It appears the proper solution is to adjust the priority of the zones to avoid them being the same priority and flooding other each other. However, I don't find a priority system in P-CAD. https://www.jlab.org/accel/eecad/manuals/PCB.pdf indicates that the 'priority' may be based on the zone/polygon/pour size, from pages 210-213 (doc pages 190-193). Seems like a lot of work to figure this out, but since it's an issue (bug?) I want to capture it.

Here is a P-CAD board you can use for testing: _pcad_zone_test2.PCB

KiCad version:

Application: Pcbnew
Version: (5.1.5)-2, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
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.71.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.66.0
    Compiler: GCC 9.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
Edited by Jeff Young