V6.99 Confused DRC Violation on Library mismatch

I don’t understand the thinking , I bring in a mounting hole in teh PCB only, I mark it "Not in schematic " and then DRC complains its not as per the library

But thats just a silly logic , why ??

place the hole in the schematic, you are left with a more professional schematic, you can use the mounting holes library, if your project is very large you can create a hierarchy sheet called mechanical

Please show the actual message.

I don’t like that idea. Schematics shouldn’t contain mechanical information simply because a DRC situation exists.

The whole point is Kicad righly has an ability to flag the component is not in the schematic. The issue is I would argue that option shouldn’t trigger a drc library mismatch.

The error is “ xxxxxxx” is different to the xxxxxx in the library

It’s not silly logic, you just misunderstood what it is saying.

I know **exactly **what the error means
I’m saying it’s a silly DRC rule to simply take the option to mark the component as not in the schematic and flag that as a drc error.

I know **exactly **what the error means

I hope you say “sorry” if you recognize that you made a mistake and misinterpreted the drc-message. Also it helps if you provide the exact error-message (as asked by eelik) and not an abbreviation. This helps us to give you helpful advice.

The drc-message as shown in the picture by eelik says:

  • footprint doesn’t match copy in footprint-library
  • it does not say: footprint has no counterpart in schematic
2 Likes

Ah jeepers lads please read my posts not nick pick

The point is that flagging a footprint as “ not in schematic “ triggers a DRC error , that error indicates that the footprint in the pcb is now not the same as the one in the library

This is true but it’s a silly logic to generate a drc on this aspect.

That’s all I’m saying.

We read it already but honestly, you weren’t specific and accurate enough.

On the one hand the DRC error is understandable if the library footprint doesn’t have the option on: the footprint has been changed. On the other, it doesn’t make sense because that option is often used for normal footprints on the board. I think this is an oversight. The footprint option is new in v6 and so is the DRC error. Usually I would ask the original poster to report it on gitlab, but I anticipate that you’re not willing to do that.

I’ll happily post it. I’ve done several in the last week. I merely brought it up here as a discussion item. As you correctly summarise the option should not be incorporated in drc checks.

As you correctly summarise the option should not be incorporated in drc checks.

This is only an opinion and I would disagree at this point.
For me the drc-tests should be consistent and predictable and not with 1001 exceptions. So the “footprint doesn’t match copy in library” should flag really all differences.
Everyone is free to ignore a drc-warning or disable this specific test at all.
But as I said this is also only an (my) opinion.

Some things are already ignored in the check, at least:

  • REF** text
  • some text locations, I guess, because they are meant to be moved
  • pad nets
  • layer
  • locked status

It makes sense to ignore properties which belong to the design.

1 Like

A drc check that flags a footprint is selected to not appear in a schematic is not a pcb DRC error . Perhaps DRC should give you an error that you haven’t saved the pcb design also or that I changed the colour of the silkscreen text. You can carry this thing way too far.

Correction: the DRC check is new in 6.99, not in 6.0. No wonder there are oversights. These should be tested extensively.

I have posted the issue on GitLab

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.