Pressing the F8 key and clicking OK in a dialog propagates schematic updates to PCB.\
Is there some function in CLI or python to perform this function automatically?
I do not think that the result will be useful most of the time if there are changes to propagate but it often happens that some change in component metadata is made in schematic, and propagating it to PCB is forgotten.
With an option to update the PCB automatically it’s possible to tell if the PCB changed with the update, and thus if there are any changes not propagated, and flag this as an error when producing fab outputs with kicad-cli.
I guess automatic update PCB from Schematic would have far to many dubious side effects.
I think the old Eagle attempted this. When a connection is removed from the schematic, it also deletes the PCB tracks, and as a result, you need some special editing modes if you for example only want to re-route the wire on the schematic to make the schematic more readable. This adds complexity without much benefit. (P.s. I never used Eagle myself).
My own method (and which I also prefer) is to have a checklist to go through before sending out Gerbers for manufacturing.
I am not aware of a function to check PCB up-to-date status. Only of function that performs PCB update, and out-of-band diff tool that can detect if the PCB changed as a result of the update.
Nonetheless, if an automated function for checking that PCB is up-to-date with schematic was available it would save some extra steps.
Like footprints that have both SMD and TH pads (ie about half of connectors and switches) are an error.
Parts that have an internal connection between pins are an error (Support virtual jumper connections (off-board or internal connections) between pads (#2558) · Issues · KiCad / KiCad Source Code / kicad · GitLab) To add insult to an injury the GUI and CLI have math differences. When trace(s) connect to the pad kicad uses some algorithm to select the object on which to flag the violation from the objects near the center of the pad, and this object’s UUID is then used for the exception. Because of some rounding error the object is picked differently between GUI and CLI about half of the time, and then the exception does not apply, and the error is reported.
Adding footprints for alternative packages of a part (eg. SMD and axial resistor) causes courtyard overlap. You can tell kicad to populate only one but it’s not taken into account for the DRC check.
Drills are pads. Good luck with mouse bites in keep-out areas and inside part courtyards. Recently I read some bug where people complained that kicad has no unplated vias, and at least for the courtyard case it would help.
Kicad is checking text bounding box, not actual characters for silkscreen overlap. Some obviously non-overlapping text is flagged as overlapping. To add insult to an injury when the exclusion is recorded the order of the two objects to which the rule exclusion applies also matters. Kicad can randomly decide to flip the order, and then the exclusion does not apply anymore.
Footprint Properties → Attributes → Component type
No, they aren’t “error”, it’s just that KiCad hasn’t had a way to define internal connections in components. It’s not a problem, just a small inconvenience – you can edit the symbols and footprints so that you can do what you want. In the development version (nightly builds, 9.99) you can even define internal connections.
That would be a bug. See if it has been reported already in the issue database, and if not, you can report it. At least in my opinion it shouldn’t matter how the one and the same check is initiated.
I hope KiCad will get the assembly variant system and that this could be considered there. However, you don’t need it to get rid of the DRC error (or warning).
Please open a dedicated thread describing the situation, maybe with a minimal example project. There may be some way to do it. But in general, I don’t see why you are obsessed with courtyards while you can either edit the footprints to have no courtyard or to exclude individual errors or ignore the whole error class.
To add insult to an injury you are forced to report actual bugs you find, otherwise it’s possible nobody else will report them and they will not be fixed. What you describe would be qualified as a bug, at least in my opinion – KiCad shouldn’t decide anything randomly or make decisions in a non-well-defined way.
You have bumped into several problems, even bugs, with footprints and DRC checks and I understand it’s frustrating, but I would still advice to formulate your findings and opinions in less negative way. People here aren’t so willing to help passive-aggressive posters.
Footprint Properties → Attributes → Component type
That has the options of SMD and THT. No option for SMD parts with TH aligment/mounting holes.
There is an Unspecififed type which may avoid this error but there other things that are decided based on footprint type so this won’t be great overall.
I don’t see why you are obsessed with courtyards while you can either edit the footprints to have no courtyard
That’s obviously an option. Except it does not remove the courtyard in that one place, it does remove it everywhere.
or to exclude individual errors
dozens of errors, each drill is an individual pad
or ignore the whole error class.
I do not see an option for that on CLI.
You have bumped into several problems, even bugs, with footprints and DRC checks and I understand it’s frustrating, but I would still advice to formulate your findings and opinions in less negative way. People here aren’t so willing to help passive-aggressive posters.
Sorry if this sounds negative. The solution is tied to running DRC, and the DRC has so many problems that I do not consider it a tool to rely on in its current state.
Yes, some of the problems are going to get eventually addressed. Nonetheless, at this point running DRC does not sound like such a good idea.
Repeating “to add insult to on injury” sounds negative. KiCad or its developers don’t want to insult you. Unfortunately the program isn’t perfect, sometimes far from it.
The CLI obeys the project’s rules (Board Setup → Violation Severity). There’s quite much to set up there. If you really feel DRC has too many problems and can’t be relied on, you should consider suggesting extra options if your wishes happen to be so generic they could help others, too.
In other respects DRC shouldn’t be unreliable – as I said, it shouldn’t change behavior between calls or make arbitrary looking decisions. If that happens, it’s a bug which should be reported. Actually DRC is critical for creating a working board, so much that bugs there are also easily critical. DRC is something which just must be reliable. An unnoticed buggy DRC result can literally cost you too much.
Yes, I noticed that severity randomly changed for something in the project config. Give that’s what also records the exceptions that are shared between GUI and CLI it should work for disabling some of the checks that pretty much always give bad result.
For others the problem is with reliability. It’s undertandable that the checks are not perfect, and in some specific cases the check does not apply. The override mechanism is very unreliable, unfortunately.
