You have to get the details right for buses to work. in the post below, I made an example of connecting buses though the hierarchy.
I’m not exactly sure what your FDA_Pow_2 is. But it looks like a regular label. If you put a label on a bus, then it bus gets the name of the bus. You can also make a list of names in Schematic Editor / File / Schematic Setup / Project / Bus Alias Definitions, and I also used that in the example linked to above.
FDA_Pow_2 is the name I choose for the bus connected to the second instance of the FDA_Power sub-schematic. It is a regular label. This is essentially my question, do labels like that work on buses? I can label the output of the second power supply “VSSA2” if I want, but that does not work on a bus?
I can not work with small snippets of descriptions and screenshots of small parts of a multi sheet schematic. Buses do work, but you have to get the details right. Have you read the chapter about buses in the Schematic editor manual?
You can upload your project, that makes it easy to have a look at all the details, or you can study the example I posted, modify it and ask questions about that if you get stuck.
From what I see from the screenshots, you have a major problem with your grid. Get that fixed first, I doubt your connections are working.
Indeed. KiCad is quite peculiar with grid settings. KiCad’s schematic editor depends on putting schematic symbols and wires on a relatively coarse grid (“50mil” is the most optimum setting) and there are 2 thing that indicate a grid problem. First, your bus lines and wires are not in the middle of the hierarchical sheet entries, and then they don’t connect.
But the second is stranger. KiCad normally shows little squares or circles on pins and open wire ends, (See screenshot below) and I do not see these at all in your screenshots.
The grid thing is just from the example screenshoot (hit the N key by mistake). It is actually connected. No idea why there are no squares in my KiCAD. None of the connections have them, but they are still connected in the schematic view, and they briefly appear if I click on wires.
I can not work with small snippets of descriptions and screenshots of small parts of a multi sheet schematic. Buses do work, but you have to get the details right. Have you read the chapter about buses in the Schematic editor manual?
Here is an even more minimal example. Without labels, this works:
If I delete the bus wires and replace with labels, it fails:
And yes, there are boxes if I click on the labels and they are aligned to the grid:
The manual states that labels should work on buses the same way as nets do, but I cannot seem to get that to work.
First, whenever you see those open boxes, it means there is no connection. It is as simple as that. That label is not connected to the hierarchical sheet pin.
Most problems with grid and alignment can be remedied by first setting the grid to 50mil, then select everything on the schematic, then a right click and select: Align Elements to Grid from the popup menu.
I still don’t know why I can’t see the boxes on those other open connections. It is a very suspicious thing. Maybe it is an artifact of making screenshots and you only see them when zooming in?
It may be useful if you post your KiCad version. Currently it’s V7.0.8 and a bug fix release is made approximately once a month.
In addition, I think it should work if you connect labels directly to those hierarchical sheet pins, but there is a subtle error in the way you do it. When you name a bus, all members must be named (or listed in Schematic Editor / File / Schematic Setup / Project / Bus Alias Definitions).
Also, have you checked ERC? It tells you a lot of what is going on.
For example, in my example, the “Music” bus is just fine, but when I put the label This-is-a-bus on it:
… and then run ERC, then I get ERC warnings about signals connected to the bus, but which are no members of that bus:
I was forgetting the curly braces. {FDA_Pow2} works, FDA_Pow2 does not. I thought with aliases that wasn’t needed, but apparently it is.
However, the way bus labels work is pretty strange. These are connected:
And all four of these are connected together, so the separate power supplies connect their (independent) VDDA rails together:
After a lot of playing with it, I cannot see anyway to implement this with bus labels:
Am I missing something or is this just a difference between what you can do with net and bus labels?
Figured it out, this does work:
Power 1 connects from power supply to load but not to power supply 2.
The key is to not use bus aliases, which apparently are treated differently than names inside labels. Weirdly if you use an alias, then it connects them together even though the names do not match.
What I find so confusing about this is the way the term in the {} is at once both the type (e.g. vector of 2 elements) and often also the variable name (for example when {VSSA VDDA} and FDA_Power1 are equivalent statements above). I thought that the bus aliases would let you define a name and a type separately, but it seems (i think??) like the alias is more like #define that gets regex’ed out to just the term inside the {}.
You can use aliases, you just need to use Power1{FDA_Power} and Power2{FDA_Power} to differentiate them.
That is because an alias is just a shortcut, so if you create an alias “FDA_Power” that contains “VSSA VDDA”, it is just a shortcut for writing the net names “VSSA” and “VDDA”. So it doesn’t work to create two different aliases “FDA_Power1” and “FDA_Power2” both containing the same nets, because they both will expand out to the same nets “VSSA” and “VDDA” and be shorted together.
By adding a prefix before the bus definition, as in Power2{FDA_Power} you can differentiate between the two sets of power connections.
Yeah I see now that FDA_Power is really just s/FDA_Power/{VSSA VDDA}/ which is why it connects to the {VSSA VDDA} bus. Still, this is really counterintuitive.
A way to make it slightly more clear to the user what is happening without breaking compatibility would be for the GUI to warn when creating aliases that clash with existing labels or when making two aliases that will map to the same thing. A simple “is this what you meant to do” text would be a lot more clear and avoid the confusion of two different names being the same variable.
Also, maybe this breaks something and so cannot be done, but it would be a lot more intuitive to allow labels that way I originally tried them, without using the {}. Then if they have incompatible types it is just an error in the ERC, if they are compatible, the buses connect just like dragging a wire. That way you can side step the confusion with aliases and duplicating types in the label name.
See also this thread, where bus aliases are used to make a list of specific attenuations (I assume relay switched), and that list is then used in two different busses.
It can’t really be done without changing existing behavior because it would create a conflict between a named bus alias and a plain net. It would be unclear what the user wanted to do.
That is true that it would allow for existing files to be ambiguous and so be a breaking change. Still, given that there were a half dozen replies to a picture of a bus with an FDA_Pow_2 label, and not one of them noticed that wasn’t how labels work, maybe some (very rare) breaks in existing files might be worth it to bring the system more in line with user’s intuition.
This is not true. Both craftyjon and me mentioned it. It is also used in the example I created and linked to (Did you even look at that?) But also. When you post a screenshot of a label, we can not see whether it is just a label, or if it is supposed to be a bus alias. For things like this I asked you two or three times to upload (a part of) your design, but you ignored all those requests too.
Edit: And as craftyjon noticed below. The grid thing was indeed also pretty distracting.
I think people were quick to jump to the grid thing because it is a common issue, and didn’t catch on to the label issue because fewer people use and are familiar with buses.
Which two posts mention that every one of the pictures are missing the necessary brackets for the syntax to make sense?
It would be wrong either way though, so actually it doesn’t matter. This is what I mean about the syntax being counterintuitive. We both looked at it very carefully, decided it was right, and then moved onto other possibilities troubleshooting when actually labels don’t work like that. It feels like it should be correct.
Off topic, but 99% of the trouble I have with the grid is the default N shortcut key. I forget to remap it after on installing on a new machine or a development build, reach for M to move something, hit both without noticing, and then the moved item ends up on a new grid.
Since changing the grid is not a good idea, maybe that shortcut key isn’t needed by default? Or it could be something like ‘Shift+N’ that would be harder to hit by mistake?
This has been improved a lot for V8, the hotkey is still there for those who need it though
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
