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)))
I can’t tell exactly what is going on in your schematic, but I want to note in case you didn’t know this, if a net has both a global and a local label, the global label will always win. If there are multiple global labels, or multiple local labels but no global labels, (in KiCad 5 at least) the resulting net name is somewhat hard to predict.
If you email me your schematic (jon at craftyjon dot com) I might be able to help understanding what is going on.
1 Like
I think I found it. Look carefully at pins 3 and 5 of U11:
I think that might be an accidental wire between the two pins. Try moving (not dragging) the SW1_D1 and SW1_D2 labels away from the pin and you will see that there is an accidental wire connecting the two. If you know what to look at you can also see it in this zoomed in screen clip of your first image (it’s the green wire overlaying the border of the global label symbols):
Global labels like this do help document the signal flow, but the boarder can sometimes obscure accidental wires where a local label wouldn’t. Pick your poison.
8 Likes
Good find. V6 will be able to catch this in ERC more easily (it will point to that specific part of the net as an issue)
Wow! It worked. I owe you a lunch 
I’m so happy because I really love and trust KiCAD. I should have put the labels far from each other.
Thanks very much to everyone who commented, I greatly appreciate it.
Best Regards.
Or you can put them directly on pins
That makes using the highlight tool impossible. Always leave a short wire between labels and pins.
N.B. this has already been improved in master. For V6 you can highlight by selecting labels.
Disclaimer added by @Rene_Poschl: Is it a good idea to use a nightly build version?
1 Like
A simple trick in Eeschema for hard to find wiring errors is to hover over a component, press “G” for grab, then move the mouse so you can see what is under it, and if the wires are attached.
Then press [Esc] to return whatever you grabbed to it’s previous position.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.