Add a warning: Track size limited by design rule
Description
If the user selects a track size that is less than the minimum track size, the track size is automatically changed to the minimum.
I understand this behaviour, but I spent way too much time trying to understand why my track was 0.2 mm when asking for a 0.16 mm.
Suggestion:
- When trying to add a track whose size is less than the minimum, warn the user ( not with a popup ) :
"The selected track size conflicts with the design rules."
Steps to reproduce
-open pcbnew
-Board Setup -> Pre-defined sizes
-Create a new track width ( 0.01 mm for instance )
-Click ok
-Using this button 
, select the 0.01mm
-Draw a track
-The track is ( certainly, depends on the default value ) 0.2mm
KiCad Version
Application: KiCad PCB Editor
Version: (5.99.0-11247-g3f6811f413), release build
Libraries:
wxWidgets 3.0.5
libcurl/7.77.0 OpenSSL/1.1.1k zlib/1.2.11 zstd/1.5.0 libidn2/2.3.1 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0
Platform: Linux 5.12.9-1-MANJARO x86_64, 64 bit, Little endian, wxGTK, KDE, x11
Build Info:
Date: Jul 3 2021 06:17:10
wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.75.0
OCC: 7.5.0
Curl: 7.77.0
ngspice: 34
Compiler: GCC 11.1.0 with C++ ABI 1016
Build settings:
KICAD_USE_OCC=ON
KICAD_SPICE=ON
Designs
Relates to
Activity
added priorityundecided statusnew labels
I'm against this whole behaviour. We're assuming the track-width is wrong, when in fact we have absolutely no data to make that assumption (it might in fact be the board-minimum that is wrong).
This is what DRC is for. If you explicitly tell the router to lay a 0.01mm track then it should do so.
I would like it to be mode-dependent (then matching my expectations coming from other software). In Walk/Shove modes where the router is in general trying to prevent DRC violations, the router should not place tracks outside the current width limits. But in Highlight mode with Allow DRC violations turned on? It should place anything.
I think this would be greatly helped if we showed current router status in the message panel or status bar during routing.
If you could just see something like
Width: 0.2mm (from: board minimum) Standard clearance: 0.3mm (from: netclass MYNETS)at the bottom I think it may do enough to prevent this kind of thing.I disagree, but that's just where I'm used to tools where the router can be set in a mode where it never violates DRC. By default, the router should follow the design rules for width as well as for clearance. This will be even more important in V7 when we introduce neckdown / width-by-region. I'm fine if there is a switch to disable this behavior and let you place tracks of width that violate the DRC, but that's what "Allow DRC violations" is for.
If the board minimum hasn't been corrected, stop routing and go correct it (this is why I think we really need a status indicator so you can clearly see what width, clearance, DP gap etc are actually in use by the router, and what their source is).
I disagree that this is an example of unnecessary restricting the user's workflow. "make wrong design rules, then route, then later fix the design rules" doesn't make sense as a workflow when some of the router modes are explicitly supposed to follow the design rules and prevent violating them.
I get that there is some friction from KiCad users who are not used to the router enforcing width, because previously it only enforced clearance, but other commercial tools do this and it seems like a desirable enhancement. I really don't understand why you guys want to treat width differently from clearance: a DRC violation is a DRC violation, and it shouldn't be allowed by the router unless Allow DRC Violations is turned on.
That's like saying you should make the router ignore clearances because that's what DRC is for...
I really don't get your argument/point of view here. There is an Allow DRC Violations mode, why would it make any UX sense to allow (width) DRC violations outside this mode?
Otherwise you're saying they have to edit things in a particular order (or training them to ignore warning messages).
How am I saying that?
If you set board minimum first, you get no warning and all is well. If you set netclass minimum first, you get a warning, but nothing forces you to edit things in a certain order (and why do you say I am saying people would need to ignore the warning?)
Edit: you also have to set up proper clearances before you begin routing, or else (assuming you want to use one of the router modes that respects clearances) your traces will be in the wrong place. That's just how PCB layout software works... it's not some arbitrary restriction in workflow.
Edited by Jon Evans-
The router isn't exact science. You're pushing things on a WYSIWYG canvas. So we have "bumper car" modes. That's all well and good.
But if you go into Track Properties and explicitly move the end of a track we don't say "no", regardless of what the router settings are.
If you're used to doing things in a different order, and every time you do a warning comes up, then after a while you tend to ignore warnings in general, without reading whether or not it's the same one you always see or not (assuming they look the same anyway).
I still don't get your argument. I'm not proposing we prevent width changes in the track properties. Just proposing that the router modes that say they respect design rules, actually respect design rules.
What "different order" are you talking about exactly? I was thinking about something like highlighting cells in yellow in board setup preset sizes page, with a tooltip hint saying that it is below the board minimums or something. With this kind of "warning" it really doesn't matter what order you do things in, but you get the visual feedback if the current state is invalid. And yes, we have to make an assumption about which is "right", but I think it's perfectly reasonable for the purposes of a warning highlight to assume that the board minimums are valid and warn based on them. If you say "but what if people want to set up their track widths and then change the board minimum" I say that's fine! They will just get the yellow box to remind them that they need to do that second step.
I am not quite sure what you mean by "not exact science" and "bumper cars", but there is a workflow that is fairly popular especially in commercial tools where you take care to set up all your design rules first, and then you do your routing. I'm not saying this is the only valid workflow, because I know you don't use this workflow personally. But for people who do use this workflow, it is valuable for the router to respect all design rules, since it makes for a much faster path to a "known good" layout.
To expand on my V7 comment: once we have the router respecting width-by-area rules, it will be much more common (on a certain type of design at least, probably not including the work that you do on your projects) for this situation to come up where a pre-defined track width, which may be valid in most of the board, is not valid in a certain part of the board. I certainly want the router to automatically choose the valid width rather than blindly sticking with the pre-defined width that will cause a DRC error later. So, again, I think this must be a setting that can be on or off, and then we can both be happy. I was suggesting tying it to the existing "Allow DRC Violations" setting, but if you would be happier splitting that into "Allow Clearance Violations" and "Allow Width Violations", I'm fine with that.
-
I am not quite sure what you mean by "not exact science" and "bumper cars"
The same difference as dragging an object with the mouse or using the "Position Exactly" dialog. The former can use rules, whereas the later should always do what you tell it.
there is a workflow that is fairly popular especially in commercial tools where you take care to set up all your design rules first, and then you do your routing
In which case you'd never run in to this as your pre-defined track widths would be set up correctly.
I certainly want the router to automatically choose the valid width rather than blindly sticking with the pre-defined width that will cause a DRC error later.
If the router is automatically choosing a rule then that's great. If you explicitly set a width, then the router should honour it.
This isn't about choosing next-width or previous-width and getting a reasonable result. It's about choosing "0.02" and getting something else.
In which case you'd never run in to this as your pre-defined track widths would be set up correctly.
No, because the correct track width can change based on where you are routing and other factors (once the router respects custom design rules for width). Pre-defined widths are, from my point of view, just a "guide", as in "use 0.25mm unless something prevents it", not "use 0.25mm no matter what"
I don't see the width dropdown in the main UI as being like the width in the Track Properties dialog. The latter is a truly manual override and should always be respected. The former, in my opinion, is just a guide input to the router, and the router should be able to override it if a rule exists to override it (I'm fine with this behavior being something that can be disabled, but I want to enable it).
There is a related issue somewhere that goes back to my status bar comment: The track-width dropdown should not be used as a status bar for the router, indicating what actual width is being used, in my opinion. Instead, I think that dropdown should be re-branded as "preferred width", and the actual width should be indicated elsewhere (along with current clearance of the routed net, diff pair gap, etc)
Assuming we work out the details, are you okay with the approach of branding it as a preferred width?
Related: in V7 I want to make it so that you can step through min/opt/max rule width (rather than having just one entry for rule width) before you get to the pre-defined manual widths. I also wanted to consider making it a combo-box, so you can enter a manual width without having to specify it in Board Setup.
Do you think we still need a warning at that control, if we indicate actual width and other things during routing in the message panel?
I think we need a warning like:
"At least one pre-defined width is smaller than minimum track width. No track can meet this value"
If you make a combobox with an editable field, the combobox should also throw the warning if needed.
It would not trigger a lot of time ( usually, there are not thousands of pre defined track widths ), but that could save a lot of time. ( in my case before opening this issue, I noticed my tracks were too small after 30 minutes )
@jeffyoung do you think this behavior should be ignored if "allow DRC violations" is on, and/or do you think we need a separate control for "allow width violations"?
If so, I don't think we necessarily need a warning in Board Setup, as we don't know at the time the user is in Board Setup whether or not they will be setting the router to obey the DRC or not.
-
I think this is more a problem for hobbyist / people with little or no kicad experience. If they just want to draw a small track, and they can't because of this behaviour, they have to find out why. If they have to adjust a setting, letting them know seems a user-friendly approach.
EDIT : and a hobbyist / new kicad user will maybe not search for the "allow DRC violations". And I some point, the user needs to know that the reason is DRC, for him to look for that checkbox.
IMHO, DRC settings should prevail on a min-preferred-max ( a la Altium ), but not on a pre-defined size. If we rebrand pre-defined as "preferred", maybe we should also add min-max ?
Edited by Fabien Corona -
I don't remember if this behaviour is new to v6, or was already in v5 ?
Based on your messages, we need it for v7. ( where maybe it will be clear for the user with a GUI for min-optimal-max ( and then, if max < minByDRC then we should throw an error / warning ? ) )
If this behaviour is new in v6, maybe we could postpone it for v7 ?
As of now, the added value of this behaviour is, in my opinion, limited, as we don't have a router with width-by-area rules.
It feels like an avoidable trap for young players trying to get small tracks. ( Now, I know :p )
Custom Rules is new in V6. I think min/opt/max in the dropdown needs to be postponed for V7 (it should go in at the same time as neckdown support / width-by-area in the router). The status display can be added for V6 to reduce confusion, as well as any warning display that we deem appropriate.
As of 277bf2b7:
Note that even in V5 (and probably earlier), actual routing width is different from what is shown in that dropdown if the "use existing track width" button is pressed. So, the concept that this dropdown isn't always obeyed is not exactly new in V6, there are just now more cases that cause this mismatch.
Now this is also shown:
Edited by Jon Evans
-
I'm also against this behaviour.
If a user wants to draw a 0.16 mm track and he did not set the minimum track width, this can happen ( default is 0.2 ) :
kicad_width-2021-07-03_12.53.31
I think we should either not override the track width with DRC minimum ( IMHO, this is the way I prefer ) or at the very least warn the user the track he is drawing is larger than what he wanted.
I have just drawn almost a whole board, routing with 0.2mm tracks but I wanted 0.16 mm ( because at some point, I would get stuck with 0.2 ).
So I got stuck and had to change most of my tracks.
assigned to @craftyjon
marked this issue as related to #8588 (closed)
marked this issue as related to #8265 (closed)
mentioned in issue #8588 (closed)
closed with commit 1b989384
unassigned @craftyjon
added statusfix-committed label and removed statusnew label
changed milestone to %6.0.0-rc1
added drc pcbnew prioritywishlist ui labels and removed priorityundecided label
I am totally with OP here: make user aware if current trackwidth is overridden by pcbnew (RED colored bold trackwidth text in the taskbar? because notification bar would be too annoying). I was stuck with pcbnew quietly laying it's own (looking buggy) trackwidth when tried to use netclasses for the first time: #9623 (comment 731916354) :/
mentioned in issue #9900 (closed)
