Case sensitive net labels?

Has anyone noticed whether their version of KiCad uses case sensitive names for net labels?

It seems that 4.0.x series is not case sensitive for net labels, ie. local1 is the same as LOCAL1
Some (all?) versions of nightly build are case sensitive, ie. local1 is not the same as LOCAL1

Older versions of KiCad did not have case sensitive net names, a bug report was made that indicates a change was made in 2015 to make net labels case sensitive. That code has since been rewritten, so perhaps 4.0.x became case insensitive.

Well, very confusing. I am using a test circuit as follows :

This generates a net list (version 4.0.6)

(net (code 25) (name GND)
  (node (ref U1) (pin 7))
  (node (ref J1) (pin 2))
  (node (ref U2) (pin 7))
  (node (ref U3) (pin 10)))
(net (code 1) (name VCC)
  (node (ref U1) (pin 14))
  (node (ref J1) (pin 1))
  (node (ref U2) (pin 14))
  (node (ref U3) (pin 20)))
(net (code 2) (name /0.WAIT#)
  (node (ref J2) (pin 4))
  (node (ref J3) (pin 4)))
(net (code 4) (name /LOCAL1)
  (node (ref J2) (pin 1))
  (node (ref J3) (pin 1)))
(net (code 5) (name GLOBAL2)
  (node (ref J2) (pin 2))
  (node (ref J3) (pin 2)))

which has all names upper case, and connected (Although in some cases the name will be the lower case version, seems to depend on which is the first label found).

Oddly, v4.0.6 ERC generates a warning:

This appears to be spurious, because in fact KiCad does connect global2 to GLOBAL2

In a nightly build from several weeks ago, I found that the names are case sensitive, and you get additional warnings about similar looking net names.

Since there are probably some people relying on case insensitive names (old KiCad behaviour) and there are many official library symbols which also depend on case insensitive names, changing the behaviour will cause breakage.

So to questions:

  1. When did KiCad start using case sensitive names for net labels?
  2. Is this a bug?

Since when does Wayne post replies to questions like that here?

* ducks and runs *


I am interested to hear from users - those “old hands” here, as well as “new users”. I’m from a programming background where case is significant, and there is a common convention in software that upper case signifies named constants, otherwise there are various conventions for local variables, parameters, member functions etc.

Is there any EE convention for example that “RESET” is a global label, and “Reset” might be a local one?

Somewhere I might have accidentally user “Reset” and “RESET” to mean the same thing, and KiCad 4.0.x joins them together. I would be surprised and disappointed if that stops working.

Wayne often says that he won’t accept changes that break user’s previous designs, but there seem to be frequent exceptions to that rule, e.g. if the change is regarded as fixing something that has always been a bug and never intended. I’m trying to work out if case sensitive names are a “new feature” or a “fix to an old bug”.

In my tests, all versions of pcbnew seem to always respect the names in the netlist, so it treats RESET and Reset as distinct nets.

1 Like

This definately looks like a bug.
Personally I vote for case sensitive net labels, mostly because I’m used to case sensitive stuff.

I also think that depending on case is usually not a good practice.
In C I had a rare occasion where I had 2 case dependent macro’s.
I was not entirely happy and for portability reasons, so I also built in a case checking macro.

// C macro’s, but “#” does something strange here if it’s the first char on a line.
define ASDF_A … // Acknowledge Request.
define ASDF_a … // Acknowledge Response.

if ASDF_A == ASDF_a
error Macro names are not case sensitive

The single thing that matters to me the most is that behaviour should be consistent through the whole KiCad package. Joining the nets in the netlist but then generating errors for DRC is not consistent. That should be a bug according to any engineer’s opinion.
PcbNew seems to have gotten a lot more attention than EEschem in the last years and is therefore more likely to reflect the developer’s goals.

Note that the DRC errors in this example would not have been generated if both spellings had more then 1 label.

For old projects where case is mixed (and the pcb traces drawn) they will definately generate DRC errors when KiCad changes to a case sensitive style.
This is easily fixed by opening the schematic in a text editor and a search&replace command.

I’ve manually edited a netlist and added the name “ASDF” with 3 nodes, before reading it in PcbNew and I can confirm that they are treated as 2 separate nets.
Both the nets “Asdf” and “ASDF” show in the Design Rules Editor.

While editing the netlist in an editor I noted an inconsistency between named nets and un named nets. The unnamed nets have their names between quotes “Net-(J102-Pad1)” while the named nets are unquoted.
I became curious and added a global Label with a net name in quotes.
In the netlist this is handled as a new netlist and the quotes are escaped with backslashes.
I’m not quite sure what to think of this behaviour.


Raise the inconsistency as a bug on Launchpad and let’s see what the developers think is the correct behaviour.
Personally I expect case to matter, but I would try hard to avoid recycling names.
DOS based ECAD must have been case insensitive, but KiCad was never a DOS application.

Having Reset and reset would be asking for accidental typos causing split nets. Maybe we need a specific warning check for similar names, but how far to go. O and 0, i, I, l and 1 (lower case “L” and upper case “i” are the same in many fonts)?