What am I missing here-in the simple reduction shown I have SMT pads connected to the front (GND) and back (3.3V) layers.
The ground layer looks fine when the full display is turned on. But the back layer does not “fill”.—Probably forgetting something here-
thanks
fritztest.zip (8.0 KB)
You forgot to set the zone on B.Cu to +3V3.
It is set to the GND net.
So either punch a GND via through the board, or set the properties of the zone of the bottom to the + 3V3 net.
Thanks Paul–I guess the zone does not pick up the network when it is defined and I have to "E"dit it to set that.
But here is a more realistic example–if I Edit the green (back) zone it is indeed 3.3V. But the pad on the resistor and the via for 3.3V are connected to the front (red) plane. I would think that the pad would disconnect from the GND and the via would “drill thru” to the 3.3V plane.
Fritz
transimpedance_REV1.zip (102.7 KB)
Nope.
When you first define a zone, you have to assign a net to it. It defaults to “No Net”, and you hat “GND”, so you must have set it.
I guess you mean the right side of:
KiCad does not always re-calclate zone boundaries. If you press b to re-calculate all zones, then the +3V3 net is separated from the GND zone again.
Via’s always “drill through” (Except “micro via’s”, but that is a special case).
OK—in the system shown, I have used the E command to set the zones to GND and +3.3V. But they do not connect to the respective pads in their network. I still am missing something here
Thanks
Fritz
test2.zip (255.1 KB)
Not confirmed here (5.99 , May17, W10). When loading the board first time, there were rastsnest lines @ pins 6 and 7. Pressing B connected pin 6 to +3V3 and pin 7 to GND.
Btw, in the schematic I get unknown symbols which I couldn’t rescue in my configuration:
Thanks Martin-
I guess I am not going crazy–I typed the “B” command on my draft and nothing happens. So-I redrafted the example and it works fine. Something odd going on here but probably not worth pursuing.
Sorry about the incomplete file that I send-I guess I forgot I have to seed all of my custom part libraries with it.
Fritz
Welcome. While software is supposed to be a deterministic system, reality proves that theory wrong at times 
Hmmm—software strikes again-
I am still having issues with establishing the power planes. This time I “think” I have included the enduser libraries to show the problem.
There are 2 sets (GND, 3.3V) of power pads on the boards. One set at 28 and 29 connects to the planes just fine. The other set at 6,7 does not.
I am guessing I have “something” set wrong in the board’s resolution needed to complete the connection-but then why would it work on one side but not the other?
Thanks
Fritz
footprints.zip (41.0 KB)
symbols.zip (19.5 KB)
temp.zip (12.3 KB)
Sorry, Fritz: same story. ‘B’ and 6,7 are connected to their respective planes…
BTW, you are on an older version than me (or at least the board was created with a version prior to May 17th).
Thanks for including the libraries, but updating the symbols still does not work as it looks for a rescue.lib on "C:\Users\Fritz\Dropbox…
I noticed, that the libraries are legacy and not converted to the new format as well. Which makes sense if you use the libraries in projects created with 5.x versions. Shouldn’t be relevant to the issue at hand, though.
If you want me to dig deeper - which I gladly could do within the confines of my KiCad knowledge - I need the “C:/Users/Fritz/Dropbox/FNSSCIENCE/electronics/KiCad/@SAMPLE_CIRCUITS/DC_DC_linear_2/main_board_rev1-rescue.lib” library.
… and the PIC18_FTDI-cache.lib
Yikes
I am always afraid of these extra libraries-not clear what they do and I fear if I change PCs they will evaporate. I wish they all were included in the folder for the design.
I have included what you need (I think). Not sure where/why the rescue lib is coming from - I think it is unrelated.
I am showing release 5.19-1. I will certainly upgrade shortly when I can get away from the lab!
Thanks
Fritz
main_board_rev1-rescue.lib (5.9 KB)
PIC18_FTDI-cache.lib (5.0 KB)
I had a look at “test2.zip” (From a few posts back) and your issue is related to the stacked pads.
I’ve moved the footprint so the zone flows around it, and refilled it with b.
On the left side there is a thermal spoke, and if you look closely at the right side, KiCad is trying to make a thermal spoke (flat section) but something prevents it from doing so.
I was suspecting the stacked pads as well. But then, on the unchanged board, after ‘B’ everything is connected all right here
I’m on 5.99, May 17th, W10. He is on 5.1.9 (he wrote 5.19, but there is no such thing to my knowledge). Did the zone filling/connectivity behaviour change since then?
There is 3 years of development in V5.99 and there is a long thread with several hundred posts about all the differences.
In V5.1.10 it definitely does not fill.
I modified the footprint in the footprint editor, and made the right pad of “7” a bit smaller. Results is that the stub is getting longer, so the thermal spoke is quite likely keeping it’s clearance from the round section of pad 7.
Changing the pad connection from “Thermal Relief” to “Solid” works as expected:
Setting it back to “Thermal Relief” again prevents the right side from connecting.
So it does look like a bug in KiCad to me.
Another unrelated (and very minor) issue.
DRC complains about: Board outline does not form a closed polygon, and the reason is that the top has two lines drawn over each other.
Application: Pcbnew
Version: 5.1.10-88a1d61d58~88~ubuntu20.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux 5.4.0-73-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.68.0
Compiler: GCC 9.3.0 with C++ ABI 1013
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
Hmmm-long forgot about the double layering and it is not obvious. I would like to remove the “single” layers-is there a way to add the 2nd hole to the double layers? If there is non I can probably cobble two singles together
Thanks for your help!
Fritz
I do not understand what you mean with “double layering”.
Is this in the footprint? on the PCB?
The way you have combined an oval pad and a round pad to make a THT pad with two holes is done quite neatly, and it should work as intended.
With a “solid fill” instead of “Thermal Relief” the connection is also done as expected, and that is why I suspect it is a bug in the way thermal reliefs are calculated. Apparently the 3nd pad is treated as something to stay clear of, while it should not.
Paul
Finally getting back to this (research proposal week here!)-
By “double layering” I mean placing two pads on top of one another, in this case to produce a 2nd “hole” in the elliptical trace. Ideally I would just like to place one trace with the 2 holes–something I probably can build. It is just less work that what I originally did, and perhaps the “double layering” is invoking the present problem-or bug. (Is there a way to drill a hole in a pad?)
Sorry about the invalid release I reported. I upgraded to 5.1.10 last last night and as you indicate the “B” command still does not fill to the pad in thermal mode. I then changed thermal connections to solid and the pads connect properly as you indicate.
So I am in a bit of a quandary here-probably won’t change all of my designs with this pad structure since I would assume this will get fixed at some point. At least in the case I don’t really need thermal connections.
A side note: I don’t use 5.99 as I assume it is a Beta Test and the earlier releases work ok for my designs. I am patiently waiting 6.xx however as there are some key things that I am hoping appear there.
Paul, Martin–many thanks for your analysis-I now can proceed with my design.
Fritz