War hier zwar auch schon ein Thema aber das ist 10 Jahre her. Zuerst etwas Hintergrund. Ich arbeite eigentlich seit ich Platinen mache mit Eagle, ich hatte mir da mal so eine Lizenz besorgt mit der ich Europakartengrösse und 4 Lagen erstellen kann. Das war zwar nicht günstig, aber wenn ich das mit den aktuellen monatlichen Gebühren für die aktuelle Version vergleiche, dann hat sich das schon mehrfach gelohnt. Es ist ja schliesslich nur für mein Hobby. Bis und mit Eagle 7.5 kann ich diese Lizenz verwenden was ich im Moment noch immer mache. Diese Version deckt so ziemlich alle meine Bedürfnisse ab. Aber eben nur so ziemlich. In der Zwischenzeit sind die Kosten für die Erstellung eigener Platinen extrem gesunken und für den Preis den ich damals für eine 100x160mm Platine bezahlen musste kann man sich heute richtig grosse Platinen erstellen lassen. Da muss man nicht mal nach China. Nun stehe ich vor der Aufgabe für ein Retroprojekt eine grössere Platine erstellen zu müssen, und zwar muss sie 8.43" x 5.187" gross sein. Also habe ich mir gedacht, das wäre vielleicht ein gutes Projekt um endlich mal auf KiCAD umzusteigen. Die Schaltung ist nicht sonderlich kompliziert, ca. 20 MSI/LSI Bauteile (darunter auch ein paar Retro Bauteile). Nur irgendwie tue ich mich schwer (das liegt definitiv an mir respektive meiner Geduld) mit der Bedienung mit KiCAD und den Abläufen. Aber ich denke da muss ich einfach mal dahinterklemmen. Daher bin ich auf der Suche nach einer ausführlichen und guten Anleitung die mir als Eagle Benutzer im "Detail" erklärt wie das dann jeweils auf KiCAD funktioniert. Deutsch, Englisch, Web oder Buch ist egal.
Arbeite Dich einfach durch die "Getting Started"-Tutorials auf der KiCAD-Seite. Die Arbeitsweise ist so unterschiedlich, dass ein Extra-Tutorial "KiCAD für Eagle-Umsteiger" sinnlos wäre.
Hallo Peter, > Nur irgendwie tue ich mich schwer (das liegt definitiv an mir > respektive meiner Geduld) mit der Bedienung mit KiCAD und den > Abläufen. Ich hatte bei meinem ersten Kontakt mit KiCad genau das gleiche Problem, nichts hat intuitiv funktioniert. Erst als ich begriffen habe das KiCad so "konstruiert" ist, das die einzelnen Programmmodule aufeinander aufbauen, wurde es deutlich besser. Grundsätzlich solltest du dich deshalb bei der Verwendung von KiCad an die vorgegebene Abfolge halten. Jede Abweichung davon führt recht schnell zu Problemen und Inkonsistenzen, die die Arbeit mit KiCad unnötig erschweren und dich frustrieren werden (ist mir bei meinen ersten Schritten so ergangen). Die sonstigen "Merkwürdigkeiten" in der Bedienung muss man einfach hinnehmen. Und du musst "dran bleiben". Wer nur einmal im Jahr einen Schaltplan zeichnet und/oder ein Platinenlayout erstellt, sollte einfacher und intuitiver zu bedienende Programme verwenden. Nach längerer Zeit der "Nichtbenutzung" ist man bei KiCad schnell wieder "raus". Wenn man das alles nicht kann oder will, Finger weg von KiCad. > Daher bin ich auf der Suche nach einer ausführlichen und guten Anleitung > die mir als Eagle Benutzer im "Detail" erklärt wie das dann jeweils auf > KiCAD funktioniert. Deutsch, Englisch, Web oder Buch ist egal. Titel: "KiCad wie ein Profi", Autor: Peter Dalmaris Verlag: Elektor ISBN: 978-3-8957-6341-0 Preis: 40,-Euro Das Buch wurde in der aktuellen c't (5/2020) rezensiert und kam ganz gut dabei weg. Es wurde lediglich bemängelt, das das Buch "es verdient hätte, besser lektoriert zu werden". Ich selber habe es noch nicht gelesen, werde es mir aber besorgen. Das "Getting Started"-Tutorial wurde schon von Walter erwähnt und auch ganz empfehlenswert, aber ich habe immer irgend wie den Eindruck das da Vieles fehlt. rhf
Wenn Du schon so lange mit Eagle arbeitest, wirst Du an KiCad wenig Freude haben - zumindest in der Anfangszeit. Ich hatte einige Anläufe versucht, aber KiCad ist definitiv nicht mein Ding, der Workflow von Eagle erscheint mir einfach logischer. Ist aber Ansichtssache und meine ganz persönliche Meinung. Du könntest einfach erst mal folgendes machen: Erstelle erst mal den kompletten Schaltplan mit der vorhandenen Eaglelizens, die dürfte ja diesbezüglich keine Einschränkungen haben. Wenn der Schaltplan fertig ist holst Du Dir eine Monatslizens für 60€, um den Kram zu routen - sollte man doch in einem Monat schaffen. Das Ergebnis kannst Du dann danach sogar mit der Freewareversion einlesen und auch die Gerberfiles kannst Du damit erstellen. Das einzige was eben nicht geht ist das Editieren. Gut wenn Dir das Retroprojekt die 60€ nicht wert ist, wirst Du wohl den steinigen Weg gehen müssen und Dich in KiCad einarbeiten.
Peter S. schrieb: > War hier zwar auch schon ein Thema aber das ist 10 Jahre her. Das Thema kommt doch alle 4 Wochen auf. Zum Thema: Ich bin nach 10 Jahren Eagle auch auf KiCAD umgestiegen: Einfach loslegen ohne Einlesen geht nicht da der Workflow etwas anders ist. Aber dazu gibt es ja ein Einsteiger-Tutorial auf deutsch: https://docs.kicad-pcb.org/4.0.7/de/getting_started_in_kicad/getting_started_in_kicad.pdf Ich muss sagen damit klappte der Umstieg bei mir fast problemlos. Die Bedenken anderer zum Umstieg kann ich nicht teilen. Bereits nach einem fertigen Projekt komme ich jetzt halbwegs gut damit klar.
Ich hatte nach KiCAD und Eagle gesucht, da kam nur ein Beitrag aus dem 2010. Aber das ist eigentlich nicht das Thema. Ich danke für die verschiedenen Tips und werde mich mal in das Abenteuer KiCAD stürzen. Das Buch gab‘s beim exlibris.ch für 31CHF das trifft dann sicher nächste Woche bei mir ein und in der Zwischenzeit lese ich mal in aller Ruhe das Tutorial durch. Und wenns nichts wird dann gibt es immer noch die Option für ein Monatsabo von Eagle.
Beitrag #6145114 wurde von einem Moderator gelöscht.
Peter S. schrieb: > Und wenns nichts wird dann gibt es immer noch die Option > für ein Monatsabo von Eagle. Ich habe letztes Jahr grob 3 Monate (Hobbyzeit mit Pausen) gebraucht, bis mit KiCAD alles so flüssig wie mit Eagle 5.0 lief. Es war quasi wieder ein Neu-Lernen.
:
Bearbeitet durch User
Ich habe Eagle nie als Krampf empfunden. Im Gegenteil, als Anfänger war der Einstieg (auch schon einige Jahre her) recht einfach. Klar mit der Zeit wachsen die Ansprüche und es gibt schon ein paar Dinge die ich vermisse. Mal schauen wie das mit KiCAD ist.
Wenn Eagle 7.5 da ist, wäre ein Gedanke, vorhandene Designs als Schaltplan und Platine in KiCad zu importieren. Es kann dabei auch zu Problemen kommen, auch abhängig von der verwendeten KiCad-Version, einfach mal als Vergleich zwischen Eagle und KiCad. Von KiCad gibt es viele Versionen, stabil dürfte derzeit 5.1.4 sein, Entwicklerversionen die sich im Detail auch täglich ändern können, würde ich nicht für Projekte empfehlen.
Moin! Ich bin auch ein Eagle-Umsteiger. Ja, wenn man Eagle gewohnt ist, ist der Umstieg schwer. Man muß sich insbesondere daran gewöhnen, nicht alles mit der Maus machen zu wollen. Ich habe mir einen Zettel mit den Tastenbefehlen und Layer-Namen gemacht. Dann habe ich ein kleines Eagle-Projekt importiert, analysiert, und anschließend in KiCad neu erstellt. Auch YouTube ist da ganz nett, wenn man sich zeigen lassen kann, wie es andere machen. Mittlerweile necke ich meine Kollegen, wenn sie mit Eagle an Grenzen kommen, und ich dann zeige, wie einfach das in KiCad geht. (Aber natürlich nur, wenn ich weiß, daß es in KiCad einfacher geht ;-) Heute importiere ich Eagle nur noch, wenn ich zu faul bin, die Librarys zu erstellen. Allerdings habe ich auch kein aktuelles Windoofs mehr... Gruß, Stefan PS: Ja, die Version 5.1.x ist empfehlenswert. Ich selbst nutzte die Version 5.1.5 z.Zt. ohne große Probleme. https://kicad-pcb.org/download/
:
Bearbeitet durch User
Wie wäre https://easyeda.com/ Kostenlos, Webbasiert, Super Library, direkte Fertigung. oder https://scooter-pcb.de/scooter-pcb.html Kostenlos, Unlimitiert. Oder http://www.circuitmaker.com/ auch kostenlos. Dieser hier wie SmartWork http://www.freepcb.com/ aber mit Source. Und für Mac: https://www.osmondpcb.com/
Beitrag #6145403 wurde von einem Moderator gelöscht.
Beitrag #6145421 wurde von einem Moderator gelöscht.
Also ich hantiere auch ganz gerne mit der Maus, aber ich bin sehr oft froh wenn es Tastenkürzel gibt. Und bei Eagle gibt es davon für meinen Geschmack zu wenige. Wenn man das 10-Finger System beherrscht, und das tue ich zum guten Glück, dann sind Tastenkürzel ein echter Turbo. Gerade wenn man mit einem grossen Bildschirm (4k) arbeitet ist es ein Segen wenn man nicht für jede Kleinigkeit mit der Maus quer durch die Landschaft reisen muss.
Peter S. schrieb: > Wenn man das 10-Finger System beherrscht Das nützt einem bei einem ECAD genauso viel wie ein Arschloch am Ellenbogen. ;-) Ich kann auch 10-Finger schreiben, mit ca. 220 Anschlägen in der Minuten. Aber weder bei einem ECAD noch beim Programmieren ist dies von entscheidenden Vorteil. Ich bin vor ca. 1 Jahr auf KiCAD von Eagle 9 umgestiegen. Was soll man da sagen: es war ein harter und steiniger Weg mit viel Frust und noch mehr Kaffee! Im Endeffekt aber erfolgreich. :-D Ob man nun mit KiCAD oder mit Eagle schneller ist mag ich garnicht mal beurteilen wollen. Beim Shematic erstellen und die Sache mit der Footprint Zuordnung finde ich bei KiCAD schöner und flüssiger gelungen. Dagegen finde ich das Routing bei Eagle flüssiger und einfacher. Zum Beispiel finde ich noch immer keine Möglichkeit die aktuelle zu legende Route zu "ändern" (Links- / Rechtsanschlag, Zuerst diagonal oder vertikal) (Das was man halt mit bei Eagle beim routen einfach mit der rechten Maustaste durchschaltet). Dagegen finde ich beim routen allerdings die etwas "unrestictive" Back-Anotation eher als hilfreich, man kann ja doch einfach mal 2 Pins noch mit einfügen ohne ihn direkt im Schaltplan mit zu verlinken. Mein Tipp: Lass eine ganze Zeit lang beide noch nebeneinander laufen und schaue immer mal wieder in KiCAD rein, mach kleine Platinen und probieren, probieren und nochmals probieren. Ich habe fast ein halbes Jahr für den Umstieg gebraucht. Bin aber zufrieden damit. Man darf halt auch nicht vergessen: Es ist kostenfrei und wird von Usern programmiert.
Aus Erfahrung mit anderen Programmen die man häufig über die Tastatur steuert weiss ich, dass es sehr wohl hilft, wenn man blind die richtige Taste trifft. Es geht in diesem Fall nicht um Geschwindigkeit. Das halbe Jahr der Eingewöhnung finde ich eigentlich nicht mal so schlimm. Ich musste beim Zeichnungsprogramm von NetViz auf Visio umgewöhnen, das habe ich in 10 Jahren nicht geschafft :-)
Roland F. schrieb: > Wer nur einmal im Jahr einen Schaltplan > zeichnet und/oder ein Platinenlayout erstellt, sollte einfacher und > intuitiver zu bedienende Programme verwenden. Die wirst Du im Bereich Platinenlayout nicht finden. Mein Umstieg von Eagle nach KiCad war einfach. Man muß sich nur an den etwas anderen Workflow gewöhnen. Was ich bei KiCad weitaus besser finde, daß die Schaltzeichen und Footprints streng getrennt sind. Ich konzentriere mich bei der Schaltplanerstellung nur auf die reine Funktion und denke nicht über irgendwelche Gehäusegrößen nach. Ansonsten (wurde schon erwähnt): https://docs.kicad-pcb.org/#_getting_started oder https://kicad-pcb.org/help/getting-started/ sowie http://www.mikrocontroller.net/articles/KiCAD und viele mehr
Ich denke auch, intuitive Platinenlayout Programme die man ab und zu (einmal pro Jahr) hervornimmt und dann erfolgreich eine Platine erstellt gibt es nicht. Auch bei Eagle war ich immer wieder überrascht, dass ich gewisse Funktionen lange nicht entdeckt hatte und danach waren sie unverzichtbar. Und ich benutze es doch recht häufig (mehrmals die Woche). Das gilt eigentlich ganz allgemein bei allen Programmen bei denen man schon für simple Projekte viele Funktionen braucht, nicht weil das Programm schlecht ist sondern weil einfach die Anforderung an das Resultat hoch sind. Bei Layout Programmen beauftrage ich ja am Ende eine professionelle Bude mit der Erstellung einer Platine, das ist nicht vergleichbar, wenn ich beim Schreiner einfach ein paar zugeschnittene Bretter verlange, das ist eher vergleichbar wenn ich beim Schreiner einen Bausatz für ein Möbel bestelle und ich zuerst alles selbst Zeichnen muss. Das gilt übrigens auch für Word (das ich nicht gerade gerne benutze) oder Excel, man hat schnell etwas zusammengeschustert, aber wenn man ein ansprechendes Dokument erstellen will dann ist viel Wissen und auch Routine gefragt. Klar kann man ohne weiteres schnell ein kleines Dokument erfassen. Aber so etwas "kleines" gibt es bei Platinen nicht. Habe mir mal die aktuelle Version auf den Computer runtergezogen und clicke da mal bunt rum. So der erste Eindruck. Es hat erstaunlicherweise überall Context Menus mit sinnvollen Aktionen (war das evtl. bei älteren Versionen nicht so vollständig) und es gibt Tastaturkürzel für Dinge die ich bei Eagle immer vermisst habe. Hingegen war der Tip mit dem importieren von Eagle Projekten nicht so effizient. Der DRC bringt jetzt 1504 Fehler. Da wird es wohl effizienter sein, wenn ich das Projekt neu erstelle (es war eigentlich ein ganz einfaches Projekt)
Peter S. schrieb: > Hingegen war der Tip mit dem importieren von Eagle Projekten nicht so > effizient. Der DRC bringt jetzt 1504 Fehler. Da wird es wohl effizienter > sein, wenn ich das Projekt neu erstelle (es war eigentlich ein ganz > einfaches Projekt) Hmm, dann werden das recht schräge Einstellungen entweder in Eagle oder in KiCad gewesen sein. Bis jetzt konnte ich noch alles einwandfrei importieren (ok, es war zugegebenermaßen nicht viel). Du kannst im Notfall ja auch nur die Boarddatei löschen und den Schaltplan stehen lassen. Ich lasse die alten Projekte normalerweise in Eagle und bearbeite die dann mit den alten Eagle 6.6. Wozu importieren?
Beitrag #6145845 wurde von einem Moderator gelöscht.
> > Stefan S. schrieb: >> Man muß sich >> insbesondere daran gewöhnen, nicht alles mit der Maus machen zu wollen. > > Du kannst Eagle komplett ohne Maus bedienen wenn Du magst. > Ich bin immer noch auf der Suche nach einer Taste mit der ich zwischen Schema und Layout wechseln kann ohne das ich mit dem normalen Change Window vom macOS im Projekt Window lande. Damit würdest du mir sehr helfen. Andreas B. schrieb: > Hmm, dann werden das recht schräge Einstellungen entweder in Eagle oder > in KiCad gewesen sein. Bis jetzt konnte ich noch alles einwandfrei > importieren (ok, es war zugegebenermaßen nicht viel). > Du kannst im Notfall ja auch nur die Boarddatei löschen und den > Schaltplan stehen lassen. Ich lasse die alten Projekte normalerweise in > Eagle und bearbeite die dann mit den alten Eagle 6.6. Wozu importieren? Bei Montagelöchern und den Löchern für die Screw-Headers hat es Fehlermeldungen gehagelt. Da habe ich bei Eagle eigentlich gar nichts eingestellt. Was mir aber aufgefallen ist, beim Import hat er etwas gesagt von ungültigem Layer tRestrict (etwa für die Köpfe der Montageschrauben). Hängt vielleicht damit zusammen, nur was ist denn das Pendent zum tRestrict bei KiCAD? Soweit bin ich noch nicht.
:
Bearbeitet durch User
Beitrag #6145902 wurde von einem Moderator gelöscht.
Da kann man sich streiten. Ich fand das in Eagle oft praktisch, auswählen und alles ist unter einem Dach (Symbol und Footprint) und manchmal habe ich mir gewünscht es wäre nachträglich möglich das Gehäuse zu ändern, vor allem bei SMD kommt das doch immer wieder vor. Für mich hat beides seine Vorzüge.
Habe gerade gelesen, xKeepout und xRestrict werden von KiCAD beim Import etwas Stiefmütterlich behandelt und da scheine ich nicht der Einzige zu sein der damit hadert.
Der Import aus einem anderen Format ist nicht unbedingt der Weg der Wahl, ein neues Werkzeug zu lernen. Und der ständige Vergleich Eagle/KiCAD auch nicht. Es ist ein neues Werkzeug, das für sich ganz allein steht.
:
Bearbeitet durch User
Eine wie ich finde gute, halbwegs aktuelle und ausführliche YouTube Playlist mit Tutorials zu KiCad 5 findet man hier: https://www.youtube.com/playlist?list=PL3by7evD3F51fKkyrUbH-PCdwPCWc9F8a Ganz nett um sich berieseln zu lassen und erst mal einen Eindruck von KiCad zu bekommen. In den aktuellsten Programmversionen muss man allerdings die Geschichte mit der expliziten Erstellung von Netzlisten eigentlich gar nicht mehr machen und auch die Gehäusebauformen können schon im Dialog ausgewählt werden, in dem man das neue Bauteil (Symbol) in den Schaltplan einfügt. Für Bauteile, die nur eine mögliche Bauform haben, ist diese oft schon voreingestellt. Auch die oft kritisierte fehlende Backward-Annotation gibt es inzwischen.
Walter T. schrieb: > Und der ständige Vergleich Eagle/KiCAD auch nicht. Es ist ein neues > Werkzeug, das für sich ganz allein steht. Na ja, sie sollen beide das Gleiche machen, nämlich Platinen. So sollte man das schon vergleichen können. Die Kriterien sind allerdings dabei sehr individuell. ;-)
Walter T. schrieb: > Und der ständige Vergleich Eagle/KiCAD auch nicht. Es ist ein neues > Werkzeug, das für sich ganz allein steht. Und vor allem auf dieser Ebene. Ja, die Bedienung funktioniert anders, schrecklich ;) Viel interessanter fände ich Vergleiche wie "welches Programm kennt Padstacks", "wie detailliert kann ich den DRC einstellen", "hat das Programm genug Layer", "wie unbenutzbar sind die Default-Einstellungen" usw.
Volker S. schrieb: > Auch die oft kritisierte fehlende Backward-Annotation gibt es > inzwischen. Aber nicht automatisch... also ich arbeite mit 5.1.5-3 und habe keine Backward-Annotation. grübel
Ich fand bis jetzt den Vergleich zwischen KiCAD und Eagle bei den Projekten die ich importiert hatte recht Aufschlussreich. Da kamen nicht nur Unterschiede zwischen den Beiden zum Vorschein. Bei einem Projekt sagt KiCAD "Board outline does not form a closed polygon", hat Eagle und zum guten Glück die Hersteller nie gestört :-).
Peter S. schrieb: > Bei einem Projekt > sagt KiCAD "Board outline does not form a closed polygon", Wenn Du bei der vorletzten Ecke einen Doppelklick machst, stellt sich das Problem erst gar nicht. Dann vervollständigt KiCad das Polygon nämlich selbst.
Beitrag #6145953 wurde von einem Moderator gelöscht.
Beitrag #6145962 wurde von einem Moderator gelöscht.
Rene K. schrieb: > Volker S. schrieb: >> Auch die oft kritisierte fehlende Backward-Annotation gibt es >> inzwischen. > > Aber nicht automatisch... also ich arbeite mit 5.1.5-3 und habe keine > Backward-Annotation. *grübel* Der Grund ist einfach: Das ist erst vor kurzem in die Entwicklungsversion integriert worden.
:
Bearbeitet durch User
Andreas B. schrieb im Beitrag #6145902: > In Eagle muß auf diesem Grunde jedes Gehäuse mehrfach in den > Bibliotheken vorhanden sein, nämlich bei jedem Bauelement welches in > diesem Gehäuse erhältlich ist. Das ist Unsinn. Siehe z.B. die Libs für Standardlogik. Da kommt z.B. DIL-14 oder DIL-18 natürlich NICHT einige Dutzend mal vor, sondern genau einmal. Aber ja, pro Lib muss das Gehäuse einmal vorhanden sein, das hätte man mit hierarchischer Lib-Nutzung schöner machen können. Das betrifft allerdings Symbole genauso. Und genau deswegen ist die KiCAD-Lösung letztlich genauso Scheiße wie die Eagle-Lösung. Beides nicht wirklich konsequent bis zum Ende durchdacht... Aber leider: bei der eigentlich idealen Hierarchie stellt sich natürlich sofort wieder ein anderes Problem: das der referentiellen Integrität... Eine unbedachte Änderung könnte eine Vielzahl von Bibliotheken auf einmal unbrauchbar machen...
c-hater schrieb: > Eine unbedachte Änderung könnte eine Vielzahl von Bibliotheken auf > einmal unbrauchbar machen... Deswegen habe ich mir angewöhnt, sowohl bei Eagle als auch bei KiCAD nur noch Projektbezogene Bibliotheken zu nutzen. Denn dieses Problem haben beide.
Peter S. schrieb: > Da kann man sich streiten. Ich fand das in Eagle oft praktisch, > auswählen und alles ist unter einem Dach (Symbol und Footprint) und > manchmal habe ich mir gewünscht es wäre nachträglich möglich das Gehäuse > zu ändern, vor allem bei SMD kommt das doch immer wieder vor. Deswegen ist das bei Eagle auch kein Problem, das zu tun. Jedenfalls dann nicht, wenn die gewünschte Gehäusevariante für das Bauteil existiert. Und falls das nicht der Fall ist, dann erzeugt man sie halt einfach...
c-hater schrieb: > Das ist Unsinn. Siehe z.B. die Libs für Standardlogik. Da kommt z.B. > DIL-14 oder DIL-18 natürlich NICHT einige Dutzend mal vor, sondern > genau einmal. Stimmt, aber trotzdem sind fast alle footprints mehrfach in den libs vorhanden. c-hater schrieb: > Das betrifft allerdings Symbole genauso. Und genau deswegen ist die > KiCAD-Lösung letztlich genauso Scheiße wie die Eagle-Lösung. Beides > nicht wirklich konsequent bis zum Ende durchdacht... Ja, hier wäre eine einheitliche lib für die Schaltzeichen auch sinnvoll. > Eine unbedachte Änderung könnte eine Vielzahl von Bibliotheken auf > einmal unbrauchbar machen... tja, alles kann man nicht haben.
Beitrag #6146001 wurde von einem Moderator gelöscht.
Rene K. schrieb: > Deswegen habe ich mir angewöhnt, sowohl bei Eagle als auch bei KiCAD nur > noch Projektbezogene Bibliotheken zu nutzen. Denn dieses Problem haben > beide. Wenn ich das richtig verstanden habe, dann macht KiCad doch Kopien der verwendeten Symbole und Footprints in das Projektverzeichnis.
Andreas B. schrieb: > Wenn ich das richtig verstanden habe, dann macht KiCad doch Kopien der > verwendeten Symbole und Footprints in das Projektverzeichnis. Jain... Wie ich das verstanden habe, gibt es dann da diese Cache Datei. Aber ich glaube ändern tut sich das auch in der Hauptbliothek, soweit man sie lokal nutzt (also nicht die von Github) aber bei PCBnew kann man mit einem Mausklick alle Footprints in die eigene Bibliothek übernehmen. So mach ich das, dann ändere ich sie, je nach Gedünken.
Rene K. schrieb: > So mach ich das, dann ändere ich sie, je nach Gedünken. Ok, wenn Du die libs änderst, ist das klar. Das habe ich überlesen.
Hallo, Andreas B. schrieb: > Die wirst Du im Bereich Platinenlayout nicht finden. Das sehe ich anders, das Ganze ist immer eine Frage der Ansprüche und Erfordernisse. Bei Diskussionen hier im Forum treffen immer wieder (Semi)Profis auf Hobbyisten wie z.B. mich. Natürlich haben Profis eine andere Vorstellung davon was z.B. ein Platinenlayoutprogramm können muss als ein Hobby-Layouter. Wer nur selten ein Layout erstellt (das dann vielleicht auch nicht besonders komplex ist), der kommt unter Umständen auch mit Programmen wie Sprint-Layout aus. Die grundsätzliche Bedienung ist hier so intuitiv, das man den Großteil davon innerhalb einer 1/2 Stunde verstanden hat. KiCad spielt dann zwar in einer ganz anderen Liga, aber der (Zeit)Aufwand der Einarbeitung in ein solches komplexes Werkzeug sollte eben auch bedacht werden. Da muss man sich dann die Frage stellen ob sich das lohnt. rhf
Angehängte Dateien:
-
Kicad.png
19 KB
c-hater schrieb: > Aber ja, pro Lib muss das Gehäuse einmal vorhanden sein, das hätte man > mit hierarchischer Lib-Nutzung schöner machen können. Ja, hätte man, aber das wäre ein elender Fehler gewesen. Grund: man hätte eine Abhängigkeit erzeugt, die das Weitergeben von Bibliotheken wesentlich erschwert oder Fehler erzeugt hätte. So wie es ist, ist sowohl eine Eagle-Bibliothek als auch ein Eagle-Projekt in sich autark. Man kann das hernehmen und auf einem anderen PC benutzen, OHNE daß da irgendwelche hierarchischen Konditionen beachtet werden müssen. Das ist viel wichtiger, als mit hierarchischem Bibliotheksaufbau ein paar Byte zu sparen. > Das betrifft allerdings Symbole genauso. Und genau deswegen ist die > KiCAD-Lösung letztlich genauso Scheiße wie die Eagle-Lösung. Beides > nicht wirklich konsequent bis zum Ende durchdacht... Nee, sehe ich ganz anders. Das was man tatsächlich verbauen kann, sind Bauteile und keine Symbole und auch keine Footprints. Das absolute Primat haben deshalb die Bauteile. Die sind es, die im Schematic durch Symbole und im Layout durch Footprints repräsentiert werden sollen. Und man tut deshalb gut daran, sich beim Ausdenken einer Schaltung schon ganz am Anfang Gedanken darüber zu machen, was für Bauteile man zu verwenden gedenkt. Solles also ein 7805 im SO8 sein oder ein TO220 Klopper mit Kühlkörper? So etwas weiß man doch, wenn man ein Gerät entwickeln will. Kurzum: Das BAUTEIL bestimmt den Footprint und das/die Symbole - und nicht umgekehrt. Deshalb ist die Eagle-Lösung gut, sauber, sicher und handlich - und die Kicad-Lösung ist schlecht. Punkt. Und eben deshalb ist die Arbeits- und Denkweise von Andreas schlichtweg gedankenlos und chaotisch: Andreas B. schrieb: > Was ich bei KiCad weitaus besser finde, daß die Schaltzeichen und > Footprints streng getrennt sind. Ich konzentriere mich bei der > Schaltplanerstellung nur auf die reine Funktion und denke nicht über > irgendwelche Gehäusegrößen nach. Ja. Eben: Stromlaufplan malen, ohne sich Gedanken über dessen tatsächliche Realisierung zu machen. Dann kommt so etwas bei heraus wie im angehängten Bild. Zweimal eine tolles OpV-Symbol, obwohl eigentlich ein Doppel-OpV zum Einsatz kommen soll. Soll man sowas ein Qualitäts-Schematic nennen??? (Stammt aus dem Padauk-Programmer) Peter S. schrieb: > Wenn man das 10-Finger System beherrscht, und das > tue ich zum guten Glück, dann sind Tastenkürzel ein echter Turbo. Das gilt aber NUR dann, wenn man stets und ständig mit nur einem einzigen Programm arbeitet. Dann kann man sich das angewöhnen. Sonst jedoch nicht. Ich benutze ja nicht nur Eagle, sondern eben auch anderes Zeugs wie Mechanik-CAD - und ein jedes hat seine eigenen Sätze von Tastaturkürzeln. Wer da glaubt, sich alle Kürzel merken und mental einfach umschalten zu können von einem Programm zum anderen, der ist entweder ein Roboter oder hat ein dickes Brett vor dem Kopf. W.S.
Andreas B. schrieb: > Stimmt, aber trotzdem sind fast alle footprints mehrfach in den libs > vorhanden. Wen stört so etwas heutzutage? Derzeitige Festplatten sind ja nun wirklich groß genug. Sieh doch den Vorteil: die Integrität einer Bibliotheksdatei. Dieser Vorteil ist riesengroß. > Ja, hier wäre eine einheitliche lib für die Schaltzeichen auch sinnvoll. Was? Eine Einheits-Bibliothek für die Symbole? Auf so eine Idee kann man wohl nur kommen, wenn man völlig außer Acht läßt, was es auf der Welt für eine ungeheure Vielzahl von Bauteilen gibt. W.S.
W.S. schrieb: > Ja. Eben: Stromlaufplan malen, ohne sich Gedanken über dessen > tatsächliche Realisierung zu machen. Das hast Du was falsch verstanden. Ich mache mir keine Gedanken über den Footprint. Aber nicht derart ob es jetzt ein TO3 mit dicken Kühlkörper ist sondern ob es SMD Gehäuse a, b oder c ist. Beim Erstellen des Schaltplans geht es erst mal um die reine Funktion. Daß ich nicht 2 Ops nehme wenn ich eine Doppel OP haben kann ist klar. Doof bin ich auch nicht.
W.S. schrieb: > Wen stört so etwas heutzutage? Derzeitige Festplatten sind ja nun > wirklich groß genug. Sieh doch den Vorteil: die Integrität einer > Bibliotheksdatei. Dieser Vorteil ist riesengroß. Das Problem ist einfach darin, daß ich schon viele Fehler in Libs entdeckt habe. (Sowohl Eagle als auch KiCad). Habe ich nur einen globalen Footprint für das betreffende Gehäuse, dann brauche ich auch nur diesen zu ändern. > Eine Einheits-Bibliothek für die Symbole? Natürlich nicht für alle. Aber z.B bei Transistoren ist es nicht notwendig, daß für jeden Typ ein eigenes Symbol existiert. Gleiches für z.B. dreibeinige Spannungsregler ect.
:
Bearbeitet durch User
Peter S. schrieb: > Daher bin ich auf der Suche nach einer ausführlichen und guten Anleitung > die mir als Eagle Benutzer im "Detail" erklärt wie das dann jeweils auf > KiCAD funktioniert. Deutsch, Englisch, Web oder Buch ist egal. Zur Erinnerung ;-)
W.S. schrieb: > Zweimal eine tolles OpV-Symbol, obwohl eigentlich ein Doppel-OpV zum > Einsatz kommen soll. Ich verstehe gerade nicht was du damit sagen magst. Es ist doch ein Doppel-OpV eingezeichnet?! ?
Volker S. schrieb: > Peter S. schrieb: >> Daher bin ich auf der Suche nach einer ausführlichen und guten Anleitung >> die mir als Eagle Benutzer im "Detail" erklärt wie das dann jeweils auf >> KiCAD funktioniert. Deutsch, Englisch, Web oder Buch ist egal. > > Zur Erinnerung ;-) Ein Nachschlagewerk mit praktischen Beispielen habe ich mir vorgestellt. Eben das erwähnte Buch.
W.S. schrieb: >> Aber ja, pro Lib muss das Gehäuse einmal vorhanden sein, das hätte man >> mit hierarchischer Lib-Nutzung schöner machen können. > > Ja, hätte man, aber das wäre ein elender Fehler gewesen. > Grund: man hätte eine Abhängigkeit erzeugt, die das Weitergeben von > Bibliotheken wesentlich erschwert oder Fehler erzeugt hätte. Das könnte man mit einer Export Funktion welche Abhängigkeiten auflöst einfach lösen. Es wäre nicht das erste Program das so etwas kann.
Angehängte Dateien:
-
Kicad-Footprints.jpg
20 KB
Andreas B. schrieb: > Das hast Du was falsch verstanden. Ich mache mir keine Gedanken über den > Footprint. Aber nicht derart ob es jetzt ein TO3 mit dicken Kühlkörper > ist sondern ob es SMD Gehäuse a, b oder c ist. Eine derartige Arbeitsweise geht mir zu 100% gegen den Strich. Man muß doch zu allererst wissen was man machen will. > Beim Erstellen des Schaltplans geht es erst mal um die reine Funktion. Eine reine Funktion gibt es bei Leiterplatten nicht. Schlußendlich soll ja eine Leiterplatte mit realen BE daraus werden. Reine Funktionen wie AND, OR, NOT, JK-FF und so gibt es nur bei CPLD- und FPGA-Entwürfen. Weil es eben reine logische Funktionen sind, die anschließend irgend ein Logik-Compiler in irgend etwas für ein Stück Silizium umsetzt. ES SIND KEINE BAUTEILE. > Daß ich nicht 2 Ops nehme wenn ich eine Doppel OP haben kann ist klar. > Doof bin ich auch nicht. Das glaube ich dir - aber ich sehe das komplette Gegenteil bei eevblog. Ich kann ja sogar verstehen, daß jemand mit Kicad sowas macht: Da darf man nachlesen, daß man den Stromlaufplan mit Symbolen macht und anschließend selbigen Footprints zuweisen muß. Wenn also jemand kein OpV-Symbol ohne Rails findet, dann nimmt er eben eines mit Rails und weist dann die 3 Nodes irgendwelchen Footprint-Pads zu. Geht - ist aber übelste Steinzeit. Andreas B. schrieb: > Das Problem ist einfach darin, daß ich schon viele Fehler in Libs > entdeckt habe. (Sowohl Eagle als auch KiCad). Habe ich nur einen > globalen Footprint für das betreffende Gehäuse, dann brauche ich auch > nur diesen zu ändern. Das ist auch wieder völlig falsch gedacht. Was kann denn an einem Footprint falsch sein? Antwort: die Geometrie. Also wenn das Pad woanders liegt als es soll oder wenn es nicht paßt. Siehe Bild: Die Footprints für die Widerstände sind lausig und der für den Doppel-OpV ebenso. _ABER_: Die Fehler, die du vermeiden willst, sind ja zumeist gar nicht in der Geometrie begründet, sondern in der Zuordnung. Also A mit K vertauscht bei einer Z-Diode und dergleichen. Genau DAS sind die eigentlichen Spielverderber beim LP machen. Wenn du also endlich einen richtigen Footprint hast, dann ist die Wahrscheinlichkeit, beim Zuordnen einen mindestens genauso deftigen Schnitzer zu machen, mindestens genauso groß. Und: ein geometrisch verkehrtes Pad erkennt man durch Draufglotzen beim Layouten zumeist von selbst - eine falsche Zuordnung hingegen nicht. Fazit: Die Eagle-Version, alles Zusammengehörige in einer Datei zu haben und damit sowohl Symbol als auch Footprint als auch Zuordnung festgeschrieben zu haben, ist nach wie vor die allerbeste. Man hat es alles zusammen und wenn sich die Lib erstmal bewährt hat, dann jahrzehntelang damit Ruhe. Ich sehe aber auch ein, daß all die Leute, die für jeden Furz nach einer fertigen Lib zum Herunterladen nachfragen (also die berüchtigte Copy&Paste-Generation) sich mit dem Verwenden von ungeprüften Libs gern selber ein Ei legen. W.S. P.S. Rene K. schrieb: > Ich verstehe gerade nicht was du damit sagen magst. Es ist doch ein > Doppel-OpV eingezeichnet?! Brille verlegt? Es sind 2 Einzel-OpV's gezeichnet und bei einem hängen die Rails in der Luft. Wie man sowa durch den ERC kriegt, ist mir schleierhaft. Peter S. schrieb: > Das könnte man mit einer Export Funktion welche Abhängigkeiten auflöst > einfach lösen. Es wäre nicht das erste Program das so etwas kann. Na klar. Noch eine Exportfunktion dazu. Warum einfach nur die Lib oder SCH+BRD auf den Stick (wäre ja zu einfach), wenn es auch komplizierter geht? Und wie soll dann das Importieren gehen, wenn dort die Abhängigkeiten nicht aufgelöst werden können, weil dort irgend etwas anders ist?
W.S. schrieb: > Brille verlegt? Es sind 2 Einzel-OpV's gezeichnet und bei einem hängen > die Rails in der Luft. Wie man sowa durch den ERC kriegt, ist mir > schleierhaft. Die hängen doch nicht in der Luft, die sind doch in 3.1 verbunden?! Deswegen wäre es ein fatales wenn der ERC das überhaupt an meckern sollte. Ich finde, der übersichtlichkeit diese Lösung definitiv besser. Somal es dort sehr leicht ersichtlich ist das es sich um ein Doppel-OpV handelt. Gut, man hätte die Rails eventuell in einem Symbol weglassen können, oder eben ein separates Symbol für die Rails.
Rene K. schrieb: > W.S. schrieb: >> Brille verlegt? Es sind 2 Einzel-OpV's gezeichnet und bei einem hängen >> die Rails in der Luft. Wie man sowa durch den ERC kriegt, ist mir >> schleierhaft. > > Die hängen doch nicht in der Luft, die sind doch in 3.1 verbunden?! > Deswegen wäre es ein fatales wenn der ERC das überhaupt an meckern > sollte. Ich finde, der übersichtlichkeit diese Lösung definitiv besser. > Somal es dort sehr leicht ersichtlich ist das es sich um ein Doppel-OpV > handelt. Gut, man hätte die Rails eventuell in einem Symbol weglassen > können, oder eben ein separates Symbol für die Rails. Wenn ich einen DualOpAmp in ein KiCad-Schema aufnehme, dann hat der immer 3 Teile: 2 OpAmps und 1 Versorgungsspannungsblock. Wenn man unbedingt "lustige" Symbole verwenden will, dann sollte man sich nicht darüber aufregen, daß sie das dann auch sind.
Dem kann ich mich nur anschließen. Die unsichtbaren Stromversorgungen an OPVs waren einer meiner Hauptkritikpunkte an Eagle - was bitte soll man denn machen wenn die Batterie an Dual-OPVs nicht eine gemeinsame Versorgung haben, sondern z.B. Entkopplungsfilter vor jedem chip? Alternativ finde ich die Lösung von PADS, wo die Stromanschlüsse als ein weiteres Segment dargestellt werden, sehr sinnvoll.
:
Bearbeitet durch User
W.S. schrieb: > Fazit: Die Eagle-Version, alles Zusammengehörige in einer Datei zu haben > und damit sowohl Symbol als auch Footprint als auch Zuordnung > festgeschrieben zu haben, ist nach wie vor die allerbeste Nein. Schliesslich kann es sein, dass der Fertiger noch kommt und meckert und die Footprints IPC konform haben will. Und dann durch alle Libs gehen und die Symbole austauschen, da wird man ja kirre. Besser 1 mal den PADstack anpassen, und schwupps updated es sich in alle Footprints und Bauteile. Aber ich bin ein grosser Freund davon, wenn dieses updaten nicht automatisch passiert, sondern nicht nur jede Lib, sondern jede Boarddatei alles enthält wie es zum Zeitpunkt der Erstellung in den Libs war, dupliziert, mit Quellverweis. Wegschicken der Datei alleine also dem Empfänger auch alle Librarysymbole editierbar mitliefert.
MaWin schrieb: > Nein. > Schliesslich kann es sein, dass der Fertiger noch kommt und meckert und > die Footprints IPC konform haben will. Ach wo. Der Fertiger hat seinen Satz von Eckdaten und minimalen Strukturgrößen und er regt sich nicht darüber auf, ob das BE drauf paßt oder nicht. Wenn sowas überhaupt nötig wäre, dann bespricht man das mit dem Bestücker. Das Einzige, was bleibt, sind ggf. die Pastenmasken, die der Bestücker grad haben will. Aber das ist ein anderes Thema, was du nicht durch Padstacks erledigen kannst. W.S.
Mark S. schrieb: > Dem kann ich mich nur anschließen. Die unsichtbaren Stromversorgungen an > OPVs waren einer meiner Hauptkritikpunkte an Eagle - was bitte soll man > denn machen wenn die Batterie an Dual-OPVs nicht eine gemeinsame > Versorgung haben, sondern z.B. Entkopplungsfilter vor jedem chip? Du schreibst wirr. Wirklich. Wenn die Versorgungspins eines Bauteils exakt einem vorgegebenen Rail entspricht (hauptsächlich bei TTL/Cmos-Standardlogik), dann schließt Eagle das automatisch an - vorausgesetzt, du willst das nicht anders. Du kannst in jedem Falle die Versorgung mit invoke dir hereinholen und nach deinem Gutdünken verdrahten. Zum Beispiel mit einem Filter davor. Und an Dual-OpV's hat man gewöhnlich nur einen Satz an V+ und V- Pins, mit denen beide OpV's versorgt werden. Die kann man anschließen wie man will. Ich hab den Eindruck, daß du Eagle noch nicht wirklich kennst. W.S.
Peter S. schrieb: > Ein Nachschlagewerk mit praktischen Beispielen habe ich mir vorgestellt. Schön wär's ;-) Bekommen hast du das übliche Eagle vs. KiCad Gewäsch, nachdem nicht gefragt war.8
Volker S. schrieb: > Peter S. schrieb: >> Ein Nachschlagewerk mit praktischen Beispielen habe ich mir vorgestellt. > > Schön wär's ;-) Bekommen hast du das übliche Eagle vs. KiCad Gewäsch, > nachdem nicht gefragt war.8 Lesen bildet: In den ersten Antworten wurde bereits auf die KiCad Hilfe verwiesen, die im übrigen sehr ausführlich ist und auch als PDF heruntergeladen werden kann. Aber es stimmt schon: Die Diskussion gleitet wieder in den üblichen Eagle/KiCad Krieg ab.
Hallo Peter s. Peter S. schrieb: > Daher bin ich auf der Suche nach einer ausführlichen und guten Anleitung > die mir als Eagle Benutzer im "Detail" erklärt wie das dann jeweils auf > KiCAD funktioniert. Deutsch, Englisch, Web oder Buch ist egal. Erst einmal nicht in Panik geraten. Du hast Erfahrung mit Eagle und Leiterplatten Design überhaupt. Und damit hast Du das wesentliche. Jemandem, der mit einem Leiterplattenprogramm umgehen kann, werden vermutlich zwei Drittel eines anderen Layoutprogrammes irgendwie bekannt vorkommen. Der Grund ist der, dass es dabei um Leiterplatten, ihre Eigenschaften und Herstellung geht. Dieses ist aber als Kontext, aus dem sich dann vieles ergibt, bei allen gleich. Unterschiede gibt es darum nur in Details der Handhabung. Ich persönlich empfand den Unterschied Eagle zu KiCad als nicht so gravierend. Genau wie Eagle gliedert sich KiCad in zwei Hauptbereiche: Einen Schaltplaneditor (EEschema) und ein Platinenlayout Programm (PCBnew). Du erstellst zuerst einen Schaltplan, und machst dann daraus ein Layout. Zum Übergang erstellst Du eine Netzliste im Schaltplaneditor EEschema, die Du dann in das Layoutprogramm PCBnew importierst. Footprints sind den einzelnen Schaltplansymbolen schon zugeordnet, oder wenn nicht oder Du die Ändern möchtest, musst Du das in einem separaten Zwischenschritt erledigen. Diese Vorgehensweise fand ich, als ich so 2009 auf KiCad gestossen bin, wesentlich einleuchtender und komfortabel als die Eagle Vorgehensweise, die ich ca. 20 Jahre schon kannte, und die nach meiner Ansicht bei generischen Bauteilen lediglich die Bibliothek aufbläht. Zugegeben, Leute, die zuerst ein Layout machen, und dann erst den Schaltplan, sind vermutlich bei Eagle besser aufgehoben. Hinweise auf Doku und Tutorials aus dem KiCad Projekt wurden ja oben schon reichlich genannt. Damit und mit selber Überlegen kommst Du schon recht weit. Ansonnsten stelle halt Deine Fragen hier im Forum mit [KiCad] im Betreff, oder schau hier nach: https://www.mikrocontroller.net/articles/KiCad Desweiteren ist es möglicherweise ein Augenöffner, sich KiCad Projektordner und Bibliotheksordner einmal näher anzusehen, und sich auch einige der Files mit einem Texteditor anzusehen, um ein Gefühl dafür zu bekommen, wie das ganze funktioniert und was für grundsätzliche Möglichkeiten bestehen. So gut wie alles ist klarschriftlesbar, OpenSource versucht im allgemeinen nicht , dem Anwender etwas zu verheimlichen oder zu verbergen. Die GUI ist lediglich dazu da, die Benutzung komfortabel und einfach zu machen. KiCad lässt sich auch über Tastaturbefehle steuern. Diese sind in den Pulldown Menues hinter den Befehlen erwähnt, und im Pulldown Menue "Einstellungen" > Tastaturbefehle aufgelistet und editierbar bzw. auch importierbar und exportierbar. Falls mal dabei eine Kommandoeingabe sinnvoll ist, poppt eine Eingabezeile auf. z.B. in PCBnew, wenn Du Footprints plazieren willst, drückst Du "t". Es poppt ein Fenster auf, in dem nach dem Referenzbezeichner des Bauteils gefragt wird. Den gibst Du ein, drückst <Enter> und der Footprint des Bauteiles hängt am Mauszeiger. Das entspricht somit dem "m" in der Kommandozeile bei Eagle. KiCad ist seit dem ich es seit 2009 kenne, mehrmals umgebaut und modernisiert worden. Darum solltest Du immer auch etwas auf das Datum schauen, wenn Du hier im Forum etwas gefunden hast. Aber keine Sorge, das meiste geht auch nach Umbau "so ähnlich" auch weiter. Manchmal musst Du z.B. etwas suchen, weil Befehle in einen anderen Button im Pulldown Menü gelandet sind. Für Verwirrung bei Neueinsteigern sorgte oft das Vorhandensein verschiedener Canvasse mit Unterschiedlichem Verhalten. Aber bei den neueren Versionen gibt es nur noch einen und seinen Fallback für Rechner, auf denen OpenGL nicht unterstützt wird (wie mein Netbook z.B.) Oder das man für spezielle Aufgaben PCBnew als "standallone" ausführen kann. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Hallo Bernd, Danke für deine Ausführungen. Ich denke das deckt so ziemlich alle Fragen die ich bezüglich einem Umstieg hatte. Und es geht genau wie du sagst um Leiterplatten einfach mit 2 Programmen erstellt aber das Resultat ist (oder sollte sein) dasselbe. Gruss Peter
Falles es jemand interessiert: Umsteigen von Eagle auf KiCAD dauert etwa eine Woche, mindestens für das wichtigste, man muss sich aber eine Woche Zeit nehmen, ich bin im Moment soweit, dass der komplizierteste Teil, eine eigenes Card-Edge Symbol mit dazugehörigem Footprint mit Konturen und Cuts, fertig ist. Für ein paar alte Bauteile muss ich noch eigene Symbole kreieren aber der Aufwand hält sich in Grenzen, für diese muss ich keine neuen Footprints erstellen. Und das Hühnerfutter gibt es ja schon alles in den Libraries. Das oben erwähnte Buch ist recht hilfreich, aber wie erwähnt, man hätte es nochmals durchlesen sollen bevor man es in Druck gegeben hatte. Es hat doch ziemlich viele Übersetzungsfehler. Wer English kann sollte lieber die PDF Version auf der original Homepage bestellen, dann hat man auch Zugriff auf weitere Kapitel und kann im Forum teilnehmen. Am Anfang wünscht man sich zwar immer wieder die Funktionen und die Bedienung von Eagle, aber mit der Zeit findet man auch Funktionen die man in Eagle immer vermisst hat. Perfekt ist keines. Das ist beruhigend. Man kann die beiden Programme nicht eins-zu-eins miteinander vergleichen. Es gibt Dinge die sind in Eagle definitiv besser gelöst und andere die gefallen mir in KiCAD besser. Zum Teil sind es komplett andere Ansätze. Man muss sich wirklich umgewöhnen. Das ist immer mit "sich ärgern" verbunden. Ich vergleiche hier Eagle 7.5 (die letzte Version ohne Onlinefesseln) mit KiCAD 5.1.5. D.h. Funktionen die ich nun in KiCAD schätze und in Eagle 7.5 nicht vorhanden sind sind u.U. in der aktuellen Eagle Version auch verfügbar.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.