Using Buses in Circuits with KiCad 7

Good video. With version 7, busses became a little more usable, in my opinion.

I had NO idea about "unfold bus." I wonder if there is a way to make it more usable though.

FYI, when you need to "repeat last command" for signals going to the right or up, like in your demo, I do a few tricks.

I use the "repeat last command" to generate all of the labels. Of course, this creates them in a vertical column from 1 to n+1. At this point, if you highlight them all, you can use R (rotate) to spin them 90 degrees for your left-to-right labels.

And to reverse the direction from n+1 to 1 vertically, just press Y (flip Y axis) to reverse the selection group

Hi James,

I reckon if they wanted to improve it, this is a situation where EAGLE was quite nice, basically first selecting wire mode, and then any click on the bus will bring up the entire list, to allow selection, and then continue drawing the signal. 

Example with EAGLE:

With KiCad, I reckon what would be good would be if they could design it such that if W (wire) was pressed when the cursor is on a bus, then instead of just drawing a wire (as it does today), then it should just instantly show all the list, just like EAGLE. In fact this would be nice; pressing W and then all the possible signals listed in columns, or one large matrix, to let the user quickly choose, rather than the multiple-mouse-clicks that need to be done today. KiCad mockup of that:

Also today there's no flexibility in the direction that the signal will be pulled out. Whereas with EAGLE, it will bend in any direction because it follows the cursor:

If the 'W' key did what has been suggested above for wires off buses, then that EAGLE-style bending in any direction would be got for free, since that's existing W functionality (just not for a bus today).

Should we suggest this (or with further refinements if you can think of any) to the KiCad developers? Would that be via the KiCad.info site, or via a GitLab request of some sort?

Also there are a couple of bugs; one bug is already known but quite old, and one bug I raised yesterday.

Gitlab issue / feature request is the way to go. You can open up a discussion about it on the KiCad forum to get wider feedback and then link to it from the issue.

But the developers definitely look at the issue list for deciding what to work on next. (Jon is one of the lead developers. He hangs out in the KiCad Discord. I think he has a macro key to write "can you please create a gitlab issue for that?")

Done!

https://gitlab.com/kicad/code/kicad/-/issues/15310

I think if they implemented that, it would speed up the implementation to be more efficient that EAGLE, and more intuitive, and in a way that still (to me) seems consistent with KiCad UI type behavior.

Done!

https://gitlab.com/kicad/code/kicad/-/issues/15310

I think if they implemented that, it would speed up the implementation to be more efficient that EAGLE, and more intuitive, and in a way that still (to me) seems consistent with KiCad UI type behavior.

(can't edit).

This was the proposal:

(1) Press W (wire) when on bus, instead of right-clicking. By doing that, KiCad should infer the user wishes to draw a signal belonging to the bus, and automatically display all the items in the bus, in columns, or in one large matrix. What I mean by columns, is that one column could contain (say) ADDR15, ADDR14, ADDR13 etc, and the next column beside it would display DATA7, DATA6, and so on, for all the items in the bus label definition.

(2) User clicks on the signal name.

(3) The user now clicks to place the wire, and continues just_as_if_they_were_drawing_a_wire. In other words,KiCad does not stop drawing the wire (as it does with the current unfold behavior), and the user can complete the wire connection all the way to the destination component, at which point Kicad stops drawing the wire of course, but remains in wire mode. In addition, as soon as the wire drawing is stopped, KiCad automatically places a label against the first horizontal or vertical wire segment closest to the bus, with the text orientation aligned with the bus if there is no other text orientation within 2.55 mm to copy the orientation from. An alternative method of inferring the text orientation would be to store the current text orientation used on a bus, and then repeat it every time. If the user subsequently changes the text orientation on a label that belongs to a bus, then store that text orientation.