Tying Globals to Buses across Pages

A little bit later

I bumped into unexpected behavior. I think I should classify it as a bug.

  1. I disconnected the globalbus from the bus (on a hierarchical sub sheet). The Unfold from bus stopped working. This is expected because the bus is no longer connected to the the globalbus label.
  2. Then, I updated the PCB with [F8]. After this, this wheel was still the same net as the wheel on the root sheet. This sheet has two instances. Wheel is connected between these sheets, and it is a global net name without a slash in front of the net name.
  3. Also drew a wire on pin 17 and put the roof label on it. Same result after [F8]: Global label and connected on both instances of the sheet.
    image
  4. Removed the global {globalbus} label and after [F8] the netnames have turned into local labels:
    image
  5. Put the global {globalbus} label back anywhere on the sheet and [F8]. KiCad now treats booth the wheel and the roof again as being global labels.

In KiCad local and global labels connect to each other if they are on the same page. But in this behavior, all names in the alias list also act this way, and I did not expect this. Should I report this in a gitlab issue?

Wonderful! My design essentially connects a pair of matching 200 pin connectors, and while I’m using busses, to bridge pages I’d defined global labels for each of the signals, making for a fairly busy schematic. I’d not realized that I could pipe entire signal sets between pages using global Bus labels. Very nifty; deleting hundreds of single signal global labels simplified the drawing considerably. This solved some of my problems; now. I’m tracking some misbehaviors of footprint file mismatches. Thanks!

Doug G.

You can also route busses through hierarchical sheet pins.

I’ve never used buses that way. I route busses/wires through hierarchical sheets pins as JamesJ suggested.

Ouwtch.
The combination of a KiCad beginner and working on a big and/or complex schematic (project) is a bad combination. I’ve mostly avoided it myself (Did it just enough to know what a pain it is) but I have seen several other people on this forum do it. The problem here is that beginners will make mistakes, and mistakes take a lot of tedious work to fix in a big design. On top of that, beginners often do not know the best way to fix a problem.

Take this for example:

And then compare it with selecting some global labels, and then a right click for the context menu:

The Ideal circuit size is somewhere between 10 and 20 “smallish” schematic symbols and footprints. Something like half of them resistors and capacitors, a few IC’s and connectors. With this size of a circuit you have just enough complexity to train your brain a bit in usage of functions, while mistakes are still easy and quick to fix.

I posted a small example project that shows most of the complex options to route a bus through a hierarchy. It has for example renaming of buses, and two instances of a hierarchical sheet, but those instances are connected in different ways to the bus.


In yesterday’s example, I did not like the way KiCad exposes the whole alias list as global labels. I am still not sure whether to create a bug report for that. But there is an alternative by naming the bus itself.

First, create the same alias list in the schematic setup:

Then, when creating the global label, create a name for the bus itself, and add the alias list using the Group Bus syntax.

When using this syntax, the local wheel labels on pins 6 and 7 connect to each other, but they are still only simple local labels, and thus do not connect to the other hierarchical sheet (not shown here) or to Big.wheel on pin 2 of the connector.

More details on the use of bus syntax in the manual:

And the project from which I made above screenshots:
2024-08-06_asdf_global_bus.zip (22.4 KB)

So, whether this is a bug or not seems to be a bit complex… There’s a few things at play here (with thanks to @Seth_h for elaborating details):

  1. Local labels connect with global labels in the global space
  2. If you are creating a global bus, then all members of the bus would be globals
  3. Bus aliases are defined in sheets, so adding different sheets can change behavior

So I think we’ve got a couple of things here:

  1. Does the documentation cover local → global promotion (including of bus aliases) well enough?
  2. Should we indicate graphically when a local label has been promoted to a global context? (And if so, how?)
  3. Should we do this local → global bus alias promotion when the global label is not graphically connected to a bus, as in this example?

I agree. I’m not sure whether it should be classified as a bug or not.

This is clear from the manual. It is explicitly mentioned in a note:

Note

Labels that have the same name will connect, regardless of the label type, if they are in the same sheet.

2. Global buses

are not mentioned at all in the schematic editor manual, neither is the the alias list mentioned in combination with global labels, so the documentation could be updated here. I guess this combination has not even been tested or used at all. Turning the whole alias list into global labels when the alias name is used as a global label is logical from a software point of view, but it surprised me when I first saw it here.

3. Bus aliases are defined in sheets, so adding different sheets can change behavior

Apart from promoting the whole alias list to global labels on a sheet when the alias name is used as a global label, I am not aware of other changed behavior. Any examples?


Another item that can use improvement in the documentation, is that “bus connectors” are optional. In the example below, “wheel” is in the alias list and it connects to the bus normally. However, pins 2 and 6 are also connected to each other because they both have the same label. It would be easy to make the mistake to assume that pin 6 will not be a part of the bus.
image

And the same when the bus itself is named:

image

In old KiCad versions (V4, V5) the blue bus lines were purely eye candy and it was mentioned clearly in the manual that connections depended on the labels to match. This section is no longer in the manual of the schematic editor.

Paulvdh, I totally agree with the sentiment that learning on a big project is less efficient than handling smaller chunks that are pedagogically easier to digest than some massive project that allows the student to make irrecoverable stupid mistakes. Unfortunately, sometimes the boss asks you to do something that requires a large leap to implement, which is how I found myself in this situation, and leads me to my next issue:

I’m storing my working files on OneDrive, as this allows me to work either from home, or from the office. This has worked ok so far, but as you might suspect, there was a trap awaiting me. At the beginning of the weekend, I lost contact with the OneDrive server, and being the weekend, I couldn’t contact the Help Desk. No problem, I thought, I’ve got the files open, and as long as I don’t close them, I’m golden. What I didn’t consider was that I’d lost contact with the Project file.

So, long story short, I made all my corrections in my _sch files to my heart’s content, but I was losing links to the project file along the way. I have no idea what all information I’ve lost in this, except that I definitely lost elements of the bus members linking somewhere along the way. The bus labels are still there (e.g. {Abus}), but when I right click on a bus, and choose Unfold from Bus, all I get is a single item, the Bus Alias, but none of the members. And it appears that the software has forgotten the members list, because running ERC now gives me hundreds of errors of the “Signalname is graphically connected to bus {Abus} but is not a member of that bus” variety. Sigh.

So, I was hoping you could offer some nifty shortcut to help restore my connections. I’ve rebuilt the member lists in Schematic Setup, but this didn’t solve the broken connection problem. Curiously, the Highlight Net tool still shows the connections are there sometimes, but not universally. All I can think of is that I need to go through the whole drawing and re-establish the Bus connections, except that’s going to be tough given the members no longer appear in the Unfold from Bus list.

All of which goes to demonstrate the truth of your observation of the futility of training on a project larger than one’s noob talents support, but that’s where I find myself. Here’s hoping for a miracle suggestion, Obi Wan!

Doug G.

Which version are you using? There were some connectivity problems that were mitigated in 8.0.4.

8.0.3, do you know the magnitude of the changes between 8.0.3 and 8.0.4?

Yes

Normally bug fixes that do not break compatibility, but the absence of new or better bug is not guaranteed

Onedrive is some kind of microsoft thing and I was fed up with that company 10+ years ago. My biggest problem with that company is that they do not make what their customers want to have (and want to pay for),but that they make the things with which they can make the most money and then force that upon their customers. I solely use Linux. It’s got it’s issues too, but at least it’s free from meddling from the “marketing department”.

For KiCad, the project file ties a project together, but it does not have (much) project specific data. It’s mostly settings such as how ERC and DRC is configured, menu options for configured panels. But it also has netclass settings and the list of libraries that are part of a project (although a project also can have it’s own sym-lib-table file). I don’t know the details, I never had to look into them. KiCad’s file formats are human readable (and understandable). A long time ago it was sort of common to hack into KiCad’s files with a text editor for some operations, but these days (nearly) anything can be done just as well with KiCad’s own GUI, and that is a safer way to change things

In KiCad the basename of a project, schematic and PCB file must all be the same. usually the directory name also has the project name, but I think that is not mandatory.

KiCad’s file format description is available on: https://dev-docs.kicad.org/en/file-formats/index.html The alias list is stored in the (a) schematic file, not in the project. I did a search for this yesterday and found the snippet below in a schematic file:

(bus_alias “globalbus”
(members “seat” “wheel” “roof” “motor”)
)

How to repair things depends on the damage that has been done. KiCad has had several problems with working from network drives directly. I would prefer to always work with a local copy, and then for example use git for the synchronizing (and backup).

Yesterday I also briefly had a moment that Unfold from bus did not work (KiCad V8.0.4) but half a minute later it worked again. I think I moved a bus label in between. the error was too vague to report it. Maybe it was just my fuzzy imagination.

Also in 8.0.4, incremental connectivity was moved behind an advanced config flag. It was causing a number of issues. I’d recommend upgrading.

1). Agree on Microsoft, haven’t trusted them for years, and should have remembered that this time, but it seemed a convenient solution to having a home vs. office storage answer. Lesson learned, looking for an alternate; I may use a portable drive I have for the purpose. A little more consideration of the software’s need for a complete file set is also probably in order.

  1. Somewhere along the way, I encountered a description of a shortcut for entering in many members all at once to a bus alias via the Schematic Setup > Bus Alias Definitions window. Does this ring a bell for you? I don’t think I encountered it in this Forum, but rather in one of the YouTube videos on the subject I watched. I’ve been using the trick to copy in the members list in my attempts to rebuild it, but though it accepts the list, it doesn’t allow me to access the list via Unfold From Bus. I suspect I’m using a slightly misformed format. Is there something in the documentation that details this feature? I can’t find it.

I do not like the current interface for entering bus aliases. My own preference would be a simple text edit window for “arbitrary text” combined with some rules. Maybe one label per line, but pasting in a comma separated list, or whatever format gets copied from a spreadsheet would also be nice. But the world is not perfect and you have to fiddle with the piano that you’ve got.

There are some programs out there which simulate keyboard and mouse input from some external file. Maybe that works.

In a previous post I posted a snippet from a schematic file with the alias list. It’s easy enough to paste some aliases into that list. But close KiCad first and make sure you have a backup.

Just discovered that you if you have list of words separated by spaces (like in a sentence) in a text editor, then you can copy it and paste it in the alias list. Each word will become a member of the alias list.

Yeah, that’s how I was using it, very efficient, very helpful feature. However, at some level I’ve broken members lists - I’m not getting anything besides my bus name in the unfold list. Troubleshooting continues>

Aha, just discovered what I was doing wrong: For some reason, I thought the alias entered into the Schematic Setup dialog had to have curly braces like it does when you use it in the drawing. As will surprise none of you, this is incorrect. The Members reappear when you unadorn the Alias of its curly braces in the Setup dialog. D’oh!

Which leads me to wonder, why can’t the manual be a little more specific on hidden features like this? I was reduced to guessing and A/B tests. It would have saved me a couple of days to have a concise paragraph or two on the subject. Or maybe I’m just missing those?

Doug G.

It is not practical to list all the things you should Not do in a manual. Manuals would become extremely big and boring to read. And besides, the manual already shows this in various ways. First, it has a screenshot of the bus alias list, and second, it is mentioned several times that the curly braces are a part of the group bus syntax, not of the alias list.