Is it perhaps a spurious warning and the issue is that the pins are of type Unspecified? Some symbols you download come like that. First thing I do is assign them the right type in the symbol editor. Using Unspecified defeats some checks so it’s better to be more precise in the symbol data.
Correct, my apology. I meant “This is matching the generated netlist exactly, but I’m still not sure why KiCAD would tie V_TC_IN_A to AFE_OUT_A?”
Thanks
If you have defined A = B, and B = C, then A = B = C. KiCad says those are all the same net, so I will pick one name to use.
1 Like
Understood.
But V_TC_IN_A should not be the same name as AFE_OUT_A, according to my understanding of the schematic above. But KiCAD netlist is suggesting they are. I wish they are same, because unfortunately we have boards assembled based on this assumption and I need to fix them if necessary.
Sorry, I thought all the labels of the line where connected. Watching more carefully I see there is no wire between SW1_S1 and SW1_D1.
I would start by detaching the labels and see what happens with the “highlight net” tool.
To speed up the process you could upload the project as a zip archive.
By the way if you want to use labels to allow the use of differing knowledge domains (which i assume you want as you have a label connected directly to a label at least once) then i suggest to have every knowledge domain in its own hierarchical sheet. In such a case do not use global labels. See Hierarchical or flat schematic design, what is best for me? (How to deal with multi page schematics?)
You have connected them, so electrically they are the same. I consider that axiomatic. Giving them aliases may help you, but it doesn’t help KiCad.
If you actually want separate nets, then you could use a net-tie.
1 Like
Thanks for the suggestion.
Yes, I’m using hierarchical sheets (U8 and U11 are on different sheets - I just placed them in the same image since I could submit only one image to the forum). I’ve been using hierarchical labels at many other places, but only when there are few of them to avoid cluttering the main sheet.
Are you using more sheets? Then the connection must be into another sheet.
You nave reached basic user status. I don’t know if this permits more. You could do multiple posts.
Using global labels when relying on sheets for abstraction violates a key requirement of good abstraction. This is the so called knowledge domain. The reason why you run into your current problem might be because you violated this core principle. You made it harder on yourself and somewhere forgot something that is not in the current picture.
A good abstraction allows you to not know anything about the rest of the system while you work inside one particular sub object. Only in the layer above do you start to care about these things.
Buses might be a good solution for you. Even the restricted once. Just take the knowledge domain of U11. I would use two buses (bus D and bus S) plus heirarchical pins for the power supply and the spi as the sheet pins.
But as you discovered there are sometimes tradeoffs. Your sheet holding U8 might not directly benefit with U8 drawn as it is now. But maybe U8 is better split into multiple units anyway and its units distributed to their best fitting sub sheets.
The main problem i see with your current way of doing things really is this mess of global labels connected directly to each other. (you tried using knowledge domains but did it not quite correctly)
This is a no-go when using global labels. It makes it excessively hard to follow your schematic. So if you want to use global labels then think of a good globally unique name for every net that tells the full story (yes global labels mean you need to think about nets instead of think about pin functions). An example: instead of having DAC_OUT_A and SW1_S2 have SW1_S2__DAC_OUT_A. And then use this label everywhere where you currently use either of the two labels that it represents.
Thanks for your help.
Per suggestion from Rene_Poschl, is there a way for me to send a zip file of my project directly to developer who might be able to recommend a next step.
My suggestion would be to clean up your global labels. For this project it might be easier to go that route than to convert it into a true abstracted view.
So find a clear name for every label group that you connect and use that name everywhere.
Also you notice that AFE_OUT_A is used twice in such a grouping connection right? This seems fishy. (Makes it even harder to understand what is truly going on)
You should be able to post it here. You can edit the post and remove it later if you wish. I’ve never posted a file, just images, so I don’t know that as fact. 
I fully agree to the risk of global labels (or variables as in software), as a general principle. I’ll try to convert V_TC_IN_A (and possibly others) to a local label and see what happens.
However, as shown in the results of the the net highlight tool, all labels of U8 (SW1_S* and SW1_D*) have exactly one producer and one consumer, in order to eliminate such risk of global labels. So these can’t be a source of “multi-writer” issue here. Same apply to V_TC_IN_A , etc.
Meanwhile, please let me know if see any thing specific in the results of the net highlight tool that indicates why KiCAD is generating V_TC_IN_A as an AFE_OUT_A net?
Thanks very much for your help and insight.
AFE_OUT_A is connected to at least 3 labels directly (the connections we see here)
My suggestion would be to disconnect one, see if it still connects to V_TC_IN_A. If it does disconnect the next one. Repeat until you found which of the 3 other labels is the reason for your connection. Then follow that label around. Check what it connects to. (Go into every sheet of your schematic! Global labels can be connected anywhere)
If disconnecting all 3 does not disconnect V_TC_IN_A from AFE_OUT_A then search all your sheets if there is some place where these labels are used without your knowledge.
Also remember all we see is the screenshot. Our advice is very limited because of that.
1 Like
Sure. I’ll play around with AFE_OUT_A and other labels and will let you know.
I fully understand that you do not have at the whole project, and I appreciate your help. The net highlight tool actually highlights the related nets,with purple color, on all hierarchical sheets – which is very cool. I reviewed all sheets for the purple color and posted all those that were highlighted.
Thanks
We have all stared at schematics looking for something and saw what we expect to see. It is entirely possible this is a software bug but more probable that it isn’t.
There is no such concept in KiCad, the direction of the global label has no significance. I did suspect that you were approaching it with a software POV, global variables in software and global labels are not really at all equivalent. Adding multiple labels to a net is more like having multiple pointers to the same memory.
I can see you hanging onto to a software paradigm here, but it’s really not a good idea. However you connect global labels, you are creating a single net with multiple names. You cannot label different parts of a net with different names, and as soon as you join them they all become the same net, and KiCad will pick one name for the whole net.
Anyway, you can probably rely on the net highlight tool to tell what is the same net.
1 Like
So far what I did is replaced all global labels (except U11 SW1_*) with local, and one hierarchical (DAC_OUT_A), labels. So, AFE_OUT_A and V_TC_IN_A are just local labels.
I’m still getting the same results in the netlist list as before (non-global AFE_OUT_A is now replaced with SW1_D1). Which is consistent with the net highlight tool and previous results (new highlights are shown in the schematic below).
So,do you think that this would eliminate the possibility that the issue is related to global labels “within the same sheet” (near U8)?
Global labels left are those shared between two hierarchical sheets (U11 and U8). I assume that you are suggesting that we convert the remaining global labels to two buses?
(net (code 275) (name SW1_D1)
(node (ref U11) (pin 5))
(node (ref D5) (pin 3))
(node (ref U11) (pin 3))
(node (ref U11) (pin 16))
(node (ref U11) (pin 15))
(node (ref U11) (pin 11))
(node (ref U8) (pin 10))
(node (ref L3) (pin 2)))
