pcb-rnd knowledge pool


The disjoint padstack vs. find.c

pstk_disjoint by Tibor 'Igor2' Palinkas on 2020-09-17

Tags: insight, find.c, disjoint, padstack, unplated, mounting, hole

node source



Abstract: A disjoint padstack has more than one copper shapes (on different physical layers) that are not connected within the padstack: there is no plated hole or slot. This used to be a problem for find.c when mapping galvanic connections. This article explains why it was broken and how it got fixed after pcb-rnd 2.2.4.


Disjoint padstacks

For our purpose in this article, a padstack is considered disjoint if:

The most typical case is unplated thru-hole padstacks with copper rings, often used for mounting holes. But there are other rare, but interesting cases, such as a double sided card-edge padstack having both top and bottom copper shapes but no hole or slot at all ("SMD pads on both sides").

The famous find.c

The part of the code base for finding galvanic connections was originally living in find.c. It runs a classic open-list based approach that collects all connected objects starting from an object. Two objects are typically considered connected if:

Once an object is found, it is marked with a flag and is put on a list.

The disjoint padstack problem

The root of the problem is that an object is either found (marked) or not found (unmarked) while find.c is mapping galvanic connections. This simple approach is fine for simple objects like lines or arcs. It is also fine for most padstacks, e.g. for classic vias where all copper shapes are internally connected with a plated hole. In this setup if the search reaches the padstack from any overlapping object on any layer group, the whole padstack is connected.

However, in case of a disjoint padstack, this is not true. For example if the hole is unplated, reaching the copper ring on the top copper layer group will make that part of the padstack connected, but this connection will not propagate to the bottom copper layer group. Which means a single bit of "the padstack is connected" is not enough. For example type {c f} while the mouse cursor is over the left line object in example 1:

padstack with unplated hole shall not connect layer groups

The solution

Some object types may have "multiple components" as far as find.c is concerned. In our above unplated hole padstack example, while being in the same single padstack object, each copper ring is a separate component since they are not galvanically connected. For those objects, the original "found" mark only indicates that some component of the object is found, but then which components are affected needs to be stored elsewhere. For such multi-component objects the code always checks if the object is marked on a specific layer group before deciding if it is connected.

(The technical solution is a hash table in the find context; any object with more than one components will get a temporary extra struct while find.c is doing the search. This extra struct keeps track on which components are really found. In case of a disjoint padstack, there's a mark bit for each possible layer.)

It is important to note that this multi-component notation is relevant only for find.c, and no other part of the code cares. It is also important that padstack prototypes have cached info about being disjoint or not, so any extra computation is done only for the complex case, and the simple case is done with a single mark bit.

Corner cases

Connection within a layer group

An interesting corner case is that a disjoint padstack's copper shape should still be able to make a connection within its own copper group. This is demonstrated by example 2: the line and arc object on each layer are connected through the ring of the padstack.

padstack with unplated hole still connecting some objects

GUI indication

The object's "found flag" also known as the green indication on screen, is outside of find.c, thus it does not know anything about multiple components. This indication is a single bit, "green or not", thus it will always mark the whole padstack found even if only one or a few components of the padstack is really participating in the connection.

This is a GUI limitation. Since disjoint padstacks are rare, this problem is most likely will not be addressed.

Disjoint padstack as the starting object

If the user starts the search from the disjoint padstack, the code does not know exactly which component the user meant. In this case, the code will assume the user meant all components, and will do a search from all. Example 2 above, with the search started from the padstack:

padstack with unplated hole still connecting some objects

Disjoint padstack as terminal

Pcb-rnd generally assumes that if multiple objects of a subcircuit has the same terminal ID, those objects are connected internally by the part soldered onto the footprint. This assumption is now extended to the case of disjoint padstacks: if a disjoin padstack is a terminal, the code assumes each component is going to have the same terminal ID thus each component is connected by the external part that is soldered on. So far this is known to be relevant in one case: when a disjoint padstack with top and bottom copper shape and no hole/slot is used as a double sided card edge pad. If such a padstack is not a terminal, the two copper shapes act independently. However if the padstack is a terminal, it is assumed to be connected by the external part soldered on the two "pads".

Disjoint padstack overlapping with another disjoint padstack

At the moment this case is not handled correctly: all shape-connection assumed and an error message is generated. Once a real life use case is revealed, we will decide how this should be handled.

Other potential multi-component objects

There are two other objects that later could be handled as multi-component objects by find.c: