Von Eagle9 auf KiCad8 umsteigen

Versuch doch mal den Import von Eagle zu KiCad mit einer alten Version. Vielleicht ist die Import Version in den neueren KiCad versionen noch nicht angepasst worden.

Bei KiCad 7 ist es genauso.

Hab inzwischen gelesen (aber nicht sicher) dass es zwischen den Eagle Versionen 9.5.x und 9.6.x eine Änderung des Formates gegeben hat. Ich benutze 9.6.2 .

Wäre evtl. ein issue report fällig.

Bernd schrieb:

Kann man die EAGLE Schaltungen nicht im alten Format speichern, gfs über ein ULP?

Keine Ahnung. Würde auch nur gehen wenn Lizenz noch gültig, also nicht mehr nachträglich und wäre VIEL Arbeit.

Bernd G. schrieb:

Das geht meines Wissens.

Wie geht das bitte ?

Bot N. schrieb:

Wie geht das bitte ?

Habe es selber gefunden, Version 7.xx geht!

Hallo Bot N.

Bot N. schrieb:

Wie geht das bitte ?

Habe es selber gefunden, Version 7.xx geht!

Version 7.xx von was? Eagle oder KiCad?

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de

Bernd W. schrieb:

Version 7.xx von was? Eagle oder KiCad?

Von Eagle 9.6.2 nach Eagle 7.xx

Einlesen von 7.xx nach KiCad 7/8 und geht aber auch nicht richtig.

73's

Es schaut ziemlich verhaut aus

Nun ja, ich denke ein Importer kann es heutzutage nicht auch noch besonders hübsch machen. Dazu braucht es vermutlich in Zukunft KI-Unterstützung. Evtl. ist das aus den Eagle-Daten nicht so einfach herauszulesen.

und außerdem scheinen die Bauteilewerte oft durch den Devicenamen ersetzt worden zu sein.

In dem Ausschnitt kann man es hier und da sehen. Ich würde mir das Bauteil mal im Detail in Eagle anschauen, ob da tatsächlich alles korrekt definiert wurde. Gerade bei Libs von Irgendwo bin ich da schon sehr dilettantische Beispiele gestoßen. Mir selber ist es auch schon passiert, das ich in eigenen Libs z.B. Name und Value aus Versehen im gleichen Layer hatte. Kann man durch Ein-/Ausschalten der Layer meist schnell erkennen. So geht z.B. das Value in den Platzhalter „>Value“ unabhängig(!) von der korrekten Layerzuordnung. Ein Importer würde aber nur nach Layer gehen, wie auch sonst.

Auch stimmt die Position der Signalnamen oft nicht.

Wie gesagt, einen lupenreinen Import wirst Du kaum erwarten können. Meine Meinung.

Zweites Problem: Das Einlesen eines anderen Layouts geht gar nicht. Es gibt einen Fehler mit Abbruch. Siehe Bild.

Der Fehlermeldung würde ich mal nachgehen. Da alles im mehr oder weniger lesbaren Format vorliegt kann man da mal schauen, ob man das nicht retten kann. Kann sein, dass das tatsächlich der Fall ist, Eagle aber einfach nur tolerant war.

Harald A. schrieb:

Nun ja, ich denke ein Importer kann es heutzutage nicht auch noch besonders hübsch machen. Dazu braucht es vermutlich in Zukunft KI-Unterstützung. Evtl. ist das aus den Eagle-Daten nicht so einfach herauszulesen.

Kann man so oder so sehen. Ich sehe das so, dass wenigstens die Werte der Bauteile mit übernommen werden, sollte schon drin sein. Das XML File gibt alles her was man in diesem Fall braucht.

Mach doch einen bug-report.

Meiner Erfahrung nach reagiert dort sehr schnell jemand und ist auch noch dankbar wenn man Beispiele beiträgt.

73

Schon längst gemacht.

Bot N. schrieb:

Kann man so oder so sehen. Ich sehe das so, dass wenigstens die Werte der Bauteile mit übernommen werden, sollte schon drin sein. Das XML File gibt alles her was man in diesem Fall braucht.

Interessant ist, das bei einigen Bauteilen die Übernahme klappt. Bei den „ROB_C-SMD0805“ nicht - daher hatte ich auf einen möglichen Definitionsfehler in der Eagle-Lib dieser Bauteile geschlossen. Mag sein, dass die Info im XML ist. Wenn an der falschen Stelle dann an der falschen Stelle.

Aber wenn Du alles geprüft hast soll es wohl am Importer liegen.

Gerhard H. schrieb:

Gibts nicht.

Natürlich kann es Definitionsfehler in einer Eagle-Lib geben, z.B. Value und/oder Name nicht in den dazugehörigen Layern. Überhaupt Layer-Verwechslungen.

Vielmehr kann man sich da alles so und nur so definieren wie man es konkret braucht. Meine enthalten z.B. nur Footprints samt Umriss-Grafik und bei ICs noch Pinbeschreibungen.

Ja, man kann alles so machen, wie man es sich für sich selbst haben möchte. Ich habe da auch ein paar spezielle Anpassungen, die mir die nachfolgenden Arbeitsschritte erleichtern. Muss man sich aber nicht wundern, wenn ein Importer eines fremden Programmes diese eigenen Definitionen dann nicht kennt.

Wie gesagt, muss im obigen Beispiel nicht so sein - dann ist nur die Frage, warum es bei einigen Bauelementen klappt und bei einem bestimmten Typ nicht.

Es beantwortet zwar nicht deine Frage und ich weiss nicht welche Anforderungen du an das EDA Tool hast, aber da du wohl von Eagle umsteigen willst/musst lohnt es sich vielleicht mal einen Blick auf LibrePCB (https://librepcb.org/) zu werfen. Viele Konzepte sind ähnlich wie bei Eagle, im Gegensatz zu KiCad welches grundlegend anders funktioniert.

Ein Eagle Importer wurde vor Kurzem implementiert (https://github.com/LibrePCB/LibrePCB/pull/1288, siehe Limitierungen dort) und kann ganz unverbindlich mit dem nightly build (https://download.librepcb.org/nightly_builds/master/) mal ausprobiert werden. Gerne nehme ich auch Feedback entgegen.

Nur zur Info

LibrePCB liest den Schaltplan soweit korrekt ein , habe aber nur kurz auf die Bauteilewerte geschaut.

Gibt natürlich sonst jede Menge Warnungen etc. Aber sieht ganz gut aus!

Bei zweiten Projekt tritt aber auch der Fehler mit "Duplicate import" auf und Import geht dann schief.

Bot N. schrieb:

Bei zweiten Projekt tritt aber auch der Fehler mit "Duplicate import" auf und Import geht dann schief.

Magst du diese Eagle-lbr evt. hier veröffentlichen?

Bauform B. schrieb:

Magst du diese Eagle-lbr evt. hier veröffentlichen?

Angekommen ?

Gerhard H. schrieb:

Bot N. schrieb:

Hab inzwischen gelesen (aber nicht sicher) dass es zwischen den Eagle Versionen 9.5.x und 9.6.x eine Änderung des Formates gegeben hat. Ich benutze 9.6.2 .

Kann man bei den aktuellsten Adlern vielleicht noch in einem älteren Format abspeichern?

Das grundlegende Format hat sich, seit es mit EAGLE 6 vor mehr als 10 Jahren als XML eingeführt wurde, nur wenig verändert.

Und es gibt eine DTD (formale Definition des EAGLE-XML-Files). Findet man nach Installation (auch ohne Lizenz) unter doc/eagle.dtd. Ein schneller Vergleich von 7.7.0 zu 9.6.0 zeigt, dass vor allem 3D dazugekommen ist. Von 9.6.0 auf 9.6.2 gab es keine Änderungen. Von 9.5.2 auf 9.6.2 kam genau ein Elementtyp dazu: Splines. Das geht natürlich verloren, wenn man die Datei mit einer älteren EAGLE-Version öffnen will.

Also ist es ofenbar möglich, Dateiformate 10 Jahre kompatibel zu halten. Soweit ich mich erinnere meckert ein älteres EAGLE nur dass es einzelne Elemente nicht erkennt, aber öffnet den Rest.

Bot N. schrieb:

LibrePCB liest den Schaltplan soweit korrekt ein , habe aber nur kurz auf die Bauteilewerte geschaut.

Sehr schön, das freut mich :)

Bot N. schrieb:

Bei zweiten Projekt tritt aber auch der Fehler mit "Duplicate import" auf und Import geht dann schief.

Wenn du mir das Projekt zukommen lässt, würde ich mir das gerne anschauen und ggf. LibrePCB anpassen damit es sich importieren lässt.

Nikolaus S. schrieb:

Und es gibt eine DTD (formale Definition des EAGLE-XML-Files).

Das ist wirklich sehr nett von den Eagle Entwicklern, hat das implementieren des Importers massiv erleichtert. Leider kann man sich aber nicht ganz darauf verlassen, bei Tests habe ich festgestellt dass Eagle manchmal auch XML Dateien speichert welche gemäss der DTD ganz klar ungültig sind...

Also, es sind tatsächlich 2 ganze libraries doppelt drin, anscheinend eine alte und eine neue Version. Wobei (nur) ein Eagle 9 die beiden unterscheiden kann. Mein Eagle 7 scheitert daran genauso wie LibrePCB. So sehen die beiden aus:

1

<library name="con-weidmueller-sl35">

2

<library name="con-weidmueller-sl35" urn="urn:adsk.eagle:library:199">

Wenn ich die Datei ins alte 7er Format konvertiere (also einfach die neuen Tags weg lasse), kann man die beiden natürlich garnicht mehr unterscheiden. Wenn ich gleichzeitig den Namen der Neuen ändere, startet Eagle 7 ohne Fehler und Warnungen.

1

<library name="con-weidmueller-sl35-199">

Praktisch betrifft das auch noch diese beiden

1

<library name="con-amp" urn="urn:adsk.eagle:library:127">

2

<library name="con-amp">

und wenn man das Problem wirklich so lösen wollte, müsste man auch noch alle Referenzen auf diese beiden anpassen. Und das auch noch im Schaltplan und alle 3D-Daten gingen dabei auch verloren.

Also, vielleicht ist das nur eine winzige Ergänzung in LibrePCB ;)

Urban schrieb:

lohnt es sich vielleicht mal einen Blick auf LibrePCB (https://librepcb.org/) zu werfen.

Danke für den Tip, das kannte ich noch nicht. Scheint schon viele Ähnlichkeiten zu Eagel zu haben. Mal sehen was daraus wird, ich finde das Programm hat durchaus Potential.

Nikolaus S. schrieb:

Also ist es ofenbar möglich, Dateiformate 10 Jahre kompatibel zu halten. Soweit ich mich erinnere meckert ein älteres EAGLE nur dass es einzelne Elemente nicht erkennt, aber öffnet den Rest.

So ist es.

Bauform B. schrieb:

Also, vielleicht ist das nur eine winzige Ergänzung in LibrePCB ;)

Vermutlich ja, aber mit einem gewissen Restrisiko dass es neue Probleme schafft bei Projekten welche jetzt funktionieren ;-) Ich ging eigentlich davon aus dass Eagle die "urn" attribute beim Referenzieren von Symbolen etc. ignoriert (auch damit es rückwärtskompatibel ist) aber das scheint wohl nicht (immer) der Fall zu sein. Sowas steht halt leider nicht im DTD.

Auf jeden Fall werde ich das noch versuchen zu fixen vor dem nächsten LibrePCB Release.

Urban schrieb:

Ich ging eigentlich davon aus dass Eagle die "urn" attribute beim Referenzieren von Symbolen etc. ignoriert (auch damit es rückwärtskompatibel ist) aber das scheint wohl nicht (immer) der Fall zu sein.

Wenn es das täte, dürfte wohl auch Eagle 9 an den doppelten libraries scheitern. Dass z.B. ein SO-16 in mehreren vorkommt, ist ja normal und funktioniert. Also war ein package schon immer nur zusammen mit dem Namen der library eindeutig. Jetzt kommt anscheinend noch diese urn dazu.

1

<element name="J1" library="con-amp" library_urn="urn:adsk.eagle:library:127" package="520250-3" package3d_urn="urn:adsk.eagle:package:8081426/1" value="" x="25" y="5" smashed="yes">

Nur zur Information.

Das Problem mit den falschen Values ist in KiCAD 8.99.0-365-.... behoben.

Das zweite Problem mit "duplicate Libary" jedoch nicht. Das kann man aber selber beheben, wenn man konsequent doppelte Libraries löscht und nur eine benutzt. Dazu muss aber EAGLE noch nutzbar sein vor dem Umstieg.