Computer science has an advantage over traditional engineering disclipines. It’s often easier to just change stuff and see what happens.
Harder to do in e.g. civil engineering but not necessarily just a general aversion to change.
1 Like
Ok. And BTW: notice that the thread (my original claim) was not about net classes functionality; a couple of replies claimed that what I was asking is already present in the net classes functionality, which definitely is not.
But again, my request really was: since the user has the ability to not use net classes and define track widths individually, those track widths should be named.
Then again, sure, the automatic update of any changes on the value of that width is what has become the subject of discussion (well, no, not really … I keep forgetting that “in this forum, we never argue” 
)
It sounds like there are multple different and orthogonal requests here.
- Automatic updating of properties when netclasses change
- Being able to name widths and via stacks without using netclasses
- Storing widths and via stacks using names in the board file
I am not sure the value of being able to name widths and via stacks without using the netclass system. That’s the main reason for the system’s existence (at least in V5)
1 Like
Two comments on this:
- I would sort of agree with that workflow, but with the added advantage that it should be done by the tool (by KiCAD, in this case) automatically walking the user through those. So, you change the net class settings, as soon as you close the dialog, all traces affected get selected, and a pop-up dialog prompts you to accept the changes, etc.
- Even better (and I think I already, at least indirectly, mentioned/suggested this earlier in the thread): it should happen automatically if there are no DRC violations, and with user intervention at every step otherwise.
And BTW, the current deficiencies in handling step 2 are exactly what prompted me to come to the forum and post this request! Not like that is the only reason why I’m suggesting what I’m suggesting, but let’s say that the last three days of work on my current layout would have been a matter of a half-hour (tops) if KiCAD had good/efficient ways to tackle step 2 as you described above! (it would also have been a matter of half-hour if KiCAD had named trace widths or automatic net class settings updating … provided that I had been using net classes, that is)
[EDIT]: incidentally, the changes I had to make were due to a change in the stackup spacing, so I had to recalculate trace widths for the given characteristic impedance. About 70% - 80% of the changes were reduction in the width — from 0.15 to 0.137; for the remaining changes, from 0.15 to 0.17 for the inner layers, not a single one of those required adjusting the route because increasing the width was causing DRC violations.
I’m with Rene & Jon.
Editing net classes is just for settings the defaults for net classes.
There are several tools for quickly modifying parts of a net, or even a selection of multiple track segments from different nets.
This is a strong indication there are plenty of features in KiCad you have not learned to use yet.
For starters, when hovering over a track segment ( or click it first if you like), you can press U or I shortcuts to select more of a net, and then you can edit that selection.
And the “[ ] Use Net class With.” checkbox works with any selection that only has tracks.
For example. I just dragged from right to left, (crossing window selectron) and selected some random section, including a QFP44 and some SMT resistors on the bottom:
Then:
[RMB] / Select / Filter Selection
Filter to only select tracks and via’s:
Which reduces the selection to:
Then I pressed e for edit, and set the track width of the selection to 0.5mm (this selection already was set to Net Class width)
Result:
Or after un-highlighting:
So with just a few actions I’ve changed a selection of multiple segments of different nets.
And even more (after Undo). If you’ve selected some tracks from different nets, then the U and I shortcut keys work on the whole selection. For example: While holding shift while clicking you can select a few track segments. Here I’ve selected 3:
Then press U and these 3 nets are selected until their nearest pad, via or T-junction.
You can also combine these. First do the drag selection, then [Shift + [LMB]] to add some more, remove other pieces, use U or I to further modify. Drag a new box selection while holding Shift also adds the new selected stuff to the selection.
Another function you seem to be unfamiliar with is:
Pcbnew / Edit / Edit Track & Via Properties
[LMB] = Left Mouse Button.
[RMB] = Right Mouse Button.
3 Likes
@cal-linux You seem to have very unusual needs (never seen such a feature in any EDA package, even the very big ones). I’ve never felt like changing all track widths in any of my designs, at least during the past 15 years… I’d be curious to hear what sort of designs you do and why such a feature would be beneficial.
Tom
1 Like
Just to add to what Paul said, using the “Set tracks and vias prooperties” dialog, if you modified your net class and use the option “Set to net class values”, you may get a dialog informing you that some parts where not modified due to DRC violations:
However, it doesn’t let you know which ones …
EDIT: I have seen a kind of similar behavior on the mechanical CAD programs where if you change a dimension and your drawing is constraint or in modellers where you can run a slider left and right and see the changes directly.
KiCad already does this:
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.
Still, awesome tip !!!
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” 
FWIW, this doesn’t happen anymore in 5.99
Hahahahahaha!!! I was actually going to write that I was sure that this would be fixed for version 6 … Good to know that it’s been already addressed.
May I ask, what does it do instead?
It does what you would expect: makes the changes, and then you can run DRC later and fix any violations.
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?)
Please open feature requests on the issue tracker, they are hard to keep track of here!
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 !!!