I agree with @m852. The SamacSys lib loader produces .lib, .mod and .dcm files, which I have to convert to to kiCAD’s “pretty” file format. The conversion seems to work - so far - but it’s not as user-friendly as in Eagle, where imports from SamacSys go smooth. No need to mess with libraries to get the job done. I’ve reported the issue to SamacSys.
When you register the old format libraries under Manage … Libraries, you are offered the option to non-destructively convert them to the current .kicad_sym and .kicad_mod format. You should accept the offer. Then the libraries can be modified whereas old format libraries are read-only.
Oh yeah, .dcm file means KiCad version 5 or even older. That’s why I said “between KiCad versions 6…9”. Between those versions only what’s inside the files have changed, but after v5 happened the big leap in file symbol file format and .dcm files were also removed.
Anyway, I reacted to m852’s comment
File format changes between versions from 6 to 9 are not a reason for possible difficulties in library handling when using a newer KiCad version.
Is it possible to use a library created in version 9 and edit it in 8-6? You don’t take into account backward compatibility, this also applies to plugins
I did take it into account. I said “when using a newer KiCad version”. What I said is true.
The 3rd party who offers the libraries would do well to use v6 format which is compatible with all later versions. And a later format only if there’s some feature in the library item which would need something which is available only in the later file format, but I don’t think that’s necessary.
I appreciate that you would like to use SamacSys components - perhaps that has been your workflow coming from Eagle. However, you should be aware that some of these third party symbols and footprints end up causing quite a few problems and may actually make your transition more difficult. They may not even be necessary. You need to appreciate that KiCad has a different philosophy compared to Eagle. Eagle uses the concept of ‘components’ - symbol and footprint are combined. KiCad manages symbols and footprints separately. To get the best out of KiCad, you might need to learn a different approach.
I would encourage anyone coming from Eagle to work through a very basic KiCad tutorial and build a basic blinky schematic and associated layout. I’m not meaning that to be patronising - even if you have 50 years of electronic design experience, you should try to understand the basic workflow as trying to force a new EDA program to work in the way they you have been used to is a recipe for dissatisfaction, irritation and frustration. Embrace the different KiCad philosophy and you might be surprised.
FWIW I’ve never found the need for autogenerated components - the KiCad libraries are very comprehensive and it is easy to modify existing designs. It is also easy to design a symbol de novo. Likewise, there are several thousand footprints in a standard install as well as scriptable variants. These cover the vast majority of situations but it’s also straightforward to design or modify a footprint.
The footprint for a DIP8 depends on your PCB limits, whether you are using a socket, hndsoldering etc - there are KiCad footprints that reflect those design choices - it doesn’t matter if it’s a 555 or a 741 that fits into that footprint.
3 Likes
The dip8 landing site, like others, must comply with the recommendations of the chip manufacturer, which follow the IPC standard. This ensures the assembly of the device and prevents developer errors. In the Kikad libraries, there are many components that have an incorrect design with an increased size of open metallization, which increases the consumption of solder paste and increases the likelihood of component displacement during reflow. For manual soldering of simple amateur designs, this is probably suitable, but no more … All landing sites must be checked and compared with the recommendations of the manufacturer of a particular component. Usually these are all active components.
There are more latent problems that will emerge when you delve further into using third party libraries. Often the electrical types of the symbol pins are improperly set, footprint layers and outlines may be wrong. These third party items have to be scrutinised and fixed before use.
Whilst I havent done PCB since v7, I always used SamacSYS for symhols etc Kicad didn’t have. I dont seem to remember doing any type of conversion to get them to to work - I think I just used the ‘legacy’ veraions of SamacSYS files, put them in a certain locaton and just accessed the file from the various editors as needed.
Has this approach changed in v9?
The components I’ve downloaded recently from SamacSys include .kicad_mod and .kicad_sym files, along with .dcm, .lib, and .mod files.
I’m still using 8.0.9, but it had no trouble with the .kicad_mod and .kicad_sym files.
Perhaps the OP is following an out-of-date procedure rather than using the new format files?
I don’t really understand your approach to learning KiCad. External stuff such as Samacsys / PCB Libraries etc, can be a nice addition, but they’re still extra’s, and not part of KiCad’s core.
A bunch of years ago, Rene Poschl wrote:
It’s written for a pretty old KiCad version (V5), and KiCad changed quite a lot in the 4 years after that (which is a good thing, lots of progress).
There probably is no universal “best” way to learn KiCad, but starting with a beginners tutorial to get familiar with how concepts are implemented is probably a good start. For example: Getting Started in KiCad | 9.0 | English | Documentation | KiCad
@paulvdh: Paul, thanks for the advice. I’m using the ‘Getting Started’ doc to find my way in KiCAD. In ‘learning by doing’ I’m trying to replicate a design I recently made using Eagle. That design required components which are not available in the KiCAD lib (and neither in the Eagle lib), hence my attempt to import components using SamacSys. The KiCAD Libraries plug-in (v 1.4) which is advertised on the SamacSys web site is almost identical to the one I used in Eagle, but I found out the hard way that it produces outdated library file formats (@RRPollack: the plug-in does not produce .kicad_mod and .kicad_sym files). The web site KiCad Symbols | Footprints | 3D Models describes in more detail (almost) all the steps required to import a component’s symbol and footprint. The end of that page also mentions how to use the Library Loader instead and that app comes to the rescue: it DOES produce lib files which are compatible with KiCAD 9 (and a few earlier releases).
Conclusion: no need to use the KiCAD Libraries plug-in, use the Library Loader (v 2.5 or later) instead and you get the library files in the correct format.
What’s missing (maybe a bug in KiCAD?): after import, the symbol is still disconnected from its associated footprint. The name of the footprint is correct, but the “SamacSys:” prefix is missing in the footprint reference. A quick trip to the symbol editor is all you need to fix that.
@retiredfeline: sorry to hear about bad experiences using imported components. I’ve been using SamacSys for years - always preferring libary designs produced in-house, not some other designs produced by unknown authors - and never had an issue.
At this point I’d like to thank everyone for their responses and valuable contibutions to keep me out of trouble.
1 Like
Nah, personally didn’t have any issues at all. I can fix the problems that I discover but usually it’s faster to just adapt an existing symbol or footprint, or make them from scratch, and you get to QC them along the way.
I notice that a lot of newbies seem to think you must have the exact symbol and footprint based on the part ID from the manufacturer or a library site, when symbols are easy to make, and footprints are usually generic.
1 Like
For me, learning to work with the internal editors for symbols and footprints will always be a higher priority then importing from other sources. The most important reason for this is that I sometimes work with custom footprints, that simply do not exist anywhere else on the internet. (See for example Marco Reps project for his design of a rotary switch https://www.youtube.com/watch?v=PP6ptUdjIF4 Another reason is that I dimply don’t want to be dependent on some internet source. And that’s also one of the reasons I use Open Source software such as KiCad whenever possible.
The things you’re now struggling with are quite common for beginners with KiCad, but once you learn KiCad better, it can all be solved with a handful of mouse clicks (or a few handfuls).
1 Like
In any case, the dependence on component manufacturers’ websites will remain; it’s just a good tool, nothing more. The development of modern electronics is impossible without a modern element base, and these are Internet sites, datasheets, libraries, etc.
Ki departs from Eagle in many ways, the concept of “Device” does not exist. The closest thing is their Symbol.
Commercially offered PCB Symbols/Devices/Footprints I have found seems to be generated by a script, and often not very good. SamacSys does not stack ground-pins in their symbols, no need for 14 extra ground-pins to clutter your schematic. Auto generated symbols are often too big, and not sufficiently descriptive. My default is to generate my own symbols, and make footprints from data sheet dimensions/recommendations. Reusing old Symbols/Footprints means editing and saving in personal libraries.
In Ki it seems you can change a Symbol to Footprint association at the board level, but having multiple footprints for one Symbol does not seem to be a priority for Ki.
Many parts have different packages. Check Digikey for “IC INVERT SCHMITT 2CH 2-INP” and you will find ten (10) different packages.
By default this would mean that Ki would need ten different symbols for the same logic function.
Different but still the same.
Ki’s willingness to update frequently and make big changes is applaudable, but the library hierarchy needs to be reconsidered. A top level “Device” hierarchy/structure could possibly be incorporated using present Symbols and Footprints, without breakage, for those who favor this.
A “Device” should have data fields for BOM details.
the general purpose of such sites is to reduce development time, you add a landing place of a symbolic 3D model, editing them will take less time than drawing from scratch. As for the same landing places, you should always look at the recommendations of the manufacturer of a particular part … there is a part number for this.
I can’t help with your question since my workflow is very different, but I will say as someone who moved from Eagle to KiCad a few years ago, KiCad, though admittedly less “slick” in some areas, is a far less hair pulling experience for me than Eagle. Autodesk did make improvements, but I think KiCad usability passed Eagle when it got to version 6.
3 Likes