Well, at least partially.
In one of my (hobby) designs I was afraid that I set the design rules too tight, and increased track width and clearance a bit after the fact, in the way I described above. This caused lots of DRC violations. And while pushing a single track segment, KiCad pushed a few other tracks aside, and instantly solved the DRC violations on those tracks.
That seems to be the limiting factor. It has to be able to find a DRC free solution. If it can not, then the Interactive router gives up and lets you struggle on yourself.
I like the Interactive router very much. It helped me route boards I would not have been able to route in the same area otherwise. But it has it’s limitations.
Some limitations:
It gives up easily (but not always!) on tracks that already have DRC errors.
It often adds very small track segments in T-junctions and pad connectons.
It can not drag a corner when track with changes in that corner.
@paulvdh ‒ as usual, your comments/replies whenever I post tend to be right on the money, and quite useful. Still, I’m not saying that I agree with everything you say (in this post or in general), so let’s discuss:
Absolutely true. And incidentally, every single item that you show in your post, I was indeed unfamiliar with! (I mean, this is borderline uncanny!!! )
However, I must argue here: this is not a valid counter-argument to my proposal; beginners do happen, and there is value in the ability to do things easily with the basic facilities that beginners tend to be familiar with. That you also have more complex functionality that allows you to do the easy and also the complicated things? Sure, I would expect no less. But having the complex tool that allows you to do anything does not negate the value of having the simple tools that allow you to do the simple things.
Awesome tip!!! I had only noticed the “Ctrl-left-click”, that “selects” the complete net (only that it does not truly select; still, the DEL key deletes the whole section of that path; moderately useful; U and I seem more useful; although, I have not been able to tell what the difference is; I see it in the menu; but in all of the cases that I’ve tried, both U and I have the exact same behaviour)
Also didn’t know, although I would have expected that this is the case.
Now, for your next tip:
I have to say:
Selecting a ton of tracks in a certain area does not seem that useful (well, for the use case I was talking about; I can visualize many scenarios where this indeed highly useful).
In general, this plus the next few steps that you show, they do seem like an unnecessarily complicated functionality; well, at least for the update/adjustment that I was talking about. In my case, the traces that required a particular characteristic impedance were not all next to each other like in a “bus” type of connection. (some of them were indeed a bus). So, again, in my case, having the “level of indirection” with the usual meaning that a value is referenced by name, and when the value associated to that name changes whatever references that value changes, that would have been much easier.
I guess one additional way to articulate my argument is: the bottom line is: with no exceptions, what you really want to accomplish when you update the value of a parameter (e.g., track width) in a net class, is to change every track that belongs to that net class to the new width. Always. There is no possible rationale or scenario where this is not what you would want to do (please correct me if I’m wrong). Then, why favor the long and potentially tedious way to do it, just in the name of “I want to explicitly see every change that happens”, instead of taking advantage of the capability of the computer to just do everything for you! Again, especially when you have the tool that can check for DRC violations after the action; or the tool could then highlight every single trace that was modified (or that is going to be modified); or a variety of other solutions that would still allow you to get the tool to do the hard work for you while guaranteeing zero chance of causing a problem.
Absolutely awesome tip!!! This would have brought the three days of work that I mentioned, maybe not to half-hour (like I claimed that the feature I’m requesting would have), but certainly to no more than one hour!
However, as pointed out already, there is a big misfeature in this functionality, when used to trigger the update of all tracks after an update in a net class (or net classes) parameter: you get the dialog telling you “Some items failed DRC and were not modified”, without telling you which items were the ones that remained unmodified. This is horrifically wrong, I’m sure you will agree. Worse than allowing the DRC violation, because with a DRC violation, I can have the DRC checker go one by one through the violations, and decide how exactly I want to fix it.
Well, I really don’t know how I could respond to this … I mean, ok, I can try to counter some of your points.
In general, I would say maybe not so much “my unusual needs”, but possibly more of a “personality type”/psychological trait — I have been accused, or really, I should rather say I have been diagnosed of “Misguided perfectionism” (I did a quick search, it was @paulvdh, back in March 2019 — I clearly remember that that gave me a big good laugh… When paulvdh commented that, I remember thinking “man, am I extraordinarily transparent and easy to figure out!!” … My former boss, back during my first job after my undergrad, about 25 years ago, used to tease me, accusing me of the same syndrome; he called it “paralyzing perfectionism”, but certainly alluding to the same psychological trait). I don’t think that’s exactly the same thing is happening here, but I certainly remember that aspect has played a role in many of the threads in this forum where I’ve found myself in strong disagreement with several other posters.
On a more concrete level, again, it’s not so much “my needs” that play a role in my request; in here, I’m mostly going with what I believe to be a blatantly obvious logic/principle; it’s not really that I have a particular board layout with a particular need where the named track widths or the “automatic update” functionality in net classes is the only solution; it’s more that I think that is the logical and reasonable way to go. Sure, I may be influenced by my experience in programming / software development; then again, the fact that the principle comes from software engineering does not mean that it cannot be right. The issue of “named tracks” perhaps comes from the programming principle that no line of code should have any “magic/hardcoded number”; any constant should be assigned a name and used by name — for readability, and for reducing the risk of bugs when we need to upgrade the value constant. And the issue of updates to net class settings propagating automatically, well, that’s a basic principle of indirection (I’ve shown several analogies earlier in this thread).
Speaking of typical human psychological traits, let me present the flip side of this argument: is it me, really, that have unusual needs and odd ideas about how to do things? Or is it that because you are much more experienced and familiar with every feature of the tool and are used to doing things based on those available features, is it possible that because of that you’re failing to see some obvious and simple solutions that a beginner sees as obvious? Also, speaking about experience: sure, maybe you have not needed to update/adjust track widths during the past 15 years because you are very experienced and very disciplined and you tend to get it right at the first try; that doesn’t mean that the tool should not accommodate those who make mistakes and at some point during the work require adjusting / changing things they already did. Lastly on this item, maybe it’s a matter that you’re not (much of) a perfectionist, so you haven’t decided that you need to update things, when maybe most other people would have noticed details that would have prompted them to decide that they needed to change things?
Huh … so much for “don’t know how to respond to that”
But does it still tell you that the action caused DRC violations? (I think it should, perhaps with a suggestion along the lines of “You may want to run the DRC checker to fix them”)
At the moment, no. One challenge is that for large designs, running DRC can take many seconds, and it would not be great to slow down the UI just to provide that automatic check. The old way this was implemented did not actually run a full DRC, but only did some limited checks. This kind of limited checking has not been implemented into the new DRC engine that has been created for V6 (yet).
May I suggest the following (probably you guys have already considered it, but I will mention it anyway):
Add a checkbox, allowing the user to indicate whether they want to Run DRC after applying the changes (this would have the sligtht added value that that warns/reminds the user that the action can cause DRC violations).
As an alternative, maybe just respond with a window saying “The changes may have caused DRC violations, you may want to run the DRC checker … etc. etc.”
Don’t get me wrong: between the behaviour in 5.1 and the behaviour in 5.99, I think 5.99 is better … but not ideal/perfect (problems, e.g. DRC violations, happening silently are certainly not a positive thing!)
I guess the “limited checking” you are referring to (your comment suggests that you are going to implement it, just that it has not yet been implemented) refers to only checking the items that changed against every other item? (instead of checking every item against every other item?)
Shoot! I forgot about the most important detail that I wanted to comment:
In response to the fact that no other EDA tool has this feature, I ask: do you guys want KiCAD to be a clone and just follow what others do, or do you want KiCAD to be an awesome upon awesome tool, which includes the possibility to better some of those tools by providing features that no-one else has?
Don’t get me wrong: KiCAD is already an awesome tool !!!
Could you please post a copy-n-pasted version info for 5.99 that exhibits that behaviour? I just opened the issue, but the bot closed it because it is missing the complte version info (and I have never used 5.99, so I can’t really generate it myself)
Could it be you have some left over frustrations from this job you need to vent?
I’m trying to imagine, what it would be to click on each track segment separately, then open a menu and set it’s track width to the net class value. That would build up some fatigue and frustrations over a few days in a complicated design.
The differences between U and I are only noticeable on complicated tracks that go to multiple IC’s and/or T-junctions.
I think it would be good for your KiCad knowledge to every now and then use some quality time to browse through KiCad’s menu’s and try out some functions you have never used before.
Look trough the shortcut keys list in KiCad / Preferences / Preferences / Hotkeys. Make some notes of shortcut keys that are useful to you.
Or just print out the cheatsheet, with a one page selection of most used shortcut keys:
Another tip:
[Del] tries to guess what you want to delete, so with tracks it deletes up to the closest junction. However, when there is an active selection, it assumes you want to delete the selection. When you single click a track segment, it gets selected, and then [Del] only deletes that single segment.
To delete the left part of a long winding track, select a segment in the middle, [Del] it, then hover over the left part and [Del] again.
Pcbnew / Edit / Edit Track & Via Properties currently indeed refuses changes that would generate DRC errors, while if it just did it, you see nice big red arrows on the DRC errors to help you fix them. However, when you use the selection methods I described earlier, it just sets your selection to your new settings, even if it causes DRC errors, as you can see in my screenshots.
But there is still a big, important missing piece: I cannot select all tracks that belong to a given net class (or to a set of net classes) and only those tracks (can I?). That is what I believe would be the more common/useful action (and in any case, it would be the alternative to the issue of Edit Track & Via not changing the items that would cause DRC violations)
I felt like changing all track widths in single design and that is while designing LED pcb for MCPCB. In some of the leds there is only anode and cathode through which led can dissipate heat and is transferred through MCPCB onto heatsink. So in that case I have to increase width of all the tracks connecting anode and cathode of all the led’s in series. In led’s with third pad to transfer heat we require area of the pad to be increased as much as possible. Along with that they all should remain isolated from each other.
)
