Hallo zusammen, weiß nicht genau, ob das hier eine Frage ist, oder eine Meinung oder dass ich einfache meinen Ärger loswerden will :-) Ich benutze sehr gerne Eagle, das Programm ist mittlerweile wirklich brauchbar geworden. Absolute Schwachstelle, meiner Meinung nach ist die Bibliotheksverwaltung. Ich benötige super viel Zeit um ein Bauteil wiederzufinden. Und noch mehr Zeit, um eigene Bauteile zu erstellen. Das was hier wirklich fehlt ist eine Favoritenliste. Wie macht ihr das denn? klar man kann ich alles was man braucht in eine eigene Lib zusammenkopieren, das ist aber super unpraktisch? Wie geht ihr denn beim Erstellen neuer Bauteile vor? Im Handbuch wird empfohlen alles in eine eigene Lib zu packen. Dann ist aber alles durcheinander. z.B. ist die Vielfalt an Dioden im Eagle sehr knapp gehalten: eine 1N4148 finde ich in diode.lbr, eine 1N4001 suche ich vergebens, sie liegt also in meiner eigenen lib - das ist doch n kack... dann fehlen natürlich auch noch etliche packages.... will ich ein neues Bauteil anlegen, dann kopiere ich es erstmal aus einer anderen lib in meine eigene, da ist es dann auch noch drin.... das ist doch doof ist die eagle-lib quelloffen? vielleicht kann man sich ja irgendein separates program überlegen, um sich seine eigenen sammlungen an devices symbols und packages zusammenzuführen, ich finde die Funktionalität von Eagle ist hier wirklich schwach und umständlich Schorsch
:
Verschoben durch User
Georg T. schrieb: > Ich benutze sehr gerne Eagle, das Programm ist mittlerweile wirklich > brauchbar geworden. Absolute Schwachstelle, meiner Meinung nach ist die > Bibliotheksverwaltung. Ich benötige super viel Zeit um ein Bauteil > wiederzufinden. Und noch mehr Zeit, um eigene Bauteile zu erstellen. Das > was hier wirklich fehlt ist eine Favoritenliste. Ich habe im Kopf, in welchen Libs meine Bauteile liegen. Ansonsten musst du die Suche nutzen.
1 | *1n400* |
wirft dir alles aus, was 1n400 enthaelt, also auch die 1n4004. Du kannst auch mit mehreren Begriffen arbeiten.
1 | *mega* *usb* |
findet alles, was mega und usb enthaelt, also zB AVRs mit USB. Manchmal muss man etwas probieren, also mit
1 | *mcp4* |
anfangen und sehen, welche Devices es gibt, oder umgekehrt die Suche immer unspezifischer machen, bis man was findet. > Wie geht ihr denn beim Erstellen neuer Bauteile vor? Im Handbuch wird > empfohlen alles in eine eigene Lib zu packen. Dann ist aber alles > durcheinander. z.B. ist die Vielfalt an Dioden im Eagle sehr knapp > gehalten: eine 1N4148 finde ich in diode.lbr, eine 1N4001 suche ich > vergebens, sie liegt also in meiner eigenen lib - das ist doch n kack... > dann fehlen natürlich auch noch etliche packages.... will ich ein neues > Bauteil anlegen, dann kopiere ich es erstmal aus einer anderen lib in > meine eigene, da ist es dann auch noch drin.... das ist doch doof Ich habe eine Lib mit allen eigenen Designs, da weiss ich sowieso was drin ist.
:
Bearbeitet durch User
Georg T. schrieb: > Wie macht ihr das denn? klar man kann ich alles was man braucht in eine > eigene Lib zusammenkopieren, das ist aber super unpraktisch? Hab ich noch nie genutzt, aber geht das nicht per drag and drop? > Wie macht ihr das denn? klar man kann ich alles was man braucht in eine > eigene Lib zusammenkopieren, das ist aber super unpraktisch? Die eagle Lib Erstellung und Verwaltung ist meiner bescheidenen Meinung nach schlicht Mist. Das Nutze ich so gut wie gar nicht sondern mache mir für jedes Bauteil eine eigene lib. Die gruppiere ich dann in Verzeichnisse. Das Verzeichnis ist somit meine Lib. Ist meiner Meinung nach einfacher zu handhaben als die sperrigen Libs. Man schleppt dann nicht ständig 50 Versionen der Libs mit sich rum nur weil ein Bauteil geändert wurde. Apropos Versionen. Seitdem eagle auf xml umgestellt hat ist das arbeiten mit einem Version Control System ein Traum. Richtig genutzt siehst wirklich jede noch so kleine Änderung.
@ Georg T. (microschorsch) >brauchbar geworden. Absolute Schwachstelle, meiner Meinung nach ist die >Bibliotheksverwaltung. Stimmt teilweise. > Ich benötige super viel Zeit um ein Bauteil >wiederzufinden. Warum? Schlechtes Gedächtnis? > Und noch mehr Zeit, um eigene Bauteile zu erstellen. Üben. > Das >was hier wirklich fehlt ist eine Favoritenliste. Mag sein. >Wie macht ihr das denn? Nicht jammern. https://www.mikrocontroller.net/articles/Eagle_FAQ#Die_wichtigsten_Bibliotheken_f.C3.BCr_den_Einstieg >Wie geht ihr denn beim Erstellen neuer Bauteile vor? Im Handbuch wird >empfohlen alles in eine eigene Lib zu packen. Ja. > Dann ist aber alles >durcheinander. z.B. ist die Vielfalt an Dioden im Eagle sehr knapp >gehalten: eine 1N4148 finde ich in diode.lbr, eine 1N4001 suche ich >vergebens, Eine 4004 ist identisch vom Gehäuse und auch in der Lib Diode. > sie liegt also in meiner eigenen lib - das ist doch n kack... >dann fehlen natürlich auch noch etliche packages.... Dafür gibt es libs, in denn SEHR viele Packages drin sind, wenn gleich nicht alle. > will ich ein neues >Bauteil anlegen, dann kopiere ich es erstmal aus einer anderen lib in >meine eigene, da ist es dann auch noch drin.... das ist doch doof Warum? Man kopiert soviel wie möglich, sei es das Symbol oder Gehäuse. >ist die eagle-lib quelloffen? vielleicht kann man sich ja irgendein >separates program überlegen, um sich seine eigenen sammlungen an devices >symbols und packages zusammenzuführen, ich finde die Funktionalität von >Eagle ist hier wirklich schwach und umständlich Jammer nicht rum, Tausende andere kommen auch damit klar, auch wenn Eagle da nicht optimal ist.
@X4U (Gast) >Die eagle Lib Erstellung und Verwaltung ist meiner bescheidenen Meinung >nach schlicht Mist. Suboptimal. > Das Nutze ich so gut wie gar nicht sondern mache mir >für jedes Bauteil eine eigene lib. DAS nenn ich mal Mist! > Die gruppiere ich dann in >Verzeichnisse. Das Verzeichnis ist somit meine Lib. Nicht sinnvoll. Auch in Eagle kann man das besser strukturieren. Sei es durch den Namen der Libs als auch in den Libs, wenn man von einem Bauteiltyp (z.B. Z-Diode) verschiedene Versionen anlegt, die sind dann in einer Art Ordner zusammengefaßt. >Ist meiner Meinung nach einfacher zu handhaben als die sperrigen Libs. Klingt nicht überzeugend. >Man schleppt dann nicht ständig 50 Versionen der Libs mit sich rum nur >weil ein Bauteil geändert wurde. Hat man so oder so nicht. >Apropos Versionen. Seitdem eagle auf xml umgestellt hat ist das arbeiten >mit einem Version Control System ein Traum. Richtig genutzt siehst >wirklich jede noch so kleine Änderung. Dafür ist Eagle an einigen Stellen deutlich langsamer geworden, z.b. wenn man das erste Mal ADD macht. Da dauert das Scanner der Libs gut 1 Minute und mehr. Früher mit den binär gespeicherten Libs waren das ein paar Sekunden.
Falk B. schrieb: >>Die eagle Lib Erstellung und Verwaltung ist meiner bescheidenen Meinung >>nach schlicht Mist. > > Suboptimal. Ok, nenn es wie du willst > >> Das Nutze ich so gut wie gar nicht sondern mache mir >>für jedes Bauteil eine eigene lib. > > DAS nenn ich mal Mist! Hab ich auch erst gedacht, finde ich aber mittlerweile einfacher zu handhaben. Das ist aber ein Vorschlag und sicher nicht das nonplusultra. >>Die gruppiere ich dann in >>Verzeichnisse. Das Verzeichnis ist somit meine Lib. > > Nicht sinnvoll. Auch in Eagle kann man das besser strukturieren. Sei es > durch den Namen der Libs als auch in den Libs, wenn man von einem > Bauteiltyp (z.B. Z-Diode) verschiedene Versionen anlegt, die sind dann > in einer Art Ordner zusammengefaßt. > Das mache ich dann teilweise auch n einer lib. Aber es kommt sowieso so gut wie nie vor das ich das dann wieder verwenden kann. >>Ist meiner Meinung nach einfacher zu handhaben als die sperrigen Libs. > > Klingt nicht überzeugend. Probiere es mal aus. Hinzufügen muss ich aber noch das ich unter Windows mit dem Total Commander arbeite. Da ist ein z.B. eine Textsuche über alle Libs in Sekunden erledigt. >Man schleppt dann nicht ständig 50 Versionen der Libs mit sich rum nur >>weil ein Bauteil geändert wurde. > > Hat man so oder so nicht. Das ist bei mir nicht der Fall, wird bei dir aber anders sein. Es gibt hier ständig Änderungen, projekt- und fertigungsbezogene Sonderfälle usw. > >>Apropos Versionen. Seitdem eagle auf xml umgestellt hat ist das arbeiten >>mit einem Version Control System ein Traum. Richtig genutzt siehst >>wirklich jede noch so kleine Änderung. > > Dafür ist Eagle an einigen Stellen deutlich langsamer geworden, z.b. > wenn man das erste Mal ADD macht. Da dauert das Scanner der Libs gut 1 > Minute und mehr. Früher mit den binär gespeicherten Libs waren das ein > paar Sekunden. Use -* ist immer mein erster Befehl beim arbeiten ;-).
Probiere mal kicad aus. Bin unter anderem wegen der von dir genannten Probleme umgestiegen. Nach etwa einer Woche Einarbeitungszeit bin ich total zufrieren. Ich kann die Tuturials von Contextal electronics auf YouTube empfehlen. Jonas
Georg T. schrieb: > ist die eagle-lib quelloffen? Was meinst du mit quelloffen? Die Bibliotheken sind in XML abgelegt und damit frei lesbar.
Hi, ich fände es echt schön, wenn es ein online open-repository gäbe. Wenn ich à la "aptitude install" mir eine common use lib herunterladen könnte. Klar es gibt auch schon jetzt libs wie Sand am Meer, aber man weiß nicht wo sie liegen und man will ja auch nicht alles doppelt haben (früher hat man sich ja auch deb-files per google rausgesucht - das würde heute auch niemand mehr tun) Weiß niemand, ob die libs quelloffen sind? hat vielleicht jemand schon ein paar c++ libs geschrieben...? dann könnte man sich ganz hopps ein kleines Programmämmili zum besseren Verwalten seiner eagle-libs basteln? use -* ist schön und gut, schön wäre wenn "use 0603, 0805" gehen würde, leider fehlen filter völlig in dem Programm Schorsch
W.A. schrieb: > Georg T. schrieb: >> ist die eagle-lib quelloffen? > > Was meinst du mit quelloffen? > > Die Bibliotheken sind in XML abgelegt und damit frei lesbar. oh....tatsächlich.... das war mir nicht bewußt..... ...mh... vielleicht bastel ich die Tage mal ein bisschen... da kann man sich ja einfach mit ein bisschen awk und grep magic seine favoriten on the fly zusammenstellen.... Schorsch
Georg T. schrieb: > ich fände es echt schön, wenn es ein online open-repository gäbe. Wenn > ich à la "aptitude install" mir eine common use lib herunterladen > könnte. Leider hat jeder andere Anforderungen an libraries. Auch ist 0805 0603 ... nur die Bauteilgröße. Schon die Pads können ganz verschieden sein. Je nach Lötverfahren oder Stopmaske, Bestückungsdruck usw. Die Technik ist einfach sehr vielseitig. Schon bei diesen einfachen Bauteilen kommt meine Wenigkeit nicht drum herum eigene libs zu pflegen. Für einfache Hobbyaufgaben ist das egal, aber auch nur für einfache.
> Absolute Schwachstelle, meiner Meinung nach ist die > Bibliotheksverwaltung. Hm..ja... das hab ich schon vor 20Jahren gemerkt. :-) > Wie macht ihr das denn? Ich weiss einfach auswendig wo etwas liegt. Nach 20Jahren geht das. :-D Olaf
@ X4U (Gast) >Leider hat jeder andere Anforderungen an libraries. Auch ist 0805 0603 >... nur die Bauteilgröße. Schon die Pads können ganz verschieden sein. >Je nach Lötverfahren oder Stopmaske, Bestückungsdruck usw. Die Technik >ist einfach sehr vielseitig. Jain. >Schon bei diesen einfachen Bauteilen kommt meine Wenigkeit nicht drum >herum eigene libs zu pflegen. Tausdende andere müssen das nicht.
Olaf schrieb: > Ich weiss einfach auswendig wo etwas liegt. Nach 20Jahren geht das. :-D und ich finde nach 20 Jahren immer noch Fehler in den ausgelieferten LIBs. Das nervt doch, man sollte meinen die LIBs mit 20 Jahre alten Bauteilen sollten nun fehlerfrei sein.
David .. schrieb: > Ich habe eine Lib mit allen eigenen Designs, da weiss ich sowieso was > drin ist. Ich hab nicht nur eine eigene Lib sondern auch ein Schaltplan/Layout-Template erstellt.Bei jedem neuen Projekt benutze ich das Template und loesche einfach die Bauteile die ich nicht benoetige.Reicht fuer meine Beduerfnisse aus und ist sehr praktisch. Was die eigene Lib angeht: Laesst sich doch mit Eagle einfach realisieren.... Falk B. schrieb: > Dafür ist Eagle an einigen Stellen deutlich langsamer geworden, z.b. > wenn man das erste Mal ADD macht. Da dauert das Scanner der Libs gut 1 > Minute und mehr. Früher mit den binär gespeicherten Libs waren das ein > paar Sekunden. Ich selbst brauche nur wenige der Eagle Libs.Was ich nicht benoetige wird einfach nicht mit eingebunden.Dasselbe gilt fuer die freien Adafruit und Sparkfun-Libs.Zu 98% kommt sowieso alles aus meiner eigenen Lib. Kurzum - Scanningprobleme kenne ich nicht.
Ich glaube, ihr habt noch nicht verstanden, was mir vorschwebt... 1. wir schmeißen alle libs, die es so mit eagle mitgibt aus eagle mitgibt raus! (schock - keine Sorge wir benutzen sie ja noch) 2. wir legen uns neue eigene libs an, die uns einfach helfen unsere Bauteile wiederzufinden: z.B. mydiodes.lbr, mytransistors.lbr, myopams.lbr, myleds.lbr, ..... diese lbrs sind alle leer 3. wir schreiben uns ein program mit einer kleinen datenbank; in dieser Datenbank steht in meine mydiodes.lbr, gehört device, package und symbol aus library xy.lbr (eagle-original) und device, package und symbol aus xz.lbr usw. 4. mit Hilfe dieser Datenbank lassen sich die Standardbauteile aus den originallibs in unsere spezifischen automatisch umkopieren - man kann die Datenbank anpassen und die libs neu erzeugen, einmal die mydiode.lbr neu einlesen uns eagle kennt die neuerungen. natürlich kann man das genauso mit den eigenen libs machen..... Auf diese Weise kann man die Libs ein bisschen sortieren, natürlich kann man sich auch eine Favoritenlib anlegen dürfe eigentlich nicht schwierig sein schorsch
Wenn du das hinbekommst, wäre das super. Da ich eagle nur gelegentlich nutze, alle paar Monate mal, such ich auch oft.
Hier fuer die, die generell nichts finden. Scheint zu funktionieren.... Ich selbst benoetige keine spezielle Suchfunktion - komme mit Eagle auch so klar. http://sparkle.tribbeck.com/eaglesearch/
Toxic schrieb: > http://sparkle.tribbeck.com/eaglesearch/ kannte ich bisher nicht, aber such mal nach lp2980 ...nichts gefunden....und es war der erste mir gerade in den sinn kam Schorsch
Georg T. schrieb: > kannte ich bisher nicht, aber Ich auch nicht....deswegen auch meine Anmerkung "scheint zu funktionieren" Das Projekt ist offensichtlich noch in der Entwicklung.Dennoch hatte es meine Testeingaben bestanden und koennte Newbies vielleicht ne kleine Hilfe sein ============= Hatte eben auch unter Eagle selbst gesucht lp2980 Da wurde allerdings auch nichts gefunden...... Dabei stellte ich uebrigens auch gerade fest ,dass Eagle 7.5.0 zur Verfuegung steht...
Georg T. schrieb: > such mal nach lp2980 > > ...nichts gefunden....und es war der erste mir gerade in den sinn kam > > Schorsch Scheinbar ist das Anspruchsdenken hier recht groß. Man sollte doch mit etwas System vorgehen. Standard BE wie R,C, Transis .. findet man schnell. Danach kommen eigene Kreationen in der eigenen .lib. Speziellere BE findet man über die Suche. Wenn das nichts hilft, durchforstet man die von Usern hochgeladene .lib. Den Rest erstellt man selbst. Deinen lp2980 habe ich in 1min in so einer Userlib gefunden. Eine extra Datenbank brauch ich nicht, meine Datenbank ist in meinen Grauen Zellen hinterlegt.
michael_ schrieb: > Deinen lp2980 habe ich in 1min in so einer Userlib gefunden. ich in 59s ..... ;-)
Alsooooo. Zuerst sollte man natürlich die Suchfunktion im Eagle kennen und dass man mit
1 | *xyz* |
nach Fragmenten suchen kann. Jaja, die Suchfunktion ist suboptimal, denn sie sucht nicht in der Spalte Beschreibung. Verschiedene Libs sind schon voll OK, z.B. RLC, dort ist das alles sinnvoll nach Bauformen strukturiert, man findet sehr schnell was man braucht. Das Gleiche gilt auch für die Digital-IC Libs, die sind voll OK. Verbesserungsfähig ist z.B. diode.lbr. Dort braucht man eine bessere Struktur, etwa so Dioden Schottkydioden Z-Dioden Doppeldioden Suppressordioden ... Dort in den Einzelkategorien braucht man zu einem Gehäuse nur einen Standardtyp, Z.B. 1N4001 für alle Dioden in DO41 oder 1N4148 für DO35. Damit kann man die Libs auch sinnvoll verkleinern. Das Gleiche gilt für die Tansistorlibs, LED etc. Denn Eagle hat mit seinen Libs NICHT die Leistungsfähigkeit wie große CAD-Systeme, die in ihren Libs riesige Mengen an Bauteilen haben, die dann mit Bestellnummer etc. schon vollständig sind und vollautomatisch vollständige Stücklisten generieren können. Denn dazu müsste man unter dem generischen Typ Z.B. N-Kanal MOSFET in TO220 die diversen Typen als Subtyp auswählen, OHNE daß dabei die Libs riesig und unübersichtlich werden! Hier könnte Eagle in Zukunft noch zulegen. Allerding braucht man dann ggf. eine Schnittstelle zu SAP & Co.
:
Bearbeitet durch User
Toxic schrieb: > michael_ schrieb: >> Deinen lp2980 habe ich in 1min in so einer Userlib gefunden. > > ich in 59s ..... ;-) Mecker nicht rum mit deiner superneuesten Version. Auch in deiner Version findest du keine EL81 :-) Falk B. schrieb: > Dioden > Schottkydioden > Z-Dioden > Doppeldioden > Suppressordioden > ... Braucht man nicht, das weiß man doch vorher. Falk B. schrieb: > Dort in den Einzelkategorien braucht man zu einem Gehäuse nur einen > Standardtyp, Z.B. 1N4001 für alle Dioden in DO41 oder 1N4148 für DO35. > Damit kann man die Libs auch sinnvoll verkleinern. EAGLE funktioniert aber andersrum. Da ist zuerst das Symbol im Schaltplan. Eigentlich auch logisch. Erstmal z.Bsp. irgendeinen R holen und danach im Layout das Package festlegen. Die Typenbezeichnung ist auch erst mal egal. Die ändert man dann so wie man will.
@michael_ (Gast) >> Dioden >> Schottkydioden >> Z-Dioden >> Doppeldioden >> Suppressordioden >> ... >Braucht man nicht, das weiß man doch vorher. Doch, braucht man. >EAGLE funktioniert aber andersrum. Da ist zuerst das Symbol im >Schaltplan. Nö, da verwechselst du was. Das machen andere Programme so, vielleicht KiCAD, DipTrace? >Erstmal z.Bsp. irgendeinen R holen und danach im Layout das Package >festlegen. Nö, das ist im Schaltplan schon festgelegt, auch wenn man es nachträglich ändern kann. >Die Typenbezeichnung ist auch erst mal egal. Die ändert man dann so wie >man will. Eben, aber das wird in Eagle nicht in allen Libs konsequent so gemacht. Man braucht nicht ein halbes Dutzend gleiche Transistorn NPN in TO92. EINER reicht.
michael_ schrieb: > Mecker nicht rum mit deiner superneuesten Version. > Auch in deiner Version findest du keine EL81 :-) Da liegt ein Missverstaendnis vor - den LP2980 hatte ich auch nur in einer user-lib gefunden. Die EL81 fand ich allerdings auch nicht - dafuer aber die PL504 !
Falk B. schrieb: > Doch, braucht man. Ich nicht. Wenn ich eine Z-Dide brauch, finde ich sie unter ZX oder ZD. Falk B. schrieb: >>EAGLE funktioniert aber andersrum. Da ist zuerst das Symbol im >>Schaltplan. > > Nö, da verwechselst du was. Das machen andere Programme so, vielleicht > KiCAD, DipTrace? Du machst also erst das Layout und danach den Schaltplan? Falk B. schrieb: >>Erstmal z.Bsp. irgendeinen R holen und danach im Layout das Package >>festlegen. > > Nö, das ist im Schaltplan schon festgelegt, auch wenn man es > nachträglich ändern kann. Bei EAGLE nicht zwingend. Wen in der .lib PIN und PAD korrekt zugeordnet sind, geht das gut. Falk B. schrieb: > Eben, aber das wird in Eagle nicht in allen Libs konsequent so gemacht. > Man braucht nicht ein halbes Dutzend gleiche Transistorn NPN in TO92. > EINER reicht. Ich unterstelle dir mal nicht, das du es nicht besser weißt. Die PIN-Belegung ist sehr verschieden. Das harmloseste ist, das BEC auch bei Ami- oder Japan Typen auch CEB sein kann. Da stimmt blos der Bestückungsdruck eben nicht. Von anderen Kombinationen abgesehen. Weitere Streitgespräche mache ich nicht mehr :-) Eine HD-Kopie hat nun glücklicherweise nach Stunden endlich ein Ende gefunden. Jetzt ist Bettgang!
> Wie macht ihr das denn? klar man kann ich alles was man braucht in eine > eigene Lib zusammenkopieren, das ist aber super unpraktisch? Jeder der sich mit Eagle näher beschäftigt (hat), kennt die Probs mit den Libs. > @ Goerg T > zu deiner Aufzählung 1.-4. Finde ich umständlich. Da kann man sich auch gleich bei machen eigene Libs erstellen. Ich hatte anfänglich auch so meine Schwierigkeiten mit den mitgelieferten Eagle-Libs. Hatte mir dann aber eigene zusammengestellt und denke dass man mit einer guten Struktur vieles schneller findet. (siehe Anhang) > Dioden > Schottkydioden > Z-Dioden > Doppeldioden > Suppressordioden > ... > Braucht man nicht, das weiß man doch vorher. > Doch, braucht man. Zustimm
@ michael_ (Gast) >> Doch, braucht man. >Ich nicht. Wenn ich eine Z-Dide brauch, finde ich sie unter ZX oder ZD. Diese Freak-Zeiten sind lange vorbei! Damals, zu seeligen DOS-Zeiten vor Eagle 4.x gab es keinen Bauteilbrowser, da musste man halb blind durch die einzelnen Libs navigieren und schon genau wissen, wo was liegt. Das kann man heute nicht mehr verkaufen. Das muss INTUITIV sein! >Du machst also erst das Layout und danach den Schaltplan? Erzähl keinen Quark. >> Nö, das ist im Schaltplan schon festgelegt, auch wenn man es >> nachträglich ändern kann. >Bei EAGLE nicht zwingend. Wen in der .lib PIN und PAD korrekt zugeordnet >sind, geht das gut. ??? >> Eben, aber das wird in Eagle nicht in allen Libs konsequent so gemacht. >> Man braucht nicht ein halbes Dutzend gleiche Transistorn NPN in TO92. >> EINER reicht. >Ich unterstelle dir mal nicht, das du es nicht besser weißt. ??? >Die PIN-Belegung ist sehr verschieden. Nö. Es gibt hunderte Transistoren in TO92 mit EBC. Für die BCE Typen braucht man halt ein weiteres Symbol, logisch. >Das harmloseste ist, das BEC auch bei Ami- oder Japan Typen auch CEB >sein kann. Das kann man problemlos mit wenigen Typen abbilden. Kann man ja z.B. so beschreiben NPN, EBC, TO92, BC337 NPN, BCE, TO92, BC640 N-Kanal, GDS, TO220, BUZ11 ...
Toxic schrieb: > michael_ schrieb: >> Mecker nicht rum mit deiner superneuesten Version. >> Auch in deiner Version findest du keine EL81 :-) > > Da liegt ein Missverstaendnis vor - den LP2980 hatte ich auch nur in > einer user-lib gefunden. > Die EL81 fand ich allerdings auch nicht - dafuer aber die PL504 ! Hi Toxic, wie geht das denn???? in den Fenstern oben rechts werden doch eigentlich symbol und package angezeigt..... wieso sehe ich da zwei Abbildungen? Schorsch
@Michal und Falk: ihr meint doch beide das gleiche.... niemand macht erst das layout und dann den Plan... aber schon wenn ich den Plan mache überlege ich mir genau, ob ein ich ein 0805 oder einen 2W Typen brauche. Ich stimme zu, dass wenn bei den libs konsequenter gearbeitet werden würde, sich viele Probleme auflösen würden. So sind bei vielen Typen nicht alle Packages vorhanden. Die Tatsache, dass man mit einer symbol-package kombination viele Typen abdecken kann ist auch klar, sonst gäbe es keine pinkompatiblen Ersatztypen. Schade ist allerdings, dass man diese Typennamen, dann nicht als "Vorauswahlwert" (Versteht ihr, was ich meine?) zu einer symbol-package kombination wählen kann. Dadurch wäre die Lib viel struktiererter. Macht das vielleicht Sinn hier ein neues Projekt aufzumachen, und eine open-source library für den File-IO von Eagle-Libs zusammenzubasteln? Ich fände einen grafischen Handler, der einem automatisch symbold und package anzeigt auch nett. Letztenendes geht es ein Stück weit in die Richtung einen Teil von Eagle nachzuprogrammieren... damit könnte man dann in einem zweiten Schritt die Bibliotheksverwaltung von eagle in ein separates Program auslagern Schorsch
@Georg T. (microschorsch) >@Michal und Falk: >ihr meint doch beide das gleiche.... Tun wir das? >niemand macht erst das layout und dann den Plan... aber schon wenn ich >den Plan mache überlege ich mir genau, ob ein ich ein 0805 oder einen 2W >Typen brauche. Mehr oder weniger. Das Problem ist hat, daß EINIGE Eagle-Libs seit Jahren vermüllt und nicht aufgeräumt sind. >Ersatztypen. Schade ist allerdings, dass man diese Typennamen, dann >nicht als "Vorauswahlwert" (Versteht ihr, was ich meine?) Nicht so ganz. >Macht das vielleicht Sinn hier ein neues Projekt aufzumachen, und eine >open-source library für den File-IO von Eagle-Libs zusammenzubasteln? >Ich fände einen grafischen Handler, der einem automatisch symbold und >package anzeigt auch nett. Gibt es doch schon, den Lib-Browser bzw. das ADD-Fenster. > Letztenendes geht es ein Stück weit in die >Richtung einen Teil von Eagle nachzuprogrammieren... Das halte ich nicht für sinnvoll. Im ersten Schritt reicht es vollkommen, EINIGE Libs aufzuräumen. Ich werd das mal mit der Dioden-Lib demosntrieren. >damit könnte man dann in einem zweiten Schritt die Bibliotheksverwaltung >von eagle in ein separates Program auslagern Wozu? Man sollte die Baustelle nicht größer machen als unbedingt nötig.
Hallo Falk, Falk B. schrieb: >>Ersatztypen. Schade ist allerdings, dass man diese Typennamen, dann >>nicht als "Vorauswahlwert" (Versteht ihr, was ich meine?) > > Nicht so ganz Es sollte meiner Meinung nach nur noch ein eindeutiges device Transistor-NPN-EBC geben, so, wie ich momentam im Plan change device machen kann, sollte man change type machen können. die change package funktionalität ist ja super und ich benutze sie gerne, aber sie funktioniert halt nur innerhalb eines devices. Ich möchte gerne nur einen "Standard Transitor NPN" auswählen und später über change type sagen können welchen genau ich will. > Gibt es doch schon, den Lib-Browser bzw. das ADD-Fenster Ist nicht open source Ich möchte eine Möglichkeit haben in einer Spache meiner Wahl die Bibliotheken manipulieren zu können Schorsch
Georg T. schrieb: > Hi Toxic, > > wie geht das denn???? > > in den Fenstern oben rechts werden doch eigentlich symbol und package > angezeigt..... wieso sehe ich da zwei Abbildungen? Naja - ich hab da ein bischen mit PaintShop "gezaubert" - die PL504 ist in keiner mir bekannten Lib enthalten... ;-)
@Georg T. (microschorsch) >machen kann, sollte man change type machen können. REPLACE >> Gibt es doch schon, den Lib-Browser bzw. das ADD-Fenster >Ist nicht open source Ist das der heilige Gral? >Ich möchte eine Möglichkeit haben in einer Spache meiner Wahl die >Bibliotheken manipulieren zu können Kannst du, seit alles auf XML umgestellt ist.
Hallo, Replace ist nicht das was ich meine. Replace ist nur ein kürzerer Weg für delete und add. Ich möchte eine Funktion, die mir wie bei change package die varianten anbietet, die hier sinn machen, aber über die verschiedenen varianten eines selben devices hinaus etwas mehr als einen XML-parser wollte ich schon. Wenn man einen Code zusammenstrick, der die Eagle-Objekte (device, symbol und package) wirklich als device behandelt kann man da einiges an Funktionalität mehr reinbringen. z.B. * automatisches Überprüfen von Doppelungen * automatisches Überprüfen von pinkompatibilitäten -> zusammenfügen in eine Lib * einheitliche Benennungen * anhängen von Userkommentaren an devices (z.B. Bestellnummern, Lieferant, Link zum Datenblatt in lokaler Datenbank ...) * eigene Sortierungen * usw Schorsch
@ Georg T. (microschorsch) >Ich möchte eine Funktion, die mir wie bei change package die varianten >anbietet, die hier sinn machen, aber über die verschiedenen varianten >eines selben devices hinaus Das geht doch jetzt schon. Du kannst doch verschiedene Packages auch mit verschiedenen Pinbelegungen unter EINEM Device zusammenfassen. >etwas mehr als einen XML-parser wollte ich schon. Wenn man einen Code >zusammenstrick, der die Eagle-Objekte (device, symbol und package) >wirklich als device behandelt kann man da einiges an Funktionalität mehr >reinbringen. Dann veränderst du aber Eagle so tief, daß du ans Eingemachte gehen musst. Ob das klappt? >* automatisches Überprüfen von Doppelungen >* automatisches Überprüfen von pinkompatibilitäten -> zusammenfügen in >eine Lib >* einheitliche Benennungen >* anhängen von Userkommentaren an devices (z.B. Bestellnummern, >Lieferant, Link zum Datenblatt in lokaler Datenbank ...) >* eigene Sortierungen >* usw Auf gut deutsch, ein deutlich aufgebohrter Lib-Editor. Einen Teil kann man sicher mit ULPs erschlagen. Aber bestimmte Dinge schafft man nur mit einer Erweiterung der Eagle-Libs, die dann aber auch Eagle selber unterstützen muss. VIEL Holz!
Falk B. schrieb: > Auf gut deutsch, ein deutlich aufgebohrter Lib-Editor. Ja genau! Der muss ja auch erstmal gar nichts mit Eagle selbst zu tun haben. > Einen Teil kann man sicher mit ULPs erschlagen. Könnte man, aber ULPs sind sicher nicht die "Sprache" (wenn man das überhaupt so nennen darf) meiner Wahl > Aber bestimmte Dinge schafft man nur mit > einer Erweiterung der Eagle-Libs, die dann aber auch Eagle selber > unterstützen muss. VIEL Holz! Und das glaube ich widerrum nicht. Das was ich vorschlage ist nur eine Art automatische Analyse aller Libraries. Mit Hilfe der Infos in den Libraries könnte man dann automatisch Libraries so verändern, dass sie gewissen Standards unterliegen. Z.B. könnte ich mir alle Packages, die auf TO-92 basieren raussuchen (hier gibt es sicherlich alleine in alles libs 50 verschiedene. Die müsste man dann auf einen Standard zurückführen - mit korrekten PAD-Namen (1,2,3) nicht B, E, C. Das kriegt man aber sicherlich automatisiert. Ich würde nicht versuchen die Funktionalität der Libs zu vergrößern, sondern einfach nur die vorhandenen besser zu strukturieren. Ich denke für 95% aller Anwendungen kommt man mit vielleicht 100 Teilen aus. Das schafft man durch geschicktes zusammenkopieren. Das kann man händisch machen (oben gibt es offensichtlich einige Leute, die das so machen) oder automatisch das fände ich die transparentere Möglichkeit. BTW: Ich schaue mir gerade die Attributen-Möglichkeit bei Eagle an. Das Feature hab ich bisher nie benutzt. scheint mir als hätte Farnell das Feature zur Kommerzzwecken hinzugefügt. Vielleicht könnte man mit einer Externen Tabelle einfach hier Userspezifische Namen einfügen. Das ist sicherlich noch einfacher umzusetzen. Schorsch
@ Georg T. (microschorsch) >> unterstützen muss. VIEL Holz! >Und das glaube ich widerrum nicht. Ich schon ;-) >Das was ich vorschlage ist nur eine Art automatische Analyse aller >Libraries. Mit Hilfe der Infos in den Libraries könnte man dann >automatisch Libraries so verändern, dass sie gewissen Standards >unterliegen. Klingt gut, aber . . . >Z.B. könnte ich mir alle Packages, die auf TO-92 basieren raussuchen >(hier gibt es sicherlich alleine in alles libs 50 verschiedene. Die >müsste man dann auf einen Standard zurückführen - mit korrekten >PAD-Namen (1,2,3) nicht B, E, C. Das kriegt man aber sicherlich >automatisiert. Na dann mal los! Ich würde hier bestenfalls eine halbautomatische Lösung sehen. >Ich würde nicht versuchen die Funktionalität der Libs zu vergrößern, >sondern einfach nur die vorhandenen besser zu strukturieren. Das allein ist ordentlich Aufwand, auch mit cleveren Hilfsprogrammen. >BTW: Ich schaue mir gerade die Attributen-Möglichkeit bei Eagle an. Das >Feature hab ich bisher nie benutzt. scheint mir als hätte Farnell das >Feature zur Kommerzzwecken hinzugefügt. Vielleicht könnte man mit einer >Externen Tabelle einfach hier Userspezifische Namen einfügen. Das ist >sicherlich noch einfacher umzusetzen. Probier mal und berichte uns.
Falk B. schrieb: > Probier mal und berichte uns. Ok.... tue ich... ganz kurzer test vorweg:, hier ein ausschnitt aus einer sehr einfachen Lib:
1 | <deviceset name="1N4004" prefix="D"> |
2 | <description><B>DIODE</B><p> |
3 | general purpose rectifier, 1 A</description> |
4 | <gates> |
5 | <gate name="1" symbol="D" x="0" y="0"/> |
6 | </gates> |
7 | <devices> |
8 | <device name="" package="DO41-10"> |
9 | <connects> |
10 | <connect gate="1" pin="A" pad="A"/> |
11 | <connect gate="1" pin="C" pad="C"/> |
12 | </connects> |
13 | <technologies> |
14 | <technology name=""> |
15 | <attribute name="GTNAME" value="my1n4004"/> |
16 | <attribute name="GTTEST" value="123" constant="no"/> |
17 | </technology> |
18 | </technologies> |
19 | </device> |
20 | </devices> |
21 | </deviceset> |
22 | </devicesets> |
Ihr sehr ich habe zwei Attribute manuell hinzugefügt. Jetzt kann ich innerhalb von Eagle durch die Attributensuche sowohl nach key als auch nach value suchen. Das klappt. Das heißt ich müsste nurnoch eine Liste anlegen mit Teilen, die ich häufig benutze, und dann pro Teil 2 oder 3 attribute definieren. Ich dachte so an MyKind = Diode, MyName = 1N4004 oder MyName = R0805 Zusammen mit der Liste müsste dann ein kleiner Parser über alle libs laufen und die Attribute aktualisieren. Das wäre dann eine händisch programmierte Favoritenliste in Eagle - tatsächlich über alle Libs hinweg. Ich kenne mich mit ULPs oder SCRs zu wenig aus, aber kann man ein script mit Icon ö.ä. ergänzen, welches add öffnet mit vorausgewählter attributensuche? Schorsch
:
Bearbeitet durch User
Hier mal ein erster Versuch, die Lib diodes.lbr aufzuräumen. Man müsste jetzt in allen Packages den Namen einer expliziten Diode eintragen, damit man überhaupt eine Referenz hat, denn kein Mensch will eine Diode suchen, von der er nur den Gehäusetyp kennt. Beispielhaft ist das mal für 1N4148 und 1N4001 gemacht, der Rest fehlt noch.
Respekt Falk! finde ich deutlich, deutlich übersichtlicher als er Sch**** der da normalerweise drin ist! Ich finde Die Lösung sehr gut, da Du nur ein Device Diode angelegt hast und darin sämtliche Packages und Typen verwaltest. Da es bei Change Package diese Funktion gibt "Alle Technologies anzeigen" folgender Vorschlag: Vielleicht ist das nicht so gemeint, aber könnte man nicht den Diodentypen (1n4001, 1n4004) also technology führen? Dann kann man mit change package sowohl die Packages als auch die Typen ändern Schorsch
@Georg T. (microschorsch) >Respekt Falk! Ist doch gar nichts passiert. >finde ich deutlich, deutlich übersichtlicher als er Sch**** der da >normalerweise drin ist! Ja. >Vielleicht ist das nicht so gemeint, aber könnte man nicht den >Diodentypen (1n4001, 1n4004) also technology führen? Dann kann man mit >change package sowohl die Packages als auch die Typen ändern Kann man machen, aber dann passiert genau DAS, was man eigentlich vermeiden will, nämliche ein RIESIGE Liste an Bauteilen, bei der man den Wald vor lauter Bäumen nicht mehr sieht. Diese Subtypen (4001, 4002, etc.) müsste man in eienr weiteren Hierachieebene unterbringen, aber das kann Eagle nicht. Darum würde ich es lieber dabei belassen. Man kann nicht alles haben. Die Sache mit der Technologie ist zwar nett, bringt aber mehr Verwirrung als Nutzen bei der Auswahl. Beispiel Logikschaltkreise. Dort ist es zur Auswahl vollkommen schnuppe, ob ich AC, HC, HCT oder sonstwas will. Dort will man nur den Typ ala 74xx00 und das Gehäuse wählen, der Rest ist nur Nebensächlichkeit. Siehe Anhang.
:
Bearbeitet durch User
Hallo Falk, Hast vermutlich recht. man bräuchte eine weitere Hirarchieebene, wie Du schon sagstest. Du willst sicher auch nicht alles was in deinem package diode steht in eine einzelne lbr packen, um eine weitere ebene zu gewinnen. Ein ähnlicher Vorschlag stand ja schon weiter oben. Man könnte natürlich große Listen machen und diese dann filtern. Leider kann man die Filter in dem Add-fenter nur auf alle libs anwenden, nicht nur auf die ausgewählten libs... Wie weit geht den die Scripting Funktionaliät von Eagle. Ich hab schon gesehen, dass es komplette GUIs in scripts oder ulps gibt. Kann man nicht mittels einer solchen sprache ein eigenes ADD-Fenster kreieren? geht sowas? Schorsch
@Georg T. (microschorsch) >man bräuchte eine weitere Hirarchieebene, wie Du schon sagstest. Du >willst sicher auch nicht alles was in deinem package diode steht in eine >einzelne lbr packen, um eine weitere ebene zu gewinnen. Daran hab ich schon gedacht, könnte man machen. Wenn man streng hierarchische Namen vergibt, bleibt es auch übersichtlich. Muss man halt abwägen. Wenn man per Mausclick die BOM mit ALLEN Daten erzeugen will, muss man es so machen. Letztendlich geht es ja aber nur um ein paar Libs, die aufgeräumt werden müssen. Die Masse wird so bleiben, weil die Masse alles Bauteile sind, die individuelle Funktionen und Packages haben. > Ein ähnlicher >Vorschlag stand ja schon weiter oben. Man könnte natürlich große Listen >machen und diese dann filtern. Leider kann man die Filter in dem >Add-fenter nur auf alle libs anwenden, nicht nur auf die ausgewählten >libs... Dazu müsste man das Lib-Konzept von Eagle aufbohren. Das muss Cadsoft machen. >Wie weit geht den die Scripting Funktionaliät von Eagle. Ich hab schon >gesehen, dass es komplette GUIs in scripts oder ulps gibt. Kann man >nicht mittels einer solchen sprache ein eigenes ADD-Fenster kreieren? >geht sowas? Keine Ahnung. Vielleicht.
Bitte 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.