Author Topic: Eagle to KiCAD  (Read 1624 times)

0 Members and 1 Guest are viewing this topic.

Offline ssashton

  • Regular Contributor
  • *
  • Posts: 172
  • Country: gb
Eagle to KiCAD
« on: April 23, 2020, 04:26:51 pm »
Hi,

For someone already familiar with Eagle 7, what would be a good tutorial to help switching to KiCAD?

I started watching a few, but they assume it's the first time using any PCB CAD software so go pretty slow and focus less on the interface and more the process.

Thanks!
 

Offline poeschlr

  • Regular Contributor
  • *
  • Posts: 52
  • Country: at
  • Head of KiCad library; Writer of tutorials
Re: Eagle to KiCAD
« Reply #1 on: April 24, 2020, 06:51:31 am »
In general I am not a fan of video tutorials as they force me to watch in the speed they are created. This is compounded by most such videos being made by people who did not train enough how to speak for the camera possibly in a room not prepared for good audio as well as not really following a prepared script or at least not being prepared to start over on a mistake.

I used this opportunity to make a full write-up over on the KiCad forum FAQ https://forum.kicad.info/t/i-come-from-eagle-what-should-i-know-about-kicad/22459 (yes i had it originally here but i thought it belongs over on the KiCad forum and i do not want to maintain the same information on two different places)

« Last Edit: April 24, 2020, 09:08:46 am by poeschlr »
 
The following users thanked this post: bitwelder, 2N3055, Jacon, ssashton

Offline ssashton

  • Regular Contributor
  • *
  • Posts: 172
  • Country: gb
Re: Eagle to KiCAD
« Reply #2 on: April 24, 2020, 02:59:18 pm »
Wow thank you, I'll give it a read!
 

Offline jpanhalt

  • Super Contributor
  • ***
  • Posts: 2071
  • Country: us
Re: Eagle to KiCAD
« Reply #3 on: April 24, 2020, 04:03:37 pm »
I'm a longtime Eagle user and my comment only refers to version 7 and earlier.

Regarding this comment in the link:
Quote
KiCad splits the lib assets completely which allows a more flexible workflow

I am not sure what is meant by that.  In Eagle the Symbol and Package libraries are completely separate.  One symbol can be used with multiple packages and visa versa.  It works easiest when the number of pins on the symbol and pads on the package are the same, but there are ways around that when you make the Device.  You can have more pads than pins and visa versa too.

Once you get to devices, the process is a little different, but you can use variants.  One can also set "swap" at >0 to facilitate moving things around, but that is usually only used for logic gates.

Good luck in switching.  I am interested in how it goes, as I have considered switching too.  Apparently making PTH slots is not easy using the Eagle-supplied CAM.  I just went through that and ordered from OSHPark as it had developed its own CAM.

Regards.
 

Offline poeschlr

  • Regular Contributor
  • *
  • Posts: 52
  • Country: at
  • Head of KiCad library; Writer of tutorials
Re: Eagle to KiCAD
« Reply #4 on: April 24, 2020, 05:06:38 pm »
KiCad has the footprint and symbol libraries completely separate. They are in different files (.lib/dcm for symbols and .pretty/kicad_mod for footprints), and they are managed independently (there are two library tables, one for symbols one for footprints).

In Eagle on the other hand one library file has both the symbol and footprint in it. (At least this is how i think eagle works, if not then i used it wrong.)

The restriction of eagle being that you need the SOIC-14 footprint in every library file that has a symbol that would require the same SOIC-14 footprint. In KiCad i have a central SOIC lib (with IPC compliant footprints) and can then link from any symbol in any symbol library to that central SOIC footprint within the SOIC lib. This allows organizing symbols by function and footprints by package type (Which is the organization scheme of the official library).

The benefit of eagles option is that you can just download a single file and get fully specified symbol/footprint pairs.
« Last Edit: April 24, 2020, 05:14:05 pm by poeschlr »
 

Offline jpanhalt

  • Super Contributor
  • ***
  • Posts: 2071
  • Country: us
Re: Eagle to KiCAD
« Reply #5 on: April 24, 2020, 06:02:00 pm »
Thanks for explaining that.

I see what you mean and had never really thought about wanting to go outside the current library to find a package.  The main reason is, like Adafruit and Sparkfun, and probably many others, almost every device I use is in my own library.   Within that library I will have an SOIC footprint that I probably grabbed from somewhere else (perhaps, "IC Packages") a long time ago and know it works.

That allows for some degree of consistency, as different vendors will use slightly different recommended packages for the same package name, e.g., SOIC-8 has several variations.  If the difference is significant, I will append the package name with that vendor, e.g., "CON-FFP-0.5_16P_MOLEX"  vs. "CON-FFP-0.5_16P_TE" and use that as a device variant.

For me, it is just convenience.  For a manufacturer, it allows them to tell a new designer, "use our library" of pre-tested designs or get approval without having to provide a list of what can or cannot be used.

 
« Last Edit: April 24, 2020, 06:05:09 pm by jpanhalt »
 

Offline poeschlr

  • Regular Contributor
  • *
  • Posts: 52
  • Country: at
  • Head of KiCad library; Writer of tutorials
Re: Eagle to KiCAD
« Reply #6 on: April 24, 2020, 07:11:48 pm »
That allows for some degree of consistency, as different vendors will use slightly different recommended packages for the same package name, e.g., SOIC-8 has several variations.  If the difference is significant, I will append the package name with that vendor, e.g., "CON-FFP-0.5_16P_MOLEX"  vs. "CON-FFP-0.5_16P_TE" and use that as a device variant.

This statement is actually misguided (or outdated). Iff the package has the same measurement and the same tolerance (Generally true for two JEDEC compliant packages with the same JEDEC identifier) then the same footprint can be used in the same manufacturing process. It does not matter what the part manufacturer suggests!

Your connector example might stretch this a bit but lets go along with it. Most FFP connectors can connect to the same pattern on the flexible PCB (cable) side (even if the ideal pattern is slightly different). This is because there are standardized cables out there and every manufacturer wants to be compatible to them. Meaning you can use the exact same footprint for all your flexible boards no matter what the exact connector is (assuming they are of the same type: so pitch, pin count and side count are equal). But the solder interface is different for every connector order number (even two connectors by molex will be incompatible). Which is why you will then have one footprint per order number not one per manufacturer. Even if there are two footprint compatible ones as it will be hard to encode the required parameters in a sensible footprint name.

Lets get back to IC footprints: Part manufacturers simply use their internal assumption of what the manufacturing process of a user might be to derive their suggested footprint from some standard (most likely IPC). Most modern datasheets will also include a note that a footprint derived from IPC-7351x is also applicable exactly because they know that their assumption will not fit the process of all their users.

The suggested footprint will be good enough for low volume production where yield is not critical so it is good enough for most of us. But so is any IPC derived footprint with reasonable parameters so you can exchange the suggested footprint by for example TI with the one by Analog as long as the dimensions of the package itself are identical.

This is actually the reason why the official KiCad library as well as the eagle footprint generator ignore the manufacturer suggestion completely and use only the package dimension including their tolerances and IPC equations to derive footprints.



The thing is that a scalable lib makes it easy to change your IPC parameters for a given package if your manufacturing parameters change. That will be quite hard if the same footprint is in multiple libraries as it is then quite easy to miss one of these copies. This is why I think KiCads approach is simply the better one.

Plus even with KiCads approach you can still make one footprint per manufacturer if you really want to (just make a SOIC lib for TI and one for Analog). However, the only reason i can think of would be to silence a superior who has no clue and wants every used footprint to follow the datasheet suggestion instead of allowing the use of modern industry standards.



By the way there are of course exceptions. Examples are MEMS components and high frequency parts which might not be well served with a footprint derived from the general industry standard. Here we use the datasheet suggestion even in the official KiCad library simply because there are other considerations to take into account that are not covered by IPC. For MEMS it is avoiding of mechanical stress and for high frequency it is the exact impedance.
« Last Edit: April 24, 2020, 07:19:24 pm by poeschlr »
 

Offline jpanhalt

  • Super Contributor
  • ***
  • Posts: 2071
  • Country: us
Re: Eagle to KiCAD
« Reply #7 on: April 24, 2020, 07:54:56 pm »
I am not arguing with you, and I picked the FFP example exactly for the reason you give. Assume you are Adafruit, do you want some young designer to grab a package that is incompatible with the made-in-China connectors you use?

From a hobbyist perspective, it is much more convenient to have everything in one place and not have to go through voluminous libraries.  As for JEDEC and the SOIC-8, the the same foot print from Microchip, Maxim, and TI may be interchangeable, but when they are different, as often they are, I carefully review each and come up with what I use.

I am not saying that separately addressable libraries are at all bad.  I am saying it doesn't matter to me (or the manufacturers mentioned), because we use our own.  That is why I was so slow on the uptake of what you meant.

John
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf