This combination works. The combination above works also if you leave out the bus label. So LEFT{QDA QDB QDC QDE QDF} becomes LEFT.QDA, LEFT.QDB etc. The logic is a little bit different compared to Altium. In KiCAD you need to use labels LEFT.QDA, LEFT.QDB or else you get an error. In Altium you start with the net labels QDA, QDB. It then detects it’s a bus and renames global nets as: QDA -> LEFT.QDA, QDB -> LEFT.QDB. I think the Altium way is little bit more elegant. Did I understood everything or is it more to it? What versions is this buses working in 5 and 6 version of KiCad? I am using the nightly build from 2021-01-26.
We could explore the thing you describe (please file a feature request for it if it’s important to you) in a future version. There are some issues with handling legacy designs to look out for, it might prevent being 100% like Altium. In KiCad 5 and earlier, buses were mostly just graphical niceties, so people used them very flexibly. Now that buses actually have a logical meaning, we have to be careful that the logical meaning doesn’t break designs where people were using them as graphical aids only.
From another post I found out.
You can configure the coordinate system in PCB to work properly.
The default way is just weird.
Here is how and where you do it:
The other things you mention are planned, but we are not planning on doing an Altium-style matrix: we instead decided to go for the custom rules system where you only need to define what you actually need (rather than putting a number in every cell in a matrix)
Of course it would be possible for people to make third-party tools that convert a “matrix style” set of rules to a minimal set of custom KiCad rules, but nobody has done that yet
What about grouping those in the ERC check with an option to exclude “strict” bus checking.
I do not see why new bus features have to play nice with the legacy versions.
KiCad-nightly V5.99 already has a built in system for ignoring certain errors.
It is not just used for ERC, but for generating netlists. Generating netlists is tricky business and I don’t think at this point we want to introduce options that change how nets are determined.
I’ve never used Altium, so please forgive any naivety on my part. What I understand you saying in Altium is you can have two busses LEFT and RIGHT each with similarly named children QDA, QDB, QDC, etc. But when labeling the signal lines (wires) you only need to use the child names. What keeps different signal line labeled QDA from being connected together?
AFAIK in KiCad non-connected local labels must have unique names, thus the requirement for LEFT.QDA and RIGHT.QDA. If in KiCad a QDA labeled signal line is connected to the LEFT bus, and a different QDA labeled signal line is connected to the RIGHT bus then the QDA children of the LEFT and RIGHT busses would be part of the same net. You are saying that this is different in Altium?
You are right, it will result in short circuit in Altium. My argument was hypothetical. Altium has second bus like concept they call harness to handle multi name buses. I think the KiCad solution is better. There would be a way to make a super solution if you expand the KiCad way a little bit and combine it with the Altium feature. It would also be nice to expand the integer limitation in buses and accept buses like Address[0…F] or Input[x…z] -> Inputx, inputy, inputz. If you have two microcontroller in one design, every one have like 6 UARTS and every UART has TxD, RxD you could have the global nets after compilation like: CoreA.UART3.TxD, CoreB.UART3.TxD, CoreA.UART4.TxD and so on. As of now I don’t know any software that support this format. They logic in the schematic parser would be to check if the net labels are connected to a bus and if so not connect them together but instead expand them to global net names as described above. Would be a nice feature. Here is an example from one of my Altium designs that goes half the way.
The two UART buses in the sub sheet each with the signals RxD and TxD are after compilation expanded to USART3_LPC.TxD, USART3_LPC.RxD, UART2_BLU.TxD, UART2_BLU.RxD.
Very easy to understand compared to many spaghetti schematics I see.
Regardless of whether or not we supported more deeply nested buses, I’m not sure we would change to having local labels mean a different thing based on whether or not they are graphically touching a bus wire. That would change a lot of KiCad precedent, and even if it could be done without breaking old designs, it might be too confusing to be a good idea in my opinion. In any case, it’s a separate issue from expanding the possibilities of how you can label buses.
What @SembazuruCDE says is right: Any local label TxD on the same schematic sheet is connected together automatically. It doesn’t matter whether any of those local labels are graphically touching a bus or not. This is the precedent that is hard to break.
A time saving feature could be to automatically label wires when they enter a bus.
For example: a micropocessor with D0 through D15, and an existing bus with Data[0…15]. When drawing a wire between the MicroProcessor and the Bus, the name of the bus can be combined with the number of Microprocessor pin.
But it won’t save much time. the [Ins] function with auto increment and repeat does a pretty good job in doing the quickly manually. A “fuzzy” string matching for a bus with control lines would be more useful.
