Your global label uses the wrong syntax (unless i am misinformed)
It also must have the syntax common_prefix[x…y] (with x and y defining the range of the numbered suffixes)
The first page works because you have the local label there.
2 Likes
I think the main problem is that your global labels are not in bus format.
They also need to have the [0..15] format at the end to mark them as carrying buses from one sheet to another.
If you change those labels to be Buffered_Address[0..15] does it fix the issues?
In KiCad V6 there will be an ERC warning that will make this more clear, because it will warn you if you attempt to connect buses and nets together in a way that doesn’t actually work.
1 Like
I assume you mean global labels (the screenshots do not show any hierarchical labels)
1 Like
Rene & Craftyjon
fantastic, you nailed it. i changed the global label shown here and that did it !!
it would be good if the manual showed this little example. The bus global label and the bus contents both need to be in that format.
note that the global label does NOT need identical names as the bus content label. the following works just fine where the global label name and the bus content label is not the same.
very helpful,
thanks
It is also worth mentioning that you do not need two labels here, unless it is visually helpful for you.
In the case that you connect a bus to a global label, the name in the global label will take priority, even on the local sheet. So, you don’t also need the local label.
2 Likes
Good information. i hadn’t tried that. when you referred to the label attached to the bus as a local label the lightbulb started to flicker here.
so you are saying that…
on the main sheet the local label needs to be attached to the bus but the global label brings all of those local labels to the same bus on a new sheet, so the local labels do not need to be redefined. the global label is connecting the bus on a different page just as if it were a continuous line (as expected).
thanks
There are two types of nets in KiCad, global ones and local ones.
Local ones always include what is called a “sheet path” which is formed from the location in the hierarchy (if you use hierarchical sheets).
Let’s say you create a local label called SIGNAL and place it on a wire.
So for example, on the top-level sheet, the net created by that wire will be called /SIGNAL, because / is the sheet path of the top-level sheet. If you instead had that label on a subsheet called SUBSHEET, the net created would be called /SUBSHEET/SIGNAL. These net names are visible if you inspect the netlist generated by Eeschema for import into PcbNew.
Now let’s say instead you attach a global label to that same wire instead of a local label. Global labels don’t have sheet paths. So, the net generated would be simply SIGNAL without the leading path. No matter what sheet you are on, that net will always be SIGNAL, and that means that when you export a netlist, all those labels will be joined together.
There is a priority of how nets will be named depending on what kind of labels are attached to them, and what pins are attached (for example, a wire that is attached to a component, but doesn’t have any explicit label, will have a name auto-generated from the component’s name and the name of the pin it’s attached to).
Global labels have the highest priority. That means, if a global label is attached to a wire, it “wins” over every other possible name that wire could take on. This means that attaching both a global and a local label to a wire is redundant, because the global label will always win.
Now, when you start talking about buses, the same rules all apply. If both a global label BUS[7..0] and a local label LOCALBUS[7..0] are attached to the same bus wire, the global label will win, and the bus members will be called BUS0, BUS1 etc on the PCB instead of LOCALBUS0, LOCALBUS1, etc.
This means that if you already are going to make your bus global by connecting it to a global label, you don’t also need a local label (on any sheet). You just need to use the same global label name everywhere you want to use that bus.
(I haven’t gotten in to hierarchical labels and sheet pins here, because that would be a longer explanation, but the very short version is that they are treated like local labels but with a higher priority. They still have lower priority than global labels, though)
2 Likes
By the way, I know the documentation is not very clear on this right now. I am planning to propose some changes to a lot of the documentation around schematic labels and connectivity (and how nets are named) for V6, because there are some changes in this area from V5 and I want to make it more clear.
3 Likes
thanks for the explanation. great information.
But because any one net must have a single unique name by the time it gets to the PCB, finding the correct net name to assign a netclass can be difficult. With your example, if you try to find bAD3 in the list of netnames in PCBNew you won’t find it. It will only show up as “AD3” (because as @craftyjon states the global net takes precedence).
If for another net you used two different local net names (for simplicity lets call it on the top level sheet) for one net because coming out of the IC you label it as “RedLED” but near the red LED you label it as “DataSend” because you plan on using the red LED as an RX data send indicator in your programming. Once you send to the PCB it will show in the list of net names as either “/RedLED” or “/DataSend” and you have no really good way of knowing which it will be. Try to make a habit of only using one netname per net or you may cause yourself confusion down the line.
2 Likes
This will also be fixed in V6:
- There’s an ERC warning that reminds you if you put multiple labels on a net (on a single sheet) that only one of them will be used on the board
- The logic for choosing which name “wins” is cleaned up and will be better documented
- You can select wires and see what net they have in real-time
2 Likes
How does this play with deep hierarchies? Do i now get a mass of error warnings on every hierarchical boundary? (If so then i hope this warning can be turned off somewhere central)
Example i have label /X/Y1/a connected to /X/a and also /X/Y2/a to /X/b (sheets Y1 and Y2 are pointing to the same schematic file).
What then happens if i connect /X/a in the root sheet to a power symbol?
hierarchy_craftyjon.zip (3.2 KB)
1 Like
No. The new code understands the hierachy and structure of the schematic in a way that current KiCad does not (until the moment when netlists are generated).
In your example,
- Sheets that are higher in the hierarchy have priority for determining net names. So, the wire connected to J1 pin 2 is called
/abecause it takes its name from the sheet pinaon the top-level sheet. This is visible in the message panel now, so you can inspect the wire on the subsheet/X/Y1and confirm it has the same name/a(the other information shown in the message panel here is debug information because I’m running a debug build, you can ignore it)
- Power connections win over everything (including global labels). In the demo project you made, you connected the net that would be called
/btoGND, so it’s calledGND. Then, on the subsheet/X/Y2you can see the wire isGNDhere too:
This demo project has no ERC warnings. The warning I mentioned would only be triggered if you had more than one conflicting label on the same sheet.
Also, in V6 ERC settings will be much better (I haven’t started on that project yet but it’s gotten some planning work already) and you will be able to turn off any ERC warning.
Edit: here’s an example of the warning I was talking about. It does not trigger right now if you have labels of a different type (for example, local vs. global or local vs. hierarchical) since it’s assumed that if people are renaming nets locally, it’s because they want to have some specific meaning on a certain sheet, but a different meaning globally.
2 Likes
At the risk of hijacking the thread I have a couple questions about your plans for ERC:
- Are you planning on some way of differentiating in the Error List which are errors vs. warnings?
- I understand the value of only having one report line per net per error, this avoids spamming the error list with duplications of the error. But sometimes that can be confusing if the actual error should be fixed at a node different than where the error is reported. Is there some way planned to help finding the error? Maybe a tree format that can be expanded to give links to potentially relavent places in the schematic? With your example above, maybe the expanded list would show all locations of the label test and all the locations of the label test2? (For pin-type errors/warnings the expanded list would provide links to all the pins on the net relevant to the error/warning sorted by pintype, etc.)
If you aren’t planning either of the above, should I submit my first GitLab issues for those ideas so you can track them?
Yes
Yes, this problem is on my mind. First of all, the new system should do a much better job of pointing the error marker at the actual place where there is a problem (this is possible because of the new real-time connectivity code that understands what net will be assigned to each wire/pin/etc even before the netlist is generated). Second of all, I have some ideas for improving the UI of the actual error list and error markers. I don’t have any prototypes to share yet but it is something I’m thinking about.
I’m not as sure about this. In the case of this specific warning, it only applies to the locations that are attached to the same wires graphically (meaning they are on the same sheet and joined together). I’m not sure the added value of showing other places where those labels appear, because the warning is localized to this particular part of the schematic where both labels are attached to the same connected net wires.
But the general concept of associating more information with ERC warnings and errors is planned. What specific information there will be depends on the specific ERC checks.
1 Like
By the way, you can see the “erc upgrades” epic here:
This is all the issues on GitLab that I have put on my to-do list to investigate as part of 6.0. This isn’t a promise that all of those issues will be fixed, or that they will be fixed the way that is suggested by the issue reporter, but you can see what has already been reported as a bug or requested as a new feature, and give “thumbs up” to things you care about most. You can also file new issues if you think of additional ERC things that are not captured there, just in case you want to make sure that the team looks in to them.
1 Like
Your example was well crafted for a screenshot, but on an ANSI-E sized sheet (I think that is close to an A0) if the two labels are on opposite corners then finding both may be challenging. (OK, yes this example may be a corner case…)
I’ll certainly check out that list of issues. (Nifty feature of GitLab, and I assume other VCS packages. I didn’t know a feature like that existed, but I can see how valuable it can be for helping to organize planning.)
If you have wires running to opposite corners of a sheet, the ERC warning can just highlight that entire net and zoom to fit (part of the plan is to have a better indication of errors, so instead of just the little arrows we can also do things like highlighting objects to make it clear the source of an error)
Well, I like the current implementation where if one clicks on the coordinates of the error message the schematic centers to that spot at the current zoom level, so I was just thinking about ideas to help find the actual issue based on this current behavior. But if you have something better planned, don’t let me get in your way. 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.