I think that if you connect a global label ‘GND’ you should obtain what you want according to the net priority explained in the attached post.
I tried it and it doesn’t work. Net is still called ‘OP_AMP_+_2’ after adding another global label with the name ‘GND’. Also tried to connect a separate global label called ‘GND’ to GND first, then connect that global label to the other global label and it’s still never called ‘GND’.
Again, I think it makes no sense that any net can override power net names. Who wants that? If you look for ‘VCC’, ‘VDD’, ‘GND’ or whatever have you, you want to find that net on the PCB. And not figure out first which other nets are connected to GND. It’s just strange. And the KICad 6 documentation suggests it shouldn’t be that way.
I’ll open a bug for this now as it seems there is no solution and it’s not clear if it IS a bug or wrong documentation.
Sounds like a bug to me.
If I was to tie something to a global power net (especially GND) I would want that to take precedence in the naming simply due to the ramifications
yes, that’s odd, here is what it does to me (v6.99) :
if i leave the GND label all is connected to GND
if i removed the GND label all is connected to GND_globallabel as it should.
well, there are other CAD that permit ‘net aliasing’, for example OrCAD.
If you ask me if is a good idea (ab)using this feature, i can answer: probably not.
It is hard to imagine to not be able to find GND net at my PCB. But I have never said that I accept to have any other net name instead of GND.
What I don’t understand is why you add second name to GND net.
I have never used (and don’t plan to do it ever) two different net names to name one net. That applies to all net names - not only GND net.
If the whole design is as shown in your screenshot, that is expected behavior.
GND sorts below GND_globallabel, so when you have two global labels connected to the same net, GND wins.
When GND is disconnected, GND_globallabel wins.
1 Like
Okay, I have a clue now where all this confusion / bug talk could come from. I just swapped the schematic symbol for the cartridge connection for another symbol (a standard IDC header). Now it’s all like expected.
The other connector that seems to produce the error is actually in import from an Eagle project. So I very strongly think now that it’s that symbol’s fault.
Will investigate.
//edit:
Got too excited. New standard library connector symbol produces same error. Had forgotten that I added an extra global label called ‘GND’ and didn’ remove it when continuing to work. Will investigate anyway.
1 Like
You didn’t read carefully what I wrote, or what Jon wrote.
The order is strictly deterministic, and you can’t expect that just adding a new global label works in all cases. When there are several global labels, they must be sorted somehow to find the winner, and the alphabetical order is meaningful here, but so that G loses to O.
EDIT: and by the way, I agree with Piotr:
Adding more names to one net only adds to the confusion. If you want to use a net named GND, then keep the plain GND symbol and if you want to add labels, give them all the same name. If OP_AMP_+_2 is the same as GND, why not call it GND? If the connection point between what is called OP_AMP_+_2 and the rest of GND is controlled, use a net tie.
Why not draw it like this? Hierarchical net names are not really meant for indicating a connectors pinout anyways, all though usually it’s conveniant to do it. You can indicate the pinout with text close to the connector?
It is exactly what I have written in first answer in this thread:
Yes, but the reply was
…which wasn’t followed up. I believe this is a misconception of schematic. I also later realized that the opamp is on his schematic, not on a connecting board on the card connector.
The next comment I don’t actually understand:
Given that a schematic, once drawn, is permanent, I don’t see why it’s important to keep the reference on the connector if it’s always connected to ground on the component. If, on a later revision of the board, one would want to connect a resistor to the pin instead of straight ground connection, you simply do that and re-instate the opamp-naming on the connector pin net.
Btw. @osterchrisi , if I understand your design correctly, you are making an “opamp daughter card” of some sort? Since you put the name of the pin on the connector, isn’t it counter intuitive to have it “pre-connected” to ground? Why not let the motherboard decide the connection?
Thank you everyone for your efforts to help out. Like stated earlier, I am specifically NOT looking for advise on drawing schematics or layouting a board. It seems like everybody is making their own assumptions about their own workflow being the solution to this issue. In my initial post I have given all necessary information to answer my question, which was also stated in the first post.
It feels though as maybe some users would feel better appreciated if I point out WHY I need to work around what still seems like a bug:
I am designing a cartridge for an open source project. This is a project that spans several teams, countries and software programs. I cannot control the cartridge connections nor their name, order or pinout. My schematic should later be published publicly and should be legible by anyone who was not a designer of the “motherboard” and therfore has no knowledge about which cartridge connections from the motherboard carry which electrical signals.
If I follow some users’ suggestions here, I would create a situation where downstream some interested person looking at my schematic might be fooled into thinking pin 19 carries a ground connection when in fact - if no cartridge is connected - it connects to the pin of an opamp.
I hope this clears up my disinterest in solutions suggesting changing my workflow.
Also, no offence to anyone please. I find it hard to find precise words and keep the conversation on topic without potentially sounding like a d*ck.
Is this because the comparison ends when the last character in the string, ‘GND’ in this case, is reached ? (I am assuming the string is compared character-by-character with each of the possible names, starting with the starting character and ending when the end-of-string character is read, before a match is declared.)
Basically, yes. But this is just how string comparison works in basically any programming language, it isn’t a KiCad feature.
1 Like
I have questions I need answered before coming up with more suggestions. Can you share some more of the OSHW design you are mating with?
All my suggestions are well meant, if they don’t suite you that’s fine. But if I spend the time to suggest something for you I hope you read and consider it even if it’s a suggestion to change your workflow. Because if you have bad workflow, why not change it? I don’t see that the constraints given by the OSHW project actually constrain you that much, I think this can be solved in many other ways then directly tying a global net to ground. Which in itself can be confusing to a reader.
Considered just leaving the connector pin floating?
Your daughter card has the opamp on it, and if you remove your daughter card from the OSHW board then no opamp is connected to the OSHW board, right? Then why
?
You mean fooled into thinking pin 19 on the OSHW project also carries a ground connection? Because in the case of your design, he is not fooled, he’s right. Wouldn’t it be solved by putting some text on the pin, indicating what the pin is used for?
Attached I have a picture of a component in Kicad component library called net ties. I think they do what you want, but I’m not sure if consideration must be taken to remove it from netlist and exactly how it translates to PCB editor. Have a play around with it? Recommend to check the two boxes as indicated
No, it’s the other way around. The opamp sits on the motherboard and I can use it on my cartridge via the pins (which I do). This is also why I draw the schematic in a way that makes a future reader understand what is going on (second screenshot in my initial post) - the connections with the labels somewhat representing a “ghost opamp”.
I already tried the NetTie component and it does the opposite of what I want - it’s somewhere in the middle of the thread.
To really boil down the issue to the most atomic version: Why does this result in a net named “WHY”?:
Well, this was explained several times. An explicit global label overrides the GND name. This may be a matter of opinion or taste, but in my opinion explicit should override implicit, it’s good.
I mean, maybe I just don’t see the tree in front of the forest. But the KiCad 6 documentation states this:
Is your statement and the KiCad statement true at the same time?
It might be easier to discuss this if you would attach your KiCad project here. But to me it looks like you have some problem with the “workflow” even though you state otherwise. Maybe you are trying to use a feature of KiCad for something it’s not designed for. For example: global labels are for a KiCad design, they don’t need to be identical with some pin name of some external component. Why can’t you control the global net name? It’s not meant to exchange information between some other KiCad project or some other external program or project.
Prepending the name with . or _ would solve the problem because then you could add another global label named GND for that net.
And reading from your first post, your problem seems to be the net name in the layout, not in the schematic. Why is it a problem? It’s just a layout, and if someone else edits it, they must have the schematic, too, and the schematic is the source of the functional understanding of the design. Or you could add an extra global label to that net called XGND which would convey the meaning well enough and would be seen in the layout without changing the other global label.
This was also told a couple of times. It seems to be a bug in the documentation.