I was referring to the help screen.
I’m not sure what help screen you mean. In any case the user manual is comprehensive
Till now I have never labeled any buses and I’m not frustrated with buses at all 
But my schematics are small so they fit at one sheet. If I had to go with signals to other sheets than labeling buses can be the way to consider. But I don’t know if I ever reach such level of schematic complication.
If this is your whole schematic (not sure, byt may be) than I don’t see any reason to label your bus.
If you do not name the bus itself, it is just a simple blue graphical line, and all connections are just made by the labels. This is the “old” behavior of KiCad, and it works just fine on a single sheet.
But it does not work well with hierarchical sheets.I do not know what the exact constraints are for a hierarchical design, but if you want to play safe, it is best to name all the busses on each of the sheets. A bus does not need to have the same name on each sheet.
You can also experiment a bit with the example I posted on this forum some time ago in the thread below:
Also, about this part:
The thread I linked to has quite some background info about the use of buses. My recommendation for the next time, is that you seek professional help Before you get into such a state of frustration. 
The manual doesn’t contain enough information on how to do what I want; I simply want three bus lines data, power and control. When I do an electrical check, it claims my pin is graphically connected, but not in the bus? How can it be connected for only two out of three symbols? The little arrow points to an issue, but no clue on how to fix it.
It’s also not clear what is meant by giving the bus a name. It shows how to add labels to the bus and vaguely how to group them using some inconsistent syntax.I tried to nest them hoping it will will use BUS as the name, but it doesn’t like the syntax:
BUS{ GROUP{ a b D[0…10] }}
I’ve run into numerous cases of bugs and other cases where it’s difficult to tell if it’s just me, or a bad UI. I have a suspicion Kicad is all of them and it’s up to the user to figure it out.
1 Like
A small excerpt from the KiCad user manual:
<OPTIONAL_NAME>{SIGNAL1 SIGNAL2 SIGNAL3}
And a little bit further, with groups of vectors added to the bus:
For example, the bus
MEMORY{A[7..0] D[7..0] OE WE}contains both vector buses and plain signals
What you tried to do in your first post, is combining different buses with different names (The group buses “CTRL” and “PWR” and the vector bus D[ . . ] in one bus and that does not work.
In your latest example you are apparently attempting to nest buses on multiple levels, and that does not work either. Nowhere in the manual suggests anything like that.
I suggest you turn this:
Into something like:
CTRL{LOAD FRM DISP D[0..7]}
and use another solution for the power signals. You can either connect them with global power symbols or global labels. Or you can put them in a separate bus.
The manual doesn’t contain enough information on how to do what I want; I simply want three bus lines data, power and control
Nesting busses is not supported.
It’s also not clear what is meant by giving the bus a name.
Place a label onto a bus → the bus get’s the name from the label. If you click (select) a labelled bus you will see the resolved name in the statusbar.
I would additionally kindly ask (a second time) for the used kicad version, as sometimes features change overtime. Additionally it’s always good to attach not only a picture, but a zipped example project (kicad main manager–>File–>Archive project). From your picture alone it’s hard to determine if you have placed 3 different labels on the bus or if you have the complete string as one label. Both versions would be false, but for the second version I could imagine a better ERC-message.
1 Like
To post your currently used Kicad version, open Kicad > Help > About Kicad. Top RH corner, left mouse click “Copy Version Info”, then Paste directly into a forum post.
I forgot to mention I’m using version 7:
Application: KiCad PCB Editor x86_64 on x86_64
Version: 7.0.8, release build
Libraries:
wxWidgets 3.2.2
FreeType 2.13.0
HarfBuzz 7.3.0
FontConfig 2.14.2
libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.12 nghttp2/1.55.1Platform: macOS Version 14.1.1 (Build 23B81), 64 bit, Little endian, wxMac
Build Info:
Date: Sep 29 2023 13:04:02
wxWidgets: 3.2.2 (wchar_t,wx containers)
Boost: 1.82.0
OCC: 7.7.0
Curl: 7.77.0
ngspice: 38
Compiler: Clang 13.0.0 with C++ ABI 1002Build settings:
KICAD_SPICE=ON
I’m now figuring out the source of my frustration. I made some incorrect assumptions based on a high expectation of software. I reasoned nested buses were supported based on the curly brace notation used for encapsulation and nesting in other file formats and languages, such as C and JSON. Why else would the software make the user specify bus labels a text format when there’s a GUI staring the user right in the face?
Turns out, I was completely wrong! Proper documentation would have prevented this misinterpretation. The text isn’t a hierarchal at all. This text implementation was chosen purely out of expedience. It could have been easily implemented using a table control with type-in fields for new labels and drop down menus to select from previously defined labels. Such an interface is self-explanatory would prevent the user from introducing errors. It’s indefensible mediocrity!
That is what the “bus aliases” are for. If you define that list, you can right click on a bus and use the Unfold from Bus menu item.
First: Schematic Editor / File / Schematic Setup / Project / Bus Alias Definitions
and then:
So I am wrong again! It’s even worst than I thought! Turns out buses do have hierarchy and do have a GUI for it, but it’s in the wrong place! The Bus Alias Definitions interface is what should be presented to the user directly from the Label Properties dialog. Instead, we have two places to define them. Bad UI!
The Schematic Definitions dialog is the worst place for defining bus definitions! A bus definition is not setup data in the sense of a page dimensions, nor is it an application specific setting. A bus is part of a schematic–the core domain you’re working with. It’s like making the user add a new symbol from the Settings dialog. If a bus needs to apply to several schematics then it should have a facility for sharing them.
I suspect this mishap is probably drug induced in which case it is what it is. There’s no point in complaining about it. KiCad is not for public consumption!
Meh, scratching it in your back with a pointy stick is probably a much worse place.
It is not a bus definition. It an “Alias List”, and it is not a part of any specific bus. The alias list can be used to add signals to busses with different names, and on different sheets of the same project. This alias list, and naming of buses themselves is also a relatively new feature. Up to KiCad V5 (I think) the blue bus lines were only graphical eye candy and the bus connections relied solely on labels. And the functionality may well be extended in the future. For example have a look at these “pin Helpers” which are coming in KiCad V8 (expected end of February): Post-v7 new features and development news - #31 by mikebwilliams
But there is at least some merit to your line of thought. There are several dialogs in KiCad that can be opened from multiple places. For example, selecting a symbol, then pressing e and pressing the Change Symbol button, opens the same dialog as Schematic Editor / Edit / Change Symbols. In the same manner, a button could be added to the labels as a direct shortcut to open Schematic Editor / File / Schematic Setup / Bus Alias Definitions. I think I like that Idea, because that makes this alias list easier to discover for beginners and people who do not read the manual.
Indeed, no point in complaining, but constructive criticism is welcome.
KiCad is just a bunch of bits and bytes. And though there are many of them, they are lightweight and easily digestible. But be careful, depending on the media type you use during consummation it may be a cause of a heavy stool or even constipation.
Interesting line of thought considering how much people and indeed businesses are using KiCad since years successfully. Maybe you should dial back a bit.
I am guessing it is either a drug induced frustration or customary language from the hood or culture he grew up in. But I do agree that toning it down a bit would be beneficial to his cause. I have heard of at lest two people who did not read past the first introductory paragraph, and I thought of deleting that paragraph myself because it does not add anything to the subject. But I don’t like censorship. There is even a vote for an outright ban.
But instead, treating it with a bit of light humor is probably a better response.
4 Likes
I use KiCAD 7 for my business, and have no problems with the bus feature.
Like most pieces of software, there is a learning curve, but once you’ve got the understanding it’s easy.
One point I learned, is that labels within buses have to be globally unique, not just unique within the bus.
Say I have two (or more) SPI buses. You’d create two buses called SPI1 and SPI2, and within each bus, create MOSI, MISO, SCLK and CS. But doing this, it joins the MOSI in SPI1 to the MOSI in SPI2.
Instead, you have to create the bus items called SPI1_MOSI, SPI1_MISO etc. for SPI1 and then SPI2_MOSI, SPI2_MISO etc. for SPI2, so that they are globally unique.
Now I know this, buses work just fine.
6 Likes
We are here as a community to make Kicad better. We do this collectively every day. If the software doesn’t meet your needs, use something else. I’m not sure why people think being discourteous is helpful.
8 Likes
I have opened this topic to add this short remark: I stumbled (by chance) about the following gitlab feature request: Expand bus label format (and move to PEGTL parser) (#3850) · Issues · KiCad / KiCad Source Code / kicad · GitLab
You could upvote that issue if you need the “nested bus” feature.
I close the topic again as this was only intended as information (not for discussion).