Why not assume pads with the same number are connected?

[Piotr Gałka]

Not bug, but suggestion to consider changing assumptions.

See attached screen shot. It is defined by me touch key placed at PCB.
To have clear DRC I had to connect many physically already connected pads in whole keyboard.

Assuming (didn't checked it) the pads are seen being connected if one of them covers the center of another to make such footprint being internally connected I would need to add many pads just to catch a center and have a new center 1/2 closer to corner and so on till having a center in the corner region. And the same for all pads you see here.

I didn't tried to use custom pads yet. May be it would help me here (I'm not familiar with any CAD program I suppose would be needed in preparing custom shape). But why to use something potentially complicated if my shape is simple set of rectangles - it should be possible to use only standard pads.

Things would be much easier if the KiCad would assume pads with the same number in footprint are just connected even if they are far away one from another. I don't see any serious argument against it.
During more then a year of my watching KiCad forum I sow few times people asking what to do with 4 pin touch buttons as the pin pairs are internally connected in button but KiCad wonts them to connect them again but they need to go across such connection with other traces. They are advised to change 2 layer PCB into 4 layer and make this connections at internal layer and then not send that layer gerber to manufacturer (don't know but may be it is not compatible with Gerber job file if they use it). The other example of such footprint is 3 pin battery to be soldered in PCB.

I would like to suggest considering taking following basic assumptions:
1. Pads with the same number in footprint are just connected - need not to be connected at PCB.
2. In connection line generation such pad set is (at the beginning) understood as one point. Then when drawing each line the nearest pad from set is selected.
3. The connection line disappears if what was pointed by it was connected to any other of pad set (got automatically if point 2 realized correctly).
4. User is allowed to connect pads in such pad set. It is not assumed being a redundant track to be removed even if "Remove redundant tracks" option is active.

[Seth Hillbrand (sethh)]

Your example footprint would be solved by using a complex pad.

I've been thinking about your suggestion to assume same pad numbers are connected in the footprint and I like it. However, there may be some case I can't think of now that would break if we changed the assumption. It also prevents us from requiring board routing between pads where that would be desirable. In generally, it is good to avoid changing existing behavior if it doesn't actively break things.

Instead of a universal joining, I would prefer we do the following:

1) Add a new field for JumperID
2) If 2 pads in the same footprint share a net name and a JumperID, they will be considered joined for the purposes of ratsnest and drc

This would allow us to not only use this for the same pad number but also for dissimilar pad numbers where it is useful for single-sided board routing (e.g. high-power LED boards)

[jean-pierre charras (jp-charras)]

"Your example footprint would be solved by using a complex pad"
Or just by a better design:
using rectangular pads with a suitable offset to keep each pad origin inside an other pad.
this is the reason on offsets in smd pads.

@Seth,

This is acceptable *only* if 2 pads (or more) are physically connected on the board.
This is *not* acceptable if they are connected by a internal connection in the component once this component is mounted.
Otherwise the Gerber X2 netlist and the IPC-D-356 netlist will show unconnected items (broken Gerbers).

Although it is not exactly the same topic have a look into
https://lists.launchpad.net/kicad-developers/msg24455.html
and other message of this thread.
there are a lot of good ideas.

[Seth Hillbrand (sethh)]

@JP - If they are connected elsewhere on the board, that defeats the purpose, no?

I thought the point was that the pads are not connected on the board, they are connected by off-board items (jumpers/switches, etc). The bare substrate electrical test for X2 and IPC-D-356 should show them disconnected.

[jean-pierre charras (jp-charras)]

"If they are connected elsewhere on the board, that defeats the purpose"

Not exactly, at least currently:
Pads can be actually connected although the DRC does not see the connection due to our DRC limitations:
Pads overlapping but pad position not inside an other pad (like this .png picture)
Pads connected by graphic items inside a footprint, but not by a track.

But no need to a JumperID: the DRC connection could be calculated only only during footprint creation
The calculation time is not an issue in this case, but it will not take in account settings like minimal track width for the net.

Now, if the bare substrate electrical test for X2 and IPC-D-356 show them disconnected and our DRC shows them connected, I call it a serious bug in our DRC.
Because as long as the off board item is not mounted, the connection does not exist.

Therefore, the board cannot actually tested for instance on a bed-of-nails tester, or even with a recent CAM tool that verify a lot of things on Gerber files.

[Seth Hillbrand (sethh)]

@JP-

Given that this feature exists in other EDA (OrCAD, PADS, Altium), do think there is a way that we can also implement it that would address your concerns?

[jean-pierre charras (jp-charras)]

Sure, we can implement it, like other tools.

But my concerns are for board testing because as I said, the connections built from the board are not exactly the same as our DRC is seeing.
(I don't know if and how these other tools fix the board testing issue)

[Seth Hillbrand (sethh)]

If the net is only connected by the footprint pads, we could split it into two nets for the purposes of exporting the testing netlist. We could check this by testing the two pads for different connectivity_cluster values.

[jean-pierre charras (jp-charras)]

Do you know how these other EDA solve this issue?

I am not thrilled by hacking the net info in gerber/ipc356 files for many reasons:
- The connectivity algo is already tricky, and adding this feature is also adding risk of bugs, very difficult to see.
- What is in the board editor is not what is in gerber files: this is really annoying.
- This feature has a very low interest: only a few footprints are using pads connected by the component internally, and the interest is only when the connection cannot be made on the board.

To be honest, it looks to me this is a ugly hack for home made boards, and not a feature usable in "professional" designs.

But the amount of work to safely add, test and maintain this feature is certainly not low.

Note also the example given in this bug report is not about separate pads having the same number,
but actually connected pads.
It shows a lack of performance of our connectivity algo because it does not detect the connection between connected pads.
Of course I fully agree this lack of performance needs to be fixed.

[Seth Hillbrand (sethh)]

I don't know how these other tools solve the issue yet. I'll be able to check PADS and Altium when I'm back at work during the week. I'll report back when I have a better survey.

We are definitely on the same page vis-a-vis improving the connectivity performance. Incidentally, I believe that Jeff had an update recently to the pad connectivity hit test that probably addresses the specific pad connection shown in this report (lp:1840721)

[Piotr Gałka (piotrgalka)]

From #9:
"It shows a lack of performance of our connectivity algo because it does not detect the connection between connected pads.
Of course I fully agree this lack of performance needs to be fixed."

I decided to add my 3 cents in the subject out of my competence. May be it should be a separate discussion.
I think perfect connectivity algo is lot of work having different pad shapes and specially that they can be rotated in any angle. There are probably much other more important work to be done to loose time for it.
But I see a simple way of little improving current algo which being not perfect should solve I think most cases.
Counting distance between two points is simple so detecting connectivity between two round pads is also simple. I suggest to put into rectangle pad 3 virtual round pads with radius being 1/2 of its shorter side. One in the center and two at far ends. The same can be done for oval or rounded rectangle. When two such pads connectivity is tested current test could be supplemented with checking connectivity between all combinations of those virtual round pads.
Three virtual pads can be replaced with a bigger set of them along the center pad line with their origins in a distance of their radius (or diameter). As most pads are not long lines then in most cases that would also mean only 3 so not taking too much counting time but it would be better for long pads.

During writing I suddenly got another idea (for precision algorithm). Tell me if I should not loose your time by writing such things here (will help me in future).
Idea: we put virtual round pads in pad centers and then they begin to magnetically attract themselves each bounded by its pad shape and if needed they can be mitigated. I think if pads are connected then in most cases after finding (simple moving along center line) the closest position for first round pad and then for second one they will be connected. If not we had to mitigate our pad sizes, but may be it is needed only if one of them is at its pad end. Unfortunately most pads are not connected and my algorithm seems needing more counts in such situation, but may be for each pad shape we can define the radius then after first step of attraction if used to found positions can inform that they can't be connected ending the counting. The bigger radius can be used before first step of attraction. I think such way can (I'm not sure) have advantage over analytic analyse of each pad shape combinations as you only have to specify how to bound round pad in each pad shape, and number of pad shapes is smaller then number of their combinations. And if in future the new shape will be added only how it bounds round pad will have to be investigated independent of existing pad shapes.

[Seth Hillbrand (sethh)]

Here's my survey of PADS and Altium.

PADS: Has specialized jumper that can be routed in place of a trace. IPC-D-356 output does not include jumper information or split nets.

P JOB Layout_Eval_Done
C DEFINE THE UNITS USED TO BE CUSTOMARY (ENGLISH) UNITS
P UNITS CUST 0
P TITLE C:\Users\Seth\Desktop\Layout_Eval_Done.ipc
P NUM ?
P REV ?
P VER IPC-D-356A
P IMAGE PRIMARY
C START DESIGN IPC356A
327$$$1 C1 -1 A01X+014590Y+001000X0380Y0300
327$$$1 C1 -2 A01X+015210Y+001000X0380Y0300
378$$$1 L01 X0060 X+016200Y+002800 X+016700Y+002800
078 X+016700Y+001000 X+015210Y+001000
378$$$1 L01 X0060 X+014590Y+001000 X+012700Y+001000
078 X+012700Y+002800 X+013700Y+002800
999

Altium: Uses the proposed "Jumper ID" in components to allow components to function as jumpers between the same net. IPC-D-356 output does not include information about the connection. This means that the bare-board test will show an open

C
P JOB
P UNITS CUST
P TITLE Pro97C3.tmp
P NUM 1.0
P REV A
P VER IPC-D-356A
P IMAGE PRIMARY
327RF_ANT C85 -2 PA04X 006358Y 022116X0205Y0205R090 S0
327RF_ANT C85 -2 PA04X 006673Y 022116X0205Y0205R090 S0
378RF_ANT L04 X30 X5600Y22116 X6358
378RF_ANT L04 X30 X6673Y22116 X7628
999

[Seth Hillbrand (sethh)]

And the PADS screenshot

[Janvi (janvi)]

> Do you know how these other EDA solve this issue?

Mentors Expedition cell editor allows items from pcb also in footprints. They may include pre routed traces, plane shape polygons, vias for heatsink or shielding. All pads are linked from seperate padstack library. Would prefer a custom pad shape solution what covers more applications.

[Michael Kavanagh (michaelkavanagh)]

Should this be filed as Wishlist or closed?

[Piotr Gałka (piotrgalka)]

I think the problem of 4-pin tact-switches or 3-pin 2032 soldered batteries (and may be some other 'like this' elements) should be in some way addressed to allow connect track only to nearest pin.
I don't understand the negative consequences of assuming pads with the same number are connected.
May be the other bug should be defined on that subject as wishlist if you know that suggested by me solution is simply impossible.

[Seth Hillbrand (sethh)]

@Piotr- We cannot just assume that they are connected as this changes the internal assumptions about the footprints. It also allows accidental errors to go undetected by DRC.

Not all footprints with multiple connection points to the same pad are internally connected in the component.

Because of this, we need to ensure that the user is very specific about which pads are _meant_ to be internally connected.

The discussion right now is whether the addition of this option breaks netlist testing at the fab house. It appears that this _does_ break the net testing of bare boards in other software packages. If we do change to allow this, we will need to carefully review how this limitation is communicated to the end user.

To solve your multiple pad connection issue currently, you should use complex pads. Make one large complex pad and then overlap small pads of the same number to the points where you want additional connections.

[Piotr Gałka (piotrgalka)]

@Seth
I know that my suggestion is to change internal assumptions. I suggest pads with the same number need not be connected but you can connect them if you wont. I have nothing against specifying that different way but using for it just the same number seams for me the simplest and most logical way.
At that moment I can't imagine any footprint to have two pads with the same number and needing them to be connected at PCB but I know only limited set of footprints I have used in past. Do such footprints can't have that pads with different numbers and symbol with separate pins? Example with info why pads have to have the same number please.
The suggestion of potential problems with netlist testing at the fab house is very surprising for me. Since over 30 years we have never send a schematic to PCB manufacturer. So the only netlist they can get comes from gerber files so if net is connected to only one pad of two (part with internal connection) they just see that this net should be connected to only that one pad and the other one is not connected. Since ± 15 years our PCB manufacturer claims he electrically tests 100% of his PCBs - so he has to base on gerbers and not other sources.
Forget my multipad connection problem (in Q-Touch key). It is only a source of this bug report. I suppose it is solved (I will see when I will install 5.1.5) - as I remember offset in SMD pads were not taken into account to detect pads are connected (if offsetted center is inside another pad) and as I remember (not sure) it was fixed.
The only reason for me to discuss it now is to make KiCad better.

[Seth Hillbrand (sethh)]

I understand that many users do not use all available KiCad features such as the IPC-D-356 output. This does not mean that we can disregard the effects of changes on this file. Some manufacturers do require the use of this file. As long as we are generating it, we need to generate it correctly or ensure that users know when they choose to generate an incomplete/invalid file.

We are not currently closing this issue. Only discussing whether and how to implement a feature.

[Piotr Gałka (piotrgalka)]

I don't understand what forces any output file (addition to gerbers) to report such 2 pads as connected if they are not connected at PCB but only inside the device.
But I know that I know really nothing about internal KiCad logic.
Assume my opinion is only what I said in #16 (writing those I didn't planned to add any more).
When I say (there or here) "I don't understand" that means only that. I don't ask for explanation. Rather I write it to explain myself - why I'm not sure of my opinion and so why I add the last sentence in #16.
My intention in #16 was to read it as: I only think that a problem is worth of addressing but which way - I know to little to even suggest (I don't insist on not closing this issue).

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2558