I’m (trying) to design a touchpad using SMD pads as capacitive touch sensing electrodes. The footprint for the square electrode has four 4mm square pads & 0.8mm air gap, where pads numbered “1” are placed in the left-top and right-bottom and pads numbered “2” are placed in the right-top and left-bottom. “1” Pads are connected with a line in F.Cu Layer and “2” Pads have to connect in B.Cu Layer. The Footprint editor doesn’t have Vias, so I added a THT pad the size of a Via in the “2” SMD pads and numbered them as “2” to be recognized as the same pad. See picture below.
This electrode will be replicated several hundred times in the PCB design, so it is essential to have the Pads connected in the footprint (and not during PCB drawing).
The problem: in PCBNew, the DRC identifies the THT Pads as “un-connected” and the B-Cu Lines that connect them as a clearance violation. It also doesn’t recognize the lines connecting the “1” pads in the F.Cu Layer.
Using a THT pad as a via in a footprint is normal, and setting the pad number to the same as the THT pad is also the right way to go.
When you just add a graphical line on a copper layer, it is not a copper track. KiCad makes a clear distinction between those. Graphical lines are never part of a net. As you’ve noticed, you can not draw copper tracks in the footprint editor. The way to go is to add the graphics themselves to a pad by drawing a custom pad. You do this by first selecting a pad in the footprint editor and then right click on it and select Edit Pad as graphic shapes [Ctrl + E] from the popup menu.
@paulvdh Thanks! Just to make sure: I created the “1” Pads just as you mentioned (picture 1). For the “2” Pads, I created circular, filled pads the same size as the THT pads (i.e. Via’s) and connected these in the B.Cu layer as a single pad (picture 2), I then added the THT’s and the F.Cu Pads, all of these (B.Cu custom pad, THT & F.Cu pads) identified as “2” (picture 3). DRC in both Eesceham & PCBNew now report no issues. So I’m good to go?
It looks quite good from what I can see from a few screenshots.
If you create a small demo project, zip it and post it here then I (or someone else here) can have a closer look if it all works as expected.
@paulvdh Many, many thanks for your patience and generosity. I can understand the “…yet another test…” thing, but you really help a lot of people with these things. You make these forums worthy! Thanks again.
When you draw a custom schematic symbol, then “left” means that put the pin on the right side of the symbol.
KiCad has a similar quirk with Up and down.
It’s a matter of definition. If A is left from B, then B is right from A.
KiCad also sometimes changes such things. I had gotten used to the X shortcut key mirroring over the X-axis, and in KiCad V6 it it now mirrors in the Y-axis. Which is the most logical to new users? Maybe you can tell me. Do the current X and Y shortcut keys for mirroring feel intuitive to you?
V6 is my first experience with KiCad (actually, with any schematic/PCB design: I started with the “KiCad Like a Pro” course a couple of months ago) .The Left/Right pin orientation was really disorienting! The only shortcut key I use is “R” Still a lot to learn…
I’ve found that for me that I ignore the left/right terms and look at the picture. The thin circle on the end of the pin representation is where the wire connection will take place. The line is just graphical representation to the rest of the graphics of the symbol. I use that to figure out what orientation that I need. This seems to work the way my mind works, hope it helps you.
I keep forgetting the XY orientation of the mirroring as well as the LR meanings of the pins, but no fuss, I just reverse or undo the edit and try the other way. It’s no different from say using a text editor like vim, you undo and try the other way. If you use the action often enough finger memory or unconscious memory will nudge you to the right key, no need to think hard about it.
I can get used to the X shortcut key mirroring in the X direction instead of in the X-Axis, and even though the change itself is a nuisance, I think it’s good this has changed.
I can also live with the Left / Right issue, I have done so for 5+ years, but it’s mostly coping by remembering that it’s the other way around.
The bigger issue for me is that it gives a weird feeling to (probably) all (or most) people starting with KiCad, and such things may add up and may be a factor in not continuining with KiCad, or being a bit less enthusiastic about KiCad when discussing it with their friends or at school or on forums.
A lot of gripes about software in forums like EEVblog boil down to “this isn’t what I’m used to (with some other tool)”. I think that as long as a software suite has sufficient internal consistency then one can adapt to each tool. Same as with computer languages, you have to take a slightly different mindset when you switch languages, although the fundamentals of algorithms remain.