Some indeed use the Most version for handsoldering: the “toe” is in general much larger.
Indeed. You just enter the dimensions, and required (or IPC recommended) heel/toe/side values, and the footprint is calculated from these settings.
No, the reference is used by the fabhouse to know which component is placed where. Apart from the value, there are more specifications for a component that are needed than the value, eg. manufacturer, power etc. This is with the refdes listed in the BOM.
My silkscreens just show the refdes. I use a separate layer in Kicad (eco1.user) to show the value of each component. There is just no place for a value on a PCB with lots of SMD components.
I just tried comparing a 0603 resistor from KiCad, normal and hand soldered and compared with IPC Most of the various types in the GiHub repository and my immediate thoughts are:
KiCad Hand solder mainly lengthens the pads beyond the part
IPC Most seems much wider and has far more pad under the part. Longer than KiCad but not nearly as long as the hand solder version. The various options have very little variation in pad size
It’s a bit confusing to stick with which…in this context what is the best practice to follow?
and how you’re maintaining the library?, two entries for a part?.. like SOT23-5 N and SOT23-5 M for h.soldering?
The original Kicad libraries, which also contain the “_Handsoldering” variants
Three IPC7351 libraries:
IPC7351C_Nominal.pretty (default for me: in most cases about the same as the manufacturer recommended footprint for recent datasheets)
IPC7351C_Most.pretty (sometimes used)
IPC7351C_Minimal.pretty (never used so far)
I generate the IPC footprints with the free Library Expert footprint generator. I also use the IPC naming conventions in that case, as I’m too lazy to rename them according to the KLC. I document the dimensions and settings I used in an excel file, so I can always regenerate them or check if I made a mistake.
And last but not least: I add the Eco1.user layer for the value and the value outline and pin 1 marker, which I make identical to the assembly outline drawn by the footprint generator.
Easy, lazy and fully reproducable
The minimal size is really small, generally even smaller than KiCad default, so marginal for soldering.
The Nominal looks to be between KiCad standard and hand-soldered, so I will try that size on my next project.
Can anybody point me at an IPC Nominal footprint for SOD-323 gull wing diodes? The one I am using now has too small pads and I’m getting a lot of dry joints
So… I’m probably stepping in it here, but I would be happy to help out generating more footprints, I’ll be honest, I had no idea what IPC was until I read this thread, but I am a mechanical guy, and have a full suite of MCAD tools at my disposal, and I would be happy to volunteer some of my time, and would be even happier to open access to more of this kind of work.
At the moment, I am slowly starting to generate more of my own footprints and schematic symbols as I go, this is mostly out of necessity, however I really don’t have much to go on as far as standardization goes.
I have been using KiCad for a number of years now and I think it’s a great program and I appreciate all the effort that has gone into making this great tool available to all of us at no cost. However, I believe programs like Eeschema and PCBNew are only as good as their libraries and KiCad’s libraries leave a lot to be desired. I fully understand how much effort it takes to create and maintain quality libraries and hopefully KiCad’s libraries will eventually be as good as the rest of the software.
As well as designing PCBs I am also a C/C++ programmer, both for Windows and embedded systems. Writing some software to read in a csv, xml, etc. file and creating footprint libraries would be a relatively trivial task. That is if the community wants a Windows program for the task. Or maybe it would be a good opportunity to improve my Python skills. Anyway, it’s something I would consider doing if we can all agree on a set of specifications as to what it should do, etc.
By the way, I don’t seem to be able to download that pdf that Mars_Warrior posted a link for. I followed the link, agreed to the EULA but then it complained that I did not have cookies enabled, but I did.
Is the SOD-323 about the same body width and lead dimensions as SOT-23, or is it the next size smaller? If it’s the same, you might try the pad geometry you’re using for SOT-23. (Or, on closer inspection, you may discover that the SOT-23’s are also getting starved solder joints.)
Keep in mind that the paste stencil - and the shrink parameters that define the stencil based on the pad sizes - may be the real problem, rather than pad size per se.
On a different assembly line, or a different reflow profile, there may not be any problems. In a prior incarnation, this was often used as justification for why the company expended significant manhours to create and maintain its own libraries: the custom footprints were proven to be reliable with the particular machinery and processes in the company’s manufacturing facility.
It does seem a good idea to have a IPC-Checker that can import/export footprints with reports, and wizards that can generate footprints using IPC rules (which seem to be continually evolving…)
I find wiki says this “S-Expressions are often compared to XML, a key difference being that S-Expressions are far simpler in syntax, therefore being much easier to parse. For instance, one could implement a simple S-Expression parser in just a few dozen lines of Python code.”
and KiCad already uses s-expression.
Of course, it would be nice to have a file that can load visually, but standards like DXF have no inbuilt structure.
KiCad can read DXF now, but in a limited manner.
There are many simple things, a DXF parser could do, to help extract footprint info from WEB DXF files.
Python is shipped with KiCad, and it is thus KiCad Standard.
There is a small issue that KiCad uses 2.7.x Python, and that sometime that will need to jump to 3.x,
and there seem some fish hooks in that move…
Wiki says this “Python 3.0, a major, backwards-incompatible release, was released on 3 December 2008 … Many of its major features have been backported to the backwards-compatible Python 2.6.x and 2.7.x version series.”
Maybe KiCad can ship with both Pythons for a time, to allow users to test scripts to confirm they are cross-compatible ?
There are currently 141 pull requests. There was discussion earlier of “how to involve the community” to deal with the changes that need to be approved.
Now that Carl is working to update the standards – how can we work as individuals to contribute to helping the parts meet the standard?
A partial answer may be… scheduled video live streams. Someone hosts their screen… staring at a footprint. Anyone can join chatroom. Go through as many parts as possible in ___ hours.
Initially this starts out very slow, begins with some current moderators ( @CarlPoirier ?) and will be very boring and slow. However, as the number of people involved grows, quick video groups can be set up (throughout the different timezones of the world). To increase quality parts can be viewed multiple times by multiple groups. New users could be required to be an observer for the first few sessions.
This may not be the most efficient way to achieve the goal of processing pull requests but it may do it fairly accurately.
Did the librarians ( @keruseykaryu, @CarlPoirier, etc??) had a look at it?
Would that work?
‘We’ would only have to redo them parts once and whenever there is a need to adapt to a different standard/etc they could be recreated via that script, no?
I sat down and read Carls link and will definitely need to do some studying to figure out exactly what some of those requirements mean in practice
eg 6.5. Silkscreen is not superposed to pads, its outline is completely visible after board assembly, uses 0.12mm line width and provides a reference mark for pin 1 (IPC-7351C).
implies that the diode symbol should not be used between pads, common in many SMD diode and LED footprints
Exactly: no silkscreen below the components.
The pin 1 marker for a diode following the IPC-7351C standard is perfectly visible after assembly. I like it, it makes a component check much easier after assembly.
Parametric library generation would seem to be a very sensible solution. The QEDA route might also facilitate the inclusion of SPICE modelling within a component definition and possibly MCAD 3d data as well?
Sorry. I’m not a library maintainer anymore.
And I don’t believe in scripts for library creation. I saw what bad things script might do.
Human abstractness is slower but generate better quality libraries. IMHO.
Scripted generators are responsible for much of the worst things in the DesignSpark libraries.
When you start comparing part and pad drawings in datasheets carefully, you realise there are many errors in the dimensions. A human filter is needed
