The Pad properties window has changed; but the functions to pass those properties to other pads seems the same.
I don’t mean the “Pad properties window”, but the properties panel. This was copied from the board editor and is now also available in the FP-editor.
Now we have the same tool (with the same usage conventions) in all editors.
the functions to pass those properties to other pads seems the same
Yes. And I appreciate that. The “push properties to other pads” is also my preferred workflow.
Ah, thanks @mf_ibfeew
It is getting late for me. Time to switch off the computer before I miss-read any more comments. 
1 Like
One method that works is:
- Modify one pad.
- Right click on it, and use the context menu options near the bottom:
Copy pad properties to Default
Paste Default Pad Properties to Selected
Push Pad Properties to Other Pads
This works quite nicely but it is not flawless. It appears to make a bit of a mess of things for a QFN that has pads on all 4 sides. Doing it two steps (the horizontally and vertically oriented pads)
Working with Footprint Editor / Show Properties Manager in KiCad-Nightly V7.99 (now: 8.0.0 RC1) has similar results. I am experimenting a bit with the footprint: QFN-48-1EP_5x5mm_P0.35mm_EP3.7x3.7mm_ThermalVias and it has set the pad rotation of all pads to 0 degrees, and it swaps X and Y coordinates instead. This is not very user friendly for later modifications. These footprints are generated by scripts. I wonder if I should make a feature request to change these scripts, so they generate identical X and Y sizes for all pads, and use pad rotation instead.
1 Like
Hi @paulvdh
That must be a bug.
Function works the same whether crossed or not crossed. Same result in 7.0.10.
Just tried it on another footprint: LQFP-32_5x5mm_P0.5mm
Step 1:
Change the Padsize_X from 1.5mm to 1.0mm:
Step 2:
Right click, and Push Pad properties to other Pads. The result is:
The option: Do not modify pads having a different orientation has no influence because all pads have an orientation of 0 degrees (See screenshots below).
Two more screenshots Properties of pad No 2:
Properties of pad No 32:
Instead of the expected orientation, pad size is handled by swapping the Size_X and Size_Y coordinates.
I also looked at a SOIC-8 (with two rows of pads), and it has the same issue. It is less important, and it would only result in more difficult editing if you wanted to make the pads (solder mask, whatever) asymmetrical. Same issue with 2 pad resistors, but the issue is even smaller for those.
I’m still not sure whether I should treat it as a bug and create an issue for it on gitlab, or whether it is an implementation choice and just leave it this way.
The problem is that pads can be designed in several ways – create one pad and copy it and rotate it, or create two non-rotated pads with different x/y dimensions and copy both. You can’t know how a pad has been designed in some footprint before looking into it. The easiest way to push properties as a recurring workflow is to select only visually similarly oriented pads and repeat again for the other orientation. Otherwise you have to first check how the pads have been made and choose whether to push to all or only some.
That is indeed the easiest workaround.
But I would expect KiCad to be able to select all pads of a QFN package and modify their size in a single operation.
This does work:
- Modify a pad.
- Push it to all other pads.
- Rotate the bottom row 90 degrees.
- (Rotate top right row 180 degrees can be skipped)
- Rotate the top row 270 degrees.
But after that is is not possible to change the size of all pads again.
When the [ ] Do not modify pads having a different orientation checkbox is on, then only one row or column is modified. When this checkbox is on, then the pad rotation is also copied to the other pads.
This last I find unexpected. The properties manager shows the pad orientation it in the "Basic Properties area, and therefore I expect the pad orientation to stay the same. I do not consider this a bug, because in other uses, changing the orientation may be the intended behavior.
After some more experimentation, what does work is:
- Do the rotation as in the earlier 5 step list.
- Select all pads.
- Unselect some pads. (For example the center and thermal pads by holding [Ctrl + Shift]).
- Use the Properties Manager panel to set the Size_X and Size_Y variables.
So I’ll leave it at that. It’s good enough to modify the occasional footprint. If you are interested in more elaborate library footprint generation or modification, then working with either the built in python generator scripts, or with the scripts (from gitlab) that are used to generate the native KiCad libraries are likely to be better options.
thanks for all the replies.
I am one that generates a new footprint for every component*… (mainly for QFN , DFN, etc, because QFN have many variants ) . and also, many power DFN/QFN have bespoke pad requirements. So, footprint creation performance must be efficient for me. I will see how the import from altium goes also, for my QFNs. Maybe that’s a workaround. There are custom paste masks (IE paste mask for a copper pad is removed and a separate non copper paste mask pad is used).
Anyhow, the discussion is good for me to learn a bit about kicad.
- not for every R and C of course, but I do have different footprints for different height capacitors…
I think the real problem is the Kicad Library footprints were created long before this function was introduced.
To solve this problem correctly requires a huge undertaking by the librarians to:
1/ Introduce a conforming rule for pad orientation in newly submitted footprints (which is yet another check for the librarians).
2/ Upgrade all the existing footprints to conform with this introduced feature (an appallingly massive undertaking).
The first may occur. The second is way beyond the libraries current abilities.
Awareness of the short comings of this feature should be made somewhere, somehow; to avoid confusion and frustration for those trying to use.
Having written all that, if the user is fully conversant with the footprint editor, it is a very quick and easy exercise to modify a Kicad footprint so the pads respond, as expected, with the editing feature.
Using two examples, I found modifying the footprint then using the feature as intended was just as quick and less confusing than attempting any of the above workarounds.
Interesting.
In Altium world, mostly we use ALL our own libraries.
We build them as required all the time… We might use a manufacturers supplied file, but in general, power users and experienced users that have some experience also with fabrication, will always customize or roll their own pads. Only kids and uni students and hobbysists will use a ‘Altium supplied library pad’
I see the kicad footprint libraries are vast, they are huge, but I would probably never use them.
I suggest you have a look at them, then check if you can make your own footprints better.
I am not too sure about this:
Quite big parts of the KiCad libraries are generated by scripts. These scripts have changed and have been updated with suggestions from IPC standards and possibly other sources. One of the changes are for example the change to pads with rounded corners.
I have some mixed feelings here. Default libraries of software packages that have been 30+ years on the market tend to be a mishmash of of different quality content. I once converted a few Nucleo boards (direct downloads from ST’s website) from altium to KiCad, just to do some tests with the importer. The first had a big QFP (I think 144 pin) and the pads were not even at a regular pitch. It seemed like a metric package was truncated to mill resolution values or something similar. With another Nucleo board I tried this did not happen.
In the end it is the quality of the footprint that counts. I don’t know if KiCad’s libraries are better then altium’s, but marking somebody as a “uni student, hobbyist or hobbysist” for the sole reason of using footprints that were shipped with the software is too extreme. I could also turn it around. Re-designing the same footprints again and again for each customer is a waste of effort and drives up costs, on top of that humans are much less accurate then computers, and likely to make the occasional mistake, which would then lead to faulty footprints. It’s common for companies to build up their own preferred (and much more importantly:) individually verified footprint libraries. But once you have them, there is no need to redo that work.
If you’re interested in scripting for footprints in KiCad, then have a look at the link below.
1 Like
Hi Paul. thanks for the writeup.
just watched " KiCon 2023 Generating Parts the KiCad Way" now I know who Seth is .
The scripting is good and I can writing things to get in and out of scripts. fantastic. Video is good. mmmmm
I guess I do not trust anyone else’s footprints unless you’ve seen them on your or someone elses PCB… it’s an expensive error when a respin of a 10 layer large PCB with $1000 tooling and then the fab and the $$$$ parts on board
Seeing that the topic today is entirely different to yesterday, I’ll move this to a new thread for future reference by others.
Yes of course. No matter what the origin of a footprint is, you should never trust it on sight. Whether it’s from a default library, a script, from websites such as SnapEDA / PCBLibraries / Samasys / etc, or even made by your most beloved spouse. People are inherently sloppy and as a countermeasure you should always have some kind of verification procedure in place. On a hobby level, something like [tutorial] Test fitting Footprints works, and in a company, which generally has higher stakes, but also more resources, having footprints checked by another person that made them is a common procedure. In mechanical engineering it is common to have drawings checked by a second (and possibly third) person before someone on a higher level signs off and the drawing goes to the factory floor.
I make PCB’s on a hobby level, and the “test fitting footprints” way works for me. I do it as a verification step just before sending out gerber files. That way there is a decent amount of time between generating a footprint and the verification, and this makes it less likely to make the same mistake twice. Mentour Pilot calls it “the swiss cheese model”. An error can go unnoticed though a hole in a layer of cheese, but when you have multiple layers of cheese then all holes should be covered.
Paul, nice idea on the Test Fitting footprints. Print wise. should be able to reverse/ invert with Irfanview etc or I can write something in python to transpose . Excellent for thru hole. and some of those thru hole drawings in datasheets are might confusing !
More tricky when you get footprints like this :
Well, that was over 6 years ago.
In tn the mean time, KiCad has evolved a bit. If such a low resolution picture is all you’ve got, you can use ** … / Place / Add Reference Image** to import images into KiCad’s sub programs and use it as a background reference (scaling and transparency is supported) for direct comparison.
As far as I know, there is no mirroring of the image (yet). In the PCB Editor you can get around that by flipping the footprint itself to the “wrong” side if it’s needed.
Or just print it on tracing paper, or if you have none at hand use a few drops of oil to make regular paper partly translucent after printing on it. Plenty of possibilities with a bit of creativity thrown into the mix.
oh yeah, have full dimensional drawing… some mfrs will supply a CAD footprint in a CAD/PCB program sometimes PADS/Altium/Kicad, sometimes just a DXF zero width line outline
ANyway, it’s not a big deal to create footprints. if its efficient.
In footprint editor , how do I get the orgin to be set at the centre off the copper pad origins ? I see it can snap to pad centres, and it can snap to grid, but cannot see how it will snap to the copper centre of all pads. ?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.