We had an interesting discussion in https://gitlab.com/kicad/code/kicad/-/issues/5448 about the interactive (push and shove) router. I remember seeing every now and then here in the forum a comment which tells someone doesn’t want to use the interactive router, instead for example resorting to the “highlight collisions” mode.
I would like to gather experiences about it here. Maybe we can find some common themes and details which could help forming concrete suggestions for enhancements.
I have already expressed some of my opinions on Gitlab, but for the sake of keeping this topic complete I might repeat myself here.
One thing that I don’t like about the “Interactive router” (“Shove mode” to be exact) is that it’s too intrusive to my liking. Now the elaborate part.
When I design a PCB, I do want to control not only what is connected on my board, but also how the routing is actually laid out. Right now, I do mostly work in “Highlight collissions” mode, since it allows me to keep in control over my layout.
On the other hand, “Shove” mode is kind of “Point and shoot”: click on startpoint, click on endpoint and Kicad tries to find a route.
My main complaint is that in this mode, Kicad leaves itself the discrection to change my existing routing according to some unclear “optimization” algorithm. And these changes to my layout may be far away from the place I’m working on. I can even miss the changes made by the Shove mode.
Now, after giving it a thought it is necessary for the “Point and shoot” mode to be able to move tracks around, since if we route tracks one by one, adding another track changes the rules on the board and may cause different solution to optimization (or at least reduces number of available deegres of freedom).
There are however features of the Shove mode that I do like and use for my designs. And this is mainly pushing bunch of tracks packed at their DRC clearance limits. In some rare cases, also shove to fit the next track in the middle.
So to me it would be beneficial to add some intermediate routing mode between existing “highlight collissions” (fully manual) and “shove” (highly automated routing); kind of “manual with assistance”. Where the assistance would be: “snapping to DRC limits of existing objects” to facilitate following the contours of existing tracks; “local push and shove” (local re-routing of selected segments, affecting only the minimum number of segments necessary to perform the requested operation; not touching the routing of other exiting routed segments). And the last one should allow to easy back-off, i.e. if I perform some operation and see that things went beyond my accepted results I coudl e.g. back-off pusing the tracks and KiCad should perform the same moves in a reverse direction.
Also maybe there should be some resistance when moving other object classes, e.g. easy to pack tracks with a single drag, but then a bit of resistance (stop moving for a while) before the tracks would start to push further VIAs etc.
That’s my opinion on the router, I’d be happy to read how other users work with their PCBs.
sometimes the “shove” when dragging a trace makes stuff go absolutely bonkers, and dragging the trace away doesn’t bring stuff back to normal. having to hit undo isn’t the end of the world, but it would be nice if it could be smarter.
similarly, it would be nice to have something that would simplify a trace that’s been splintered into a dozen segments by push/dragging it into a more spacious region. right now I resort to deleting the offending region and rerouting.
First: It seems that already quite some improvements have been made in KiCad V5.99. So adding the KiCad version to your posts is a good idea.
@fred4u
I had a similar experience of not liking the changes that the router did “far away”. After a while I decided to work with the router, instead of against it, and I just let it do it’s thing during routing (which makes this a lot quicker) and then later come back for a cleanup pass.
A final thorough visual inspection at a later time (just before making Gerbers) is also a part of my work flow.
@halachal
Me too. Backing off during routing and KiCad not putting the “shoved” tracks back where they were is a point for improvement. Often the reason for backing off is because KiCad shoved tracks into an area that you don’t want them. I’m not sure yet, but I think this has already improved in V5.99.
In KiCad V5.1 I had issues after DRC violations have been generated, for example after a block move, or a change of NetClass parameters. This used to confuse the Interactive Router and was hard to repair. I just did a quick test in KICad V5.99. I first made this little test project:
Then I deliberately created DRC violations by increasing the clearance, and upon the first attempt to drag one of the tracks, KiCad cleared the DRC violations by increasing the spacing on all of them. Wonderful!!!
The old KICad V5.1 would also shove tracks much farther then needed. for example after dragging the 5th track upward a bit I get this in KiCad V5.99:
The old KiCad V5.1 very likely would have completely straightened the topmost 4 tracks. This probably also (partly?) fixes the issue halachal mentioned.
The next issue is still present in KiCad V5.99.
If a track changes width halfway, then the coordinate where the track changes width is “fixed”. In the screenshot below, dragging of the topmost track is severely limited by the change of track width in the topmost track. For example trying to drag the 2nd to 5th track upward does not work anymore because it’s blocked by the width change.
One think I absolutely hate about the walkaround mode is that it can move around tracks that are not the one that I’m currently drawing. Which, for me is the purpose of the push mode.
For me, the shove mode should never move anything aside from the track I’m currently drawing.
Aside, the walkaround mode would be perfect and I use it often. But it may become incredibly frustrating when some tracks that I’m laying against get moved somehow.
Generally speaking, I would agree with @fred4u that the interactive router tends to move things that are supposed to be routed and not moved.
I think you may misunderstand the modes: It sounds like you want the walkaround mode. The whole point of the shove mode is to be able to move things other than the track you’re drawing.
@paulvdh just some funny router decision, based on your sample project. Removed track 4, pushed tracks and try to automatically route it back. Kicad ends up with some funky stuff.
You make it a lot easier for the the Interactive Router if you click [LMB] in short increments, but it sure is not the expected result.
I tried to duplicate your work and got this:
And a screen recording of the above screenshot. I don’t know how to directly embed a video here. vokoscreen-2020-12-06_23-55-34.mkv (255.4 KB)
@suzizecat
You should not have edited your previous post as it destroys the context and responses from others.
You have accidentally also turned your own post into an abomination:
The “Walkaround” mode does just that. It walks around everything and it never moves another track. Only the “Shove” mode does that.
My advise is to experiment with: Pcbnew / Route / Interactive Router Settings
… and then experiment with changes in those settings.
Well, I transformed my message in what it was meant to say to begin with.
I do know that walkaround is not supposed to move anything but I was pretty sure that there was a situation when walkaround would move other tracks.
Right now I only found that behavior when dragging a track or a via, in 5.1 and not anymore in V5.99.
If it actually works like that now, I’m glad and you can just don’t mind this part of my rant (I’ll see next time I actually have to route something with a nigthly build).
The part about the fact that already routed tracks tends to spring back to a straight line when using the push mode (as detailed in other people posts in this thread) still stand though.
but the tracks do spring back with no obvious reason.
This spring back may be unwanted, but it is logical and (sort of) expected.
The reason is that you push the track further than it can go. If you stop the mouse movement at the location where tracks stop shoving, then the location will be accepted. (Same behavior as in V5.1).
Before the tracks “sprang back” they were at a valid location, and close to the mouse cursor. It would be an improvement if that location was accepted as a new location, even though it is not at the location that the mouse wants the tracks to be.
If you do some more tests with this, then you’ll find that the behavior has already improved much over KiCad V5.1. In V5.1 tracks were often straightened when “touched” by the Interactive router. In V5.99 it shoves other tracks only as far as needed.
P.s: Don’t mind the choppy behavior. My old PC is struggling with sumulatneous running the Interactive router and screen recording software. Without the screen recording it runs fluently (and is much easier to operate)
Also: How do you embed the screen recordings directly?
If I push tracks, I expect them to move as far as they can go and no further. But for Push operation in the “Shove” mode, I expect that Kicad will take care of the allowed distances. Right now I can see that the pushed track disappears at the end, but that’s also rather unintended behavior.
And hopefully - don’t get me wrong that I’m trying to “bash” kicad. I love the tool, and just would like it to become the best EDA tool on earth Hence my reports which are supposed to give the Developers some feedback from the users - without it, it’s hard to know what the users like and what they don’t.
For screencast recording I use ShareX which was recommended by someone here - FOSS piece of software. Shift+PrtScr allows me to record screen, I just select the scope (Window/Parent/Screen etc). It outputs to *.mp4, which I just upload here using the “Upload” tool. Maybe it’s the matter of supported media contents (mp4 vs mkv) that either embeds the video or just links it.
We’ve known these issues/limitations for a long time, so frankly this thread feels more like bashing than actual feedback. I don’t want now to get into technical details, but the router (not only KiCad’s but other tools too) has some fundamental limitations:
can’t push joints between tracks of different widths. Making that work is a serious development and I don’t find it justified, at least not for now.
will likely fail if the set of traces to push have a lot of clearance violations (i.e. if you increase the clearance in design rules with already min-clearance-tight routing).
I might imagine the complexity of the above mentioned issues, and I do not ask the router to do “more”.
Quite the opposite - I’d prefer it to do less.
In this case it would be more user-friendly if the router stopped at the obstacle (joint of tracks with different widths) and did not attempt proceeding further. It actually “achieves” the final geometry, there’s not much to be done so instead of user trying to stop the mouse cursor at precise location, router would prevent further move that is “unsolvable”/otherwise problematic.
So from my point of view, with performing less tasks the Router could gain usability.
This whole thread was started to get some list of points that could be improved, regardless of how long they already exist or how difficult or trivial they are to solve.
Sometimes long standing issues are “looked over” by people with more experience, they may have gotten so used to it that they do not notice it anymore.
Fixing issues with changing track widths would be quite high on my list for improvements for the Interactive router.
Another long standing issue is the insertion of very small track segments instead of aligning. The track segment below has a length of 7um
In this particular case it was probably caused because to match a track of 0.23mm widht with a track of 0.24mm width, but I also see these being added for various other reasons. Especially with T-junctions. KiCad seems to want to the grid first before going further, and stuff gets pushed off-grid easily.
In itself these short track segments seem harmless. The’re barely visible, and DRC has no problems with it. However, if these accumulate over a PCB they become a mayor hurdle for the Interactive router.
In turn this makes it almost mandatory to clean them up, and this is a step that can easily become very time consuming.
[Edit] I like KiCad very much and the Interative router is a wonderful tool in KiCad. It has helped me tremendously with routing dense boards which I would not have dared to route so dense otherwise. So maybe this needs to be said more…
A footprint place at 45 degree for better routing:
Because clearances are small on this 0.5mm pitch QFP I have a strong preference for the first track segment from the pad to be at the same angle as the pad.
I had some trouble with routing, because KiCad wanted to connect the tracks with horisontal or vertical stubs to the pads. I think this is influenced by: “Pcbnew / Route / Interactive Router Settings / [x] Optimise pad connections” My guess is that this disregards the part rotation.
Hence my reports which are supposed to give the Developers some feedback from the users - without it, it’s hard to know what the users like and what they don’t.
