In my reply to retiredfeline, there’s two images of a circuit where I tried his suggestion* with a switch. The switch has 2 pads with number (1) and two pads with number (2)
The suggestion was to simply give two pads the same number and Net, and DRC would understand that they are internally connected in the switch’s footprint
However, DRC says that the two F.Cu zones (both belonging to GND Net and with pad number (1)) are not connected.
Your image: Yes that I can do, but the problem is that DRC doesn’t understand that there is an internal connection inside the switch? What if you’d draw a GND zone that would get an island inside of your trace… would it not say that the island was unconnected to GND even though it is, by the internal “jumper wire” inside the switch?
Perhaps others can explain better than me and repeating myself (because I don’t understand) isn’t helping.
Thus, let me suggest that, in lieu of Asking:
• What if you’d draw…
• Would it not say…
Try the suggestions and some attempts to answer your own questions. If you don’t get the answer you need, post what you’ve tried with Clear/Clean, Images and files).
So you are using the inherent connection within the device to make the connection between the two GND pins. The device isn’t part of the footprint so KiCad doesn’t “understand it” . . . not sure how you fix that for DRC purposes, sorry.
This is Not a solution to your need but, it may answer part of your question about Zone and Trace under the Buton-Sw
Trace is on GND net
Zone is on TOFU net
This uses the new Zone/Fill Tool. Because they are on different Nets, the Zone abides by the Keepout settings
ADDED: Naturally, a next question might be: What if I need a GND (or other) Plane under the Btn-Sw and what if I want to connect the Button’s Pins…
Picture worth 1000 words (?)…
Think of TOFU as VCC or other… The Zone abides by Settings. The Traces from the Pin to Pin’s were done in PCB not in Footprint.
[Edit: It took a while to write this so the question had already been answered when I posted]
I’m sorry, I’m not explaining my feature suggestion clearly. I don’t mean that you should do the work for me, I just can’t get any of the suggestions to work.
This is the problem:
I need to get DRC to understand that a jumper wire exists. In the following example the wire is inside a tact switch. (In my original post problem it’s the two internally interconnected GND pins of an Arduino Nano.)
First: The copper zone island that R3 connects to is isolated, that’s expected
Second: Now I add a tact switch that in physical reality has “internal jumper wires”. I get the same type of error, because DRC doesn’t understand that they are jumpered.
I understood you correctly. No, Can’t cross tracks on different Nets or Planes.
And, perhaps more importantly to get comfortable with is that the Button’s internal connections do NOT need to be re-produced on the PCB or in Footprint. You just need to connect your circuit to them as desired. Think of the Extra two pins as convenience hookup pins. They won’t DRC error.
This is the internal circuit
And ,this snippet is a built product I did awhile back - multiple BTN’s with Trace between Pins. Nothing was needed to ensure connection between internal connected pins…
If you really want to take advantage of the jumpering capability of those switches, you could make the connection between the two pairs of identically numbered pins on an unused Cu layer and then not submit that layer for fabrication.
Retiredfeline ideally I would be able to define such a copper layer (a “hovering layer”?) inside the footprint, DRC would understand the electrical implications of it, but wouldn’t export it…
BlackCoffee I think it works when you draw the traces to the pads (as long as the pads have the same number and belong to the same net) but not for bridging zone fills? Or maybe I’m getting tired
I’m trying to cram a lot of components within the width of an Arduino Nano. Since the Nano has two GND pins I thought I could use one as “GND input” to Nano, and the other as an “GND output” from Nano to other components. I will still do that, just ignore the DRC error
Perhaps I wasn’t clear enough… And look at my posted image - see the numbers…
In all of my posted images, there are only two Numbers, 1 & 2. There are 4 Pins.
ADDED: Because not all Btn switches are identical, consider when not certain, the best solution is grab a DMM and test the Switch Open and Closed. Then you’ll know what’s connected internally and what gets connected when Pressed…
At the moment I have no time to read the thread (certainly will do it later) but may be the discussion with developers in 2019 can shed some light on the subject:
What I remember is that I suggested to just assume pads of footprint with the same number are connected even there is no connecting them copper at footprint and developers had something serious against it what I didn’t understood why. It was in some way connected with PCB testing by manufacturer and I don’t know if it was associated with files already being exported for it or only future planned in 2019.
I read the gitlab discussion. From my perspective it’s less logical for a user to rename the pads, it feels strange to rename pad 29 to 4 (both are GND) on an Arduino Nano. Maybe it’s not supposed to be used that way, but having pad numbers correspond to pin numbers help when routing.
The idea of each pin having a field in the symbol called “jumper group” or similar, and then add the pins to same group sounds appealing to me Or maybe it was in the footprint, not the symbol, but anyways…
touch key constructed of several rectangular pads but really having only 2 pads (Key.png in my first post there), in V5 I couldn’t make one pad from these pads,
push button having 4 pads, but really 2,
coin battery having 3 pads but really 2.
For such footprints the rule - the same pad number means they are connected would work, I think.
I didn’t thought about DIL, TQFP like footprints with selected pads connected internally. For TQFP microcontrollers even pads are connected internally I assumed that they have to be connected also at PCB so didn’t thought about it in this context.
