No via without a track

Bug #999057 reported by Tommi Karkkainen on 2012-05-14
This bug affects 96 people
Affects Status Importance Assigned to Milestone

Bug Description

PCBnew does not allow to place arbitrary vias, that is, I cannot add a via unless I'm drawing a track. This makes it impossible to stitch two ground planes on separate layers together. There are workarounds but they are too cumbersome to use in board designs where a large number of stitches is desired.

Judging from PCBnew's manual this is intended behaviour. It should, however, be considered as a misfeature as this is very basic functionality found in practically every other PCB design program.

On Mon, May 14, 2012 at 10:02:41AM -0000, Tommi Karkkainen wrote:
> Judging from PCBnew's manual this is intended behaviour. It should,
> however, be considered as a misfeature as this is very basic
> functionality found in practically every other PCB design program.

Yes, it is intended since it is 'not obvious' which netlist to assign to
these via; I'd put it in the wishlist (there is some work in progress
about netlist to track assigment but I have no idea if it's related to
your question).

Lorenzo Marcantonio
Logos Srl

Ivica Kvasina (kvasina) wrote :

placing arbitrary vias works for me:
- select layer
- select wire tool
- click on zone or track
- type V to place via.
- check board

for example when dealing with high ampacity tracks, i ended placing multiple vias to create low resistance path between layers.

but there is an issue. any further work that requires hiding zones or reflowing etc isolates those arbitrary vias. more over, this also creates isolation gap around via further diminishing ampacity of the track and DRC does nothing to warn you about this.
when via is placed it should be assigned net name so reflowing etc do not affect it.

Changed in kicad:
importance: Undecided → Wishlist
szymon (szymon123) wrote :

it would be nice to put a single pad in arbitrary position. I usually use this feature to add holes on the boards.

Mansour Behabadi (oxplot) wrote :

A bullet proof and headache free way right now is to:

- create a module with a single through-hole pad (you do this once and use it forever)
- in pcbnew, add this module (no need to add it to schematics)
- edit the pad of this module and set its netname to your the name of your ground plane (e.g. GND)
- make as many copies as you need


- you don't have to do any maintenance—no touching your schematics, no reconnecting to ground plane after re-filling zones, etc
- you can change the size of or any other properties (thermal relief, drill size, etc) of all the pads at once if needed (just right click any of them and select "Global Pads Edition" under Pads menu)


- no shortcut to add a netname configured pad—you need to copy one of the existing ones

Martin Errenst (imp-d) on 2014-02-22
tags: added: pcbnew via
Mikk Leini (mikk-leini) wrote :

One little problem with "headache free way" is that it leads to another headache - footprints copy-pasting is not so easy (bug report #1233586).

Could you please prioritize adding an abstract pads/vias feature to PCB editor? This seems to be the most obvious missing feature.

Stefan Kraus (stefankraus) wrote :

This is really a nasty bug. The workaround that szymon described helps (I simply used a "wirepad" in the library), but has its quirks. First of all, the DRC should warn, if I place a part under another part (which I have to do if I want to place a "via" in the thermal pad of an IC) - for some reason, the DRC does not complain. It also does not allow me to use my preconfigured via sizes but I would have to make a part for every size.

In Altium, you can just place vias and if you place it on a polygon on the selected layer, it automaticly uses the net of the polygon. You can also change the net manually (in Kicad, you would just press 'e' on a via and get a menu, where you could select via size, net, and so on).

Ondřej Vaverka (onvav) wrote :

Is there any progress in resolving of this issue? I think that it is important limitation of KiCad. Arbitrary vias are common practice. Please consider a solution.

Karl Zeilhofer (zeilhofer) wrote :

I'm also missing this feature!

*) Problem now when using the CERN interactive router:
When I want to place heat-sink-vias on an exposed pad, the router always snaps to the center of the exposed pad.
So the normal workaround by drawing traces alternating on top and bottom doesn't work here.
*) Workaround:
Draw a trace from the desired net into an empty region. Ther you can draw the vias with the alternating top/bot-method. Then delete the drawn traces, and keep the vias. The vias can now be moved to the desired place.
*) Remark: I did try the method with crating a "via-module", placing many "vias", and manually connect them to the desired net. This way is very time consuming, due to the manual connection to the net.

Perhaps the procedure of a very simple implementation of the missing feature could be:
1) select place-vias-tool
2) a window pops up, where one can select the net out of a list
3) place the vias.

I would donate €100, if someone will implement this feature!

Maciej Suminski (orsonmmz) wrote :

Hi Karl,

Regarding the snapping problem - you may temporarily disable the snapping by holding Shift while routing.


Mark Haun (haunma) wrote :

Sorry to pile on, but I just wanted to add my voice to the chorus. KiCad is really improving fast and I so much want to use it for my next project, but this is the one thing holding me back. Frankly, I don't understand why the CERN folks are working on things like push-and-shove when this feature request is still open. You can do a serious layout with primitive manual routing but you can't do a serious layout without lots of arbitrary vias, at least not if signal integrity is an issue. Are there working EEs consulting on the prioritization?

Regarding the via-as-footprint solution proposed above, how do you keep the "via" covered with soldermask? Can you set up the module/footprint so no copper is showing through? Otherwise it doesn't seem like a practical workaround...


Maciej Suminski (orsonmmz) wrote :

Hi Mark,

We hoped the Push and Shove router will significantly speed up the routing process. Via stitching is on our to-do list, and that means it will appear in KiCad one day. As far as I understand, you would like to place vias between polygons to e.g. improve grounding. It can be done, you just need to have a track connecting the vias. I agree it is not the most convenient way to solve the problem, but currently it is possible.
We have a long list of features we would like to implement in KiCad. Some of the tasks depend on others, and that is one of the major factors in prioritization. It is hard to make everyone happy with limited man power (please note that KICad is not the primary mission of CERN; there is a very limited budget, and we raise funds ourselves to keep going). If you read other comments you may notice many "why is XXX still not implemented? that's the most important feature in EDA!" and we agree with most of the people. Not to mention that everyone has an individual idea for a tool and they are not always converging.
How about joining our efforts to make KiCad better? Recently there are more and more contributors coming and I am really glad to see the project growing.


Mark Haun (haunma) wrote :

Thanks Orson,

Sadly I'm not in a position to donate code but I would donate some cash. Is there some place to do that online?

I know everyone thinks "their bug" is the most important, but in this case I'm right... really! :) I am serious about the suggestion to put these proposed features in front of some working EEs, people who do layout for a living, and ask them to help you rank the priorities. I realize no one who does this professionally is going to switch from Altium [yet], but I think you might be surprised what floats to the top in such an exercise.

The push-and-shove stuff is awesome, and is going to save a LOT of time in layout, but in my experience (using a build from last year), the via issue is more than just a time waster. If I knew I could get the result I want, by spending 10x or 100x of the time it would take in another layout package, this would not be such a problem. But when I tried to string the vias along a track as suggested, pcbnew would delete old vias somewhat unpredictably whenever I tried to move things around later. It also would not allow adjacent vias to touch, which is another show-stopper. (E.g., often when placing your array of grounding vias under a QFN package, they will need to touch in order to satisfy the PCB house design rules and still have enough vias.) For my next project I will need to use some vias in an LVDS diff pair, and I am guessing the code will insist on having the vias centered on the traces, which will not allow me to get the impedance matched correctly. These are just a few of the problems, off the top of my head. I have pretty much accepted the fact that the boards I create with KiCAD will be electrically inferior.

Basically, until vias are treated as first-class objects which can exist independently of any net, this is going to be a problem. IMO it is one of the few things gEDA got right, i.e. they take it as a given that the vias, and all copper generally, will stay wherever the user placed them; then, they run a connection engine to figure out which nets are actually connected to one another, and whether or not this matches the netlist. There may be a better way to do it, but it needs to allow equivalent flexibility w.r.t. via and copper polygon placement.

I am still curious if the footprint-as-via technique, mentioned above by Mansour, will let you cover the whole thing with soldermask. That might be the best workaround in the short term.

Nick Østergaard (nickoe) wrote :

@Mark: I will only comment on a fraction of your last comment. Regarding: "but when I tried to string the vias along a track as suggested, pcbnew would delete old vias somewhat unpredictably whenever I tried to move things around later. It also would not allow adjacent vias to touch, which is another show-stopper."

As of now, I can do thoe two things in GAL when I disable the "Remove redundant tracks" for the pns router. I can also overlap vias. I have not tested this extensively with ground planes and such, or how hard this is to make work on a real design.

Mikk Leini (mikk-leini) wrote :

Seems like nobody is going to implement stitching vias (no such clue in roadmap) so i would like to try implementing this feature. I'm on vacation currently so i have little bit of time.
How should this be organized? I just attach a patch? I guess in the end somebody needs to review and merge it to main tree anyway, so maybe i can get some support right away?
I managed to build Kicad on Windows and add a new menu item but i don't yet know how complex it goes so support or idea sharing with developers would be really nice to have.

Nick Østergaard (nickoe) wrote :

@Mikk, I think it is best to announce your plan on the list and align with the rest of the developers on how it should be made.

Mansour Behabadi (oxplot) wrote :

> Regarding the via-as-footprint solution proposed above, how do you keep the "via" covered with soldermask?

@Mark It's been a while since I used KiCad, but I think you need to set the Soldermask relief or whatever it's called to "-n" (negative n) where n is the size of your pad (or your pad+drill). The negative number is the key.

robotarmy (ry-white) wrote :

"no one who does this professionally is going to switch from Altium" ...I am, I make PCBs professionally at work, and when I'm not at work I still freelance, and for that I use KiCad.

I wouldn't be able to do that work so well if KiCad didn't exist. I've needed Via stitching before, I used the hacky via-as-a-component workaround, but I think this software is awesome and really going somewhere.

I could see myself seriously ditching altium if KiCad moved forward quickly on these sorts of features. I would love to be on a panel of EE's that gets to prioritize features in KiCad.

1) Cross-probing (including full nets)
2) Via stitching
3) More flexibility in scripting/component generation/editing (i.e. properties export of the parts in the schematic to add custom fields and merge with a BOM library, absolutely nothing like Orcad)
3) Better library management UI/UX
4) Better general UI/UX

Franck78 (fbourdonnec) wrote :

strangely, adding a 'free' footprint is available in pcbnew but assigning the net name of each (or single) pin absent from the UI

Pretty useless unless you

-add the required footprint
-save and close
-text edit the xxx.kicad_pcb

and take a look at the beginning for available Net Names

-find your new footprint
-add the missing block in each pad description

(pad 1 thru_hole rect (at 0 0) (size 2.2352 2.2352) (drill 1.016) (layers *.Cu *.Mask F.SilkS)
      ========>(net 1 GND)<========= )

After that, the pad is connected to where you want, ERC is fine, Read netlist is ok, no errors.

And you can duplicate (CTRL-D) this footprint (it keeps net names).


Piotr Esden-Tempski (esden) wrote :

fbourdonnec you don't have to edit your file for this. You just click on the pad and edit it's parameters. You might need to unlock the footprint fully to do that. I did not test it in the legacy interface but it definitely works in OpenGL mode.

Franck78 (fbourdonnec) wrote :

yep, another pitfall I jumped in..... edit footprint not showing pads.

Just saw it after posting.
Thanks Piotr

Here a first patch which enables the editing of vias and tracks net belonging (first patch out of three). By using this patch one can simply copy an existing via and set net name to Ground or what ever is needed.
Next patch will hopefully avoid the automatic renaming of non connected vias during the load process.
The last patch will add a via button for single via placing.

improved version of net name edit patch and...

...the second part. This patch enables the user to decide (via an option in the general settings) if "unconnected" items should lose their net association.

levente (leventelist) wrote :

When can we see this patch merged to git?

Ah well there was a mailing list discussion and it was decided to pursue a different way to handle this problem. It is planed to fix the DRC & connect algorithm. So I discontinued the development. Actually only the via button patch is missing. One can easily copy any existing via and rename it with the two existing patches until the final DRC & connect fix will be released.

As the task has been set we can hopefully pursue the defined solution for this issue in an combined effort.

Mark Haun (haunma) wrote :

Could someone point to the relevant discussion on the dev list? My google search for this bug number and does not turn up anything in the past year.

Assuming that there is a plan (and reworking the connection algorithm sounds like a great idea), shouldn't this bug be promoted beyond "new issue, wishlist, unassigned"? It is currently leading all other issues in heat-index by more than 2-to-1.

Particularly since the devs are prepared to turn down actual patches (see above), shouldn't an actual priority be assigned?

Jakub Kozdon (fldrivers) wrote :

Fixed in revision 3b7b0603b60b50716b6f9f75b14a9bba3c5d9915

Changed in kicad:
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers