For those struggling with migration to KiCAD

From: silverdr_at_wfmh.org.pl
Date: Sat, 24 Mar 2018 18:14:49 +0100
Message-Id: <91F7EF3E-E3B7-493F-A0BF-1C34B419A0D7@wfmh.org.pl>
Executive summary, AKA TL;DR - if I was eventually able to do it with some, acceptable level of success after decades of using EAGLE - anyone can do it :-)

The full story - I lost count which time it was that I tried, and all previous ones failed. This time I eventually succeeded. I both started and finished a project without touching EAGLE. What I can list as key factors, which you may want to have in mind on your next approach ;-) is the following:

- take a really small but at the same time a non-trivial project.
- something that you would do in EAGLE in not more than a few hours, but
- something that requires all elements of a bigger design, just in small quantities.
- ground/power planes, vias, components with exchangeable gates/pins, ...
- give it more than part of your weekend, something like 5-10 times more than in EAGLE
- use the "unstable" aka "nightly" builds, don't even touch the old "stable"
- learn all main single-key keyboard shortcuts (they are actually surprisingly intuitive)
- use only the "modern (accelerated) toolset". Forget the rest.
- have forum.kicad.info open all the time ;-)

I think that my previous failures can be attributed to me not observing all of the above. I usually had something like full Sat and half Sun to use and tried to do things that would require about a day in EAGLE. I tried "stable" builds, and use mouse rather than keyboard shortcuts.

The good:

- I was able to crash the last "unstable" build only once during three days of work! It is still not in EAGLE's league (one crash in almost three decades, after I manually modified its files in a wrong way) but it is an enormous improvement over the "stable" (V4 I think) one, which kept crashing on me every couple of minutes / mouse clicks. I don't know how the builds for other platforms behave(d) but the OSX version was _that_ bad in terms of stability. This (literally) show-stopping problem seems to be under control now.

- The "modern" / "accelerated" "toolset" is usable at last. The "legacy toolset" IMHO never was. Again YMMV, especially on other platforms - maybe it was usable on Windows for example, don't know. In any case the "modern", which I understand (correct me if I am wrong) some of my countrymen at CERN introduced to KiCAD not so long ago, is - I dare saying - good enough to be fully usable, with some non-critical limitations (opacity settings for example).

- There is (at last?) a way to bind the schematics and the layout with something more comfortable than: eeschema -> export netlist -> generate netlist -> save -> overwrite existing -> yes, I am sure -> pcbnew -> import netlist -> read current netlist -> yes, I am sure -> why didn't the footprint actually change(?!), damn it! Rinse and repeat for every small changeset you might have introduced. The "update pcb from schematics" option seems to work acceptably well and dampens the urge to scream every time I need to adapt the pins' connections on the schematics in order to get cleaner routing. I believe I should be able to live with this "meet in the middle" type of approach, between what's been available in EAGLE for decades and what was the only way in KiCAD before. I even think it might have some advantages over EAGLE's way, in the sense that once your files in EAGLE get out of sync (for any reason), the process of getting them back on one track is quite painful today and was almost impossible in preV5 versions, which used binary files to store your creations.

- Some workflows, especially in eeschema, become quickly faster than in EAGLE: wiring, buses, bus entries and more. Prerequisite (again) is remembering the most important keystrokes.

- Seems I wasn't the only one ranting about unconnected, hidden power pins that don't trigger any ERC errors (sic!) and somebody, eventually seem to have corrected it, at least in such way (didn't check thoroughly but my components got power connected automatically) that "hidden pins" are not "hidden" by default. Actually I need to check it more thoroughly, maybe I am wrong here on why this worked this time.

- I surprisingly quickly got used to the lack of "devices", aka separation of "symbol" and "footprint". I thought it was wrong when compared to EAGLE's way but now I think that EAGLE's way is inferior, less flexible and more difficult to both grasp and maintain over time. If you have similar concerns as I had - they will most probably be quickly gone and you'll be glad seeing them go.


The bad:

- V5 (rc - I had) feels in terms of trustworthiness still somewhere less than EAGLE V2 for DOS ;-) There is still a lot of places where I can't just simply trust it to do the correct thing. Either due to confusing / inconsistent naming, or a confusing, inconsistent, unintuitive workflow, or any other factor like "libraries hell" (see below). All in all, I feel like I need to be much more suspicious and double-verify many more things, than I am used to. It might be at least partially due to my habits and proficiency in using EAGLE but I have the feeling that I need to baby-sit more things than I needed when I was learning "the other" software.

- True, there are inconsistencies in EAGLE too but KiCAD looks like there is a huge pile of legacy stuff behind it and there is no dictator who would tell everyone to just forget the legacy and order the devs to bring consistency between various subprograms of the suite. Some things work differently in eeschema, in pcbnew, in footprint editor, in symbol editor, etc., etc. Yes, you learn those things eventually but you shouldn't have to, IMO. I tend to blame it at least in sizeable part on "democratic" process of Free Software development.

- General lack of polish in most areas (although much better than earlier versions). A trivial example: why tooltips of the GUI buttons don't show the equivalent keyboard shortcut and force me to open the shortcut list window instead? But there is many, many more in every corner and often need to be worked around one way or another.

- Lack of non-rectangular selections. You don't know how valuable it is until you lose it.

- Libraries. Honestly - it's a mess. Double-check all the components you import from official libraries. Both the symbols and the footprints. You can get anything but correct stuff if you are not conscientious verifying what you pull-in to your design. For example: I spent quite a portion of a day trying to route a trace to a pad, which I had connected in the schematic. I was able to route the trace all the way until the pad and that was it. The "airwire" was there but pcbnew didn't allow me to make the final connection. Just - no and that's it! I tried to blame various things, turning off (and on and off) DRC checks, clearances, widths, and whatnot... I even opened the footprint in the editor and... didn't find a thing there either. It was until I opened its file in the text editor (sic!) and found (by noticing suspiciously similar lines) that _under_ the pad I tried to connect to, there was another, invisible to me one. Yes, there were two pads, one on top of another, and the presence of the (hidden beneath) other one was preventing me from making the final connection! But you can get lots of other "interesting" things too. Inconsistent drills, misaligned pads, bad references, you name it. Put on top of it a number of various methods of accessing the libraries in various subprograms and lack of central place of managing your lib-set and you'll know what I mean by "mess".


The ugly:

- the damned, hardcoded, non-angular font with O in place of 0 (no slashed zero!)
- the inability to "flow" copper around your text (you end up with an ugly, rectangular hole)


Good luck! All in all - I believe it's worth it, especially given current circumstances around EAGLE.

-- 
SD! - http://e4aws.silverdr.com/
Received on 2018-03-24 19:03:16

Archive generated by hypermail 2.2.0.