Copper Pour not connecting to Ground Pins

I have a connector that is on the Back Side of the board. It has a pin for Ground (Net Gnd) and a pin for Power (Net V3). The (Back Side) Power Zone is connecting but Ground (Front Side) is not. The Power pin just happens to be Pin 1 and so it is square. The other pins are round and all are thru-hole. Just in case there is some setting different between the two zones, I took the Power zone and duplicated it. Still doesn’t work. I have played with the clearances and other parameters but to no avail.

Not clear from your post:

Have you set the zone to being a ground zone? Must be set to the same net as the pin to which you want it to connect. Be sure to reflow the zones (B shortcut) to make sure that isn’t the issue.

I just noticed that the pins that are connecting are net GND. The ones that are not are net Gnd. Net Names are Case Sensitive! Problem solved.

Good that you have it solved. I wonder whether case sensitivity in net names was implemented intentionally.

Mainly to other forum members: I think I would prefer that it would not be case sensitive…but maybe I would be out-voted on that?

I don’t know if you’ll get out-voted, but I will vote against :crazy_face:

As a compromise, ERC in KiCad-nightly V5.99 has a check for it:

Meaning you would rather not have case sensitivity?

User option sounds good.

I’m against an option and against ignoring case. Having “Gnd” on one side of the board and “GND” on the other just is unclean and difficult to understand when e.g. looking at a printed schema.

It’s a good think that KiCad forces you to be consistent and the warning added in 5.99 is obviously useful.

1 Like

I am all for respecting the sensitivity of the case :slight_smile:

2 Likes

Isn’t unclean in the eye of the beholder? Might cleanliness to one person be useless nitpicking to another? Case sensitivity has a purpose in passwords, but I do not see the point here. 2n3904 is the same transistor as 2N3904.

I can imagine a design which distinguishes between Gnd, gNd, GNd, etc. but such distinction seems more likely to be typos than intentional. I would rather have Gnd1, Gnd2, Gnd3, or any of the other common separations.

I just want to add that I am commenting in the spirit of constructive debate; nothing intended beyond that. I love a good argument. Regardless of any decision in this matter I do not see the stakes as being particularly high.

Case Sensitive for me.
This allow you to name certain parallel things in a unique way (e.g. big and small AN2 pins for the two different type of A pins. perhaps an2 going into a amplifier and AN2 going out of one)
Also, programming traditions. Most programming languages have case sensitive variable names.

Case non-sensitive actually require more code (as you can just compare the two strings to see if they are equal, typically simply comparing the two string as if they are numbers, whereas case non-sensitive need to check each letter and see if they are different letters or identical letters but different cases)

You might also have a power ground and a signal ground (who knows), so in that case you can just label GND for power and gnd for signal.

2 Likes

Thanks for contributing. Is there some special meaning to an “A” pin or “AN2”?

Would there be some disadvantage to adding another character such as AN2A and AN2B so as to distinguish between two AN2 pins?

I am not surprised that case insensitive requires more coding. But if in fact we have that as an option (I just now searched for the option unsuccessfully) then the coding has already been done. I do not remember for sure but I think that word processors in the DOS days (run from a floppy disk) could find text in a case insensitive manner. My point is that the required coding would appear to be small by the standards of modern software.

Does having an option in preferences (again; I have not found it) leave some needs unsatisfied?

1 Like

Other than portability issues depending on where the case preference is. Designer Able doesn’t have case sensitivity set and has multiple labels that have random capitalization. He then publishes his design into the Open Hardware ecosystem. If the setting is at the program level (i.e. not saved in the project files) then Baker who also doesn’t have case sensitivity set can use Able’s project without issue. But then Charlie who does have case sensitivity set and is a newbie to the community has a broken project leading to both frustration and support requests to Able. A significant portion of the rest of the alphabet of users will be in the same boat as Charlie, causing a significant support issue to Able, and a significant portion of the alphabet getting frustrated and bashing KiCad for not working.

Just one example of “just make this compatibility breaking feature an option” causing issues. Sometimes too much freedom in implementation can cause problems. IMHO, KiCad should either always be case sensitive, or always be case insensitive. I actually don’t care which, although because it is currently case sensitive I see more problems with changing it now with the possibility of breaking older designs when loading into newer versions of KiCad.

3 Likes

OK thanks. That makes sense.

Net at microcontroler pin: PC1, and after series resistor: pc1, and after LC low pas filter at shield edge: Pc1 and so on.

This seems confusing. When I am trying to keep something straight in my mind while working, I say it to myself:
“Capital P Capital C 1”
“Capital P Little C 1”
“Little P Capital C 1”
Yikes! In English (and I think most other languages) we have conventions for using capital letters in certain places (beginning of a name or a sentence) but usually do not assign it a critical meaning.
Why not use pc1a, pc1b, pc1c etc? Much easier to say, and therefore much easier to keep in mind while working…

This reminds me of an old comedy skit where this guy has two brothers, both named Darryl…

But I appreciate the point made by SembazuruCDE that if someone decides to rely on case to define nets (or maybe something else) it is best that everyone working on the design respects the distinction.

1 Like

I agree with your point here, although I would use a tick mark meaning in my head “prime”. So I would have PC1 (pee cee one), PC1’ (pee cee one prime), PC1’’ (pee cee one double prime), etc. Although, now that I think more about it, I’m not sure if the single quote symbol is an acceptable character in label names. Maybe a back-tick then? I’d personally avoid appending a letter for fear that I might get confused with component units. I confuse easily. :wink:

But, realistically, what ever method that works best for you and/or your organization should be the one to go with, and flexibility of the program to allow all of them is a GoodThing™.

:grinning:

This is extra text to get past the minimum…

2 Likes

Feel free to steal it, I think I did. BTW, if you are on Winblows, the trademark symbol is alt+0153

1 Like

Stealing trademarks? What sort of legal advise is that?

And why referring to this movie:

No. I’m thinking that because there is this programming convention they assume that you assume that things should be case sensitive. And it’s okay to not have the assumptions line up correctly.

You can start a new thread with a poll titled things like “case insensitive Net” under suggestions.

1 Like