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
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).
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:
When did KiCad start using case sensitive names for net labels?
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.
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
endif
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)?
