User-defined DRC violation severities (including “ignore”).
DRC violation filtering (by severity).
Ability to mark individual DRC violations as exceptions.
Persistence of exceptions.
User-defined DRC marker colours.
Feedback encouraged. 
8 Likes
I haven’t tried it yet, but from the description, these enhancements to the DRC feature are a VERY WELCOME addition! I’m sending out (virtual) beer to everybody on the development team who helped make it happen. 
I hope that some serious thought, and discussions with real-world users, happened before the User Interface was defined. There are very good, and very real, reasons why the DRC is there in the first place. Giving somebody the ability to over-ride or downgrade DRC squawks is somewhat similar to taking the battery out of your household smoke detector. There should probably be some situation within the typical DRC usage where KiCAD reminds us, “Hey, you are ignoring some DRC violations. Do you want to continue doing that? Would you like to review your exceptions?”
And I hope that within the development work on DRC, some meaningful checks for silkscreen violations were added.
Dale
3 Likes
Hi Dale,
The actual DRC checks haven’t changed (yet), just how they’re managed. Big changes to the checks are planned for 6.0 though…
Cheers,
Jeff.
1 Like
It might be useful to indicate errors by an annotated shape rather than a single pointer. This method is used in ASIC design tools and it works very well for indicating clearance and width errors.
1 Like
Did you try clicking on the individual object descriptions under the error report? That will highlight the two objects in the document.
Other things could be done (including animation), but a lot of them would require knowing the error distances (which we don’t today because they’re expensive to calculate).
A pop up message when plotting Gerbers that some DRC was disabled would be great. We already have a prompt about updating copper zones.
2 Likes
We have a policy against “nag” dialogs, but I did add some warning text regarding known violations and exclusions down by the Run DRC… button.
(I tried it in both normal text colour and red, but the red didn’t seem better enough to make it worth fighting the “UI themes” battle.)
1 Like
I also have a strong dislike for nag dialogs. A nice solution could be to add a status line in the gerber options about full or partial DRC status. No dialog, just an extra line of text in the Gerber Options.
Just a simple message, with for example:
2020-03-06 Full DRC check with no errors.
Or:
12 Errors supressed on last DRC check.
Or:
Board modified after last DRC check.
Probably a combination “DRC check passed with 12 suppressed errors, 2 suppressed warnings” would be about as clear as you could make it
3 Likes
Another thing to remember is design reuse. If you copy a working design then the first thing you want to do is remove all DRC waivers. Just because it was OK for the last designer doesn’t mean that its OK in your design. You don’t want a board to fail because a critical warning was disabled.
2 Likes
I generally like the eagle approach to ERC/DRC warning and error reporting. It uses a tree view for this task. The top most level of the tree is for the message severity (warning, error and ignored)
Within each of these there is another level with the report type (example “error track to close to track”). The leaves then are the pointers to each occurrence.
You then have the option to ignore any specific report which moves it under the “ignored” section. If i remember correctly then the ignored section has a layer for severity below it and then the error type with the occurrence.
Every non leave layer displays the number of errors reports below it. Ignored reports are still shown in the report view this way (with a counter to see how many have been set to “ignored”) but not as markers on the PCB.
I think a similar concept might work well for KiCad. It would not require an extra warning for “hey you have ignored some warnings or errors” and it is quite easy to sort through your reports this way.
Another convenient choice by eagle is the separation of the report and trigger dialog. This allows the report dialog to be very small which means it can be kept up while checking out which of the reports one can ignore without taking up much screen space. The trigger dialogs can then focus on guiding the user through the rule setup (I seem to remember that most of the board setup stuff is reachable through the DRC trigger dialog but i could be wrong and i no longer have access to eagle 9, but i could ask a college of mine to make a few screenshots if somebody is interested.)
I filed an issue about the Show checkboxes: https://gitlab.com/kicad/code/kicad/-/issues/4026. ATM it’s very difficult to test because they don’t work correctly.
1 Like
Above bug should be fixed now.
(I say “should” because it was MSW-specific, and I don’t have a Windows box. But others have tested it and it appears to work.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.