Multiple warning for the same violation. (Resume needed)

Hello Everyone:
I have a new question/suggestion hehehe. I place 2 terminal blocks in the right spacing to be one at side of another like discused on old topic.

The idea of this post is not discuss about footprint of terminal blocks, spacing or etc. The idea is show that one single warning at footprint level is reported 17 times at internal traces footprint level.

Like this placement was intentional, the idea is one single report, one single arrow, and one single exclusion to do.

The same issue is when the component has part of drawing outside of PCB.In the next image i place a terminal block to show the problem (as example), but the real problem was the conector under the terminal block that require 4 exlusions.

Thanks to everyone

1 Like

What is then the 5th DRC arrow in your last screenshot?

More serious:
KiCad just reports overlapping lines. If it just showed one warning for overlapping silkscreen in footprints, then you could get lost or be wondering where it is. And if you want to fix it, then running DRC again after fixing one warning would have you run DRC 17 times and 17 separate modifications of the footprint. One way or the other, there is always something to complain.

My own preference would be to separate DRC warnings for overlapping silkscreen into text and other graphics. I don’t care at all if lines overlap, this is common too, but if silkscreen texts overlap they become more difficult to read. Sometimes I think about making a feature request for this, but it’s still a small thing and there are already so many open issues & feature requests, with to little developer resources to implement them.

I use a PCB with 0 errors and 0 warnings for the screen capture (adding 2 unconnected terminal blocks), all errors and warnings are terminal block related.
So all are copy of the same warning infraction except the error that is the red arrow courtyard overlap.
In this example I have 2 options:

  1. move the footprint (single solution)
  2. put 18 exclusions (for a single problem).

If this is in mind, is ok for me.

I don’t know what are exclusions you are speaking about but when I exclude ‘Silkscreen overlap:’ from being performed I have 0 Warnings.

I have just checked what would be with PCB I have finished last week if I switch this error checking from ‘Ignore’ to ‘Warning’. I found that KiCad stops counting warnings at 200. I got info that I have 199+ warnings :slight_smile:
I would certainly not be doing 199+ exclusions.

I dont know in which number stop to count. The number changes between projects. Some projects stop on 328+, another 499+.
For exclusion i reffer to the first option on image

In my case to delete the warnings i need place 18 exclusion ( 17 for the warnings, and one for the error)

Maybe i need clarify that this example of overlap the terminal block inside a PCB with 0 errors and 0 warnings.

At this point i think that the feature request is clear.

I have two opinions about this. First, I agree that an overflow of identical messages isn’t good and it’s worth thinking how it could be enhanced. I have a couple of suggestions.

  • There could be different messages for text items (as Paul suggested). Not only because text is often more important for reading, but also because some footprint text items – usually reference designators – can be moved and are expected to be moved while doing the design, but footprint graphic items can’t be moved independently.
  • There could be one message for each pair of footprints and each pair of footprint/board item. For example: “Items of J1 on F.Silkscreen; Items of J2 on F.Silkscreen” and “Items of J1 on F.Silkscreen; Segment on F.Silkscreen” and "“Items of J1 on F.Silkscreen; Text on F.Silkscreen”.

My second opinion is that you could turn silkscreen checks off (ignore them) and just use visual inspection. Personally I want to inspect silkscreen layers as one of the last steps of a design. If you find a good combination of visible layers, visible items and selection filter, cleaning up the reference designators is easy, and at the same time you can see whether the non-text graphics makes sense or needs modification. The 3D viewer is also my friend here, I get a realistic view of the board with the components, and it’s easier to detect some problems in the silkscreen.

I have the same issue that you do with the interlocking terminal blocks . . . IMO the remedy is clear, fix the footprint so that when the terminal blocks are next to each other and interlocked the silkscreen does not overlap, in other words, fix the footprint. It’s on my long list of things to do . . but I do understand your point.

Perhaps a nice solution would be the option to group errors or warnings by type and be able to collapse them by type to aid clarity.

As an extension to this:

What about putting some DRC messages in a “tree” view.
On the top level it would generate one “Silkscreen Overlap” DRC warning for a footprint (or footprint pair). You can then either exclude all warnings of that type for that footprint (or footprint combination), or you can fold open the tree to look at each individual message.

Another Idea is to use custom rules to suppress DRC violation messages inside a rule area. I’ve been looking though the syntax help for custom rules, but I think this is not (yet) possible at the moment. How useful would this be?

Or detect that this footprint already have one warning, stop show more for this footprint.

You are assuming that all warnings for the same footprint carry the same severity and hence once you have seen one you don’t need to see the rest, while that may be true in this particular instance it’s probably not the case for all instances.

Indeed. I already mentioned

And that is not a good solution.

Not so fast.


(rule "silkover"
	(severity exclusion)
	(condition "A.Type == 'Graphic' && B.Type == 'Graphic' && A.memberOfFootprint('J*') && B.memberOfFootprint('J*')")
	(constraint silk_clearance))

This makes all silkscreen graphic line overlaps of any two connector (refdes starting with J) footprints to be Exclusions. The footprints can of course be named exactly, but in case of several footprints or pairs it becomes tedious. Text, including text/graphic overlaps are still warnings.

Yes, this shouldn’t be hardcoded.

2 Likes

I have never right-clicked the Error message (no longer true - I found that function).
I only left-clicked them to see which arrow is it.
I only knew that in Board Setup I can switch some tests to ignore.

At silkscreen layer I have only footprint rectangles with pin1 marking and no texts.
As I decided to have these rectangles such that when footprints placed adjacent than rectangles have common line I have lot of these errors so I switch DRC to not test it at all.

I know, but i dont want ignore the test. Its useful for me. When i place 200 components, is normal overlapings and misplaces. So is a help to find and fix

Also, selecting a specific connector, pressing [Ctrl + e] to load it in the Footprint Editor and then moving or deleting some silkscreen lines is a quick fix. Disadvantage is that you loose the changes when you update the footprints from the library, unless you also export the modified footprint to a library and update the links in the schematic.

I understand. I only wanted to explain what I didn’t know previously.

For me it would be very big disadvantage.
I am trying to keep everything consistent with libraries. So whenever I update any symbol/footprint I select to update all symbols/footprints.

Well, if that is your work method, then:

  1. First put a copy of the footprint under a different name in a project specific library.
  2. Modify that copy.
  3. Make sure the right schematic symbol uses that modified footprint.
  4. Update the PCB.
1 Like

You simplified it too much :slight_smile:
When I then, as I have written, at schematic do update all symbols to library…

I modify library rather rarely and if I get old designs to modify I start from updating everything to current state of library.

It does not matter here what your personal workflow is. My main points were:

  1. It’s easy to ad-hoc modify symbols or footprints to get over some limitations.
  2. If you want to make it more robust, you have to add the library management on top of the change.

Right.
I only wanted to pay attention to different possible approaches.