Electronics > KiCad
Is this a bad idea?
knotlogic:
Long time Eagle user finally making the move to KiCad for my personal projects. There are some things that are nice, some things that are odd, and some things that are just plain frustrating… but that’s probably best left to another post.
Right now I’m getting everything set up the way I like, and one of the things I figured I’d like to get right from the beginning are footprints for chip components. One thing that’s always been a minor annoyance is how the anchor point of chip pads (for routing) don’t always line up nicely on the grid I’m using. I try to keep everything to a 0.1 mm grid, though I’m told a 0.05 mm grid is a standard.
With Eagle, this sometimes results in a little “stub”. Which is no big deal. If I move the component, one end of the routed trace is anchored to the pad, and the trace will stretch to accommodate the move. Easy to spot and correct for. With KiCad though, that doesn't happen, and I have to be careful to keep an eye out for any orphaned stubs. I haven’t spent much time with KiCad yet, but this seems like it could trip me up.
Taking the 0603 footprint as an example, KiCad places the pads at +/- 0.775 mm away from the origin. Obviously not on a 0.05 mm grid, let alone 0.1 mm. Playing around with the PCB Libraries footprint generator tool, I get a smaller pad, offset at +/- 0.745. Better, and I suppose I could round that off to 0.75 and be done with it. But going to smaller components I expect it won’t be so easy.
Which brings me around to an idea I had. One of the nice things I’ve found is the ability to create arbitrary pad shapes. Drop a core pad, draw a shape around it, and done. What I’ve found is that the anchor point will be the centre of that core pad. Which means I have control of where the overall pad’s anchor point is. And I can make that location the same for capacitors and resistors, which should make routing nice and neat.
In the attached image, I’m using simple rectangles with a 0.1mm line thickness. That gives me 0.05 mm radiused corners for the pads. I’ve left the pad on the right unfilled to make it easier to show what I mean. Ignore the pad numbers… I was playing around with various things.
Is this a bad idea though? Does it have the potential to cause problems that I haven’t foreseen? And are there better ways to approach this or am I just wasting time.
bpiphany:
I too like that kind of perfectionism myself. I don't see how that would be an issue. I used to achieve similar results by hacky means in previous releases of kicad that didn't have the custom pad shape options. That came back to bite me later, but this is a supported feature, so I would be surprised if you run into problems with that. A simpler(?) way to get the same offset result is to use the "Offset shape from hole" option, which works also for SMD pads. I guess it's a matter of taste which math is more convenient to get the desired pad anchor location and offset.
knotlogic:
Thanks for the suggestion about using "offset shape from hole"! It does seem like a simpler way to get the same result. I only had a vague idea about what it did before, and didn't know it could apply to SMD pads too.
TomS_:
Personally I think it's a waste of time trying to get the pads centered on the same grid as routing your traces. For example, what happens when you decide to use a different grid? Are you going to produce a new set of footprints for that new grid, no, that would be crazy talk. 🙂
I also sincerely doubt there's any "standard grid" in this world. While you can certainly try and have one for your own projects, there will always come a part that doesn't conform to it and then what do you do?
So, does it really really matter if the pads aren't on a certain grid when 99.999% of the rest of the trace will be? At the end of the day you really just want a functioning circuit, and there are plenty of other ways to focus your creative effort than grid alignment of pads. IMO of course.
Finding stubs is easy by running DRC too - at which point you can delete them.
Completely echo your feelings towards KiCad too, as someone that moved from EAGLE last year. But I'm not really looking back having done so.
Doctorandus_P:
--- Quote from: bpiphany on April 23, 2023, 11:47:55 am ---I too like that kind of perfectionism myself.
--- End quote ---
I am also plagued by that sort of "perfectionism", but I learned a long time ago that it's mostly a waste of time and effort, and you will never get it "perfect" anyway.
With KiCad, a track does not have to reach the center of a pad to be recognized as a connection, but I still kike KiCad snapping to pad centers because that gives me confirmation that a track will always be recognized as a connection.
As for the grid. I usually use some coarse grid to align parts for "better looks", but for routing tracks I just set the grid to "something small" and then completely rely on the interactive router for the track placement.
If you're coming from Eagle (or any other PCB program), the first thing you have to realize is that KiCad is "different", and you have to accept those differences. Handling of parts and footprints is quite different from the way eagle treats them. I don't think eagle has an "interactive router" (or anything close to it). Using the interactive router effectively takes some time and practice, but it is a very mayor time saver for routing an PCB. You can just quickly route some tracks haphazardly, and then take the outermost and shove them into the bunch to align them all. This "looks nicer", but it also increases coupling between those tracks, so from an electrical point of view it is a deterioration. So there goes your "perfectionism" once again.
KiCad also has: PCB Editor / Tools / Cleanup Tracks and Graphics and you can use this for cleaning up unconnected track sections quickly.
I recommend that if you switch from one PCB design program to another, to not do it "perfect", especially in the beginning, but first do a bunch of simple and or "sloppy" projects just to get to know the new program, and which workflow works best in that new program.
Navigation
[0] Message Index
[#] Next page
Go to full version