Vias get excluded when refilling areas


#5

Vias and planes are parts of nets. You must tell KiCad which nets they belong to or it has no idea which planes to connect.

Consider the case where there are four overlapping planes. If I place a via, which planes should it connect? All of them? Some of them? None of them?

Click on one of the orphan vias and hit “e”. What net is the via part of?

Click on the edge of one of your planes and hit “e”. Which net is that plane part of?


#6

Sorry about that. I am new and this is my first project. Now let’s get back to business:

The net for the orphan via is 0.0 and for the front/back copper layer is 3.


#7

Those are the “Net Codes”


#8

I am possitive though that KiCad knows what plane to connect it to because when I created the front and back coppers first, and then attached vias (using the “v” while starting and finishing a trace in the same spot) the vias had the word GND on them. Only later did they disconnect. It deffinitely has to do with the refill function in my oppinion?


#9

If both planes are net “3”, then you need to change each of your vias to net “3” as well. Then when you refresh the plane fill they’ll connect.

You might also want to associate a name with that net: “3” isn’t particularly descriptive. If you have a net named “GND” already and the planes aren’t part of the “GND” net, then they’re not connected to “GND”.

Refill won’t (or shouldn’t) change the association of vias and nets. What does happen is that KiCad doesn’t always update the plane fill until you tell it to. This can result is all sorts of issues (and is at least partially fixed in v5). Any time things look wrong, refill the filled areas. And always, always, always do this before sending files for fabrication, or you’ll get bad boards.


#10

I am confused:

1: When I finished my schematic and associated components with footprints and generated the netlist, wasn’t that the only time to associate anything at all with a net? Is it even possible to a change a net of something once the netlist was already generated?

2: The net is GND and the “NET CODE” is 3. I followed what you said and clicked on the edge of the plane and hit “E” with my mouse.

What showed up was a menu to choose from two zone outlines on front or back copper and I chose the top copper. What showed up next was this:

When hitting “E” above an orphan via what showed up was no net name but only a net code (which is why i chose to use net codes and not names in my post)

3: How come when drawing traces there is no need to go ahead and name each and every one of their net names individually but for vias you do? Does it have anything to do with being in the middle of the board? But that doesn’t make sense because they ARE drawn from one GND plane to another (using the trace drawing tool)?

Any help will be really helpful.


#11

Sorry… I’m running bleeding-edge v5 and it doesn’t show net numbers, only net names.

When routing a track you’re starting from a point already associated with a net, such as a pin on a component, so the track inherits that net. Planes don’t appear on the schematic so you have to specify what net they’re part of; this can be done when they’re create, and changed afterward. If you create a via while you’re routing a track the via becomes part of that net too, because the intent is clearly to carry that net through the board to another layer. If you’re placing vias separately, though, they often need a bit of help or they end up orphans.

I vaguely remember that placing vias to stitch together multiple planes was a right pain in v4. In v5 it’s much easier – there’s a LOT to like about v5, but it’s not quite ready for release.


#12

Here’s the Edit dialog for a via in v5.0-rc2:


#13

1: The way I am creating the vias is by using the tracing tool though. Is there a way to “just place a via” without having to hustle your way through tracing starting and ending your trace from the same point on two different layers?

2: How come the filled plane doesnt have a net? Doesn’t it attach to pads from ICs who have nets?

3: Traces don’t exist in the schematic either but still don’t need netting?

I would appreciate if anyone knows the solution.


#14

Do you know how to get to this dialogue for v4?


#15

That’s the dialog that you get when you click on a via and hit “e” in v5, and there should be a similar dialog on v4. I would expect you can change the net there. Changing your vias one at a time is tedious, yes, but doable.

With v4 I think you should only have to route a track on one side, not both. If you place a via known to be part of the GND net, it should connect to all GND planes it passes through.

Yes, this is a royal pain in v4. It was one of the things that annoyed me greatly. All fixed in v5.


#16

When I hit “E” above the orphaned vias, no dialogue comes up. Only on the outside border of the filled GND area a dialogue appears.

So basicly if I have one via connected to another on the back plane all the vias will be fine and “netted”?

What about this: Protip: nicer via stitching

Is that too fancy for what I’m practicing?


#17

I can’t tell you what is or isn’t too fancy for your needs.

I’m sorely tempted to tell you to install one of the nightly v5 builds, or even the V5.0-rc1 build. It’s surprisingly stable for pre-release software (possibly more stable than v4.0.7 according to some users). But then I’m a software engineer who builds my copy of KiCad from source code with all the debugging options turned on, files bug reports, and has no deadlines on my hobby projects. I’ve even been known to use a text editor on the .sch and .kicad_pcb files on occasion.

I’m curious how you got vias in the wrong nets. What does your board look like with the zones un-filled (11th icon down on the left edge)? Is there still a track from a known GND pin to the vias?


#18

The way I created my vias was simply by starting a trace using a mouse click, hitting “v” on my keyboard, and finally double clicking without moving my mouse (basicly the shortest trace possible with a “v” used on it).

My board looks like this:


#19

Ah, that’s what happened.

Google shows a bunch of discussions on the best way to address this with v4. I haven’t done enough with v4 to tell you a “right way” for you. Do whatever you have to do to get this board out and comfort yourself with the thought that v5 should be out in a couple of months.


#20

Just be aware that there is a particularly nasty bug in PcbNew at the moment. I’m not sure what release it crept in at, and I’ve never personally experienced it.

Otherwise, I agree, I’ve had fewer problems with the nightlies then some of the stable versions (though I have never used the latest .07 stable).

ON EDIT: PcbNew


#21

@Sprig care to be more specific about this “nasty bug” in eeschema?


#22

1767826

and maybe now it will be 20 characters…


#23

This bug argues heavily for frequent use of content management software like Git, Subversion, or the like. My philosophy is never go longer between commits than I’m willing to re-do after a failure.

Given how cheap disk drives and network-attached servers are, anything worth preserving should be stored in at least two places, preferably shadowed on multiple pieces of media. Even my home system has RAID-1 protection of the /home partition, and my Git repos live on a RAID-1 server that cost less than $300 to assemble and consumes less power than an old incandescent nightlight. I’ve been burned too many times by failures to have it any other way.


#24

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.