DK1RM - Linux - Eagle-Daten in KiCad konvertieren

Da mir die Aktionen der Firma CadSoft etwa 2010 zu suspekt wurden, habe ich mich entschlossen, auf KiCad umzusteigen. Aus diesem Grund existieren auf meinen Webseiten sowohl Eagle- als auch KiCad-Dateien. Und mein unguter Verdacht hat sich (leider) mittlerweile bestätigt: Die aktuellen Eagle-Versionen gibt es nur noch mit ekligen Auflagen/Bedingungen, die ich bestimmt nicht akzeptieren werde. Aber was mache ich nun, wenn ich mal an eine alte Schaltung von mir heran muß? Glücklicherweise gibt es (noch?) die alten Versionen zum Download (auch für Linux)! Und es gibt eine Sammlung von Eagle-Scripten, mit der sich Eagle-Dateien (sehr weitgehend automatisiert) in KiCad-Dateien umwandeln lassen. Also sollte es doch keine großen Probleme geben, oder?

Eine etwas ältere Installationsdatei von der Linux-Version von Eagle (V7.0) hatte ich mir irgendwann mal heruntergeladen. Die kann ich ja nutzen, um die Konvertierung auszuprobieren. Alles klar, Installation funktioniert, nur Ausführen kann ich das Programm nicht, da der Code nur auf einem Intel-X86-System läuft... Jedoch ist mein "Arbeits-PC" ein ARM-System. Und nun? Versionen von Eagle für ARM-Architektur gibt es nicht, und Quellcode (zum "Selberbauen") schon gar nicht! Einen weiteren PC kaufen/aufsetzen? Ach nee, das muss auch anders gehen!

Mein System (Rasbian) unterstützt doch "Virtuelle Maschinen", also Programme (VMs), die einen ganz anderen Rechner simulieren können. Da mein "QRP-PC" ja nicht zu den leistungsstärksten Systemen gehört, brauchte ich also eine einfache aber schnelle VM, und so fiel meine Wahl auf QEMU. Dieses Programm hat zwar keine "hübsche" Bedienoberfläche, aber mit (etwas kryptischen) Befehlszeilen kenne ich mich ja mittlerweile so einigermaßen aus... Und was soll nun "da drin" laufen? Am Besten auch ein keines, resourcensparendes System. Also startete ich den ersten Versuch mit einem Damn Small Linux, welches sich recht gut installieren lies, und einigermaßen lief. Aber der Versuch, das Eagle-Installations-Paket darin laufen zu lassen, schlug schon bei der (eingebauten) Prüfsummenberechnung fehl. Nanu, die Shell und "md5sum" sollten doch auf allen Systemen gleich funktionieren??? Egal, ich hatte ja noch ein komplett installiertes Eagle V7.0 auf meinem Arbeitssystem, welches ich in die VM kopieren konnte... Nur leider meckerte das beim Start, daß ihm "libXrandr.so.2" fehlt. Da diese kleine Linux-Installation weder über eine (brauchbare) Paketverwaltung, noch über die dafür notwendigen Programme verfügte, mit der ich die geforderten Bibliotheken nachinstallieren konnte, musste ich mir etwas anderes überlegen...

Ich brauchte also eine Distribution mit einer brauchbaren Paketverwaltung, und entschloß mich zu einem Debian, Diese Distribution ist mir einigermaßen bekannt, hat eine passable Paketverwaltung, und unterstützt auch ältere Versionen. Nur leider gibt es anscheinend keine Installationspakete (z.B. ISO-Images) für ältere (kleinere) Versionen. Also hatte ich mich schon mal auf eine langwierige Installation eingerichtet, aber 14 Stunden hatte auch ich nicht erwartet. Auf die Installation einer grafischen Bedienoberfläche habe ich verzichtet, aber (nachträglich) die "x11-apps" installiert, damit das System die Möglichkeit erhielt, auch Programme mit grafischem Interface auszuführen. Die eigentliche Darstellung erfolgt in diesem Fall mit Hilfe eines "ssh -X" auf dem Host, und nicht im Fenster der VM, was wohl noch langsamer wäre. Die Installation von Eagle funktionierte anstandslos, jedoch meuterte das installierte Programm ebenfalls über eine fehlende "libXrandr.so.2" und eine fehlende "libXi.so.6", was sich durch Nachinstallation der entsprechenden Pakete (libxrandr2 und libxi6) beheben liess. Danach fehlten dem Eagle-Programm noch "libssl.1.0.0" und "libcrypto.1.0", welche nicht als Pakete verfügbar waren. Das Einfügen zweier (etwas unschöner) Links zu etwas neueren Versionen von vorhandenen Bibliotheken löste auch dieses Problem. Danach lief Eagle in der VM, und ich konnte anfangen, die alten Daten zu konvertieren. Daß dieser Vorgang aufgrund der "etwas dünnen" Systemleistung (insbesondere in der VM) etwas dauern könnte, war mir schon klar, aber ich konnte ja nebenbei auf meinem System weiterhin andere Programme schreiben... Die Konvertierungs-Skripte liefen fehlerfrei, und gelelegentlich erschienen Nachfragen nach Parametern für die Konvertierung, die ich alle auf den vorgegebenen Werten beliess. Nach ein paar Stunden war die Umsetzung abgeschlossen, und ich war gespannt auf das Ergebniss während ich die erzeugten Dateien aus der VM heraus auf mein Arbeitssystem kopierte. Der erzeugte KiCad-Schaltplan war zwar korrekt, jedoch etwas klein in der Darstellung → Mit ein wenig "Handarbeit" anpassbar. Nur die (in der Beschreibung erwähnte) Funktion "File->Import Non-KiCad Board File" war in meiner installieren KiCad-Version (V4.07) nicht enthalten... Ok, ich kann also Schaltpläne (mit etwas Mühe) übertragen, jedoch keine Layouts → keine wirklich befriedigende Lösung. Aber vielleicht habe ich ja die falschen Versionen der Programme verwendet...

In der Hoffnung, daß die nicht mögliche Konvertierung des Schaltungslayouts durch meine (veraltete?) KiCad-Version begründet ist, habe ich mal das KiCad des Systems in der VM installiert. Und was muss ich sehen? Die Version (V4.05) der aktuellen(!) Debian-Installation ist sogar noch älter als meine "Arbeitsversion" (V4.07), und enthält die benötigte Funktion natürlich auch nicht! Aber es gibt doch eine "Rückwärts-Portierung" der aktuellen Version von KiCad! Leider kollidiert diese Version mit der "vorgesehenen" Version, und es wird eine fehlende Systembibliothek (libcurl4) angemeckert. Nach "Reparatur" der Paketabhängigkeiten und Entfernung/Installation einiger weiterer Pakete lässt sich das "pcbnew" (V5.01) starten, und enthält tatsächlich den gesuchten Menuepunkt! Nur leider führt der Datei-Import zu einem "segmentation fault"...

Da in der Konvertierungsanleitung von Eagle V6.X die Rede ist, habe ich mir noch ein mal diese entsprechende Version heruntergeladen, und ausprobiert. Ergebnis: Gleiche Effekte wie mit Eagle V7.0. Die Analyse eines Coredumps von "pcbnew" sieht mir danach aus, als wenn ein Zeiger in einer der Darstellungsfunktionen (Modul "crti"?) den Stack des Programms überschrieben hätte. Aber mangels eines Pakets mit den entsprechenden Debug-Symbolen ist das nur schwer zu beurteilen. Und die Aktion, mir das Programm aus dem (verfügbaren!) Quellcode zusammenzubauen, möchte ich meinem (doch leistungsmäßig recht eingeschränkten) System nicht zumuten.

Nun werde ich (wohl oder übel) auf die nächste KiCad-Version (5.02?) warten müssen... Die andere Alternative wäre nur, mit Hilfe von Eagle in der VM die Schaltpläne und Layouts in Druckdateien zu wandeln, anhand derer ich die Schaltungen in KiCad neu erstelle. Aber die Lektion "Mache dich niemals von kommerzieller Software abhängig" habe ich nun (nochmals) gelernt...

Trotz der Info, daß der Eagle-Schaltplanimport von KiCad V5.01 "buggy" sein soll, habe ich es ein mal ausprobiert. Dabei habe ich festgestellt, daß diese Funktion mit etwas "Handeditieren" der entstehenden Dateien doch recht gut zur Schaltplankonvertierung verwendbar ist. Auf jeden Fall ist nach der Konvertierung weniger "Nacharbeit" notwendig, als bei der Lösung mit den ULP-Skripten (siehe oben). Hier nun meine aktuelle Vorgehensweise zur Schaltplankonvertierung:

Schaltplan mit Eagle V6.x öffnen, und gleich wieder abspeichern. Dieser Schritt ist nur notwendig, wenn die Eagle-Dateien mit einer älteren Version erstellt wurde, die noch in einem binären Dateiformat speicherte. Liegt der Schaltplan bereits im XML-Format (mit Texteditor "lesbar") vor, kann dieser Schritt übersprungen werden.

"eeschema" (Teil vom Kicad-Paket) einzeln starten (nicht aus der KiCad-"Umgebung"), Funktion "File→Import Non-KiCad Schematic File" aktivieren, und Eagle-Schaltplan-Datei (.sch) auswählen. Kurz danach sollte der Schaltplan angezeigt werden. Dann den Kicad-Schaltplan mittels der Funktion "File→Save Current Sheet As" (in einem anderen Verzeichnis, denn die Datei hat auch die Extension ".sch") speichern. "eeschema" wieder beenden. Beim Speichern des neuen Schaltplans als "projektname.sch" sollte auch eine Datei names "projektname-cache.lib" erzeugt worden sein. Diese beiden Dateien enthalten nun sämtliche notwendige Daten. In meinem Fall habe ich diese beiden Dateien aus der VM heraus auf das Host-System kopiert, um sie dort (einfacher) weiter bearbeiten zu können.

"projektname-cache.lib" mit Hilfe eines Texteditors öffnen, und alle Texte "-eagle-import_" in "-eagle-import:" (der Unterschied ist nur der Doppelpunkt anstatt des "Underline" am Ende) ändern. Wer sich mit der Befehlszeile von "sed" auskennt, kann diese Modifikation selbstverständlich auch damit vornehmen...

"eeschema" starten (wieder einzeln, und nicht aus der KiCad-"Umgebung"), Funktion "File→Open Schematic Project" aktivieren, und die neue KiCad-Schaltplan-Datei (.sch) auswählen. "eeschema" wieder beenden. Dieser Schritt sollte bewirken, daß eine Datei namens "projektname.pro" erzeugt wird.

Da nun eine "Projektdatei" existiert, kann ab jetzt mit der (normalen) KiCad-"Umgebung" gearbeitet werden → KiCad starten, Funktion "File→Open Project" aktivieren, und die neue KiCad-Projekt-Datei (.pro) auswählen. Nun sollte im Projektbaum die neue Schaltplan-Datei erscheinen. Diese kann nun geöffnet und nachbearbeitet werden: Funktion "File→Page Settings" aktivieren, und ein passendes Papier/Seitenformat und die entsprechende Ausrichtung auswählen. Wahrscheinlich ist es danach notwendig, den komplette Schaltplan zu selektieren und in dem neuen KiCad-Seitenrahmen zu verschieben. Der noch vorhandene "Eagle-Schaltplan-Rahmen" (nebst Doku-Feld) kann nun entfernt werden. Ggf. befinden sich (sehr kleine) "Label" an den GND-Symbolen, die (je nach Belieben) auch entfernt werden können. Nun noch die Texte des Eagle-Doku-Feldes etwas verschieben (oder in das "KiCad-Worksheet" übertragen), und dann war es das wohl auch schon mit der "Nachbearbeitung" → Schaltplan von Eagle nach KiCad portiert.

KiCad Version 5.0.2 wurde am 9.12. laut Info veröffentlicht. Und wie es scheint, wurden auch ein/zwei Bugs beim Import von Eagle-Dateien behoben. Jedoch fehlt bisher noch die "Rückwärts-Portierung", die ich benötige. Also: Weiter warten...

Nun ist auch die KiCad Version 5.0.2 in der "Rückwärts-Portierung" im Debian-Repository verfügbar, aber leider nicht in der "armhf"-Version, die mein RasPi-System benötigen. Und auch im Raspbian-Repository für die "Strech"-Version ist es leider nicht zu finden. Mglw. gehen die Maintainer davon aus, daß niemand so verrückt ist, dieses Programm auf einem RasPi laufen zu lassen. Also habe ich mir die "x86"-Version beschafft, und in meine VM gestopft: Die Konvertierung von Schaltplänen und auch Layouts (!!) funktioniert anstandslos, nur die Bedienung des Programms in der (sehr langsamen) VM über eine SSL-Session erfordert eine große Menge an Geduld → Nach der Positionierung des Mauszeigers auf einen Menüpunkt mindestens 30s warten, bevor die Maustaste betätigt wird. Ein "zu hektisches" Agieren führte bei meiner Konfiguration zum "Hängen" des Windowmanagers (e17), wobei das restliche System weiter lief. Die bei den diversen Aktionen ggf. geöffneten "Datei-Auswahl-Dialoge" zeigten dieses zeitkritische Verhalten nicht. Die konvertierten Dateien wurden von meiner KiCad-Version 4.07 geladen mit dem Hinweis, daß eine "rescue"-Bibliothek angelegt wird. Nur leider wurden anstatt der Schaltplansymbole nur Kästchen mit einem Fragezeichen angezeigt. Dieser Umstand ließ sich jedoch durch Modifikaton/Editieren der Schaltplan- und der Symbolbibliotheks-Dateien beseitigen, sodaß irgendwann ein "brauchbarer" Schaltplan sichtbar wurde → Die Schaltplan-Konvertierungen, die mittels V5.02 ausgeführt werden, funktionieren mit etwas "Handarbeit", die Layout-Konvertierungen sogar ohne "zusätzliches Gebastel".

Lustig finde ich die Aufforderung "Please consider Updating" beim Öffnen einiger Dateien → Ich würde ja gerne meine V4.07 updaten, vielleicht fällt dann sogar die "Nacharbeit" weg. Nur leider gibt es (momentan) die 5er-Versionen weder in der Rasbian-Version 8 noch in der Version 9... Und aus dem Quellcode "bauen" möchte ein Programm dieser Größenordnung lieber nicht...