Thanks paulvdh. It actually isn’t as bad as you think. The real issue has been addressed by eelik. All the other issues you mentioned do not exist. I can say that because, having assured myself that I was not concerned about what KiCad was complaining about, I have had the boards fabricated without any problems - all 7 of them for the price of one. Winner😃
< sigh >
Do you really mean that two hours from my message you had fixed the problems and now have the ready made working boards in your hand?
Whether or not a manufacturer accepts those several boards in one go is of course their own business, we just hope there hasn’t been any misunderstanding.
You should never just ignore clearance errors unless you really know they can’t be avoided for some very specific reason. You can for example make some track segments narrower or maybe change some clearance values depending on the manufacturer’s recommendations, but don’t just leave the clearance DRC errors there.
At least some of the problems Paul mentioned of course go away when the pads are properly defined, but it requires taking care of the mask (and paste) layers, too.
1 Like
No, and I did not just ignore KiCad. I manually checked all the things it flagged up and decided I had no issues with them. So I ordered my boards days ago while I quietly resolve how to not get those errors from KiCad. I think we are there now with your help. Yep, I indeed have the all singing, all dancing, working boards in my hand.
This is a very naive approach to working with KiCad, (and also for programming and other tasks). What if you change a few small things and then want to order some more PCB’s? Are you going to carefully check all error messages again, or do you just think: “Meh, I already checked those”. It is also completely unusable when projects get bigger and more complex.
All the errors I pointed out are real issues in your project, and I gave suggestions on how you can fix them all, and get the project free of DRC errors. Also, if you put in some effort to learn the more subtle parts of KiCad, you can avoid making all these DRC errors in the first place, and it would not take much time for the PCB design itself (Just a bit for the learning curve).
I’m not sure, because there are so many (47) DRC errors in the project, but from what I’ve seen of the project there is no special treatment needed for the mask layers.
I meant the stacked pads, as you already pointed out. It’s possible to create too large mask opening so that DRC is error free. This is improbable if the pads are designed from scratch like you and me told, but if they are just modified from the original, at least I got too large mask opening.
The way I modified them, the THT pad has a “disc” on both sides, and the large pad becomes a THT pad with both copper and mask only on the backside, and tha large clearance is gone. See the last picture I posted where I modified pad nr. 6, while pad 7 still has the large hole in the solder mask.
But you may also define this as “taking care of mask & paste layers”.
I think you are being needlessly judgemental here Paul (with good intentions no doubt). If you read all the post, you will understand that all issues with this design are now resolved. Perhaps not in the order you would, but resolved nonetheless. So there are no “What if you change a few small things…” problem.
Nope.
We clearly have a different opinion of what “issues” are.
For me it’s very simple. DRC is there to help you, and a PCB should be DRC error free.
For a very simple PCB such as this you already have 47 DRC errors.
Now have a look at A64-OlinuXino, which is the first project on: https://www.kicad.org/made-with-kicad/
(The whole project is on github)
With the way you are working, a PCB of that complexity would have thousands of DRC errors, which would make DRC unusable.
A long time (30+ years) ago, while writing C programs I had a similar attitude. I read through all the compiler warnings and error messages and disregarded most of them. There were also a few I did not really understand, but they were just a few of the many. Later I learned more about programming, what the error messages meant and how to fix them. For some of the error messages, it is jumping though a loophole to make the compiler happy, but even for those it is worth to fix them, just to make the more important errors more visible. Long lists of error messages make the whole error checking unusable. Fixing the error messages also helped me to become a better programmer
Also:
Some of the error messages are for clearance violations. With the default settings KiCad won’t even let you make these errors, which means you’ve disabled this in the interactive router settings, and this also implies you can not use important parts of the interactive router such as the “shove mode”.
I’m not trying to be judgemental here, just trying to share my experience. If you learn to work with KiCad and learn to use it’s features you will design better PCB’s, and design them quicker.
It’s also part of my personality.
I easily get confused by conflicting information. In your schematic for example you have connected: 
to: 
and the only way for me to get over it is to remove such inconsistencies.
3 Likes
One trick to have ‘padstacks’ is to edit custom footprints ‘by hand’, opening the kicad_mod file with a text editor and adding the layers you want it to be in (In1.Cu In3.Cu, etc). No need to duplicate pads. An example of this can be seen in https://gitlab.com/openventilator/openventilator
Yeah, uummm, did you want everyone to read everything in that link?
Here a more specific example: https://gitlab.com/openventilator/openventilator/-/blob/master/CPU_RB0505/GR106772-A.pretty/VIA-091X03-VE_110001.kicad_mod
1 Like
The open ventilator project used a nightly build. In nightlies there is already support for pad-stacks. This topic is about the current stable version. And at this point in time even in the GUI so no more need to edit the footprint with a text editor.
1 Like
But not in the sense used here, for full control of pads. It supports only turning the pad on/off for layers in a limited way. It doesn’t help if non-identical pads are needed.
1 Like
No, in the open ventilator project, we used KiCad stable 5.1.6 or 5.1.7.
We just used python scripting for editing the footprint text files so as to create custom padstacks.
I’ve tweaked the PCB a little bit and it’s now free of DRC errors.
The majority of the errors was because of thwo THT pads stacked on top of each other, so I changed those to a THT pad and an SMT pad on the bottom.
The rest of the errors were mostly clearance violations, which I fixed by making some tracks a bit narrower.
I also noticed you have a netlist file in the project. This is deprecated. It’s quicker & easier to use: Eeschema / Tools / Update PCB from Schematic. This does basically the same, but you do not have to import the netlist manually in Pcbnew afterwards.
I also deleted the .step file. I did not feel like putting that 11MB file in the project, as you already have it and it can also be auto generated.
I did modify some footprints in the PCB, and according to the schematic they are from some external library, so if you update the PCB you may loose them if you’re not careful.
2021-06-03_Tx-TB-Controller-1.zip (96.8 KB)
1 Like
It appears we have convergence. It is as eelik said earlier. I applied his solution, as you have, and got the same result as you. Thanks for your contribution.
Well, strictly speaking, that conclusion doesn’t really follow. You can manually move (with Ctrl-M or M) traces or vias or in general any element to DRC-violating configurations. I guess with copy-n-paste you can also accomplish it.
I’m not disagreeing with your main points — at the risk of being tagged as judgemental as well, I completely agree with your points, and I hope the OP improves his technical skills to the point of understanding that your advice is actually valuable and right on the money.
Cheers!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.