Ich möchte das einfach mal loswerden, und auch andere animieren zu berichten... Ich habe mich vor einiger Zeit durchgerungen Eagle mal beiseite zu legen und KiCAD mal wirklich anzutesten und mittlerweile habe ich schon ein paar Leiterplatten damit gemacht. Anfänglich tat ich mich schwer mit der Bedienung, die ist doch deutlich unterschiedlich: Scrollen, Footprints zuweisen, Netzlisten, Gerberdaten, dass der Cursor nach dem Editieren wieder an die Ausgangsposition zurückspringt... Alles Kleinigkeiten die mir am Anfang als unerträglich nervig vorkamen. Nach 2 kleinen Projekten hatte ich mich aber an den Workflow gewöhnt und auch die ab und zu komisch anmutende Benutzung nervt nicht mehr wirklich. Ich hab durchgehalten und seitdem nix mehr mit Eagle gemacht! Halt, stimmt nicht ganz: einmal eine 7.6. Freeware Version installiert um die alten 5er Dateien in das neue Format zu konvertieren damit KiCAD das importieren kann. Ging erstaunlich glatt, ich wollte allerdings nur die Bauteile und habe deswegen weder Schaltplan noch Layout wirklich überprüft. Sah auf den ersten Blick allerdings recht komplett aus. Ein paar Sachen waren auf dem falschen Layer gelandet, aber nichts was man in tagelanger Arbeit hätte anpassen müssen Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder anfassen müssen, und was soll ich sagen, nun kommt mir dort die Bedienung sehr sehr komisch und nur wenig intuitiv vor lach Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen? Fazit: beide Programm habe Ihre Eigenheiten! Meine Projekte konnte ich immer realisieren egal ob Eagle oder KiCad. Zugegeben sind es immer minder-komplexe Angelegenheiten gewesen! Aber ich kann jedem der keine Lust mehr auf Eagle hat oder die Beschränkungen der Gratis-Version umgehen möchte nur dazu raten mal KiCAD anzutesten. Zeit zur Umgewöhnung sollte man mitbringen, aber ich denke das ist bei jedem Wechsel so. Und ja, ich schreibe vielleicht etwas überschwänglich und möglicherweise nicht ganz objektiv aber das ich eben in Eagle nicht zurechtkam war einfach ein schönes Aha-Erlebnis das ich gerne teilen wollte... Würde mich freuen mal ein paar Erfahrungen von Anderen zu lesen (die mehr als mal eine Stunde mit KiCAD rumgespielt haben). Sehr interessieren würden mich Erfahrungen von aufwändigeren Projekten! Viele Grüße, Bob
:
Gesperrt durch Moderator
Bob A. schrieb: > Würde mich freuen mal ein paar Erfahrungen von Anderen zu lesen (die > mehr als mal eine Stunde mit KiCAD rumgespielt haben). Ich habe mir das gerade mal angetan. Ca. ne Stunde... Und was soll ich sagen - bin relativ enttäuscht. Ich habe mir das aktuelle stable geladen, welches sich dann mit ca. 3.2GB auf die Platte legt. Gestartet und nach Frage ein Projekt angelegt. Der Schaltplaneditor ist noch relativ intuitiv gehalten. Rechts halt die Symbole und das Symbol zum hinzufügen der Bauelemente. Ich hab was ganz leichtes gemacht, zwei 2xPinheader jeweils mit einem GND und einem 12V versehen. Da stieß ich schon auf das erste Problem: Beim verschieben der Bauelemente auf dem Feld (und da waren ja bloß zwei!) ruckelte es wie die Hulle. Am Rechner kann es eigentlich nicht liegen, ein i7 32GB GTX980, wahrscheinlich eine Treibersache - was anderes kann ich mir nicht erklären - jedoch das Bauteil dann irgendwo dorthin zu treffen wo es soll war mehr als schwierig. Nun... okay... das Layout stand und ich wollte daraus ein PCB machen und öffnete dafür PCBNEW über das Hauptfenster: Joar... aber wie und wo und womit bekomme ich da meine Bauteile nun auf meine Platine die ich im Layout habe?! Ich habe (intuitiv) keine Möglichkeit gesehen dies dort einzufügen. Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann zurechtrücke und ich sie verbinden kann. Nach ca. ner Stunde insgesamt hab es dann erstmal wieder ausgemacht und sein lassen. Ohne sich vorher erstmal in Tutorials einzulesen werde ich wahrscheinlich erstmal noch nicht warm mit KiCAD. Wenn ich mal etwas Zeit und Muse habe - dann werde ich mir wohl mal nen Beginner-Tut von KiCad zu Gemüte führen. Solange werde ich wohl noch bei Eagle bleiben - wo alles irgendwie "flüssiger" ist.
Danke für deinen Bericht. Jaa, die steile Lernkurve am Anfang hatte ich auch. Da ich mittlerweile fließend damit arbeiten kann habe ich das aber irgendwie verdrängt. Das hätte in der Tat in meinen Bericht mit rein gehört! Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen und in pcbnew einzulesen. Dass es keinen Automatismus dafür gibt ist mir schleierhaft und sicherlich eine der größten Hürden beim antesten / einlernen. Die ganze Bedienung scheint mir von einem streng linearen workflow auszugehen. Wenn die Schaltung fertig ist entscheidet man sich für die Bauformen der Komponenten und macht dann das Layout. Änderungen erfordern immer weider das erstellen der Netzliste im Schaltplan-Editor und diese muss dann in pcbnew eingelesen werden. Hat man das mal raus geht es in 1-2 Sekunden die paar Klicks durchzuexerzieren aber ja, intuitiv ist anders! Ich habe aktuell die beta von Version 5, da gibt es "Update PCB from Shematic" in Schaltplan-Editor und Layout-Editor, ist trotzdem noch etwas Rumgeklicke und kein Automatismus...
Haters will Always hate. Was soll das gebashe. Bleibt doch beim Adler wenn der so geil ist. Man kann mit kicad arbeiten. Und es ist kostenlos. Den Rest entscheidet die persönliche Flexibilität.
Rene K. schrieb: > Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg > gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde > halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann > zurechtrücke und ich sie verbinden kann. Also von Altium kenne ich das nicht, hier hole ich die Änderungen immer über Design/Import Changes in die PCB. Für mich war diese Auto-Annotation (nennt man das so?) immer eine Eigenheit von Eagle.
Karl schrieb: > Was soll das gebashe Wieso Gebashe? Ich empfinde das alles noch als legitime Kritik und Meinungsäußerung. Mein Punkt ist einfach: Weder Eagle noch KiCAd sind wirklich intuitiv! Ich habe das erst bemerkt nachdem ich im Wechsel mit beiden gearbeitet habe. Man gewöhnt sich lediglich an die Eigenheiten "seines" Programms...
:
Bearbeitet durch User
Ich kann den Eindruck des TO voll bestätigen. Nach dem Wechsel auf KiCAD durchläuft man erst mal eine Lernkurve und es geht alles etwas lamgsamer. Aber beim zweiten oder dritten Layout hat man das im Griff, und dann ist KiCAD ein vollwertiger Ersatz für den Adler. Wie es bei sehr großen Designs aussieht, kann ich nichts dazu sagen. Ich vermute mal, ich wollte kein Kuchenblech mit 12 Layern und 10k Vias damit designen. Aber mit Eagle wollte ich das auch nicht. Hat jemand schon mal KiCAD für ein richtig komplexes Design verwendet?
wäre halt schon cool wenn man wüsste was die beim CERN damit anstellen...
Peter schrieb: > Für mich war diese Auto-Annotation (nennt man das so?) immer eine > Eigenheit von Eagle. Hmmm... auch ich überlege, den Adler ins ewige noShow zu verbannen... doch das mit dem "anderen" Workflow schreckt mich wirklich ab. zB PinSwap / GateSwap benutze ich sehr häufig, wenn ich beim Layouten draufkomme dass es andersrum einfacher wäre... muss ich dann Schaltplan und Layout "halbmanuell" synchronisieren?
Michael R. schrieb: > zB PinSwap / GateSwap benutze ich sehr häufig, wenn ich beim Layouten > draufkomme dass es andersrum einfacher wäre... muss ich dann Schaltplan > und Layout "halbmanuell" synchronisieren? Ich befürchte ja, wobei das wirklich flott geht. Was ich nicht weiß ist ob es die Möglichkeit gibt Änderungen im Layout in den Schaltplan zu übernehmen? Mein Erfahrungsschatz bei eagle und KiCad ist eben doch recht beschränkt...
Bob A. schrieb: > Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile > erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen > und in pcbnew einzulesen. > > Dass es keinen Automatismus dafür gibt ist mir schleierhaft und > sicherlich eine der größten Hürden beim antesten / einlernen. Wie sollte der Automatismus aussehen? Woher soll der Automatismus wissen, ob Du 0805 oder 1206 als Widerstandsbauform haben möchtest? Übrigens kann man einem Schaltplanbauteil problemlos direkt im "Field properties"-Dialog mit "Assign footprint" (wer hätte das gedacht ;-) einen Footprint suchen und fix zuordnen - so wie bei Eagle (siehe Screenshot). Man hat also beide Möglichkeiten, je nach persönlichem Geschmack. Ich selbst habe lieber übersichtliche Schaltplanbibliotheken und weise dann per Annotation-Dialog zu. Fixe Zuordnungen habe ich nur bei entsprechenden ICs, bei denen es nur einen sinnvollen Footprint gibt. Ansonsten: ein doch relativ komplexes Programm nach nicht einmal einer Stunde zu beurteilen halte ich für wenig zielführend. Natürlich muss man sich da einarbeiten, insbesondere wenn man schon auf ein anderes Programm fixiert war. Wer noch nie mit ECAD-Software zu tun hatte, tut sich da meiner Erfahrung nach erheblich leichter, einfach weil er nicht auf auf einen bestimmten Ablauf geprägt ist.
:
Bearbeitet durch Moderator
> Man gewöhnt sich dran nachdem der Schaltplane erstellt ist, die Bauteile > erstmal einem Footprint zuzuordnen und dann die Netzliste zu erstellen > und in pcbnew einzulesen. Ich finde es interessant dass ausgerechnet Eagle User so vorgehen und sogar meinen es sei normal in Kicad die FPs erst später zuzuweisen. Kann man zwar so machen, finde ich aber ungeschickt. Inzwischen benutze ich Kicad seit gut einem Jahr, mittlerweile auch beruflich (Eagle: 15 Jahre). Ich bin es von Eagle her so gewohnt das Symbole und Packages bereits verknüpft sind wenn ich ein Bauteil im Schaltplan einfüge. In Kicad arbeite ich ähnlich. Wenn ich z.B. einen Widerstand einfüge, dann ist es für mich normal dem Bauteil einen Wert und ein FP zu geben. Das geht sogar während das Teil noch am Mauszeiger hängt. Und da die meisten Widerstände ohnehin das gleiche Package haben, füge ich nicht jeden Widerstand aus der Lib einzeln ein sondern kopiere einen vorhandenen und ändere ggf. den Wert. Mache ich auch mit Eagle so. Dieses CvPCB Tool benutze ich nicht. Alle Teile haben bereits ihren FP. Netzlisten erstellen und einlesen muß man inzwischen auch nicht mehr. Einfach im Schaltplaneditor "F8" drücken und das Board wird aktualisiert. Nein, Backannotation wie Eagle es kann geht nicht. Ist imho für die V6 geplant. Aktuell benutze ich Eagle kaum noch. Meine Einstellung zu den beiden Programmen hat sich inzwischen umgekehrt. So hatte ich mich vor ca. 1 Jahr noch über diverse Merkwürdigkeiten von Kicad geärgert ("in Eagle könnte ich jetzt einfach..."). Jetzt ärgere ich mich über Eagle ("Boah, ist das umständlich"). Ich sollte aber vielleicht anmerken dass ich das aktuelle Eagle V8 nur kurz angetestet habe. Da hat sich ja einiges getan. Ich vergleiche hier Eagle V6.6 mit Kicad nightly. Meiner Meinung nach reicht es nicht aus in einem ECAD Programm etwas herumzuklicken um sich eine Meinung dazu zu bilden. Dazu sind diese Systeme zu komplex. Man sollte sich schon die Mühe machen ein komplettes Design durchzuziehen. Dazu muss man auch in der Lage (und bereit) sein seine Komfortzone zu verlassen. Sonst kann man es gleich lassen.
Also Stefan schrieb: > Meiner Meinung nach reicht es nicht aus in einem ECAD Programm etwas > herumzuklicken um sich eine Meinung dazu zu bilden. Dazu sind diese > Systeme zu komplex. Ja keine Ahnung, aber genau so habe ich Eagle gelernt: mit klicken und probieren. Da müsste sogar der Thread hier noch irgendwo rumhuschen. Ja das mit den FP ist halt so eine Sache. In Eagle suche ich mir ja mein Bauteil incl. FP und setze ihn auf. Das man dies im Nachhinein macht ist halt eine Umgewöhnung, ohne Frage. Hab heut nochmal ne halbe Stunde "rumgespielt" und nun auch die FP zugewiesen und diese Liste ins PCB übernommen - da kam dann mein nächstes Problem: Wie zum Geier verschiebt man auf der Platine ein Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben" ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben. Heute Nachmittag mach ich mal ein Tut durch. Ich denke aber auch das das anlernen ohne jegliche Vorkenntnisse wesentlichen einfacher ist als ein Umstieg. Peter schrieb: > Also von Altium kenne ich das nicht, hier hole ich die Änderungen immer > über Design/Import Changes in die PCB. Altium müsste ich lügen, dafür isses zu lange her. Aber bei Target ist es jedenfalls so. Gut, kann man nicht vergleichen. Zum Thema Backanotation in Eagle: Ja gut, kann man sich wahrscheinlich drüber streiten: In meinen Augen ist es Segen und Fluch zugleich.
Vancouver schrieb: > Hat jemand schon mal KiCAD für ein richtig komplexes Design verwendet? Ja das geht ohne Probleme! Mit 12 Lagen mit und ohne Sacklöcher und mit einen Platzierungsfaktor von 0,7. (1 = Platine voll bedeckt mit Bauteilen) Das Problem ist nur man muss den richtigen Fertiger finden der das zufriedenstellen hinbekommt. Bob A. schrieb: > Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder > anfassen müssen, und was soll ich sagen, nun kommt mir dort die > Bedienung sehr komisch und nur wenig intuitiv vor lach > Ich musste suchen um die Löschen-Funktion zu finden. Das ist sehr amüsant zu lesen. Ich kann mir vorstellen da wechseln jetzt Leute die hätten vor 1 Jahr noch jeden KiCad Prediger auf dem Scheiterhaufen verbrannt :-(
Rene K. schrieb: > Wie zum Geier verschiebt man auf der Platine ein > Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben" > ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben. Siehe Kontext-Menu (Rechtsklick über dem Bauteil), und dort sind im Submenü die "Bewegungsarten" mit Hotkeys aufgelistet: "M" (move) bewegt das Bauteil "G" (drag) bewegt mit Leiterbahnen usw. Ja, ist anders, aber nicht schlechter - spätestens nach ein paar Platinen auf jeden Fall deutlich schneller als per Kontextmenü. > Heute Nachmittag mach ich mal ein Tut durch. Ja, das hilft sehr :-) > Ich denke aber auch das das anlernen ohne jegliche Vorkenntnisse > wesentlichen einfacher ist als ein Umstieg. Da bin ich ziemlich sicher. Ähnliches habe ich auch beim Umstieg von Leuten von Windows auf Linux beobachtet.
:
Bearbeitet durch Moderator
Bob A. schrieb: > Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder > anfassen müssen, und was soll ich sagen, nun kommt mir dort die > Bedienung sehr sehr komisch und nur wenig intuitiv vor lach > Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es > unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen? Ich habe vor einer Weile ein Projekt mit zwei Leiterplatten gemacht. Eine in KiCAD, die andere aus historischen Gründen noch in Eagle. Wenn man beides fast parallel benutzt, macht man sich echt einen Knoten ins Hirn. Was in Eagle besser gelöst ist, ist die Anlage von irgendwelchen Kupferflächen (z.B. für Touchflächen). In KiCAD suche ich die geniale Lösung noch. Beim Highlighting hat beides seine Stärken und Schwächen. Die Library-Konzepte sind in beiden Systemen eher mittelprächtig toll. Insgesamt habe ich den Wechsel nicht bereut. Aber ich muss in jedem Fall Chris D. recht geben: nach einer Stunde kann man das nicht beurteilen. Mir half es enorm, ein bestehendes und bekanntes Eagle-Projekt zu importieren und daran weiterzuarbeiten.
Stefan schrieb: > Dazu sind diese > Systeme zu komplex. Da frage ich mich immer: Muß das sein? Für eine simple Platine könnte es so einfach sein. Aus einem ausreichenden Bauteilfundus Bauelemente auf die Platine ziehen, verbinden, fertig! In dieser Hinsicht lernte ich Eagle früher spielend. Für KiCad brauchts unbedingt Tutorials. Freilich, die Komplexität kommt auch mit den vielen Möglichkeiten. Aber: Das nicht unmittelbar benötigte muß doch nicht gleich so brachial in den Arbeitsablauf eingreifen daß man den mindestens halben Funktionsumfang schon am Anfang in einer steilen Lernkurve nehmen muß! KiCad ist in seinem Arbeitsablauf schon sehr festgelegt. Man muß sehr vieles gleich zu Beginn wissen um überhaupt zu einer simplen Platine zu gelangen. Was mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das mag ja Industrie-Standard sein, aber warum geht das nicht einfach in einer einzigen Layout-Datei wie bei Eagle? So wie diese Frage gibt es derer viele. Man hat oft den Eindruck so ein System wird nicht aus Anwendersicht geschaffen sondern Entwickler gestalten ganz nach ihren Mitteln und Fähigkeiten.
Chris D. schrieb: > "D" (drag) bewegt mit Leiterbahnen klappt bei mir nicht, wünsche ich mir aber öfters :(
Rene schrieb: > warum geht das nicht einfach in > einer einzigen Layout-Datei Ich bin mir fast sicher: würde KiCAD z.Bsp. eine .zip-Datei mit den Gerbers ausspucken, da würden dann Andere mosern...
Rene schrieb: > Was > mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das > mag ja Industrie-Standard sein, aber warum geht das nicht einfach in > einer einzigen Layout-Datei wie bei Eagle? ??? Gerber ist nun mal ein Satz an Dateien. Wenn ein Hersteller eine .brd akzeptiert, übernimmt er die Umwandlung von .brd nach Gerber für dich. Es gibt genauso Hersteller, die auch .kicad_pcb akzeptieren. Versuche mal OSHPark.
Rene schrieb: > Was > mich auch stört ist der altbackene Gerber-Output mit vielen Files. Das > mag ja Industrie-Standard sein, aber warum geht das nicht einfach in > einer einzigen Layout-Datei wie bei Eagle? Wenn Dich die paar Dateien (von denen Du auch wählen kannst, welche überhaupt erzeugt werden sollen) stören, kannst Du sie doch einfach in eine ZIP-Datei packen. So werden die auch problemlos von Elecrow etc. akzeptiert. Und genau aus dem von Dir genannten Grund gibt es bei KiCad Gerber: weil es eben Industriestandard ist und wirklich jeder Leiterplattenfertiger damit etwas anfangen kann. Niemand benötigt noch ein proprietäres Format - es gibt eh schon mehr als genug.
:
Bearbeitet durch Moderator
Rene K. schrieb: > nächstes Problem: Wie zum Geier verschiebt man auf der Platine ein > Bauteil?! Mit links und ziehen, geht nicht. Mit Rechts und "Verschieben" > ploppt dann ein Fenster auf und sagt ich solle eine Referenz eingeben. ...also nach der ersten Platine hatte ich irgendwann gemerkt, dass man "richtig" mit links in ein Bauteil klicken kann, um es danach mit links zu verschieben. Und das "richtig" heisst einfach, dass man zwar im Bereich des Bauteils klicke muss, aber ohne eines der Bestandteile wie "Referenz" oder "Silk" zu treffen. Erkennt man dann am "highlighting", geht oft nur bei passendem Zoomlevel, hab' mich a aber dran gewöhnt. Der Weg über Rechtsklick ist natürlich "sicherer", aber es sind halt ein paar Klicks mehr. Btw, so richtig warm geworden bin ich mit Kicad erst nach dem Wechsel auf die "Nightlies". Macken gibt's aber m.E. durchaus noch einige, und seien es nur die diversen Dateidialoge, die sich mal an "Normen" halten, und mal nicht.
Weril ich mich aktuell grad wieder (mit Eagle) ärgere: Wie ist das Handling von Bauteilen mit unterschiedlichem pitch in Kicad? Das raster umschalten geht in Eagle ja schnell, was ich mir wünsche wäre den "Raster-Nullpunkt" mal schnell auf die Mitte eines ICs zu verschieben, wenn ich in diesem Umfeld route. In Eagle plag ich mich da immer mit kgv-Rechnern, "move (>0 0) (62.5 125)" und ohne Taschenrechner daneben geht sowieso gar nix...
Bob A. schrieb: > Chris D. schrieb: >> "D" (drag) bewegt mit Leiterbahnen > > klappt bei mir nicht, wünsche ich mir aber öfters :( Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü).
Chris D. schrieb: > Bob A. schrieb: >> Chris D. schrieb: >>> "D" (drag) bewegt mit Leiterbahnen >> >> klappt bei mir nicht, wünsche ich mir aber öfters :( > > Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü). Nö, geht leider auch nicht... Ist das in der 5.0er rausgeflogen? Da hat sich ja einiges geändert.
Chris D. schrieb: > Bob A. schrieb: >> Chris D. schrieb: >>> "D" (drag) bewegt mit Leiterbahnen >> >> klappt bei mir nicht, wünsche ich mir aber öfters :( > > Ach Sorry, ist auch nicht "D", sondern "G" (siehe Kontext-Menü). Doch, 'd' ist für Drag bei Leiterbahnen. Funktioniert aber nur wenn du auch im "Leiterbahn verlegen Modus" bist (im OpenGl Canvas). mfg
:
Bearbeitet durch User
Bob A. schrieb: > Nö, geht leider auch nicht... > Ist das in der 5.0er rausgeflogen? Da hat sich ja einiges geändert. Hmmm, gute Frage, kann ich mir aber nicht vorstellen. Wir arbeiten hier noch mit 4.0.6. Ich installiere nachher mal die neue parallel.
Ich kann dieses Tutorial für Neueinsteiger empfehlen: http://docs.kicad-pcb.org/4.0.5/de/getting_started_in_kicad.pdf Vorher dachte ich auch Kicad ist sche*ße. Danach war waren mir die Grundlagen klar und fand es deutlich besser als Eagle. mfg
Bob A. schrieb: > Wieso Gebashe? Das war nicht auf dich bezogen. Rene K. schrieb: > Ich habe mir das gerade mal angetan. Rene K. schrieb: > ruckelte es wie die Hulle. > Am Rechner kann es eigentlich nicht liegen, Rene K. schrieb: > Entschuldigt bitte, aber bei allen anderen ECAD die mir so über den Weg > gelaufen (Eagle, Target, Altium) sind öffne ich den PCB Editor und finde > halt meine Bauteile da irgendwo auf dem Blatt die ich mir dann > zurechtrücke und ich sie verbinden kann. > Nach ca. ner Stunde insgesamt hab es dann erstmal wieder ausgemacht und > sein lassen. Rene K. schrieb: > Ohne sich vorher erstmal in Tutorials einzulesen Mimimi. Das meine ich. Ein CAD, egal ob E oder M, kann nicht intuitiv zu bedienen sein. Dafür ist die Sache zu komplex. Die Qualität zeigt sich dann an anderer Stelle, z.b. Tastaturshortcuts für alles wichtige. Oder einen p&s Router. Oder oder oder. Die Diskussion über den gewohnten Workflow ist so lächerlich dass mir kein Wort dafür einfällt. Andererseits fragt der Faden nach Erfahrungen... Bitte entschuldigt mich. Wahrscheinlich bin ich voreingenommen weil kicad >> Eagle. Arbeite damit in der Arbeit. Gerade an 8 Lagen.
Karl schrieb: > Tastaturshortcuts für alles wichtige. Oder > einen p&s Router. Nuja gut, Tastaturshortcuts gibt es bei beiden - einstellbar - und P&S hat ja nun auch endlich bei Eagle Einzug gehalten. Das ist nun wirklich beides kein Kriterium das für oder wieder eines der beiden Systeme spricht. Für mich es ist es schon wichtig das es einen gewissen Workflow gibt, das hat auch nichts mit "Mimimi" zu tun. Und ganz ehrlich, bis jetzt empfinde ich halt Eagle noch "einfacher" als halt KiCad - einfach weil es selbstklärender ist. Wie schon oben erwähnt wurde, muss solch ein ECAD nicht völlig überfüllt von Möglichkeiten sein - und ein separates Netzlisten System welches eigentlich nur dafür da ist von Programm A (EESHEMA) zu Programm B (PCBNew) zu übergeben ist halt ein Punkt der den Workflow nicht gerade zuträglich ist. Dagegen steht dann aber wiederum bei EAGLE das, wenn ich ein FP eines Teiles ändere (Was übrigens bei Wechsel von z.b. 0805 auf 0603 ganz genau zwei Klicks sind) - das das Bauteil dann sofort wieder außerhalb des PCB platziert wird. Das ist dann bei Eagle wiederum nervig ohne Ende. Karl schrieb: > Die Qualität zeigt sich > dann an anderer Stelle Wenn ein CAD auf einer Workstation ruckelt? Qualitativ unwichtig? Eine hohe Einstiegshürde und enorme Lernkurve = Kosten für ein Unternehmen? Qualitativ unwichtig? Ein Programm aus vielen Einzelprogrammen gebastelt - wo man Paramterlisten übergeben muss? Qualitativ unwichtig? Kein fester Support? Qualitativ unwichtig? Genau da sind die Punkte und nicht bei Shortcuts die man auch noch selbst belegen kann. P&S ließe ich natürlich bis V7 gelten, aber in der 8er gibt es das ja nun. Bis jetzt war es eine sachliche Diskussion über den Umstieg, den sicherlich einige gehen werden, auch ich. Belasse es bitte dabei. Es gibt schon genügend "EAGLE-KiCad-Bash-Threads" lass dich bitte dort aus.
Ganz ehrlich KiCad und Eagle sind beide Scheisse. Trotzdem benutze ich sie mangels Alternativen. Es gibt halt nix besseres was Kostenfrei ist.
Rene K. schrieb: > Nuja gut, Tastaturshortcuts gibt es bei beiden - einstellbar - und P&S > hat ja nun auch endlich bei Eagle Einzug gehalten. Das ist nun wirklich > beides kein Kriterium das für oder wieder eines der beiden Systeme > spricht. Stimmt. Mein Umstieg ist schon länger her. Eagle 4.6 war das damals. Also auch noch bevor kicad push and shove konnte. Damals war es halt der online DRC. Rene K. schrieb: > Für mich es ist es schon wichtig das es einen gewissen Workflow gibt, > das hat auch nichts mit "Mimimi" zu tun. Doch genau das hat es. Du willst "deinen" Workflow behalten. OK. Bleib dabei. Aber Kreide es nicht einem anderen CAD an, dass es nicht Eagle ist... Rene K. schrieb: > einfach weil es selbstklärender ist Das muss und will es nicht sein. Rene K. schrieb: > Wenn ein CAD auf einer Workstation ruckelt? Qualitativ unwichtig? Nein. Deine Ausdrucksweise nervt mich. Eine > hohe Einstiegshürde und enorme Lernkurve = Kosten für ein Unternehmen? > Qualitativ unwichtig? Bla bla. Warum hat es mich damals genau zehn Minuten gekostet das erste Projektchen zusamnenzuklicken? Mit weniger Tutorials. Weil ich es lernen wollte. Das ist der Unterschied zu "eine Stunde lustlos rumklicken". Ein Programm aus vielen Einzelprogrammen gebastelt > - wo man Paramterlisten übergeben muss? Qualitativ unwichtig? Bla. Das sind zwei Mausklicks und drei Mal enter. Kein > fester Support? Qualitativ unwichtig? Durchaus nicht. Wer auf Support angewiesen ist, vergleicht nicht unbedingt Eagle mit kicad. Das ist doch eher Hobby und Gelegenheitsarbeit, bei der sich ein Profi CAD nicht lohnt. Rene K. schrieb: > Bis jetzt war es eine sachliche Diskussion über den Umstieg, den > sicherlich einige gehen werden, auch ich. Belasse es bitte dabei. ?Nö. In jedem thread das gleiche Lied. Eagle ist nicht kicad aber ich habs auch nicht ernsthaft probiert. So geht der Refrain.
Beitrag #5343873 wurde von einem Moderator gelöscht.
Rene schrieb: > Man hat oft den Eindruck so ein System wird nicht aus > Anwendersicht geschaffen sondern Entwickler gestalten ganz nach ihren > Mitteln und Fähigkeiten. Tja, meine Rede seit langem. Chris D. schrieb: > "M" (move) bewegt das Bauteil > "G" (drag) bewegt mit Leiterbahnen > usw. > > Ja, ist anders, aber nicht schlechter Nö. Ist anders UND schlechter. Wenn man auch jetzt noch mit dem Move die Netze und Leiterzüge abreißt, WOZU soll dieses Kommando dann eigentlich gut sein? Zum Stiften von Designfehlern? Mein Vorschlag: das M Kommando entfernen und das G Kommando in M umbenennen. Hätte schon längst erledigt sein können. Nein Chris, ich lese hier wenn es um Kicad geht, immer wieder, daß es ja SOOO komplex sei und man genau DESHALB zuerst ganz viel lernen müsse, bis man in der Lage ist, es zu benutzen. Im Klartext heißt das ganze Geschafel von der steilen Lernkurve, daß das Produkt eben bloß schlecht konstruiert ist. Das ist alles, was man dazu noch sagen kann. Genau DAS ist eben mal wieder die eingeschränkte Sicht der Programmierer, die ihr Produkt eben nicht aus Sicht des Benutzers sehen bzw. sehen wollen. Ich sag dazu nur eines: Im Grunde soll die Maschine dem Menschen dienen und nicht umgekehrt. Und dazu soll ein Programm eben nach den bedürfnissen des benutzers konstruiert sein und nicht der Benutzer nach den Bedürfnissen eines Programmes. Bob A. schrieb: > wäre halt schon cool wenn man wüsste was die beim CERN damit > anstellen... Da kann ich nen Beitrag liefern: Die benutzen Kicad und zugleich auch.. - nun bei einem Treffen vor geraumer Zeit hat einer meiner Ex-Kommilitonen sich heftig über die miserable Qualität der deutschen Leiterplattenhersteller beklagt. Die lieferten ihm nie das, was er an realer Leiterplatte haben wollte. So war das. Nun, bei meinen LP beachte ich die Constraints der Hersteller und bin bislang immer gut bedient worden. So verschieden kann das sein. W.S.
Rene K. schrieb: > Dagegen steht dann aber wiederum bei EAGLE das, wenn ich ein FP eines > Teiles ändere (Was übrigens bei Wechsel von z.b. 0805 auf 0603 ganz > genau zwei Klicks sind) - das das Bauteil dann sofort wieder außerhalb > des PCB platziert wird. Das ist dann bei Eagle wiederum nervig ohne > Ende. Da wechselt man auf dem Board nur das Package. Da wird nichts verschoben!?
W.S. schrieb: > Nö. > Ist anders UND schlechter. > Wenn man auch jetzt noch mit dem Move die Netze und Leiterzüge abreißt, > WOZU soll dieses Kommando dann eigentlich gut sein? Zum Stiften von > Designfehlern? Mein Vorschlag: das M Kommando entfernen und das G > Kommando in M umbenennen. Hätte schon längst erledigt sein können. Es kommt durchaus vor, dass man die Leiterbahnen gerne so liegen lassen möchte wie sie waren und von den "abgerissenen" Enden selbst weiterrouten möchte (hatte ich bei unserem letzten PCB) . Nur weil man selbst es nicht benötigt ist ein Feature nicht direkt sinnlos. Die beiden Kommandos sind also durchaus sinnvoll. Wenn es Dich stört, ist die Änderung nun wirklich einfach. Du änderst den Hotkey für Drag einfach von "G" auf "M" und löscht den von Move und speicherst die Änderungen ab. Wo ist das Problem? W.S. schrieb: > Nein Chris, ich lese hier wenn es um Kicad geht, immer wieder, daß es ja > SOOO komplex sei und man genau DESHALB zuerst ganz viel lernen müsse, > bis man in der Lage ist, es zu benutzen. Im Klartext heißt das ganze > Geschafel von der steilen Lernkurve, daß das Produkt eben bloß schlecht > konstruiert ist. Das ist alles, was man dazu noch sagen kann. Dass es komplex sei und man so viel lernen müsse, liest man nur von denjenigen, die das hier schreiben. Das ist aber immer so: die, die zu meckern haben, tun das deutlich lauter als die, die zufrieden sind. Und wer die negativen Berichte über Eagle hier zählt, muss das für eine grottenschlechte Software halten. Was genau so falsch ist. Das ist also kein Maßstab - insbesondere, wenn man vorher Eagle benutzte. Da hat man nämlich auch nicht einfach so angefangen (ich weiß das noch gut von mir selbst), sondern die Lernkurve war entsprechend steinig. Aber: man wollte es und hatte auch keine andere Wahl, denn es gab kaum andere Software. Jetzt ist das anders: man hat Eagle, kommt damit zurecht, und probiert eine neue Software aus, aber nicht weil man muss sondern weil man einfach mal gucken möchte oder die beschränkte Platinengröße der kostenlosen Version nicht mehr reicht. Zusätzlich ist man vom Ablauf her auf Eagle geprägt. Natürlich schmeisst man da eher hin und denkt: "Mist!". Der OP beschreibt das Phänomen ja selbst sehr gut: Bob A. schrieb: > Aber das Beste ist: Ich hab heute ein altes Eagle-Projekt wieder > anfassen müssen, und was soll ich sagen, nun kommt mir dort die > Bedienung sehr sehr komisch und nur wenig intuitiv vor lach > Ich musste suchen um die Löschen-Funktion zu finden. Und warum gibt es > unterschiedlich Knöppe für Leiterbahn löschen und Andere Sachen löschen? Man sieht - das gibt es auch genau anders herum - von einem ehemaligen Eagle-Nutzer. > Genau DAS ist eben mal wieder die eingeschränkte Sicht der > Programmierer, die ihr Produkt eben nicht aus Sicht des Benutzers sehen > bzw. sehen wollen. Ich sag dazu nur eines: Im Grunde soll die Maschine > dem Menschen dienen und nicht umgekehrt. Und dazu soll ein Programm eben > nach den bedürfnissen des benutzers konstruiert sein und nicht der > Benutzer nach den Bedürfnissen eines Programmes. Wir kommen hier seit vielen Jahren problemlos mit KiCad zurecht und setzen es professionell ein, es erfüllt also durchaus die Bedürfnisse seiner Nutzer. Man muss den Umstieg aber auch wirklich wollen - das ist der Grund, warum die meisten Leute meckern und hinschmeißen. (Das ist dasselbe wie beim Wechsel von MS Office zu bspw. OpenOffice. OO kann dasselbe wie MS Office, aber manche Dinge werden eben anders gemacht. Ebenso Windows -> Linux. Da muss man sich umstellen. Habe ich damals gemacht und es funktioniert sehr gut. Und ich habe dadurch mittlerweile einen Haufen Geld gespart - bei gleicher oder mehr Leistung.) Man gewöhnt sich an Dinge, die KiCad schon einige Zeit bietet (P&S, differential Routing, Echtzeit-3D-Darstellung usw.). Diese Dinge ersparen einfach sehr viel Zeit und hier damit Geld. Es ist schon länger einfach Stand der Technik, dass man ein 3D-Modell seiner Platine hat und das einfach in sein CAD-System übernehmen kann, um direkt das Gehäuse zu designen (oder umgekehrt). Ich bin damals allerdings zu KiCad gewechselt, weil Eagle keine hierarchischen Schaltpläne beherrschte - und auch wegen der Versionspolitik von CadSoft. Immer wieder wurde man vertröstet und es passierte: nix. Wann kamen dann Schaltplanhierarchien? Sehr viele Jahre später. Gut, dass ich nicht gewartet hab. Und wie man hier gut nachlesen kann, passierte in den letzten Versionen vor der Übernahme außer neuen Icons nicht wirklich viel. Eagle zieht mir schon zu lange immer nur (äußerst schleppend) nach. Warum also sollte jemand bei Eagle bleiben oder auch dahin wechseln, wenn der Funktionsumfang bei KiCad zumindest gleich bzw. deutlich höher ist und ich es kostenfrei und unbegrenzt nutzen kann, egal ob AutoDesk Pleite geht, es einstampft oder irgendwelche Server ausfallen? Ich habe mir gerade mal die Lizenzbedingungen für das Abo angesehen, weil hier immer von der Premium-Version die Rede war. Das ist eine Einzelplatzlizenz mit Single-User-Zugriff. Das heisst, ich würde hier mindestens zwei Lizenzen benötigen,d h. doppelte Kosten. Das Geld stecke ich dann doch lieber in neue Maschinen, Messgeräte und günstigere Preise gegenüber der proprietär lizenzierten Konkurrenz :-) Ich sehe bei Eagle schlicht keinen Mehrwert gegenüber KiCad. Bezüglich des OP kann ich sagen: Ja, der Umstieg von Eagle nach KiCad ist gut machbar, aber man muss es auch wollen und nicht nur mal eben installieren und etwas rumklicken.
:
Bearbeitet durch Moderator
W.S. schrieb: >> wäre halt schon cool wenn man wüsste was die beim CERN damit >> anstellen... > > Da kann ich nen Beitrag liefern: Die benutzen Kicad und zugleich auch.. > - nun bei einem Treffen vor geraumer Zeit hat einer meiner > Ex-Kommilitonen sich heftig über die miserable Qualität der deutschen > Leiterplattenhersteller beklagt. Die lieferten ihm nie das, was er an > realer Leiterplatte haben wollte. So war das. > > Nun, bei meinen LP beachte ich die Constraints der Hersteller und bin > bislang immer gut bedient worden. So verschieden kann das sein. > > W.S. Ist da etwas Text im ewigen Daten-Nirvana verloren gegangen? und zugleich auch was?? Kaffeemaschinen? Abisolierzangen? V8-betriebene Smoothie-Maker? ;-)) Wo ist da der Bezug zur Leiterplattenherstellung? Das kommt irgendwie abrupt aus dem Nichts... Aber: schön wenn Du alles richtig machst, hat das dein Ex-Kommilitone nicht? Oder gibt es evtl. einen anderen Grund für die Diskrepanz Layoutdaten <-> reelle Leiterplatte? Wenige Sätze, viele Fragen...
:
Bearbeitet durch User
Chris D. schrieb: > Warum also sollte jemand bei Eagle bleiben oder auch dahin wechseln, > wenn der Funktionsumfang bei KiCad zumindest gleich bzw. deutlich höher > ist Also mal Butter bei die Fische: Kann ich in Kicad für ein Bauteil auf dem Board im Boardeditor das Footprint ändern, und das wird ins Schematic übernommen, so dass auch Kopien dieses Bauteils dann dieses Footprint haben? Werden geänderte Bauteilbezeichnungen, Bauteilwerte vom Board ins Schematic übernommen? Meines Wissen wurde FB-Anno lange abgelehnt wegen "brauch mer nich".
Karl schrieb: > Also mal Butter bei die Fische: Kann ich in Kicad > für ein Bauteil auf dem Board im Boardeditor das > Footprint ändern, und das wird ins Schematic > übernommen, so dass auch Kopien dieses Bauteils > dann dieses Footprint haben? Kannst Du im Restaurant das von Dir bestellte Steak nachwürzen, so dass dann alle anderen Exemplare dieses Gerichtes auch nachgewürzt sind? > Werden geänderte Bauteilbezeichnungen, Bauteilwerte > vom Board ins Schematic übernommen? Wird die neue Würzmischung automatisch in das Rezept übernommen, das der Koch befolgt? > Meines Wissen wurde FB-Anno lange abgelehnt wegen > "brauch mer nich". Bist Du sicher? Mein Ablehungsgrund wäre "grausames Bedienkonzept".
Possetitjel schrieb: > Kannst Du im Restaurant das von Dir bestellte Steak > nachwürzen, so dass dann alle anderen Exemplare > dieses Gerichtes auch nachgewürzt sind? das ist jetzt aber schon sehr sehr an den Haaren herbeigezogen, oder? ich persönlich würde FB-Anno vermissen, und halte es NICHT für ein grausames Bedienkonzept, ganz im Gegenteil.
Michael R. schrieb: > Possetitjel schrieb: >> Kannst Du im Restaurant das von Dir bestellte Steak >> nachwürzen, so dass dann alle anderen Exemplare >> dieses Gerichtes auch nachgewürzt sind? > > das ist jetzt aber schon sehr sehr an den Haaren > herbeigezogen, oder? Findest Du? :) > ich persönlich würde FB-Anno vermissen, und halte > es NICHT für ein grausames Bedienkonzept, ganz im > Gegenteil. Zugestanden. Der Punkt ist: Jedem konkreten Arbeitsablauf liegt immer auch eine (implizite oder explizite) Vorstellung über die Dinge zu Grunde, die in diesem Ablauf bearbeitet werden. Manche dieser Vorstellungen widersprechen sich logisch; deswegen sind die Arbeitsabläufe dann nicht wirklich kompatibel. Der Programmierer hat jetzt zwei Möglichkeiten: Entweder er entscheidet sich für ein Universum, dann kann er das konsistent implementieren, aber er schließt die Abläufe m.o.w. aus, die damit nicht kompatibel sind. Oder er entscheidet sich nicht für ein Universum, sondern versucht, eine Obermenge zu implementieren, die mit allem kompatibel ist, dann wird sein Programm ein mehr oder weniger unsortierter Werkzeugkasten, mit dem alles "irgendwie", aber nix wirklich gut geht. Wer sich für die erste Variante entscheidet, ist deswegen nicht dümmer oder rückständiger als andere Leute -- er hat einfach nur eine andere Meinung zum Thema! Deswegen hat die Kritik, Programm X verfüge nicht über Funktion Y, für mich immer den Anstrich von kleinkindlichem Gestänkere, denn die wirklich wichtigen Fragen - Verfolgt Programm X eine bestimmte Bedienphilosophie? - Ist Funktion Y mit dieser Philosophie verträglich? - Warum benötige ich Funktion Y? - Ist mein Arbeitsablauf mit Programm X verträglich? werden weder gestellt noch beantwortet. Sollte sich nämlich herausstellen, dass ich Funktion Y benötige, weil ich einen Arbeitsablauf bevorzuge, der dem Konzept von Programm X widerspricht, dann könnte ich die Schuld ja nicht auf Programm X abschieben -- und DAS geht ja nun GAR NICHT! :/
Possetitjel schrieb: > Kannst Du im Restaurant das von Dir bestellte Steak > nachwürzen, so dass dann alle anderen Exemplare > dieses Gerichtes auch nachgewürzt sind? Kannst Du ein noch bekloppteres Beispiel finden? Ich habe eine Baugruppe. Beim Routing stelle ich fest, dass sich andere Gehäuseformen sinnvoller machen, zum Beispiel ein Widerstand im RM15 statt RM10, um noch ein paar Leitungen durchzubekommen oder Isolationsabstände einzuhalten. Natürlich will ich diese Änderungen auch im Schaltplan haben, und wenn ich diese Baugruppe kopiere, sollen alle Bauteile der neuen Baugruppe auch die geänderten Footprints haben. Ich verwende oft Schaltungsteile woanders wieder, oder erstelle eine neue Version einer Schaltung. Da will ich nicht jedesmal wieder die Footprints neu zuweisen müssen. Das ist so diese typische "works for me" Denke: Was ich nicht brauche, brauchen andere auch nicht.
Karl schrieb: > Natürlich will ich diese Änderungen auch im Schaltplan haben Na dann mach die Änderung doch dort... Karl schrieb: > und wenn > ich diese Baugruppe kopiere, sollen alle Bauteile der neuen Baugruppe > auch die geänderten Footprints haben. Wo ist das Problem? Ich kann mir kein Programm vorstellen dass beim Kopieren Teile der Daten auf einen vorherigen Stand zurücksetzt... Wirkt mir auch wie ein bescheidenes Beispiel deinerseits ;-) Karl schrieb: > Ich verwende oft Schaltungsteile woanders wieder, oder erstelle eine > neue Version einer Schaltung. Da will ich nicht jedesmal wieder die > Footprints neu zuweisen müssen. Außer ich irre mich, ist das gerade bei KiCad durchaus elegant gelöst. Habe das zwar noch nicht selber ausprobiert, mich aber etwas eingelesen. Vielleicht kann das jemand mit mehr Erfahrung bestätigen? Karl schrieb: > Das ist so diese typische "works for me" Denke: Was ich nicht brauche, > brauchen andere auch nicht. Geht auch so: Was ich bevorzuge, müssen auch andere toll finden. Frage: Hast Du schonmal ernsthaft mit KiCad versucht zu arbeiten? Ich hab mich am Anfang genau so schwer getan und stur gestellt, mittlerweile bin ich froh dass ich dran geblieben bin!
:
Bearbeitet durch User
Bob A. schrieb: > Na dann mach die Änderung doch dort... Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert, und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig? Workflow?
Karl schrieb: > Possetitjel schrieb: >> Kannst Du im Restaurant das von Dir bestellte Steak >> nachwürzen, so dass dann alle anderen Exemplare >> dieses Gerichtes auch nachgewürzt sind? > > Kannst Du ein noch bekloppteres Beispiel finden? Falls Dir das wichtig sein sollte, kann ich es versuchen. > Ich habe eine Baugruppe. Beim Routing stelle ich fest, > dass sich andere Gehäuseformen sinnvoller machen, zum > Beispiel ein Widerstand im RM15 statt RM10, um noch ein > paar Leitungen durchzubekommen oder Isolationsabstände > einzuhalten. Okay. > Natürlich will ich diese Änderungen auch im Schaltplan > haben, und wenn ich diese Baugruppe kopiere, sollen > alle Bauteile der neuen Baugruppe auch die geänderten > Footprints haben. Stop. Erste Bemerkung: Wenn ich eine Größe, die in den Schalt- plan gehört, ändern will, dann gehe ich in den Schaltplan- editor und ändere sie dort. Ich verlange nicht, dass ich den SCHALTplan mit dem LAYOUTeditor modifizieren kann. Zweite Bemerkung: Der Footprint hat (logisch) gar nix im Schaltplan zu suchen; das ist eine Angabe, die in die STÜCKLISTE gehört. Aus mir rätselhaften Gründen gibt es weite Teile der EDA-Welt, die sich standhaft weigern, die Stückliste als gleichberechtigte Fertigungsunterlage neben z.B. dem Schaltplan und dem Layout anzusehen. > Ich verwende oft Schaltungsteile woanders wieder, oder > erstelle eine neue Version einer Schaltung. Da will > ich nicht jedesmal wieder die Footprints neu zuweisen > müssen. Das verstehe und akzeptiere ich. Komponenten rekursiv aus anderen Komponenten zusammen- zusetzen führt auf eine Baumstruktur oder eine Halb- ordnung. Bäume bilden Hierarchien ab. Du meckerst über fehlende feedback annotation, beschreibst aber hierarchisches Schaltplandesign. Findest Du das logisch? > Das ist so diese typische "works for me" Denke: Was > ich nicht brauche, brauchen andere auch nicht. Möchtest Du diesen Vorwurf vielleicht nochmal überdenken?
Karl schrieb: > Das man ein Bauteil beim Layouten direkt im Boardeditor > ändert, und nicht erst auf den Schaltplaneditor wechselt, > das Bauteil sucht, ändert, und die Änderung wieder in > den Boardeditor übernimmt ist sooo abwegig? Deine Idee ist keineswegs abwegig. Aber nicht alles, was "nicht abwegig" ist, ist deswegen schon gleich sinnvoll.
Karl schrieb: > Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und > nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert, > und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig? Nö, aber nicht wirklich logisch. Der Layout-Editor ist dazu da die Teile zu platzieren und zu verbinden. Wäre für mich "nice to have", aber sicher kein Ausschlusskriterium. Komischerweise lese ich von den Gegner nie was zu tatsächlichen Schwächen (gibt einige...) von KiCad, sondern nur irgendwas was eagle kann und KiCad nicht...
:
Bearbeitet durch User
Bob A. schrieb: > Karl schrieb: >> und wenn ich diese Baugruppe kopiere, sollen alle >> Bauteile der neuen Baugruppe auch die geänderten >> Footprints haben. > > Wo ist das Problem? Ich kann mir kein Programm vorstellen > dass beim Kopieren Teile der Daten auf einen vorherigen > Stand zurücksetzt... Das nicht -- aber es kann andere Daten kopieren, als der Nutzer GLAUBT, das kopiert werden... > Wirkt mir auch wie ein bescheidenes Beispiel deinerseits ;-) Nein, nicht unbedingt. Vielleicht ist das nicht exakt das Gleiche, aber ich hatte solche Probleme vor vielen Jahren auch mit OrCAD: Änderungen sind aus für mich nicht nachvollziehbaren Gründen nicht in abgeleitete Versionen der Baugruppe übernommen worden. Ich habe nie wirklich verstanden, wann welche Änderung in welches Exemplar übernommen wird. Letztlich hatte ich nicht begriffen, wie die Projektverwaltung dort funktioniert. (Später habe ich dann gelernt, dass mein Vorgänger genau dieselben Schwierigkeiten hatte.)
Possetitjel schrieb: > Aber nicht alles, was "nicht abwegig" ist, ist deswegen > schon gleich sinnvoll. Ich fand es jetzt 18 Jahre lang sinnvoll. Der Witz ist doch: Ich habe einfach gefragt: Gibt es diese Möglichkeit in Kicad inzwischen? Und statt einfach zu sagen, nein es geht nicht, wird mir lang und breit erklärt, warum ich das nicht brauche.
Ok, bei dem Thema sollte ich mich dann besser ausklinken weil ich derlei noch nie selber genutzt habe. Sorry wenn ich da jetzt aus Unwissen blöd reingegrätscht habe
Karl schrieb: > Der Witz ist doch: Ich habe einfach gefragt: Gibt es diese Möglichkeit > in Kicad inzwischen? Und statt einfach zu sagen, nein es geht nicht, > wird mir lang und breit erklärt, warum ich das nicht brauche. Vielleicht weil es jemand Anderem schwer fällt nachzuvollziehen wieso diese Funktion ein Ausschlusskriterium für ein durchaus brauchbares Alternativprogramm sein soll?
Possetitjel schrieb: > Komponenten rekursiv aus anderen Komponenten zusammen- > zusetzen führt auf eine Baumstruktur oder eine Halb- > ordnung. Bäume bilden Hierarchien ab. Nein, ich übernehme nicht Komponenten rekursiv. Ich übernehme Baugruppen als eigenständige Kopie und Änderungen in dieser Kopie bleiben auch in dieser Kopie. Warum soll ich einen gern verwendeten Schaltregler nebst Beschaltung jedesmal neu zeichnen, wenn ich ihn in einem anderen Projekt einsetzen will. Und warum sollte ich ihm dann jedesmal die Footprints neu zuweisen, die passende Spule und Diode raussuchen... Oder ATmegas mit Standardbeschaltung: Quarz, Abblockkondensatoren, SPI-Stecker werden einfach übernommen und die zum Projekt passende Peripherie drumrumgebaut. Da muss ich nicht jedesmal mit einem weissen Blatt anfangen. Praktisch, das Board wird auch übernommen und enthält gleich Standardmaße, Standardbohrungen.
Karl schrieb: > Ich übernehme Baugruppen > als eigenständige Kopie und Änderungen in dieser Kopie bleiben auch in > dieser Kopie. Nun bin ich doch verwirrt... wolltest Du vorhin nicht dass sich die Kopie mitändert? Das Konzept an sich finde ich super!
:
Bearbeitet durch User
Possetitjel schrieb: > Zweite Bemerkung: Der Footprint hat (logisch) gar nix > im Schaltplan zu suchen; das ist eine Angabe, die in die > STÜCKLISTE gehört. ich würde sie mehr im Layout sehen als in der Stückliste; aber sie ist durchaus auch im Schaltplan relevant, sogar sehr: Der Footprint gibt nämlich auch Eigenschaften (zB Rth, Leistung) vor, welche bereits im Schaltplan definiert werden (müssen). > Aus mir rätselhaften Gründen gibt es weite Teile der > EDA-Welt, die sich standhaft weigern, die Stückliste als > gleichberechtigte Fertigungsunterlage neben z.B. dem > Schaltplan und dem Layout anzusehen. In welcher (EDA-)Welt lebst du? ich kenne niemanden der Stücklisten ignoriert; irgendwo müssen die bauteile ja auch herkommen (aka bestellt werden)
Karl schrieb: > Possetitjel schrieb: >> Aber nicht alles, was "nicht abwegig" ist, ist deswegen >> schon gleich sinnvoll. > > Ich fand es jetzt 18 Jahre lang sinnvoll. Ist ja in Ordnung; das sei Dir zugestanden. > Der Witz ist doch: Ich habe einfach gefragt: Gibt es > diese Möglichkeit in Kicad inzwischen? Und statt einfach > zu sagen, nein es geht nicht, wird mir lang und breit > erklärt, warum ich das nicht brauche. Nun, nicht ganz. Zum einen: Du hast zwar gefragt, ob es das gibt, dann aber mit der Bemerkung geschlossen: > Meines Wissen wurde FB-Anno lange abgelehnt wegen > "brauch mer nich". Das "brauch mer nich" unterstellt den KiCAD-Leuten durchaus eine gewisse Ignoranz gegenüber berechtigten Wünschen der Nutzer. Das war der Seitenhieb, der mich getriggert hat. Zum anderen: Ich bedauere, aber ich halte Dich und Deine Wünsche nicht für den Nabel der Welt. Ich habe Dir nicht erklären wollen, warum DU das nicht brauchst. Ich habe eine alternative Erklärung vorschlagen wollen, warum die KiCAD-Leute es nicht implementiert haben: Vielleicht waren sie ganz einfach der Meinung, es füge sich nicht logisch in das Bedienkonzept von KiCAD ein? Wäre das denkbar?
Karl schrieb: > Ich übernehme Baugruppen als eigenständige Kopie und > Änderungen in dieser Kopie bleiben auch in dieser > Kopie. Ja; ich glaube, ich habe Dich verstanden. Der Punkt ist: Sobald Baugrauppen nicht AUSSCHLIESZLICH aus aus Bauteilen bestehen müssen, sondern auch Baugruppen als Bestandteile enthalten können, IST das rekursiv. Es ENTSTEHT eine Hierarchie -- ob Dir das gefällt oder nicht. > Warum soll ich einen gern verwendeten Schaltregler > nebst Beschaltung jedesmal neu zeichnen, wenn ich ihn > in einem anderen Projekt einsetzen will. Und warum > sollte ich ihm dann jedesmal die Footprints neu > zuweisen, die passende Spule und Diode raussuchen... Nein -- warum solltest Du das müssen? Ich verstehe nur nicht, was das mit feedback annotation zu tun hat. Der Wunsch, Baugruppen aus (selbstentwickelten oder von außen übernommenen) Teilbaugruppen zusammensetzen zu wollen, ist mir völlig verständlich, und natürlich müssen alle zur vollständigen Beschreibung der "Muster- baugruppe" notwendigen Daten (Stückliste, Schaltplan, Layout) gemeinsam übernommen werden. Wieso ist es dazu zwingend erforderlich, den Footprint im Layouteditor zu ändern? > Oder ATmegas mit Standardbeschaltung: Quarz, > Abblockkondensatoren, SPI-Stecker werden einfach > übernommen und die zum Projekt passende Peripherie > drumrumgebaut. Da muss ich nicht jedesmal mit einem > weissen Blatt anfangen. Praktisch, das Board wird > auch übernommen und enthält gleich Standardmaße, > Standardbohrungen. Ja, ich verstehe, was Du erreichen möchtest. Ich sehe nur den Zusammenhang zur fehlenden feedback annotation nicht. (Wahrscheinlich haben die Begriffe bei Eagle eine bestimmte Bedeutung, die ich nicht kenne.)
Michael R. schrieb: > Possetitjel schrieb: >> Zweite Bemerkung: Der Footprint hat (logisch) gar nix >> im Schaltplan zu suchen; das ist eine Angabe, die in die >> STÜCKLISTE gehört. > > ich würde sie mehr im Layout sehen als in der Stückliste; > aber sie ist durchaus auch im Schaltplan relevant, sogar > sehr: Der Footprint gibt nämlich auch Eigenschaften (zB > Rth, Leistung) vor, welche bereits im Schaltplan definiert > werden (müssen). Hmmja... ich mag Dir nicht direkt widersprechen, aber ich sehe (schon seit längerem) die Gefahr, dass der Schaltplan (aus alter Gewohnheit) mit zahlreichen Daten überfrachtet wird, die sich im Schaltplan nicht optimal abbilden lassen. Ich würde z.B. die zulässige Verlustleistung als "nicht- funktionale Eigenschaft" eines Widerstandes ansehen, die deswegen nicht in den Schaltplan gehört, weil sie nicht die Schaltungsfunktion unmittelbar beeinflusst, sondern "nur" die Überlebensdauer des Bauteiles selbst. Auch z.B. für hochintegrierte Bauteile wie Mikrocontroller ist der Schaltplan suboptimal. Das ist aber ein weites Feld, und man muss meine Meinung nicht teilen. >> Aus mir rätselhaften Gründen gibt es weite Teile der >> EDA-Welt, die sich standhaft weigern, die Stückliste als >> gleichberechtigte Fertigungsunterlage neben z.B. dem >> Schaltplan und dem Layout anzusehen. > > In welcher (EDA-)Welt lebst du? Ich bin ein Außerirdischer, der auf der Erde Fuß zu fassen versucht. > ich kenne niemanden der Stücklisten ignoriert; irgendwo > müssen die bauteile ja auch herkommen (aka bestellt > werden) Nein, "ignorieren" nicht -- aber ich bin schon der Meinung, dass das Thema umfassend unterschätzt wird. Der Schwerpunkt "Bauteildatenbank" ist im Prinzip genauso groß und genauso wichtig wie der Schaltplan oder das Layout; die reine Stückliste ist nur ein Teilaspekt davon.
Possetitjel schrieb: > Ich sehe > nur den Zusammenhang zur fehlenden feedback annotation > nicht. (Wahrscheinlich haben die Begriffe bei Eagle > eine bestimmte Bedeutung, die ich nicht kenne.) FB heisst Forward-Backward-Annotation: Änderungen im Schaltplan werden sofort im Layout sichtbar, Änderungen im Layout (Footprints, Namen, Bauteilwerte) werden sofort in den Schaltplan übernommen. Zum Beispiel gibt es die Möglichkeit, im Layout sämtliche Bauteile der Position nach umzunummerieren, so dass man sie leichter findet. Diese geänderten Namen müssen natürlich auch in den Schaltplan übernommen werden. Eine Funktion, die ich zugegeben nur bei größeren Platinen nutze. Für mich entscheidend: Board und Schematic müssen konsistent sein. Es geht nicht, dass ich im Board ein anderes Footprint habe als im Schematic.
Karl schrieb: > Das man ein Bauteil beim Layouten direkt im Boardeditor ändert, und > nicht erst auf den Schaltplaneditor wechselt, das Bauteil sucht, ändert, > und die Änderung wieder in den Boardeditor übernimmt ist sooo abwegig? Ja es ist abwegig (Punkt) Der Schaltplan stellt immer die Wuzel eines Designs dar, und da hat keiner von hinten (durch du Brust) drein zu pfuschen. Das gilt besonders dann wenn Designer und Layouter 2 Personen sind. Back-Annotation ist Teufelszeug. Die Lösung ist doch ganz einfach (für den Fall das Designer und Layouter die gleiche Person ist): Man stellt da mindestens 2 große Monitore nebeneinander auf (besser drei) lädt auf dem Linken den Schaltplan in der Mitte das Layout und rechts bei Bedarf den Rest. (Datasheets, Checklisten, BOMs usw.) Änderungen werden dann immer händisch im Schaltplan durchgeführt (am jeweiligen Symbol) und nirgendwo anders ! Das betrifft in der Hauptsache Footprint, Disti Bestellnummer, Eigene Teile Nummer, Notizen u.s.w. Die weiteren Schritte wie DRC, Netzliste generieren und im Layout einlesen geht doch ratz fatz - null Problemo. Was mir in den Diskussionen zu kurz kommt sind die Checklisten. Die ersparen einem mindestens einen Leiterplatten Durchgang. Auch die leidige Lagerliste wäre ein Thema. Mal sehen wenn es zeitlich mal wieder klappt werd ich unter einem andern Synonym was vorstellen.
KiCadSuperman schrieb: > Man stellt da mindestens 2 große Monitore nebeneinander auf... Ich habe zwei große Monitore nebeneinander. > Änderungen werden dann immer händisch im Schaltplan durchgeführt > (am jeweiligen Symbol) und nirgendwo anders ! Und das ist jetzt besser als einfach im Layout auf das Bauteil zu klicken und ihm einen anderen Footprint zuzuweisen? Dass ich das jeweils im Schaltplan suche, ändere, einen DRC mache, eine Netzliste generiere und dann das Layout aktualisiere, und dann erst sehe, ob es passt. Wenn das so ist, dann könnte ihr das behalten. Das geht vielleicht für eure Arduino Bastelplatinen mit 15 Bauteilen.
Karl schrieb: > Für mich entscheidend: Board und Schematic müssen konsistent sein. Diese Forderung beinhaltet nicht dass eine Änderung in einem bestimmten Programmteil gemacht werden muss...
Karl schrieb: > Possetitjel schrieb: >> Ich sehe >> nur den Zusammenhang zur fehlenden feedback annotation >> nicht. (Wahrscheinlich haben die Begriffe bei Eagle >> eine bestimmte Bedeutung, die ich nicht kenne.) > > FB heisst Forward-Backward-Annotation: [...] Ahh okay, danke. > Zum Beispiel gibt es die Möglichkeit, im Layout sämtliche > Bauteile der Position nach umzunummerieren, so dass man > sie leichter findet. Diese geänderten Namen müssen > natürlich auch in den Schaltplan übernommen werden. Selbstverständlich. Das ist ja der wesentliche Identifikator für die Bauteile. > Für mich entscheidend: Board und Schematic müssen > konsistent sein. Es geht nicht, dass ich im Board > ein anderes Footprint habe als im Schematic. Naja, es tut mir leid, aber für meinen schwachen Verstand ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan ÜBERHAUPT einen Footprint haben sollte. Der Schaltplan ist eine abstrakte Darstellung der elektrischen Funktion der Schaltung. Angaben, die mit der elektrischen Funktion der Schaltung nicht direkt zu tun haben, gehören nicht in den Schaltplan. Das ist für mich einfach eine Frage des hinterliegenden Datenmodelles. Niemand diskutiert darüber, wie man die Farbe eines bedrahteten Widerstandes im Schaltplan abbildet, obwohl alle bedrahteten Widerstände, die ich kenne, tatsächlich eine Farbe haben -- aber die ist irrelevant, weil für die elektrische Funktion der Schaltung nicht wichtig. Dasselbe gilt für den Preis, die Länge der Anschlussdrähte, die Bestellnummer oder die Verlustleistung. Die Zuordnung von abstrakten elektrischen Eigenschaften zu konkreten, kaufbaren, bestellbaren Bauteilen macht die Stückliste (lies: SOLLTE die Stückliste machen).
Karl schrieb: > Wenn das so ist, dann könnte ihr das behalten. Das geht vielleicht für > eure Arduino Bastelplatinen mit 15 Bauteilen. Nö, geht auch problemlos bei über 250 Bauteilen (mehr hab ich noch nicht in einem KiCAD-Projekt gehabt)
Karl schrieb: > Und das ist jetzt besser als einfach im Layout auf das Bauteil zu > klicken und ihm einen anderen Footprint zuzuweisen? In KiCad wird das eben nicht sofort im Schaltplan ersetzt, und das ist gut so! Man hätte als Benützer eigentlich keine Kontrolle aus welchem "Pretty" Pool er das zumischt. Das ist für mich Kontrollverlust und nicht akzeptabel. Aus gutem Grund gibt es in PCBnew nur die Forward Annotation - Möglichkeit.
Karl schrieb: >> Änderungen werden dann immer händisch im Schaltplan >> durchgeführt (am jeweiligen Symbol) und nirgendwo >> anders ! > > Und das ist jetzt besser als einfach im Layout auf > das Bauteil zu klicken und ihm einen anderen Footprint > zuzuweisen? ??? Wovon reden diese Leute? Können wir uns für die Zwecke der laufenden Diskussion auf zwei Thesen einigen? Erstens: Daten können von vielen Stellen aus gelesen und von vielen Stellen aus geändert werden, aber sie werden programmintern nur an genau EINER Stelle gespeichert. Zweitens: Das, was man im GUI sieht, ist NICHT zwingend mit der Struktur identisch, in der die Daten programm- intern gespeichert werden. Wert, Baugröße, Footprint, Prüfspannung, Verlustleistung, Preis, Bestellnummer, ... sind Attribute eines Bauteils; die Gesamtheit dieser Attribute legt fest, um welches Bauteil es sich handelt. Jedes Bauteil hat eine ID, die projektweit eindeutig ist. Bauteile werden intern in der Stückliste gespeichert. Der Zusammenhang zwischen Stückliste, (Bauteildatenbank, ) Schaltplan und Layout wird durch die Bauteil-ID hergestellt. Ein Klick auf ein bestimmtes Bauteil -- egal in welchem "Fenster" -- bezieht sich somit immer auf eine bestimmte Bauteil-ID, die dann z.B. in allen anderen "Fenstern" selektiert werden kann ("Target3001" macht das so). Die Attribute eines selektierten Bauteils können natürlich auch geändert werden. Selektiert werden kann von überhall her; geändert wird in dem Fenster, das zuständig ist. Wo ist das Problem? So, jetzt zur Kernfrage: Was ist forward-backward-annotation?
KiCadSuperman schrieb: > In KiCad wird das eben nicht sofort im Schaltplan > ersetzt, Das beantwortet meine Frage nicht: Was hat der Footprint im Schaltplan zu suchen?
Possetitjel schrieb: > Naja, es tut mir leid, aber für meinen schwachen Verstand > ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan > ÜBERHAUPT einen Footprint haben sollte. > > Der Schaltplan ist eine abstrakte Darstellung der elektrischen > Funktion der Schaltung. Angaben, die mit der elektrischen > Funktion der Schaltung nicht direkt zu tun haben, gehören > nicht in den Schaltplan. Das ist für mich einfach eine Frage > des hinterliegenden Datenmodelles. Wir reden hier von KiCad oder Eagle und nicht von Mentor, Cadance und co :-( Possetitjel schrieb: > Die Zuordnung von abstrakten elektrischen Eigenschaften > zu konkreten, kaufbaren, bestellbaren Bauteilen macht die > Stückliste (lies: SOLLTE die Stückliste machen). Mach mich nicht schwach: Wie bitte sollen all die nützlichen Sachen in die Stückliste rein kommen? händisch ?
Possetitjel schrieb: > KiCadSuperman schrieb: > >> In KiCad wird das eben nicht sofort im Schaltplan >> ersetzt, > > Das beantwortet meine Frage nicht: Was hat der Footprint > im Schaltplan zu suchen? meine Vermutung/mein Verständnis: Das Dateiformat wurde ursprünglich so angelegt, dass das so sein muss und wegen dem Dateiformat ist bisher auch keine back-annotation möglich. Die gesamte Bedienung/Funktionalität wurde um das einmal festgelegte Dateiformat herum entwickelt und musste sich dieser bedingungslos unterordnen. Entsprechend wurde argumentiert: "Was mit dem Dateiformat nicht geht, das hast Du nicht zu brauchen. Backward Annotation? Ok, aufgrund der uns verliehen Gnade darfst Du den Footprint vom PCB ins Schematic annotaten. Damit ist das Thema Backward annotation aber jetzt abgeschlossen" ....Jahre später: "Ok, Pin swap, mmhhh. Kann das denn Eagle oder ein anderes Schrott-Tool? mhhhh." Bzgl. des Footprint ist es nicht schlimm, die Info auch im Schematic zu haben. Mein Eindruck ist jedoch, bedingt durch das bisherige Dateiformat muss das dort gemacht werden (bzw. historisch wegen dem Format so gewachsen). Bei, bzw. ab der 5er Version soll es Veränderungen am Format geben. Sehr unschön ist das unterschiedliche Verhalten und die unterschiedlichen Funktionalitäten der Anzeigemodi (Default und OpenGL). Besser als Kicad ist DesignSpark PCB. Allerdings empfehle ich nicht, heute neu damit anfangen, falls es nicht sein muss.
:
Bearbeitet durch User
Possetitjel schrieb: > Das beantwortet meine Frage nicht: Was hat der Footprint > im Schaltplan zu suchen? Ich werde mit dir keinen Glaubenskrieg anfangen. Ich vermute mal, dass weitere Diskussionen mit dir nich viel bringen werden. (und auch nicht für die Mitleser) siehe hier: Possetitjel schrieb: > Naja, es tut mir leid, aber für meinen schwachen Verstand > ist nicht nachvollziehbar, wieso ein Bauteil im Schaltplan > ÜBERHAUPT einen Footprint haben sollte. im Übrigen ist dein "TARGET 3001" nicht das mass der Dinge. das kannst du am Stellenwert hier im Platinen-Forum fesstellen.
Possetitjel schrieb: > aber die ist irrelevant, weil für die elektrische > Funktion der Schaltung nicht wichtig. > Dasselbe gilt für den Preis, die Länge der Anschlussdrähte, > die Bestellnummer oder die Verlustleistung. Die Verlustleistung ist für die elektrische Funktion der Schaltung nicht wichtig? Ich denke doch die ist sehr wichtig. Possetitjel schrieb: > Wert, Baugröße, Footprint, Prüfspannung, Verlustleistung, > Preis, Bestellnummer, ... sind Attribute eines Bauteils; > die Gesamtheit dieser Attribute legt fest, um welches > Bauteil es sich handelt. Jedes Bauteil hat eine ID, die > projektweit eindeutig ist. Das ist so leider nicht richtig. Die Welt ist leider viel viel komplizierter... Ein Widerstand im Schaltplan ist erstmal nur ein Widerstand => Footprint irrelevant. Bestellnummer irrelevant, das macht die Supply Chain. Hersteller irrelevant, das macht die Supply Chain. Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich ist der Footprint doch relevant... Es sei denn es gibt eine AML (Approved Manufacturers List)... uuups... Hersteller plötzlich doch relevant. Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90% der zeit. Und die Ausnahmen dann die anderen 90% ;-)
Michael R. schrieb: > Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich > ist der Footprint doch relevant... nein, ist er nicht. Die Verlustleistung wohl, aber der Footprint nicht. Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um beispielsweise die Impedanz fest zu spezifizieren.
Michael R. schrieb: > Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in > deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90% > der zeit. Und die Ausnahmen dann die anderen 90% ;-) Genau Diese Ausnahmen gibt es. Und eigentlich ist dies nach meinem Verständnis eben ein Argument GEGEN FB Annotation. Der Schemadesigner entwickelt die Schaltung und fügt da, wo er es für nötig hält, Attribute wie z.B. eben den Footprint hinzu. Dann kommt die Schnittstelle zum Layouter. Da kann man z.B. zusammensitzen, wobei der Layouter dann sagt: Ich hätte am liebsten durchgehend 0402 Hühnerfütter. Gut, dann legt man für alle Bauteile, bei den übrigen (meisten) Rs und Cs einen 0402er an. Was ich jetzt aber ganz sicher nicht möchte, ist, dass der Layouter findet, dass der 1210er auf dem Board jetzt aber doch viel zu viel Platz benötigt und deswegen diesem ebenfalls einen 0402er zuordnet. Selbst wenn ICH der Layouter UND der Schemazeichner bin, möchte ich das nicht. Wenn ich mich während des Layouts entscheide, dass ich einen Footprint ändern möchte, möchte ich das dort tun, wo ich die Entscheidung ursprünglich gemacht habe. Ja, es ist einfacher, dies im Layout zu tun. Ja, wenn man es im KiCad könnte, würde ich es wohl auch oft so machen. Nein, es ist kein Weltuntergang, dies halt doch im Schematool zu machen. Ja, man macht könnte dadurch durchaus erkennen, dass es sehr wohl Sinn machte, den Footprint so zu definieren, wie er definiert war. Ich halte FB Annotation nicht für Teufelszeug. Aber auch nicht für den Heiligen Gral. Es macht wohl die Arbeit oft einfacher, verleitet aber auch zu Fehlern.
Simon schrieb: > Michael R. schrieb: >> Ja, das sind Ausnahmen. Der Regelfall mag durchaus so laufen wie in >> deiner Welt. Aber du weisst ja... den Regelfall abzubilden kostet 90% >> der zeit. Und die Ausnahmen dann die anderen 90% ;-) > > Genau Diese Ausnahmen gibt es. Und eigentlich ist dies nach meinem > Verständnis eben ein Argument GEGEN FB Annotation. > > Der Schemadesigner entwickelt die Schaltung und fügt da, wo er es für > nötig hält, Attribute wie z.B. eben den Footprint hinzu. Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen Footprint. Beide haben (irgendwann im Laufe des Designs) die selben Attribute. = Bauteil. > > Dann kommt die Schnittstelle zum Layouter. Da kann man z.B. > zusammensitzen, wobei der Layouter dann sagt: Ich hätte am liebsten > durchgehend 0402 Hühnerfütter. Gut, dann legt man für alle Bauteile, bei > den übrigen (meisten) Rs und Cs einen 0402er an. Genau. Sämtliche Bestückeroptionen und Eigenschaften des PCB im Schematic festlegen. > Was ich jetzt aber ganz sicher nicht möchte, ist, dass der Layouter > findet, dass der 1210er auf dem Board jetzt aber doch viel zu viel Platz > benötigt und deswegen diesem ebenfalls einen 0402er zuordnet. Und anders herum sagt dann der PCB-Entwickler, wie der SChaltplan auszusehen hat? Oder das dann nicht? Warum nicht? Wer bestückt es denn eigentlich? Der Schematic-Zeichner nach Schematic oder was? > > Selbst wenn ICH der Layouter UND der Schemazeichner bin, möchte ich das > nicht. Wenn ich mich während des Layouts entscheide, dass ich einen > Footprint ändern möchte, möchte ich das dort tun, wo ich die > Entscheidung ursprünglich gemacht habe. Ich bin auch dafür, dass wir Schematic und PCB endlich zusammen legen, damit ich nicht ständig umzeichnen muss. Ich hätte gern die Netzvergabe und Annotations im PCB gehabt. Aber wenn dafür die gesamte PCB-Funktionalität ins Schematic soll, so wie Du das vor schlägst, so soll mir das auch recht sein.
:
Bearbeitet durch User
Lars R. schrieb: > Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen > Footprint. Beide haben (irgendwann im Laufe des Designs) die selben > Attribute. = Bauteil. Bei Kicad ist ein Attribut des Schemasymbols. Lars R. schrieb: > Genau. Sämtliche Bestückeroptionen und Eigenschaften des PCB im > Schematic festlegen. Nein. Aber die für den Layouter relevanten. Da kann man auch in KiCad noch einiges machen (Netzattribute etc.) Lars R. schrieb: > Aber wenn dafür die gesamte > PCB-Funktionalität ins Schematic soll, so wie Du das vor schlägst, so > soll mir das auch recht sein. Wo habe ich das vorgeschlagen? In einer mechanischen Zeichnung werden alle Masse etc. vermerkt. Wie genau das Teil gefräst/gedreht/gegossen/gespritzt/gedruckt werden soll, weiss der Fertiger selber besser als ich. ABER wenn eine Fläche aus welchem Grund auch immer mit einem speziellen Fräser geschlichtet werden muss, dann wird das in der mechanischen Zeichnung spezifiziert.
Hab vorletzte Woche einen FPGA-Adapter mit Kicad realisiert. Links Buchsenleiste (Zusatzplatine). Rechts Buchsenleiste (Zusatzplatine). In der Mitte Buchsenleiste (FGPA). Ich lege also mit Kicad das Schematic an: . 3 Buchsenleisten . Für Buchsenleiste links und Buchsenleiste rechts kann ich im Schematic Netznamen an den Pins vergeben. Eigentlich ist das überflüssig, aber soweit kann ich den Workflow machen. Dann layoute ich, wie es am besten passt. Dh, ich ziehe von den äußeren Buchsenleisten zur inneren die Leitungen, ohne mit den Pins der mittleren Buchsenleiste zu verbinden. Ich würde gern auch von der inneren aus zu den äußeren ziehen, aber das würde später schief gehen, weil diese Leitungen im Moment noch keinen Netz-Namen haben. Wenn ich fertig bin, gehe ich ins Schematic. Nun weiß ich, welcher Pin der mittleren Buchsenleiste welches Netz bekommt. Ich weise das so zu, wie ich im PCB die Leitungen heran gezogen habe. Dafür muss ich immer wieder ins PCB gehen zum Nachschauen. So geht es mir mit dem Design mit FPGA oder mit RAM oder mit Konfigurierbaren IOs von uCs. Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu. Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns endlich diese BS-Argumentation.
:
Bearbeitet durch User
Michael R. schrieb: > Possetitjel schrieb: >> aber die ist irrelevant, weil für die elektrische >> Funktion der Schaltung nicht wichtig. Dasselbe gilt >> für den Preis, die Länge der Anschlussdrähte,die >> Bestellnummer oder die Verlustleistung. > > Die Verlustleistung ist für die elektrische Funktion der > Schaltung nicht wichtig? Hmm. SPICE simuliert doch die elektrische Funktion der Schaltung, nicht wahr? Wo muss ich in den SPICE-Files die Verlustleistung des Widerstandes angeben? > Ich denke doch die ist sehr wichtig. Auf einer bestimmten Abstraktionsebene - ja. Auf ein einer anderen - nein. Es geht mir ja gerade darum, die verschiedenen Abstraktions- ebenen auch für den Nutzer erkennbar im Programm zu unter- scheiden! > Das ist so leider nicht richtig. Die Welt ist leider viel > viel komplizierter... > > Ein Widerstand im Schaltplan ist erstmal nur ein Widerstand > => Footprint irrelevant. Bestellnummer irrelevant, das macht > die Supply Chain. Hersteller irrelevant, das macht die > Supply Chain. > > Es sei denn er muss eine gewisse Leistung aushalten... uuups, > plötzlich ist der Footprint doch relevant... > > Es sei denn es gibt eine AML (Approved Manufacturers List)... > uuups... Hersteller plötzlich doch relevant. > > Ja, das sind Ausnahmen. Nein, ganz im Gegenteil: Das ist der Regelfall -- genauer: Es sind unterschiedliche Stadien dieses Regelfalles. > Der Regelfall mag durchaus so laufen wie in > deiner Welt. Ich denke, wir missverstehen uns. (Reale) Dinge lassen sich abstrakt als Kombinationen von Attributen (bzw. Attributwerten) beschreiben. Umgekehrt entspricht aber durchaus nicht jede Kombination von abstrakten Attributwerten einem realen Ding. Es hat überhaupt keinen Sinn, einfach den Hersteller eines Präzisionswiderstandes auf einen zugelassenen Hersteller zu ändern, wenn dieser zugelassene Hersteller den gewünschten Widerstand überhaupt nicht herstellt! Es hat daher keinen Sinn, im Programm einfach an beliebigen Stellen irgendwelche Attributwerte ändern zu können, weil das Programm schließlich die Realität (im weitesten Sinne) abbilden soll. Soll heißen: Man kann natürlich Schaltplan und Layout als getrennte Dinge ansehen, die jeweils irgendwelche Elemente mit bestimmten Attributen enthalten. So lange die Attribute der Schaltplanelemente wenig oder nix mit den Attributen der Layoutelementen zu tun haben, ist das kein Problem. Sobald man aber anfängt, Konsistenzbedingungen für diese Attribute zu fordern, ist man SEHR gut beraten, sich Gedanken über das hinterliegende Datenmodell zu machen. Wenn man das tut, stellt man fest, dass die forward- backward-annotation eine Chimäre ist, die sich bei näherer Betrachtung in Luft auflöst: Ist gibt (lt. Definition) in einem bestimmten Projekt nur (höchstens) EINEN Widerstand mit der ID "R42" (weil diese ID die Rolle eines Schlüssels spielt). R42 hat (in diesem Projekt) GENAU EINEN Footprint. Es ist absolut irrelevant, in welchem Fenster man was sieht oder wann man worauf klickt -- die Zuordnung zwischen Bauteil(-ID) und Footprint ist projektweit eindeutig. Da ist überhaupt nichts forward oder backward zu annotieren, weil in einem vernünftigen Datenmodell i.d.R. jedes wesentliche Datum nur an GENAU EINER Stelle gespeichert wird, und zwar als Attribut des Objektes, dem es gehört.
KiCadSuperman schrieb: > Possetitjel schrieb: >> Das beantwortet meine Frage nicht: Was hat der >> Footprint im Schaltplan zu suchen? > > Ich werde mit dir keinen Glaubenskrieg anfangen. Sollst Du auch gar nicht. Es genügt, wenn Du eine Antwort auf die Frage oben geben kannst. Versuche einfach, die Frage ernst zu nehmen. > Ich vermute mal, dass weitere Diskussionen mit dir > nich viel bringen werden. (und auch nicht für die > Mitleser) Sehr lahmer Versuch der Stimmungsmache.
Lars R. schrieb: > Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und > der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um > beispielsweise die Impedanz fest zu spezifizieren. Hab ich irgendwo "zwingend" gesagt? Und ja, Leiterbahn-Breiten sollen (auch) im Schematic definiert werden können (Netzklassen). Lars R. schrieb: > Footprint ist kein Attribut. Es gibt ein Symbol und es gibt einen > Footprint. Beide haben (irgendwann im Laufe des Designs) die selben > Attribute. = Bauteil. Bauteil setzt sich nicht nur aus Symbol + Footprint zusammen. Es gibt viele Parameter, die schlussendlich zu einem (konkreten) Bauteil führen, welches bestellt (und später bestückt) werden kann. Und einige dieser Parameter kommen weder aus dem Schematic noch aus dem Layout. Andere Parameter entweder/oder. Und es ist nicht einfach "nur eine Frage des Datenmodells", und das Datenmodell ist keinesfalls einfach (ich hatte vor Jahren das zweifelhafte Vergnügen, viele Daten von Nortel zu übernehmen, da durfte ich lernen wie komplex solche Datenmodelle sein können, und dass sie es nicht ohne Grund sind) Es spricht doch nichts dagegen, die Möglichkeit zu bieten, gewisse Parameter in beiden Design-Welten (also Schaltplan und Layout) zu definieren, und FB-Anno hilft, die synchron zu halten. Ob man das dann zulässt und verwendet, ist eine andere Frage. Aber ein System, welches das eben nicht zulässt, hat eine (Design-)Schwäche.
:
Bearbeitet durch User
Lars R. schrieb: > Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das > ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu. > > Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns > endlich diese BS-Argumentation. Komm mal runter. Dein Kritik ist mit deiner textuellen Beschreibung ohne Bilder kaum nachvollziehbar. Einen Weg den wir beschreiten bei ähnlichen Gegebenheiten ist folgender: Wir rufen vor dem Schaltplan zeichnen ganz zwangslos den PCBnew auf und platzieren alle relevanten Bauteile. Dazu mergen wir noch die 3d-Modelle. Wir überlegen uns dabei die Leiterführung, Bauteilgröße die beste Platzierung, und lassen diese Erkenntnis dann im eigentlichen Schaltplan einfließen und starten so unsere Projekte. Deine oben beschriebenen Probleme kennen wir so nicht.
Lars R. schrieb: > Possetitjel schrieb: >> KiCadSuperman schrieb: >> >>> In KiCad wird das eben nicht sofort im Schaltplan >>> ersetzt, >> >> Das beantwortet meine Frage nicht: Was hat der Footprint >> im Schaltplan zu suchen? > > meine Vermutung/mein Verständnis: > Das Dateiformat wurde ursprünglich so angelegt, dass das > so sein muss und wegen dem Dateiformat ist bisher auch > keine back-annotation möglich. > Die gesamte Bedienung/Funktionalität wurde um das einmal > festgelegte Dateiformat herum entwickelt und musste sich > dieser bedingungslos unterordnen. Hmm. Okay. Das klingt logisch. Das kann ich nachvollziehen; das habe ich bei einem privaten Miniprojekt auch schon erlebt. Danke für den Denkanstoß.
Michael R. schrieb: > Und es ist nicht einfach "nur eine Frage des Datenmodells", Naja, doch. > und das Datenmodell ist keinesfalls einfach DAS hat auch niemand ernsthaft behauptet. > (ich hatte vor Jahren das zweifelhafte Vergnügen, viele > Daten von Nortel zu übernehmen, da durfte ich lernen > wie komplex solche Datenmodelle sein können, und dass > sie es nicht ohne Grund sind) Ja: Ein Grund ist häufig, dass die Dinge, die im Computer abgebildet bzw. modelliert werden sollen, entstanden sind, bevor es den Begriff "Datenmodell" überhaupt gab :) Beim E-CAD ist die Sachlage insofern anders, als dass das eine relativ junge Sparte ist, die sich erst entwickelt. Wir haben also jetzt die Möglichkeit, neue Begriffe und Konventionen zu schaffen, und diese können konsistent oder widersprüchlich sein, je nachdem. > Es spricht doch nichts dagegen, die Möglichkeit zu bieten, > gewisse Parameter in beiden Design-Welten (also Schaltplan > und Layout) zu definieren, und FB-Anno hilft, die synchron > zu halten. Doch, es spricht etwas dagegen: Die Normalformtheorie. Wenn man an der Idee der Schlüsselattribute festhält, und die Bauteil-ID als ein solches auffasst, dann erschließt sich mir nicht, warum es möglich sein sollte, DEMSELBEN Bauteil mit DERSELBEN ID zwei UNTERSCHIEDLICHE Footprints zuordnen zu können. DASSELBE Bauteil hat doch auch in der Realität nur EINEN Footprint! GENAU einen! Ich spreche nicht vom GUI, nicht davon, in welchem Fenster man worauf klickt. Ich spreche vom Datenmodell. > Aber ein System, welches das eben nicht zulässt, hat eine > (Design-)Schwäche. Ich vermag nicht einzusehen, wieso ein System, das KEINE widersprüchlichen Daten zulässt, eine DesignSCHWÄCHE hat.
Michael R. schrieb: > Lars R. schrieb: > Es spricht doch nichts dagegen, die Möglichkeit zu bieten, gewisse > Parameter in beiden Design-Welten (also Schaltplan und Layout) zu > definieren, und FB-Anno hilft, die synchron zu halten. Ob man das dann > zulässt und verwendet, ist eine andere Frage. > > Aber ein System, welches das eben nicht zulässt, hat eine > (Design-)Schwäche. Auf jeden Fall. Aber so lang noch nicht einmal mal Netznamen den Weg vom PCB ins Schematic finden können... KiCadSuperman schrieb: > Lars R. schrieb: >> Dann kommen die "Spezialisten" und erklären: Genau so muss das sein. Das >> ist die ideale Arbeitsweise und deshalb lassen wir nichts anders zu. >> >> Die Entwickler dürfen realisieren, was sie wollen. Aber erspart uns >> endlich diese BS-Argumentation. > > Dein Kritik ist mit deiner textuellen Beschreibung ohne Bilder kaum > nachvollziehbar. Was gibt es da nicht zu verstehen? Ich beispielsweise 100 Signalleitungen und die müssen möglichst günstig (wenig Vias) geroutet werden. Das geht im PCBnew am realen Footprint ganz einfach, aber ohne Netznamen lässt sich da nichts verbinden. Zusätzlich schlecht ist, dass die im PCBnew bereits gezogenen Leitungen bei einer Netznamen-Änderung im schematic mit forward-annotation den geänderten Namen des Pins nicht mitnehmen. > Einen Weg den wir beschreiten bei ähnlichen Gegebenheiten ist > folgender: > Wir rufen vor dem Schaltplan zeichnen ganz zwangslos den PCBnew > auf und platzieren alle relevanten Bauteile. > Dazu mergen wir noch die 3d-Modelle. > Wir überlegen uns dabei die Leiterführung, Bauteilgröße die beste > Platzierung, und lassen diese Erkenntnis dann im eigentlichen Schaltplan > einfließen und starten so unsere Projekte. > Deine oben beschriebenen Probleme kennen wir so nicht. Weil ihr nicht ernsthaft designt. Wenn Du FPGA nicht verstehst, verstehst Du RAM? Ein RAM habe die Pins RAM_DATA0-RAM_DATA15. Der RAM soll an einem uC angeschlossen werden. Dieser hat die Pins uC_DATA0-uC_DATA15. Wie Du die Pins nun miteinander verbindest (zB. RAM_DATA0 mit uC_DATA15) ist egal. Die Schaltung funktioniert trotzdem. Ja donnerwetter. Das ist ja zauberei. Kannst Du Dir nun vorstellen, dass das einen Unterschied macht bzgl. Anzahl Vias, Anzahl Lagen und Signalqualität? Jetzt nicht 16 Leitungen, sondern 100 (100 ist ein kleines Beispiel). Zwei Lagen oder acht?
:
Bearbeitet durch User
Lars R. schrieb: > Michael R. schrieb: >> Es sei denn er muss eine gewisse Leistung aushalten... uuups, plötzlich >> ist der Footprint doch relevant... > > nein, ist er nicht. Die Verlustleistung wohl, aber der Footprint nicht. > > Entsprechend Deiner Argumentation müsste auch die Leiterbahnbreite und > der Stackaufbau und die Lage der Leiterbahn zwingend in's Schematic, um > beispielsweise die Impedanz fest zu spezifizieren. Das kann anderswo auch so gemacht werden. Ich möchte den Thread hier aber nicht unnötig weiter ins OT treiben, da ich mich eigentlich als stiller Mitleser über zahlreiche "Ich mach jetzt auch KiCad und Eagle ist ja wirklich ein Graus"-Beiträge gefreute habe. ;)
Lars R. schrieb: > Und anders herum sagt dann der PCB-Entwickler, wie der SChaltplan > auszusehen hat? Oder das dann nicht? Warum nicht? Ja. Natürlich. Wenn ich im Layout sehe, dass es besser wäre OPV A und B zu tauschen, dann ändere ich das. Wenn ich sehe, dass ich einige Leiterbahnkreuzungen sparen kann, indem ich die Pins an einem µC anders belege, dann lege ich die um. Und wenn ich aus einer Zweilagen- eine Einlagenplatine machen kann, indem ich ein paar 0-ohm-Widerstände einfüge - da muss der Schaltplan durch.
Lars R. schrieb: > Dann layoute ich, wie es am besten passt. Dh, ich ziehe > von den äußeren Buchsenleisten zur inneren die Leitungen, > ohne mit den Pins der mittleren Buchsenleiste zu verbinden. > Ich würde gern auch von der inneren aus zu den äußeren > ziehen, aber das würde später schief gehen, weil diese > Leitungen im Moment noch keinen Netz-Namen haben. > > Wenn ich fertig bin, gehe ich ins Schematic. Nun weiß ich, > welcher Pin der mittleren Buchsenleiste welches Netz bekommt. > Ich weise das so zu, wie ich im PCB die Leitungen heran > gezogen habe. Dafür muss ich immer wieder ins PCB gehen > zum Nachschauen. > > So geht es mir mit dem Design mit FPGA oder mit RAM oder > mit Konfigurierbaren IOs von uCs. "Konfigurierbar". Das merken wir uns. > Dann kommen die "Spezialisten" und erklären: Genau so muss > das sein. Das ist die ideale Arbeitsweise und deshalb lassen > wir nichts anders zu. > > Die Entwickler dürfen realisieren, was sie wollen. Aber > erspart uns endlich diese BS-Argumentation. Du hast Recht -- aber Du schüttest das Kind mit dem Bade aus. Die Entwickler sind einfach betriebsblind. Sieh es ihnen nach. Das Problem ist meiner Ansicht nach wesentlich grundsätzlicherer Natur: Der (klassische) Schaltplan ist für vielpolige programmier- bare bzw. konfigurierbare Bauteile kein sinnvolles Beschreibungs- mittel mehr.
Karl schrieb: > Lars R. schrieb: >> Und anders herum sagt dann der PCB-Entwickler, wie >> der SChaltplan auszusehen hat? Oder das dann nicht? >> Warum nicht? > > Ja. Natürlich. Wenn ich im Layout sehe, dass es besser > wäre OPV A und B zu tauschen, dann ändere ich das. ...und bekommst anschließend Schläge, weil Du natürlich nicht einen schnellen bipolaren OPV mit einem Elektrometer- FET-Opamp tauschen darfst...
Chris D. schrieb: > Es kommt durchaus vor, dass man die Leiterbahnen gerne so liegen lassen > möchte wie sie waren und von den "abgerissenen" Enden selbst > weiterrouten möchte (hatte ich bei unserem letzten PCB) Ist dir eigentlich klar, daß du mir ständig ausweichst? Ich schreibe vom Schematics und nicht vom Layout. Da gibt es keine Leiterbahnen zu routen. Abgesehen ist es ein Mumpitz, solchen Befehlen derartig irreführende Bezeichnungen zu geben. Ist dasselbe wie "typedef" bei C. Wennschon, hätte man sowas "cutout" oder nen ähnlich klingenden denglischen Namen geben müssen. Das ist genau so, als ob du ständig RECHTS sagst, wenn du LINKS meinst. Chris D. schrieb: > Dass es komplex sei und man so viel lernen müsse, liest man nur von > denjenigen, die das hier schreiben. Jetzt werd ich so langsam sauer. Ich hatte beim Ausprobieren von Kicad nicht nur einen derartigen Bug bereits binnen der ersten 10 Minuten gesehen. Denke mal an das seltsame Verhalten im Schematics, wo man zuerst irgendwo ins Schematics klicken muß und dann erst sich ein Bauteil auswählen kann, das dann aber nicht an der Maus klebt, sondern an dem zuvor angeklicktten Ort. Ist so etwas in deinen Augen etwa auch sinnvoll? Es gibt noch ne Menge anderer Abstrusitäten in Kicad und es widert mich so langsam an, von dessen Fans immer nur lesen zu müssen "das ist ein großartiges Feature!" Nee, ist es eben nicht und es wäre einfach mal angebracht, den Kopf zu senken und zuzugeben, daß es damit im Argen liegt. Einfach mal den Mist ZUGEBEN !!! Chris D. schrieb: > Das ist also kein Maßstab - insbesondere, wenn man vorher Eagle > benutzte. > Da hat man nämlich auch nicht einfach so angefangen (ich weiß das noch > gut von mir selbst), sondern die Lernkurve war entsprechend steinig. > > Aber: man wollte es und hatte auch keine andere Wahl, denn es gab kaum > andere Software. Das mag auf dich zutreffen - aber nicht auf mich. Ich hatte zu der Zeit PADS und wollte eigentlich zu Seto wechseln, ging aber nicht, weil das kurz zuvor von Mentor aufgekauft wurde (war ne ähnliche Situation wie heuer die mit Eagle8). Also, es gab zu der Zeit eine Menge anderer Programme und falls du zu dieser Zeit ein Greenhorn warest, dann solltest du nicht versuchen, dies auch bei anderen vorauszusetzen. W.S.
Das Beispiel mit dem FPGA und den vielen (beliebigen) Pads, die zu vielen (beliebigen) Pads geroutet werden müssen, ist in der Tat einleuchtend. Als ganz grosser Kicad-Fan muss ich ganz klar zugeben: Es wäre in manchen Fällen schön, wenn man das so machen könnte. Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu verwenden, weil das Gift für die Datenkonsistenz sei. Aber wie gesagt: Unqualifizierte Anmerkung. Ob die Warnung berechtigt war und ob das auf für Eagle gilt, kann ich nicht sagen. Sauber programmiert sollte das ja eigentlich schon gehen. Meine Sicht der Dinge ist nach wie vor, dass das Schema der Ursprung ist und sich das Layout diesem unterzuordnen hat. Nur im von Dir erwähnten Beispiel sehe ich, dass man sich da viel Arbeit ersparen könnte. Andererseits - das ist aber ein reines,vielleicht falsches, Bauchgefühl - würde ich selbst da ungern zulassen, dass das Schematool mir Leitungen im Schema verändert oder Labels umbenennt. Ich will z. B. auch nicht, dass irgendein Tool, z.B. gerade in diesem Kontext, meinen Sourcecode für den Prozessor verändert, so dass das Label "GPIO_LED5" nun auf "GPIOA_3" verändert wird. Der Sourcecode ist der Chef. Wenn sich im Verlauf des Layouts ergibt, dass ein anderer GPIO besser wäre, dann mache ich das im Sourcecode. Und halt eben im Schema. Es wäre viel praktischer und schneller, wenn das Layouttool das macht. Aber ich möchte es trotzdem selber machen. Aber soweit ich mich erinnere, hatte Eagle bis vor einiger Zeit keinen Online-DRC. Mit aktivem Online-DRC ist so etwas aber schlicht nicht möglich, denn man KANN die Tracks gar nicht so ziehen, dass sie dem Schema widersprechen. Wie ist denn das in Eagle gelöst? Muss man dazu den Online-DRC ausschalten?
Possetitjel schrieb: > Zweite Bemerkung: Der Footprint hat (logisch) gar nix > im Schaltplan zu suchen; das ist eine Angabe, die in die > STÜCKLISTE gehört. > Aus mir rätselhaften Gründen gibt es weite Teile der > EDA-Welt, die sich standhaft weigern, die Stückliste als > gleichberechtigte Fertigungsunterlage neben z.B. dem > Schaltplan und dem Layout anzusehen. Du hast dich verstiegen, ganz einfach verstiegen. Zuerst mal eins: eine automatische V/R-Annotation ist etwas essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als eben überragend wichtig dafür finde. Was meinst du, in was für eine Katastrophe du hineinsteuerst, wenn das auseinander driftet? Die Kundendienstler werden dir dafür den Hintern versohlen - und zu Recht! Obendrein die Fertigung und der Einkauf. Noch schlimmer wird's, wenn die Fertigung ausgelagert ist. Und sowas Wichtiges willst du freiwillig dem persönlichen Zufall überlassen - in einer Welt, wo V/R-Annotation dank leistungsfähiger PC's überhaupt kein Problem mehr ist? Und Stücklisten sind Nachbereitung. Der Entwickler hingegen hat sich auf seine Funktionalität zu konzentrieren - und dazu zählt eben auch, daß er für die Bauteile, die er in seiner Schaltung sehen will, bereits vor dem benutzen des EDA-Programms die passenden Baugrößen und damit den Footprint auswählt. DAS ist das Wichtige. In die Stückliste kommt später dann nur noch, ob der Widerstand von Beyschlag oder Isabellenhütte oder anonym per Distri und dessen Katalognummer bezogen wird. Das interessiert den Entwickler und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603 dort haben. W.S.
Simon schrieb: > dass das Schematool mir Leitungen > im Schema verändert oder Labels umbenennt Sollte natürlich "Layouttool" heissen
W.S. schrieb: > Zuerst mal eins: eine automatische V/R-Annotation ist etwas > essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß > Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz > zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als > eben überragend wichtig dafür finde. automatische V/R-Anntotation ist aber keine Voraussetzung für Datenkonsistenz. Der Maschinencode ist, wenn man die Toolchain sauber verwendet, immer konsistent mit dem Sourcecode, obwohl ich nicht im Hex-Editor eine Zahl ändern kann, und das dann automatisch den Sourcecode verändert.
Simon schrieb: > Andererseits - das ist aber ein reines,vielleicht falsches, Bauchgefühl > - würde ich selbst da ungern zulassen, dass das Schematool mir Leitungen > im Schema verändert oder Labels umbenennt. Huch? Also erstens ist es die Aufgabe des Schematic-Editors, Änerungen am Schematic zu machen. Dafür ist dieser Teil des Systems gedacht. Zweitens bist DU es, der diesen Editor benutzt und dort Änderungen vollzieht. Aber betrachte mal das Layouten: Da hast du dir im Schematic eine Schaltung ausgedacht und dabei die Bauteile so verwendet, wie es dir am sinnvollsten erschien. Dabei eben auch die OpV's in einem oder mehreren 4fach-OpV's oder die Gatter in einem 7400 oder die Widerstände in einem Widerstandsarray so verschaltet, daß sie die gewünschte Schaltung ergeben. Schön soweit. Aber beim Layouten stellst du fest, daß es wohl besser wäre, die im Schematic vorgenommene Aufteilung etwas anders vorzunehmen. Jetzt kannst du dir die Änderungen auf einen Notizzettel schreiben, ins Schematics wechseln, dort die Änderungen machen, die Netzliste exportieren, diese dann ins Layout importieren und gucken, ob du es dir so richtig gedacht hast. Finde ich umständlich. Sowas hatte man früher notgedrungen gemacht, als die PC's noch winzig im Vergleich zu heute waren. Du kannst bei einem V/R-Anno fähigen System aber auch mit Pinswap und Gateswap es gleich im Layout machen, schauen ob das nun besser ist und ggf mit Undo es wieder rückgängig machen, wenn es dir mißfällt. Das ist weitaus effizienter, als der oben skizzierte umständliche Weg. Ich sehe da eine Einschränkung: Wenn jemand beim Dienstleister sitzt und dort vorgegebene Schaltungen layoutet, ohne ein Mitspracherecht zu haben, dann ist jegliche Annotation sinnlos. Aber auf wie viele Leute trifft dieses zu? Wohl doch die Wenigsten. W.S.
Simon schrieb: > Das Beispiel mit dem FPGA und den vielen (beliebigen) Pads, die zu > vielen (beliebigen) Pads geroutet werden müssen, ist in der Tat > einleuchtend. Als ganz grosser Kicad-Fan muss ich ganz klar zugeben: Es > wäre in manchen Fällen schön, wenn man das so machen könnte. > Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich > im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir > richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu > verwenden, weil das Gift für die Datenkonsistenz sei. Aber wie gesagt: > Unqualifizierte Anmerkung. Ob die Warnung berechtigt war und ob das auf > für Eagle gilt, kann ich nicht sagen. Sauber programmiert sollte das ja > eigentlich schon gehen. Vielleicht war die in der gerade verwendeten Version kaputt. Gerade die manuelle Backward-Annotation war in diversen Tools...naja... Langjährige Nutzer beherrschten es, aber einmal falsch geklickt und der Datensatz des Designs ist Schrott. Possetitjel schrieb: > Das Problem ist meiner Ansicht nach wesentlich grundsätzlicherer > Natur: Der (klassische) Schaltplan ist für vielpolige programmier- > bare bzw. konfigurierbare Bauteile kein sinnvolles Beschreibungs- > mittel mehr. Doch schon, zur Beschreibung des Ist-Zustandes einer realisierten Schaltung. Nur sollte er mindestens teilweise aus dem PCB-Tool erzeugt werden. Dh, Netznamenvergabe und Pinzuweisung im PCB-Tool und per Backannotation erscheint der (ggf neue) Netzname im Schematic am richtigen Symbol am richtigen Pin. Das ist der Ist-Zustand (jedoch nicht bei Kicad) Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist das sehr gut. Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe, dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen bestehende) Symbol im Schematic anlegen und die Pins benetzen. Warum muss oder soll ich heute überhaupt noch Schematic-Symbole malen? Merging von Netzen im PCB/Layout-Tool auf Nachfrage. Gibt es seit Jahrzehnten (natürlich nicht bei Kicad). Demgegenüber ist das Gezerre bei Kicad manchmal schon unglaublich. Die sind konservativer und restriktiver als Intel, Texas und Siemens zusammen. Hauptsache klick-bunti.
Simon schrieb: > Meine Sicht der Dinge ist nach wie vor, dass das > Schema der Ursprung ist und sich das Layout diesem > unterzuordnen hat. Du scheinst mit dieser Sicht ja nicht ganz allein dazustehen -- aber Diskussionen wie diese haben ja auch den Zweck, mal die Frage zu stellen: Was würde passieren, wenn man mal eine andere Sicht der Dinge einnimmt? > Nur im von Dir erwähnten Beispiel sehe ich, dass man > sich da viel Arbeit ersparen könnte. Nicht nur in diesem Beispiel. Eine der wenigen Schaltungen, für die ich mal ein Layout gemacht habe, war eine Prüfschaltung mit einem Mikro- controller. Dort genau dieselbe Scheisse: Massenhaft Pins sind im Prinzip gleichwertig, weil man ohnehin in der Software definiert, welcher I/O-Pin was macht -- aber die Layoutsoftware bietet keinerlei Hilfestellung für diesen Fall. > Andererseits - das ist aber ein reines,vielleicht > falsches, Bauchgefühl - würde ich selbst da ungern > zulassen, dass das Schematool mir Leitungen im Schema > verändert oder Labels umbenennt. Nein -- das Bauchgefühl ist schon richtig: Software soll sich vorhersagbar verhalten. Auf der anderen Seite: Wenn man Bauteile und Verbindungen in den Schaltplan einfügen und auf Knopfdruck die Daten an den Layouteditor übergeben kann -- warum sollte man dann nicht auch Bauteile und Verbindungen ins Layout einfügen und die Daten per Knopfdruck an den Schaltplan- editor übergeben können? Da ist doch nix Magisches dabei.
Lars R. schrieb: > Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt > würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist > das sehr gut. > Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe, > dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen > bestehende) Symbol im Schematic anlegen und die Pins benetzen. Ach? Also du ziehst dir nen QFP64 ins Board und erwartest von der EDA-Software, daß sie deine Gedanken lesen kann und das richtige Symbol ins Schematic packt. O ha. War das nun ein Mikrocontroller oder ein CPLD oder ein Audiocodec oder was ganz anderes? Nee, deine Gedanken sind wirr. Bei ein wenig Nachdenkens wäres du von selber auf den immanenten Unsinn gekommen. Aber auch das Gegenteil ist Nonsense: In eine Schaltung zeichnet man Symbole, aber die stehen für einen Teil eines real existierenden Bauteils und dieses nun hat einen Footprint. Nochmal zur Klarheit: Ein Symbol hat KEINEN Footprint. Das Haben eines Footprints ist das alleinige Privileg eines echten Bauteils - und dieses Bauteil kann seinerseits mit einem oder mehreren (im Prinzip beliebig vielen) Symbolen in der Schaltung beschrieben werden. W.S.
Possetitjel schrieb: > Ja: Ein Grund ist häufig, dass die Dinge, die im Computer > abgebildet bzw. modelliert werden sollen, entstanden sind, > bevor es den Begriff "Datenmodell" überhaupt gab :) Ach... Nortel hat vermutlich schon Datenmodelle gemacht, da warst du noch nicht auf der Welt... > Beim E-CAD ist die Sachlage insofern anders, als dass das > eine relativ junge Sparte ist, die sich erst entwickelt. > Wir haben also jetzt die Möglichkeit, neue Begriffe und > Konventionen zu schaffen, und diese können konsistent oder > widersprüchlich sein, je nachdem. ECAD jung? Ach... >> Es spricht doch nichts dagegen, die Möglichkeit zu bieten, >> gewisse Parameter in beiden Design-Welten (also Schaltplan >> und Layout) zu definieren, und FB-Anno hilft, die synchron >> zu halten. > > Doch, es spricht etwas dagegen: Die Normalformtheorie. Ach ach ach... W.S. hat es auf den punkt gebracht: Du hast dich verstiegen. Schlaf mal drüber...
W.S. schrieb: > Possetitjel schrieb: >> Zweite Bemerkung: Der Footprint hat (logisch) gar nix >> im Schaltplan zu suchen; das ist eine Angabe, die in die >> STÜCKLISTE gehört. >> Aus mir rätselhaften Gründen gibt es weite Teile der >> EDA-Welt, die sich standhaft weigern, die Stückliste als >> gleichberechtigte Fertigungsunterlage neben z.B. dem >> Schaltplan und dem Layout anzusehen. > > Du hast dich verstiegen, ganz einfach verstiegen. Natürlich. Und so lange ich keine guten Sachgründe sehe, von meiner Meinung abzurücken, rücke ich nicht ab. (Du machst das ja schließlich auch nicht anders, oder?) Die bloße ständig wiederholte Behauptung, ich hätte Unrecht, überzeugt mich nicht davon, dass ich Unrecht habe. > Zuerst mal eins: eine automatische V/R-Annotation ist > etwas essentielles [...] Nein. Du setzt unhinterfragt voraus, was gerade geklärt werden soll: Es wird wie immer diskussionslos voraus- gesetzt, DASS es zwei Datenobjekte gibt, die konsistent gehalten werden müssen. Ich halte -- zum wiederholten Male -- entgegen: Innerhalb eines Projektes gibt es nur EINEN EINZIGEN R42; datenbank- technisch gesprochen ist die ID "R42" ein Schlüssel. Das ist auch sinnvoll, weil es auf der fertigen Leiterplatte AUCH NUR EINEN EINZIGEN R42 gibt. Dieser R42 hat ein Schaltplansymbol, einen Wert, ein Gehäuse, einen Footprint (und vielleicht noch weitere Attribute). Den internen Container, in dem die EDA-Software solcherart Zuordnungen speichert, nenne ich "Stückliste". Und ich wiederhole verzeifelt meine Frage: WAS soll da forward und backward annotiert werden, um es konsistent zu halten? Es gibt da nichts konsistent zu halten, weil die Zuordnung nur ein einziges Mal gespeichert wird! Und sie wird nur ein einziges Mal gespeichert, weil es nur einen einzigen R42 GIBT ! Im Schaltplaneditor ist R42 ein Fremdschlüssel, über den der Widerstandswert und z.B. das Symbol aus der Datenbank namens "Stückliste" abgerufen werden können. Im Layouteditor ist R42 auch ein Fremdschlüssel, über den der Footprint aus der Datenbank namens "Stückliste" abgerufen werden können. Was ist daran so kompliziert? Ich bin -- auch wenn es nicht so scheinen mag -- durchaus lernwillig, aber dafür gibt es eine Bedingung: Wer meine Gedanken durch Anwendung passender Argumente ändern möchte, der möge sich BITTE auf das oben von mir skizzierte Modell einlassen und mir zeigen, warum es nicht praxisgerecht ist. Die bloße Behauptung "Das ist Schwachsinn" oder "in Eagle geht das ganz anders" genügt nicht. (Ach so, nur zur Klarstellung: Mir ist bewusst, dass die übliche EDA-Software nicht dem oben skizzierten Modell folgt. Genau das halte ich ja auch für den fundamentalen Fehler der üblichen EDA-Software.)
W.S. schrieb: > Zuerst mal eins: eine automatische V/R-Annotation ist etwas essentielles..... Nur wenn man Änderungen im Layout machen kann, die man besser wo anders gemacht hätte. Bleibt doch beim Adler. Aber hört bitte endlich auf, dessen Designentscheidungen als das einzig wahre zu predigen. Ist ja wie in der Kirche hier. Im Mittelalter. Kreuzzüge inkl.
W.S. schrieb: > Lars R. schrieb: >> Fortschrittlich wäre es, wenn das Schematic komplett automatisch erzeugt >> würde. Gerade bei kleineren Schaltungen und bei Einmann-Projekten ist >> das sehr gut. >> Wenn ich einen Footprint ins PCB ziehe und Netznamen an die Pins gebe, >> dann soll er halt automatisch das (ggf aus mehren Teil-Symbolen >> bestehende) Symbol im Schematic anlegen und die Pins benetzen. > > Ach? > > Also du ziehst dir nen QFP64 ins Board und erwartest von der > EDA-Software, daß sie deine Gedanken lesen kann und das richtige Symbol > ins Schematic packt. Ja genau. Entweder es wird ein Symbol (Bauteil) ausgewählt oder ein neues Symbol erstellt. Bei QFP64 ist klar, wie viele Pins an jeder der 4 Seiten des Package sind. Je nach Nutzereinstellung soll er schon mal standardmäßig ein 4-teiliges Symbol machen. Vielleicht reicht mir das ja schon und nach dem Erstellen des PCB ist auch das Schematic fertig. Auf jeden Fall will ich nicht die Vierecke des Symbols malen und die Pins in einem bestimmten Abstand einzeln anlegen. Auch nicht parametrisiert. Denn das Symbol verwendet dann ein bestimmtes Pin-Raster. Und für ein anderes Pin-Raster male ich ein neues Symbol. Das ist überhaupt nicht erforderlich und stammt aus einer Zeit, als die Rechner zu dumm waren, um ein Viereck zu zeichnen. Teilweise gibt schließlich bereits Funktionen, um Powerpins in einem Teilsymbol automatisch zusammen zu fassen. Die Eingabe der Pinbezeichner eines Symbols sollte prinzipiell über CSV-Dateien erfolgen (falls überhaupt). Warum soll ich dafür in einer GUI herum klicken und mir die Arbeit machen, die Striche zurecht zu rücken?
Michael R. schrieb: > Possetitjel schrieb: >> Ja: Ein Grund ist häufig, dass die Dinge, die im Computer >> abgebildet bzw. modelliert werden sollen, entstanden sind, >> bevor es den Begriff "Datenmodell" überhaupt gab :) > > Ach... Nortel hat vermutlich schon Datenmodelle gemacht, > da warst du noch nicht auf der Welt... Ja - und? Ich kenne Dich eigentlich als sachlichen Teilnehmer und diskutiere gern mit Dir; könntest Du bitte wieder auf die Sachebene zurückfinden? >> Beim E-CAD ist die Sachlage insofern anders, als dass das >> eine relativ junge Sparte ist, die sich erst entwickelt. >> Wir haben also jetzt die Möglichkeit, neue Begriffe und >> Konventionen zu schaffen, und diese können konsistent oder >> widersprüchlich sein, je nachdem. > > ECAD jung? Ach... Natürlich. Der Siegeszug des Drehstromes begann WIMRE 1898. Anlass für die Entwicklung der Vierpoltheorie war u.a. die Entwicklung des Telephonnetzes; ich habe jetzt nicht gegurgelt, aber Feldtkeller und Co. müssen so um 1920 herum aktiv gewesen sein. Wo war da ECAD? ECAD kann frühestens in den 70ern weitere Kreise gezogen haben -- passend zur Feier "100 Jahre Elektrotechnik". >>> Es spricht doch nichts dagegen, die Möglichkeit zu bieten, >>> gewisse Parameter in beiden Design-Welten (also Schaltplan >>> und Layout) zu definieren, und FB-Anno hilft, die synchron >>> zu halten. >> >> Doch, es spricht etwas dagegen: Die Normalformtheorie. > > Ach ach ach... > > W.S. hat es auf den punkt gebracht: Du hast dich verstiegen. > Schlaf mal drüber... Du machst mich echt wütend. Wenn Du ein Sachargument hast, dann sollte ich als Dein Diskussionspartner es Dir doch wert sein, dass Du es hier auch darstellst. (Oder habe ich Dich irgendwo herabgesetzt oder beleidigt? Das war nicht meine Absicht.) Dauernd wird hier beschworen, dass Daten konsistent gehalten werden müssen -- aber nirgendwo wird für mich nachvollziehbar erklärt, warum man sie überhaupt mehrfach speichern muss!
Lars R. schrieb: >> Also du ziehst dir nen QFP64 ins Board und erwartest >> von der EDA-Software, daß sie deine Gedanken lesen >> kann und das richtige Symbol ins Schematic packt. > > Ja genau. Wie soll das gehen? Schließlich gibt es hunderte ganz verschiedene Bauteile im QFP64.
Possetitjel schrieb: > Lars R. schrieb: > >>> Also du ziehst dir nen QFP64 ins Board und erwartest >>> von der EDA-Software, daß sie deine Gedanken lesen >>> kann und das richtige Symbol ins Schematic packt. >> >> Ja genau. > > Wie soll das gehen? > > Schließlich gibt es hunderte ganz verschiedene Bauteile > im QFP64. Das habe ich doch geschrieben: Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern" Wie ist Deine Frage? Edit: Pinbezeichner könnte sich das Programm auch vorläufig aus den im Layout-Tool zugewiesenen Netznamen holen. Es geht doch darum: Wenn ich ein Design aus dem Handgelenk machen will, dann will ich genau das. Und ich will die Symbole nicht anlegen. Es ist doch klar, wie das Symbol auszusehen hat: . Bei kleinen Footprints (Pinzahl) sieht das Symbol wie der Footprint aus . sonst: strukturiert; ggf. Teilsymbole
:
Bearbeitet durch User
Lars R. schrieb: > Das habe ich doch geschrieben: > Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern" > > Wie ist Deine Frage? Das habe ich doch geschrieben: Wie soll das gehen? SCNR > Edit: > Pinbezeichner könnte sich das Programm auch vorläufig > aus den im Layout-Tool zugewiesenen Netznamen holen. > Es geht doch darum: Wenn ich ein Design aus dem Handgelenk > machen will, dann will ich genau das. Dann habe ich nicht verstanden, was Du gemeint hast. Lass' mich beschreiben, was ich verstanden habe, und korrigiere mich bitte entsprechend: Deinen Beitrag weiter oben habe ich so verstanden: Du hast ein Bauteil (z.B. einen FPGA) in der programmeigenen Bauteildatenbank ("Library"). Du fügst dieses Bauteil ins LAYOUT (nicht in den Schaltplan!) ein, ziehst Verbindungen, und möchtest diese im Layout angelegten Verbindungen im Schaltplan sehen und weiterbearbeiten können. Deinen letzten Beitrag verstehe ich anders: Du möchstest ein Layout mit einem Bauteil anlegen, das Du NICHT in der Datenbank hast. Dazu willst Du "on the fly" zunächst das Bauteil definieren, dann im Layout Verbindungen verlegen, und schließlich den zugehören Schaltplan sehen können. Die Varianten sind zwar ähnlich, aber nicht gleich. Daher meine Verwirrung.
Possetitjel schrieb: > Deinen Beitrag weiter oben habe ich so verstanden: Du > hast ein Bauteil (z.B. einen FPGA) in der programmeigenen > Bauteildatenbank ("Library"). Du fügst dieses Bauteil > ins LAYOUT (nicht in den Schaltplan!) ein, ziehst > Verbindungen, und möchtest diese im Layout angelegten > Verbindungen im Schaltplan sehen und weiterbearbeiten > können. Richtig. Für existierende Bauteile möchte ich das. Diese Bauteile haben bereits ein Symbol (oder mehrere) und sie haben bereits Pinbezeichner. Kleine Footprints, die im Layout nah beieinander sind und verbunden sind, sollen auch im Schematic automatisch beieinander angeordnet werden. > Deinen letzten Beitrag verstehe ich anders: Du möchstest > ein Layout mit einem Bauteil anlegen, das Du NICHT in der > Datenbank hast. Dazu willst Du "on the fly" zunächst das > Bauteil definieren, dann im Layout Verbindungen verlegen, > und schließlich den zugehören Schaltplan sehen können. Richtig. Ich möchte einen Footprint ins Layout ziehen. Dann soll eine Auswahl möglicher, bereits vorhandener Symbole angeboten werden. Wähle ich keines der vorhandenen Symbole aus, so soll automatisch ein Symbol (oder mehrere Teilsymbole) erstellt werden. (Teil-)automatisierte Symbol-Erstellung gibt es bereits. Das Problem ist, dass die Symbolerstellung typischerweise vor der Erstellung des Footprint erfolgt. Dh, die Vorgehensweise ist folgende: 1. Man erstellt das Symbol. 2. Man macht das Symbol hübsch, damit es ggf so ähnlich wie der Footprint aussieht, 3. Man erstellt den Footprint Bei QFP44 würde ich sagen: Das Symbol möge einfach wie der Footprint aussehen. Die Schaltung mache ich aus dem Handgelenk im Layouteditor und ich vergebe die Netznamen im Layouteditor. Das Tool erstellt bitte alle unbekannten Symbole automatisch und erstellt das Schematic automatisch. Für Pinbezeichner von Symbolen sollte es CSV-Dateien geben. Die Standardeingabe sollte NICHT grafisch sein. Pinraster im Schematic seien dynamisch. Dh, das Pinraster eines Symbols kann jeder Zeit geändert werden und dann ändert das Symbol seine Größe und die Anordnung der Pins.
Simon schrieb: > Eine ganz unqualifizierte Anmerkung dazu: Vor laaaaaanger Zeit, als ich > im Studium mal mit Protel (später Altium) gearbetet habe, wurde mir > richtiggehend eingetrichtert, die FB-Annotation NIE NIE NIE zu > verwenden Protel 99 SE? Ich weiss noch wie es unserem damaligen Elektroniker regelmäßig Schweissperlen auf die Stirn getrieben hat, wenn er den Speichern-Button klickte - und die Bombe kam. Ich hab mit Eagle seit 3.irgendwas gearbeitet, und FB-Anno ging dann schief, wenn man das Schematic geschlossen hat und allein im Board weitergearbeitet hat. Was auch irgendwo klar ist. Spätestens seit 6 warnt Eagle dann ganz gross und fett. Ich mach das manchmal, wenn ich ne kleine Leiterplatte fertiggeroutet habe und davon schnell mal ein paar Kopien nebeneinander brauche. Schematic aus, Board unter neuem Namen speichern!, Board kopieren. W.S. schrieb: > in einer Welt, wo V/R-Annotation dank leistungsfähiger PC's > überhaupt kein Problem mehr ist? Was heisst hier leistungsfähige PCs? Das ging schon vor 15 Jahren auf einem 700 MHz Pentium 3 mit 500MByte RAM. Ich seh auch nicht, wieso das groß Leistung brauchen sollte? Possetitjel schrieb: > Wie soll das gehen? > Schließlich gibt es hunderte ganz verschiedene Bauteile > im QFP64. Es ist durchaus nicht unüblich bei der Analyse einer unbekannten Schaltung - zum Beispiel zur Reparatur - sich erstmal die reinen Packages hinzupacken und so zu verbinden, wie sie auf der Leiterplatte liegen, um dann nach und nach den Schaltplan zu bereinigen und den Teilen Namen zu geben.
Hallo Possetitjel. Possetitjel schrieb: > Aus mir rätselhaften Gründen gibt es weite Teile der > EDA-Welt, die sich standhaft weigern, die Stückliste als > gleichberechtigte Fertigungsunterlage neben z.B. dem > Schaltplan und dem Layout anzusehen. Das sind die gleichen Leute, die meinen, dass in einen Schaltplan unbedingt zusätzlich zum Referenzbezeichner die Bauteilwerte eingetragen sein sollten...... Ausser bei sehr kleinen Schaltungen bzw. für Bausätze ist das aber keine so gute Idee, weil es den Schaltplan unübersichtlich macht. Ausserdem muss dann bei jeder Bauteiländerung der Schaltplan erneuert werden, und nicht nur die Stückliste. Stücklisten haben auch den Charm, dass man dort jede Menge Zusatzinformationen hineinstecken kann, die auf keinen Fall in einen Schaltplan passen würden, wie z.B. Hinweise für den Bestücker, welche alternativen Transistoren aus welcher Quelle er einsetzten darf, falls die original vorgesehehen nicht lieferbar sind. > > >> Ich verwende oft Schaltungsteile woanders wieder, oder >> erstelle eine neue Version einer Schaltung. Da will >> ich nicht jedesmal wieder die Footprints neu zuweisen >> müssen. > > Das verstehe und akzeptiere ich. > > Komponenten rekursiv aus anderen Komponenten zusammen- > zusetzen führt auf eine Baumstruktur oder eine Halb- > ordnung. Bäume bilden Hierarchien ab. > > Du meckerst über fehlende feedback annotation, beschreibst > aber hierarchisches Schaltplandesign. Findest Du das > logisch? Hierarchische Schaltpläne kann KiCad gut. So gut, dass die anno 2008 für mich der Grund zum Wechsel von Eagle nach KiCad waren. "Back annotation" braucht man tatsächlich eher nicht. Eine Schaltungsänderung wird halt zuerst im Schaltplan, und dann im Board durchgeführt. Wo ist da nun jetzt das Problem? Probleme, eine im Board durchgeführte Bastelei adäquat in den Schaltplan einzufügen? Das wäre ein Indiz für "den Überblick" verloren. ;O) >> Das ist so diese typische "works for me" Denke: Was >> ich nicht brauche, brauchen andere auch nicht. > > Möchtest Du diesen Vorwurf vielleicht nochmal überdenken? Unter diesem Aspekt könnte eine "Back annotation" von einigen als bequem eingestuft werden. Persönlich bearbeide ich aber selber schon in Gedanken den Schaltplan, auch wenn ich am (realen) Board herumbastel. Wenn ich theoretisch nicht nachvollziehen könnte, was ich da gerade Bastel, wäre ich mir selber unheimlich. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > "Back annotation" braucht man tatsächlich eher nicht. Da hast Du recht. Brauchen braucht man das nicht. Man braucht auch kein Layoutprogramm. Kann man alles von Hand auf Millimeterpapier zeichnen. Man kann auch Schaltpläne auf Karopapier zeichnen. Ham wir früher so gemacht. Stundenlang. Will ich nicht zurückhaben.
Lars R. schrieb: > Richtig. Für existierende Bauteile möchte ich das. > Diese Bauteile haben bereits ein Symbol (oder > mehrere) und sie haben bereits Pinbezeichner. Okay, soweit klar und einfach. > Kleine Footprints, die im Layout nah beieinander > sind und verbunden sind, sollen auch im Schematic > automatisch beieinander angeordnet werden. Das hat Anklänge an eine "Kartoffeldruck"-Idee: Schaltungssplitter, die als Teilmodule angelegt werden und quasi wie Bauteile aus der Library abgerufen, platziert und verschaltet werden können (triviale Beispiele: LED mit Vorwiderstand; Schalttransistor mit Basiswiderstand). Trick dabei: Diese Grundschaltungs- muster müssen trotzdem noch parametrierbar und nicht komplett vordefiniert sein. Weiterer Trick: Redundante Bauteile (z.B. Vorwiderstände), die doppelt entstehen würden, weil bei Teilschaltungen ihn mitbringen, würden erkannt und eliminiert. > Richtig. Ich möchte einen Footprint ins Layout ziehen. > Dann soll eine Auswahl möglicher, bereits vorhandener > Symbole angeboten werden. Wähle ich keines der > vorhandenen Symbole aus, so soll automatisch ein Symbol > (oder mehrere Teilsymbole) erstellt werden. Ah okay. Ich verstehe. Hmm. Warum nicht. Das läuft darauf hinaus, in der Stückliste eine ID zu erzeugen und diesem Bauteil erstmal nur einen Footprint zuzuordnen. Sollte technisch kein Problem sein (obwohl ich es von der Bedienerführung her nicht schön finde, das im Layouteditor zu machen. Das gehört "eigentlich" in die Bauteildatenbank.) > (Teil-)automatisierte Symbol-Erstellung gibt es bereits. > Das Problem ist, dass die Symbolerstellung typischerweise > vor der Erstellung des Footprint erfolgt. > Dh, die Vorgehensweise ist folgende: > 1. Man erstellt das Symbol. > 2. Man macht das Symbol hübsch, damit es ggf so ähnlich > wie der Footprint aussieht, > 3. Man erstellt den Footprint Naja, das würde mich eben dazu bewegen, das alles in das User-Interface der Bauteildatenbank (oder der "Stückliste") schieben, wo es ja rein logisch auch hingehört. Das Mantra wäre dann: Man kann weder im Schaltplan noch im Layout ein Bauteil platzieren, das nicht wenigstens eine Bauteilklassen-ID UND ENTWEDER ein Symbol (für den Schaltplan) ODER einen Footprint (fürs Layout) in der Stückliste hat. > Bei QFP44 würde ich sagen: Das Symbol möge einfach wie > der Footprint aussehen. Das ist ja leicht durch einen passenden Default machbar. > Die Schaltung mache ich aus dem Handgelenk im Layouteditor > und ich vergebe die Netznamen im Layouteditor. Was willst Du mit den Netznamen? Wegen der Pinbezeichnungen, oder warum? > Für Pinbezeichner von Symbolen sollte es CSV-Dateien geben. > Die Standardeingabe sollte NICHT grafisch sein. Ja, auf jeden Fall. Auch so eine Arbeitsbeschaffungsmaßnahme. Stellt sich die weiterführende Frage: Könnte man die Pinnamen auch (halb-)automatisch irgendwo extrahieren? Aus den Daten- blätter zum Beispiel? Oder gibt es SPICE-/VHDL-Files, wo man das entnehmen kann? > Pinraster im Schematic seien dynamisch. Dh, das Pinraster > eines Symbols kann jeder Zeit geändert werden und dann > ändert das Symbol seine Größe und die Anordnung der Pins. Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist ein anderes Trauerspiel.
Karl schrieb: > Possetitjel schrieb: >> Wie soll das gehen? >> Schließlich gibt es hunderte ganz verschiedene Bauteile >> im QFP64. > > Es ist durchaus nicht unüblich bei der Analyse einer > unbekannten Schaltung - zum Beispiel zur Reparatur - > sich erstmal die reinen Packages hinzupacken und so > zu verbinden, wie sie auf der Leiterplatte liegen, um > dann nach und nach den Schaltplan zu bereinigen und den > Teilen Namen zu geben. Okay, ja, es stimmt. Lars' Idee hörte sich zunächst abstrus an, aber es gibt dafür durchaus mehr Szenarien, als ich spontan erwartet hatte.
Possetitjel schrieb: > Ich halte -- zum wiederholten Male -- entgegen: Innerhalb > eines Projektes gibt es nur EINEN EINZIGEN R42; datenbank- > technisch gesprochen ist die ID "R42" ein Schlüssel. > Das ist auch sinnvoll, weil es auf der fertigen Leiterplatte > AUCH NUR EINEN EINZIGEN R42 gibt. > > Dieser R42 hat ein Schaltplansymbol, einen Wert, ein Gehäuse, > einen Footprint (und vielleicht noch weitere Attribute). > Den internen Container, in dem die EDA-Software solcherart > Zuordnungen speichert, nenne ich "Stückliste". Ein Footprint kann mehrere Symbole haben. Possetitjel schrieb: >> Kleine Footprints, die im Layout nah beieinander >> sind und verbunden sind, sollen auch im Schematic >> automatisch beieinander angeordnet werden. > > Das hat Anklänge an eine "Kartoffeldruck"-Idee: > Schaltungssplitter Es ging mir nur darum, dass die Symbole beieinander sind, soweit möglich. > Sollte technisch kein Problem sein (obwohl > ich es von der Bedienerführung her nicht schön finde, > das im Layouteditor zu machen. Das gehört "eigentlich" > in die Bauteildatenbank.) Kann ja. Es gibt eben einen Dialog Zuordnung-Footprint-Symbole. Nur, dieser Dialog kein zwingender Bestandteil des Schematic, sondern funktioniert auch ohne Schematic. >> Die Schaltung mache ich aus dem Handgelenk im Layouteditor >> und ich vergebe die Netznamen im Layouteditor. > > Was willst Du mit den Netznamen? Wegen der Pinbezeichnungen, > oder warum? Eine Schaltung braucht Netznamen. > Stellt sich die weiterführende Frage: Könnte man die Pinnamen > auch (halb-)automatisch irgendwo extrahieren? Aus den Daten- > blätter zum Beispiel? Ja, oder es gibt bereits Excel- oder CSV-Files. >> Pinraster im Schematic seien dynamisch. Dh, das Pinraster >> eines Symbols kann jeder Zeit geändert werden und dann >> ändert das Symbol seine Größe und die Anordnung der Pins. > > Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist > ein anderes Trauerspiel. Mir geht es darum, dass ein Symbol keine statisch gemalte Grafik zu sein braucht.
Hai Bernd. Bernd W. schrieb: >> Aus mir rätselhaften Gründen gibt es weite Teile der >> EDA-Welt, die sich standhaft weigern, die Stückliste >> als gleichberechtigte Fertigungsunterlage neben z.B. >> dem Schaltplan und dem Layout anzusehen. > > Das sind die gleichen Leute, die meinen, dass in einen > Schaltplan unbedingt zusätzlich zum Referenzbezeichner > die Bauteilwerte eingetragen sein sollten...... Naja, wie Du schon sagst: Wenn es geht, ist es sehr nett, aber es ist halt nicht immer praktikabel. > Stücklisten haben auch den Charm, dass man dort jede > Menge Zusatzinformationen hineinstecken kann, die auf > keinen Fall in einen Schaltplan passen würden, wie > z.B. Hinweise für den Bestücker, welche alternativen > Transistoren aus welcher Quelle er einsetzten darf, > falls die original vorgesehehen nicht lieferbar sind. Naja, in der Praxis kann man nicht sinnvoll auf die Stückliste verzichten. Das habe ich auf die harte Tour gelernt, als ich mal eine kleine Weile für die Kleinst- serienfertigung bei uns verantwortlich war... :) > Hierarchische Schaltpläne kann KiCad gut. So gut, dass > die anno 2008 für mich der Grund zum Wechsel von Eagle > nach KiCad waren. Das habe ich schon mehrfach gelesen; die Beschäftigung damit steht auch auf meiner Liste... > "Back annotation" braucht man tatsächlich eher nicht. > Eine Schaltungsänderung wird halt zuerst im Schaltplan, > und dann im Board durchgeführt. Wo ist da nun jetzt das > Problem? Das Problem ist (aus meiner Sicht), dass das (zumindest in manchen Fällen) "broken by design" ist. Es sollte für jede benötigte Information EINE Stelle Stelle geben, wo diese Information verbindlich gespeichert ist. Alle anderen Stellen im Programm, die die Information visualisieren, abfragen, ändern, ... müssen, sollten auf diese eine Stelle zugreifen (und zwar i.d.R. über entsprechende Funktionsaufrufe). Ich unterstütze ja die Forderung, dass die Daten projektweit konsistent sein sollen -- aber an der Diskussion über forward-backward-annotation regt mich auf, dass immer wieder eine bestimmte Lösung eines Problems eingefordert wird, das nur aufgrund eines Designfehlers überhaupt entsteht! > Probleme, eine im Board durchgeführte Bastelei adäquat in > den Schaltplan einzufügen? Das wäre ein Indiz für "den > Überblick" verloren. ;O) Naja, nicht zwingend. Das, was Lars und Karl geschrieben haben, gibt für mich schon Sinn.
Possetitjel schrieb: > Es sollte für jede benötigte Information EINE Stelle > Stelle geben, wo diese Information verbindlich gespeichert > ist. Alle anderen Stellen im Programm, die die Information > visualisieren, abfragen, ändern, ... müssen, sollten auf > diese eine Stelle zugreifen (und zwar i.d.R. über > entsprechende Funktionsaufrufe). > > Ich unterstütze ja die Forderung, dass die Daten projektweit > konsistent sein sollen -- aber an der Diskussion über > forward-backward-annotation regt mich auf, dass immer wieder > eine bestimmte Lösung eines Problems eingefordert wird, das > nur aufgrund eines Designfehlers überhaupt entsteht! Ein Footprint hat eine Pinanzahl. Ein Symbol (Symbolgruppe) hat eine Pinanzahl. Für die Zuordnung Footprint<>Symbol muss die Pinzahl überein stimmen. Ein Footprint kann eine Verlustleistung haben. Ein Symbol kann eine Verlustleistung haben. Hat ein Footprint ein Verlustleistung und hat das Symbol eine Verlustleistung, so sollten diese für eine Zuordnung Footprint<>Symbol übereinstimmen. Frage: Wo ist nun die Verlustleistung gespeichert? Antwort: Im Symbol und auch im Footprint Man kann im Schematic ein Symbol setzen ohne Footprint. Man kann im PCB einen Footprint setzen ohne Symbol. Was passiert, wenn im Schematic die Verlustleistung verändert wird, obwohl bereits eine Zuordnung Footprint<>Symbol besteht? Wird dann mangels passender Verlustleistung automatisch der Footprint im PCB gelöscht? Die Lösung/Antwort ist folgende: Das Attribut Verlustleistung existiert in der Datenbank für den Footprint und im PCB für die Instanz dieses Footprints. Das Attribut Verlustleistung existiert in der Datenbank für das Symbol und im Schematic für die Instanz dieses Symbols. Annotation verändert dann die Werte der Instanzen. Ebenso, wie diese Werte bei der Zuordnung überschrieben werden können um eine Zuordnung zu erzwingen. Dh, den Wert Verlustleistung gibt es 4x.
Lars R. schrieb: > Possetitjel schrieb: >> Ich halte -- zum wiederholten Male -- entgegen: >> Innerhalb eines Projektes gibt es nur EINEN >> EINZIGEN R42; datenbanktechnisch gesprochen ist >> die ID "R42" ein Schlüssel. Das ist auch sinnvoll, >> weil es auf der fertigen Leiterplatte AUCH NUR >> EINEN EINZIGEN R42 gibt. >> >> Dieser R42 hat ein Schaltplansymbol, einen Wert, >> ein Gehäuse, einen Footprint (und vielleicht noch >> weitere Attribute). Den internen Container, in dem >> die EDA-Software solcherart Zuordnungen speichert, >> nenne ich "Stückliste". > > Ein Footprint kann mehrere Symbole haben. Du sprichst in Rätseln. Mehr Kontext, bitte. Ein - ich will es mal "generischer Footprint" nennen - definiert nach meinem Verständnis nur Mechanik und Geometrie. Ein "spezifischer Footprint" ist Bestandteil einer Bauelement-Definition und enthält noch Pinnamen und solches Zeug. Sicherlich kann dieselbe Bauelemente-Definition auch mehrere alternative Schaltplansymbole enthalten (ein Widerstand z.B. das europäische und das Ami-Symbol) -- aber inwiefern ist das hier relevant? >> Sollte technisch kein Problem sein (obwohl >> ich es von der Bedienerführung her nicht schön finde, >> das im Layouteditor zu machen. Das gehört "eigentlich" >> in die Bauteildatenbank.) > > Kann ja. Es gibt eben einen Dialog Zuordnung-Footprint- > Symbole. Nur, dieser Dialog kein zwingender Bestandteil > des Schematic, sondern funktioniert auch ohne Schematic. Ja, selbstverständlich. In dem Punkt sind wir einer Meinung. >>> Die Schaltung mache ich aus dem Handgelenk im >>> Layouteditor und ich vergebe die Netznamen im >>> Layouteditor. >> >> Was willst Du mit den Netznamen? Wegen der >> Pinbezeichnungen, oder warum? > > Eine Schaltung braucht Netznamen. Klar, für die Netzliste -- aber rein technisch können die auch vollautomatisch erzeugt werden und N001, N002, N003 usw. sein. >>> Pinraster im Schematic seien dynamisch. Dh, das Pinraster >>> eines Symbols kann jeder Zeit geändert werden und dann >>> ändert das Symbol seine Größe und die Anordnung der Pins. >> >> Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist >> ein anderes Trauerspiel. > > Mir geht es darum, dass ein Symbol keine statisch gemalte > Grafik zu sein braucht. Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik", aber skalierbar ist sie trotzdem... :) Es ging Dir doch nur um den Aspekt, dass das Symbol keine fixierte absolute Größe haben, sondern skalierbar sein soll -- oder habe ich Dich missverstanden?
Possetitjel schrieb: >> Ein Footprint kann mehrere Symbole haben. > > Du sprichst in Rätseln. Mehr Kontext, bitte. Mehrere (Teil-)Symbole für einen Footprint. Schon mal ein Schematic Symbol mit 2000 Pins gesehen? >>>> Die Schaltung mache ich aus dem Handgelenk im >>>> Layouteditor und ich vergebe die Netznamen im >>>> Layouteditor. >>> >>> Was willst Du mit den Netznamen? Wegen der >>> Pinbezeichnungen, oder warum? >> >> Eine Schaltung braucht Netznamen. > > Klar, für die Netzliste -- aber rein technisch können > die auch vollautomatisch erzeugt werden und N001, N002, > N003 usw. sein. Ja. Sollte auch. Das sind auch Namen. Die kann man nach Bedarf ändern. >>>> Pinraster im Schematic seien dynamisch. Dh, das Pinraster >>>> eines Symbols kann jeder Zeit geändert werden und dann >>>> ändert das Symbol seine Größe und die Anordnung der Pins. >>> >>> Ja gut... automatisches Erzeugen "schöner" Schaltpläne ist >>> ein anderes Trauerspiel. >> >> Mir geht es darum, dass ein Symbol keine statisch gemalte >> Grafik zu sein braucht. > > Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik", > aber skalierbar ist sie trotzdem... :) Wenn Du in einem Schematic aber ein Viereck malst und fest legst, welchen Abstand die Pins des Symbols haben, dann ist das nicht dynamisch, sondern fest. -> "Pinraster" Das Symbol eignet sich dann nur genau für dieses Pinraster. > Es ging Dir doch nur um den Aspekt, dass das Symbol keine > fixierte absolute Größe haben, sondern skalierbar sein soll -- > oder habe ich Dich missverstanden? Ja.
Lars R. schrieb: > Ein Footprint hat eine Pinanzahl. Ein Symbol > (Symbolgruppe) hat eine Pinanzahl. Für die Zuordnung > Footprint<>Symbol muss die Pinzahl überein stimmen. Korrekt, aber ungünstiges Beispiel: Footprint und Symbol sind im Datenbanksinn verschiedene Dinge, deswegen ist dort nicht dieselbe Information redundand gespeichert, sondern es sind unterschiedliche Informationen. > Ein Footprint kann eine Verlustleistung haben. Nicht in meinen Universum. Wenn man die Information haben will, welche Leistung über Gehäuse X abführbar ist, dann formuliert man eine passende Abfrage an die Datenbank und selektiert nach Gehäuse und Verlustleistung. > Ein Symbol kann eine Verlustleistung haben. Noch viel weniger in meinem Universum. Dem europäischen Widerstandssymbol ist unter überhaupt keinen Umständen eine Verlustleistung zugeordnet. Nicht bei mir. [...] > Man kann im Schematic ein Symbol setzen ohne Footprint. > Man kann im PCB einen Footprint setzen ohne Symbol. > > Was passiert, wenn im Schematic die Verlustleistung > verändert wird, Das kann in meinem Universum nicht passieren, weil die Bauteildefinition in der Stückliste bestimmt, welches konkrete Bauteil tatsächlich verbaut wird. Wenn ein "generischer" Schaltplan gezeichnet werden soll, ist die Frage nach der zulässigen Verlustleistung nicht beantwortenbar: Welche Verlustleistung verträgt ein Widerstand in SPICE? [...] > Annotation verändert dann die Werte der Instanzen. Okay... das ist ein neues Spielfeld, das hatten wir noch nicht bisher. -- Annotationen verändern keine Werte, sondern definieren Prüfbedingungen. > Dh, den Wert Verlustleistung gibt es 4x. Nicht in meinem Universum. Keinesfalls.
Lars R. schrieb: > Possetitjel schrieb: >>> Ein Footprint kann mehrere Symbole haben. >> >> Du sprichst in Rätseln. Mehr Kontext, bitte. > > Mehrere (Teil-)Symbole für einen Footprint. > > Schon mal ein Schematic Symbol mit 2000 Pins gesehen? Nein. Ich bin Analog-Fuzzi. Aber jetzt habe ich Dich verstanden, ja. Das Problem hatte ich noch nicht auf dem Schirm. >> Hmmja... auch Vektorgraphik ist "statisch gemalte Graphik", >> aber skalierbar ist sie trotzdem... :) > > Wenn Du in einem Schematic aber ein Viereck malst und fest > legst, welchen Abstand die Pins des Symbols haben, dann > ist das nicht dynamisch, sondern fest. -> "Pinraster" > Das Symbol eignet sich dann nur genau für dieses Pinraster. Ach so -- okay. Technisches Ärgernis. Verstanden. (Hmm. Wieso ist das eigentlich so? Hat doch keinen sinnvollen Grund...?!) >> Es ging Dir doch nur um den Aspekt, dass das Symbol >> keine fixierte absolute Größe haben, sondern skalierbar >> sein soll -- oder habe ich Dich missverstanden? > > Ja. Super: "Kaffee oder Tee?" -- "Ja." :)
Possetitjel schrieb: >> Ein Footprint kann eine Verlustleistung haben. > > Nicht in meinen Universum. > > Wenn man die Information haben will, welche Leistung > über Gehäuse X abführbar ist, dann formuliert man eine > passende Abfrage an die Datenbank und selektiert nach > Gehäuse und Verlustleistung. Im Schematic wird der Footprint nicht zwingend festgelegt, sondern allenfalls optional. Man will ja gerade die Entscheidung, welcher Footprint genutzt wird, im Schematic offen halten können. ...jetzt wird mir alles klar. Hier gibt es Begriffsschwierigkeiten folgender Art: Typischerweise gibt es A. ein Schematic-Tool und B. ein Layout-Tool. Einige hier, scheinbar insbesondere leidenschaftliche Kicad-Verfechter sehen jedoch: A. ein Specification-Tool und B. ein Specification-to-Gerber-Tool. Dann benennen sie das Specification-Tool als Schematic-Tool und das Specification-to-Gerber-Tool als Layout-Tool. Das Umdeuten etablierter Begriffe gefällt mir nicht, wenngleich das heutzutage Mode ist. >> Ein Symbol kann eine Verlustleistung haben. > > Noch viel weniger in meinem Universum. > Dem europäischen Widerstandssymbol ist unter überhaupt > keinen Umständen eine Verlustleistung zugeordnet. Nicht > bei mir. > > [...] >> Man kann im Schematic ein Symbol setzen ohne Footprint. >> Man kann im PCB einen Footprint setzen ohne Symbol. >> >> Was passiert, wenn im Schematic die Verlustleistung >> verändert wird, > > Das kann in meinem Universum nicht passieren, weil die > Bauteildefinition in der Stückliste bestimmt, welches > konkrete Bauteil tatsächlich verbaut wird. Warum machst Du (bzw warum macht Ihr) dann überhaupt noch während des Designs die Zuordnung Footprint<>Symbol? Das müsstest Du dann zwingend gleich bereits beim Anlegen von Footprint und Symbol machen. Na? Gotcha! > Okay... das ist ein neues Spielfeld, das hatten wir noch > nicht bisher. -- Annotationen verändern keine Werte, > sondern definieren Prüfbedingungen. Wieder Begriffsumdeutungen?
..... und dabei wollte ich doch nur wissen, ob die Forward-Backward-Anno geht..... So interessant eure Strategien sind, aber ein bißchen müßig ist das schon, oder? Die werden deswegen jetzt nicht Kicad umprogrammieren.
Karl schrieb: > So interessant eure Strategien sind, aber ein bißchen > müßig ist das schon, oder? "Jemand gilt so lange als Spinner, bis sich seine Idee durchgesetzt hat." (Mark Twain) > Die werden deswegen jetzt nicht Kicad umprogrammieren. Und? Es gibt auch noch geda-rnd und horizon.
Lars R. schrieb: > Possetitjel schrieb: >>> Ein Footprint kann eine Verlustleistung haben. >> >> Nicht in meinen Universum. >> >> Wenn man die Information haben will, welche Leistung >> über Gehäuse X abführbar ist, dann formuliert man eine >> passende Abfrage an die Datenbank und selektiert nach >> Gehäuse und Verlustleistung. > > Im Schematic wird der Footprint nicht zwingend > festgelegt, sondern allenfalls optional. Richtig. Die Bauteile im Schaltplan (Schematic) werden (nach meiner Vorstellung) durch IDs repräsentiert, die auf die "Stückliste" verweisen. In der Stückliste stehen entweder vordefinierte Bauteile aus der Bauteildatenbank ("Library") mit Symbol und Footprint, oder ad-hoc-Bauteile, die z.B. nur Symbole enthalten können (man will ja vielleicht einen "generischen" Schaltplan für eine SPICE-Simulation zeichnen, der keine Footprints benötigt.) > Man will ja gerade die Entscheidung, welcher Footprint > genutzt wird, im Schematic offen halten können. Jein: Man kann die Stückliste durch Zugriff auf die Bauteil- datenbank füllen; dann wird man i.d.R. komplette Bauteile mit Symbol und Footprint haben. Man kann natürlich auch ad-hoc-Einträge vornehmen, dann hat man erstmal nur ein Symbol (oder nur einen Footprint, das müsste auch gehen). Insofern: Ja, die Entscheidung, ob man das eine, das andere oder beides gleichzeitig haben will, ist offen. > ...jetzt wird mir alles klar. Hier gibt es Begriffs- > schwierigkeiten folgender Art: > > Typischerweise gibt es A. ein Schematic-Tool und B. ein > Layout-Tool. Ja, das ist meine Annahme. geda macht es z.B. so; KiCAD meines Wissens auch. > Einige hier, scheinbar insbesondere leidenschaftliche > Kicad-Verfechter sehen jedoch: > A. ein Specification-Tool und B. ein Specification-to-Gerber-Tool. > > Dann benennen sie das Specification-Tool als Schematic-Tool > und das Specification-to-Gerber-Tool als Layout-Tool. Ich kann Dir nicht folgen, ich weiss nicht, wovon Du sprichst. > Das Umdeuten etablierter Begriffe gefällt mir nicht, > wenngleich das heutzutage Mode ist. Es wird sicher so sein, dass ich etablierte Begriffe ungewöhnlich oder gar sinnwidrig verwende, aber sei versichert, das ist keine böse Absicht. Ich hatte beruflich sporadischen Kontakt zu OrCAD (ganz früher) und zu Target3001; privat habe ich ganz schüchtern eagle, geda und (ganz wenig) KiCAD ausprobiert. ECAD ist zwar heutzutage eine Notwendigkeit für den Elektronik- entwickler, aber mich schreckt jedesmal die grausige Ergonomie der ECAD-Software ab. >> Das kann in meinem Universum nicht passieren, weil die >> Bauteildefinition in der Stückliste bestimmt, welches >> konkrete Bauteil tatsächlich verbaut wird. > > Warum machst Du (bzw warum macht Ihr) dann überhaupt noch > während des Designs die Zuordnung Footprint<>Symbol? Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem Stand. geda kennt m.W. ganz konsequent NUR "generische" Symbole im Schaltplan, d.h. "abstrakte" Bauteile ohne Footprint. Zwischen Schaltplanerstellung und Layouterstellung ist ein Zwischenschritt eingeschaltet, in dem den Symbolen die Footprints zugeordnet werden müssen. Bei Target ist es nach meiner Erinnerung so, dass man ziemlich frei wählen kann, WANN man dem Schaltplansymbol einen Footprint zuordnet. Es gibt zwar irgend eine Standard-Einstellung, aber man kann das auch problemlos nachträglich ändern. Insofern: Ja, es gibt mMn keinen zwingenden Grund, warum man während der Schaltplanerstellung schon Footprints zuordnen müsste. Man KANN das tun -- aber man MUSS nicht. > Das müsstest Du dann zwingend gleich bereits beim Anlegen > von Footprint und Symbol machen. Jein: Es ist richtig, dass Bauteile in der Bauteildatenbank immer beides haben müssen -- einfach weil die Bauteildatenbank reale, kaufbare Bauteile abbilden soll, und reale, kaufbare Bauteile eben immer sowohl Symbol (=elektrische Funktion) als auch einen Footprint haben. Wenn man also die "Stückliste" aus der Bauteildatenbank befüllt, dann haben die Einträge in der Stückliste automatisch Symbol UND Footprint. Soweit stimmt das. Allerdings sollte es auch nicht verboten sein, in die Stückliste erstmal NUR Symbole oder NUR Footprints hineinzuschreiben. Dann kann man trotzdem einen Schaltplan bzw. ein Layout erstellen, aber das jeweils andere geht noch nicht, weil die entsprechenden Spalten in der Stückliste noch leer sind. Das muss später nachgetragen werden, wenn man es braucht. >> Okay... das ist ein neues Spielfeld, das hatten wir noch >> nicht bisher. -- Annotationen verändern keine Werte, >> sondern definieren Prüfbedingungen. > > Wieder Begriffsumdeutungen? Sei versichert: Nicht absichtlich.
Possetitjel schrieb: > Ich unterstütze ja die Forderung, dass die Daten projektweit > konsistent sein sollen -- aber an der Diskussion über > forward-backward-annotation regt mich auf, dass immer wieder > eine bestimmte Lösung eines Problems eingefordert wird, das > nur aufgrund eines Designfehlers überhaupt entsteht! Ich glaube mittlerweile, die (hitzige) Diskussion entsteht primär wirklich aus Begriffsverwirrungen ;-) Possetitjel verwendet oft den begriff "Stückliste", versteht darunter aber was ganz spezielles, nämlich eine Art "Datenstruktur". Für mich ist der Begriff anderweitig belegt; eine Stückliste ist ein (weiteres) Element (sagen wir "Dokument") welches ein Item (Artikel, bestückte Platine) beschreibt. Mal abgesehen davon dass es nicht "die" Stückliste gibt, sondern viele Abwandlungen (Struktur-, Baukasten-, Mengen-, Varianten-, Auftrags-, Stamm-, Fertigungs-, ...-Stückliste) und diese idR ein "Abfallprodukt" des jeweiligen Autorensystems ist (ECAD, MCAD, PDM, ERP) Deswegen wehre ich mich dagegen, die Stüli wäre "zentrale Instanz um gewisse Daten zu speichern". Wenn man Stüli hier durch einen anderen (welchen?) Begriff ersetzt, bin ich aber einverstanden ;-) Ob bestimmte Informationen jetzt einmalig gespeichert werden, oder mehrfach, aber vom System konsistent gehalten werden, ist für den Anwender erstmal egal (auch wenn die einmalige Speicherung vorzuziehen ist). Wichtig ist doch nur, dass beim Anwender immer dieselbe Information ankommt, egal ob er die jetzt im Design, im Layout, in der Stückliste oder wo auch immer abruft. Insofern ist FB-Anno auch nicht unbedingt ein "technisches" Feature (dem Anwender ist es erstmal egal wie das implementiert wird), es ist mehr Funktionalität die er nutzen kann und möchte. Aus der Diskussion ist (für mich) einigermaßen klar, dass es ein legitimer Wunsch ist, Informationen an mehreren Stellen zu ändern: Einen Footprint im Design vorzugeben; einen Footprint im Layout zu ändern, aber auch einen Bauteilwert im Layout zu korrigieren (oder überhaupt erst zuzuweisen), und so weiter. Und, ganz wichtig: ich erwarte, Änderungen an einer Stelle an den anderen Stellen möglichst sofort (maximal 1-2 Mausklicks) und möglichst automatisch wiederzufinden. In weiterer Folge sollte es aber möglich sein, gewisse Änderungen einzuschränken: wenn ich zB Layout extern vergebe (oder auch nur an eine andere Abteilung) möchte ich dort die Änderungsmöglichkeiten einschränken können. Das ist dann aber mehr eine Frage des Prozess-Designs. Ein Fehlen der Möglichkeit dieser Einschränkung wäre eine Design-Schwäche, die man mit prozesstechnischen Workarounds bewerfen müsste. Ein Fehlen der grundsätzlichen Möglichkeit (oder anders gesagt: das Bestehen einer grundsätzlichen Einschränkung) ist aber auch eine Designsschwäche. Diese Designschwäche mag manche gar nicht treffen, manche leichter, manche schwerer. Aber es ist und bleibt eine Designschwäche. "braucht man nicht" ist die falsche Antwort.
Karl schrieb: > ..... und dabei wollte ich doch nur wissen, ob die Forward-Backward-Anno > geht..... Nein, geht nicht. > So interessant eure Strategien sind, aber ein bißchen müßig ist das > schon, oder? Die werden deswegen jetzt nicht Kicad umprogrammieren. Doch, die schreiben das um. Das dauert nur. Michael R. schrieb: > Aus der Diskussion ist (für mich) einigermaßen klar, dass es ein > legitimer Wunsch ist, Informationen an mehreren Stellen zu ändern: Einen > Footprint im Design vorzugeben; einen Footprint im Layout zu ändern, > aber auch einen Bauteilwert im Layout zu korrigieren (oder überhaupt > erst zuzuweisen), und so weiter. Und, ganz wichtig: ich erwarte, > Änderungen an einer Stelle an den anderen Stellen möglichst sofort > (maximal 1-2 Mausklicks) und möglichst automatisch wiederzufinden. Aus der Diskussion sollte hervor gehen, dass es nicht genau exakt einen Weg für alle Entwickler und für jedes Projekt geben muss, so wie das Kicad im Moment ein Stück weit erzwingt. Es ist eben nicht sinnvoll, bei der Programmentwicklung festzulegen, dass jede Änderung des Layouts auch automatisch im Schematic erfolgen muss. Das sollte einstellbar oder abstellbar sein. > In weiterer Folge sollte es aber möglich sein, gewisse Änderungen > einzuschränken: wenn ich zB Layout extern vergebe (oder auch nur an eine > andere Abteilung) möchte ich dort die Änderungsmöglichkeiten > einschränken können. Was meinst Du mit einschränken? Bei der Annotation wird eben eingestellt, was annotatet wird. Weitere "Einschränkungen" braucht es nicht und diese könnten ohnehin umgangen werden. Am Ende sieht man ohnehin, an welchen Stellen Schematic und Layout voneinander abweichen. Michael R. schrieb: > Ob bestimmte Informationen jetzt einmalig gespeichert werden, oder > mehrfach, aber vom System konsistent gehalten werden, ist für den > Anwender erstmal egal (auch wenn die einmalige Speicherung vorzuziehen > ist). Ein Layout muss auch ohne Schematic und ohne Symbole funktionieren. Ein Schematic ist ein Schematic und ein Layout ist ein Layout https://en.wikipedia.org/wiki/Schematic https://en.wikipedia.org/wiki/Layout https://en.wikipedia.org/wiki/Layout_(computing) Wenn es nicht mehr um Schematic und Layout geht, sondern eine andere Aufteilung und Benennung verwendet, so kann man alles anders machen. Jedoch bitte ich darum, diese Begriffe nicht umzudeuten. Eine Darstellung des Footprint als Symbol-Attribut ist in der Schematic-Layout-Welt schlicht falsch.
:
Bearbeitet durch User
Possetitjel schrieb: > Ich hatte beruflich sporadischen Kontakt zu OrCAD (ganz früher) > und zu Target3001; privat habe ich ganz schüchtern eagle, geda > und (ganz wenig) KiCAD ausprobiert. Possetitjel schrieb: > ECAD ist zwar heutzutage eine Notwendigkeit für den Elektronik- > entwickler, aber mich schreckt jedesmal die grausige Ergonomie > der ECAD-Software ab. Wenn das deine Wissensbasis sein sollte, dann macht einem dein Nassfrosches Auftreten hier irgendwie stutzig. Du solltest in die Politik gehen da kann man Leute wie dich gebrauchen :-)
Possetitjel schrieb: > Naja, in der Praxis kann man nicht sinnvoll auf die > Stückliste verzichten. Das habe ich auf die harte Tour > gelernt, als ich mal eine kleine Weile für die Kleinst- > serienfertigung bei uns verantwortlich war... :) So könnte das zugehörige Arbeitszeugnis aussehen: ... bemühte sich redlich seinen Aufgaben gerecht zu werden. (oder) ... hat nach Kräften versucht, die Leistungen zu erbringen, die wir an diesem Arbeitsplatz fordern müssen" (und) ... war tüchtig und wusste sich gut zu verkaufen. (Schlussformel) Wir wünschen Ihm für die Zukunft alles Gute, auch Erfolg.
W.S. schrieb: > Possetitjel schrieb: >> Zweite Bemerkung: Der Footprint hat (logisch) gar nix >> im Schaltplan zu suchen; das ist eine Angabe, die in die >> STÜCKLISTE gehört. >> Aus mir rätselhaften Gründen gibt es weite Teile der >> EDA-Welt, die sich standhaft weigern, die Stückliste als >> gleichberechtigte Fertigungsunterlage neben z.B. dem >> Schaltplan und dem Layout anzusehen. > > Du hast dich verstiegen, ganz einfach verstiegen. > > Zuerst mal eins: eine automatische V/R-Annotation ist etwas > essentielles weil nur dadurch von der EDA-Soft gesichert ist, daß > Schematic und Leiterplatte tatsächlich konsistent sind - und Konsistenz > zwischen beiden ist so überragend wichtig, daß ich kein anderes Wort als > eben überragend wichtig dafür finde. [..] > W.S. ...gilt für Dich aber auch. Wenn das Programm nur einer Forward Annotation hat, erzeugst du keine Inkonsistenzen wenn Du im PCB Editor den Footprint nicht ändern kannst. Wie soll das gehen? Man muß das nicht gut finden das KCad zum derzeitigen Zeitpunkt keine Backward Annotation unterstützt, aber man muß Dein ständiges Gelaber darüber auch nicht gut finden. Du hast einen "gravierenden Fehler" gefunden der Keiner ist, sondern nur ein Missing Feature. Wenn Dir das nicht paßt, renne los und implementiere das, anstatt stets und ständig zu behaupten wie Scheiße KiCad ist. Da das nun nicht das erste mal ist das Du das gesagt bekommst und auch nicht nur von mir, bin ich der Meinung das ich einen "gravierenden Fehler in Deiner Software gefunden habe. Wird Zeit das dieses Memory Leak mal einer patcht. >Das interessiert den Entwickler >und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603 >dort haben. Nein, wenn der noch alle Tassen im Schrank hat, dann will er da 4k7 100mW oder aber 4k7 4W, genauso wie der nicht 4,7µ RM5 sondern 4,7µ 63V will. Gruß, Holm
Hallo, warum nicht auf Target 3001 wechseln? Kann Eagle importieren. Ich nutze als privater Bastler die kleinste Kaufversion. Damit habe ich Support. Und ich muss sagen der Support ist wirklich super. Jede Frage wird umgehend beantwortet, meistens wird sofort zurückgerufen auf Mail Anfrage. Wenn das im kleinen passiert, dann mit Firmen sicherlich erst recht. Mit Eagle kam ich nie zurecht. Mit Target kam ich ohne eine Anleitung zulesen sehr weit. Irgendwann muss man dann etwas nachlesen. Bauteile selber erstellen ist auch einfacher gewurden.
Hat dieser Thread eigentlich noch was mit seinem Titel zu tun? Der Mechanismus ist doch immer der Gleiche: 1. Jemand erwähnt mehr als ein EDA-System. 2. Im unmittelbaren Anschluss hagelt es dann die Kommentare im Sinne von "A ist Spielzeug"/"B ist unbenutzbar". 3. Die jeweiligen Fanboys werden neugierig und schreiben auch mal was. In der Regel nach der Schablone "Eagle ist einfach toll"/"Die Eigenheiten von KiCAD müssen halt so sein". 4. Die ersten werden persönlich. 5. Die Postinganzahl wird dreistellig, der weitere Wissenszuwachs konvergiert gegen Null. Zum Glück gibt es hier weder Alkohol noch Maßkrüge, sonst hätten wir hier regelmäßige Kneipenschlägereien...
Michael R. schrieb: > Possetitjel verwendet oft den begriff "Stückliste", > versteht darunter aber was ganz spezielles, nämlich > eine Art "Datenstruktur". Ja. > Für mich ist der Begriff anderweitig belegt; Das ist ein gewisses Problem, ja. > eine Stückliste ist ein (weiteres) Element (sagen wir > "Dokument") welches ein Item (Artikel, bestückte Platine) > beschreibt. Ja -- genau das ist ja meine (provokatorische/didaktische) Absicht dahinter, dass ich den Begriff "Stückliste" verwende: Wäre es nicht an der Zeit, sich von der Auffassung, die Stückliste sei ein untergeordnetes, sekundäres Dokument, das irgendwie aus den "richtig wichtigen Daten" abgeleitet wird, zu verabschieden? Sind nicht die Daten auf der (klassischen) Stückliste schon ein Teil der "richtig wichtigen Daten"? > Deswegen wehre ich mich dagegen, die Stüli wäre "zentrale > Instanz um gewisse Daten zu speichern". Wenn man Stüli hier > durch einen anderen (welchen?) Begriff ersetzt, bin ich > aber einverstanden ;-) Gern. Mach' einen Vorschlag :) > Ob bestimmte Informationen jetzt einmalig gespeichert > werden, oder mehrfach, aber vom System konsistent gehalten > werden, ist für den Anwender erstmal egal [...] Richtig. > Insofern ist FB-Anno auch nicht unbedingt ein "technisches" > Feature (dem Anwender ist es erstmal egal wie das implementiert > wird), es ist mehr Funktionalität die er nutzen kann und > möchte. Auch richtig. > Aus der Diskussion ist (für mich) einigermaßen klar, dass > es ein legitimer Wunsch ist, Informationen an mehreren > Stellen zu ändern: [...] Ja -- und noch einen Schritt weiter: Das System muss in der Lage sein, auch mit "unvollständigen" Informationen zu arbeiten. Beispiel: Eine SPICE-Simulation möchte man in Form eines Schaltplanes erstellen können, aber die dort verwendeten Bauteile sind i.d.R. nur "abstrakte" Bauteile, benötigen also nur Symbole und keinen Footprint (dafür aber ggf. ein SPICE-Modell). Anderes Beispiel wurde schon genannt: Reverse Engineering. Man möchte dort Layouts mit Footprints erstellen können, denen erstmal noch kein Symbol zugeordnet ist, die also keine vollständigen Bauteile sind. > In weiterer Folge sollte es aber möglich sein, gewisse > Änderungen einzuschränken: wenn ich zB Layout extern > vergebe (oder auch nur an eine andere Abteilung) möchte > ich dort die Änderungsmöglichkeiten einschränken können. > Das ist dann aber mehr eine Frage des Prozess-Designs. Ja... gut. Ist das nicht bei genauer Betrachtung eine andere Baustelle, nämlich eine Art "Rechteverwaltung"? Letztlich baut das doch auf der Idee von oben (Arbeit mit unvollständigen Information) auf: Ein bestimmter Bearbeiter trifft bestimmte Einschränkungen, schränkt also die Menge der Bauteilkandidaten ein, die in Frage kommen. (Es ist also schon Auswahlinformation da, aber die ist unvollständig.) Ein anderer Bearbeiter wählt dann aus dieser Teilmenge das Bauteil aus, das dann letztlich genommen wird; damit wird die Auswahl völlig eindeutig. Die Information ist vollständig. > Ein Fehlen der Möglichkeit dieser Einschränkung wäre > eine Design-Schwäche, die man mit prozesstechnischen > Workarounds bewerfen müsste. > [...] > Diese Designschwäche mag manche gar nicht treffen, manche > leichter, manche schwerer. Aber es ist und bleibt eine > Designschwäche. "braucht man nicht" ist die falsche > Antwort. Selbstverständlich. Es wäre halt nur schön, wenn auch die Kritik an fehlenden Features in einigermaßen qualifizierter Gestalt daherkäme. Wenn forward backward annotation als Feature verstanden wird, das deswegen zwingend erforderlich ist, weil man die Symbol-Footprint-Zuordnung in Schaltplan und Layout konsistent halten muss, dann ist das keine qualifizierte Kritik, sondern ein schlechter Würgaround für einen ganz anderen Designfehler: Inkonsistenzen dürfen nicht auftreten. Die korrekte Antwort hierauf ist tatsächlich: Braucht man nicht. Wenn jedoch FB als Möglichkeit im GUI verstanden wird, eine bestimmte Zuordnung von mehreren Stellen aus verändern zu können, dann ist daran erstmal nix falsch. Zu überlegen wäre allenfalls, wie eine konsistente, logische Nutzer- führung aussehen müsste. Am Wunsch an sich ist aber nix verkehrt.
Lars R. schrieb: > Aus der Diskussion sollte hervor gehen, dass es nicht > genau exakt einen Weg für alle Entwickler und für jedes > Projekt geben muss, Klar. Das ist ja das Problem: Natürlich geht jeder Software-Entwickler erstmal von seinem eigenen Arbeits- ablauf aus, und das ist ja auch legitim. Das hinterliegende Datenmodell sollte aber schon so allgemein sein, dass andere Arbeitsabläufe genauso möglich sind. > so wie das Kicad im Moment ein Stück weit erzwingt. Weil man nur den Weg Schaltplan --> Layout gehen kann, nicht aber Layout --> Schaltplan, oder worauf willst Du hinaus? > Es ist eben nicht sinnvoll, bei der Programmentwicklung > festzulegen, dass jede Änderung des Layouts auch automatisch > im Schematic erfolgen muss. Das sollte einstellbar oder > abstellbar sein. Hmm. Ja. Das setzt aber voraus, dass das System 1. mit unvollständigen Daten arbeite kann und 2. unvollständige von widersprüchlichen Daten unterscheiden kann. > Eine Darstellung des Footprint als Symbol-Attribut ist in > der Schematic-Layout-Welt schlicht falsch. Man korrigiere mich bei Bedarf -- aber ist das nicht eine ausdrückliche Eagle-Spezialität? Nach meinem Empfinden besteht fast niemand (außer vielleicht einigen wenigen Eagle-Jüngern) auf dieser Auffassung.
Max G. schrieb: > 5. Die Postinganzahl wird dreistellig, der weitere > Wissenszuwachs konvergiert gegen Null. Das liegt wohl im Auge des Betrachters. Ich habe der laufenden Diskussion einige Anregungen entnommen, auf die ich im Leben nicht allein gekommen wäre.
Possetitjel schrieb: > Wäre es nicht an der Zeit, sich von der Auffassung, die > Stückliste sei ein untergeordnetes, sekundäres Dokument, das > irgendwie aus den "richtig wichtigen Daten" abgeleitet wird, > zu verabschieden? Ist es aber. Manchmal. Dazu musst Du erstmal definieren, was auf eine Stückliste gehört. Bauteil-ID, Wert, Package... sicher. Wobei es mir bei einigen Packages beim Routing nicht drauf ankommt, ob ich da ein 0603 verwende um möglichst dicht ranzukommen, ein 0805 um vielleicht noch eine Leiterbahn durchzuziehen oder ein 1206, weil da eine dickere Leiterbahn durchmuss. Brauche ich aber Mindestleistung, muss es halt das 1206 sein. Und muss es ein spezieller Melf sein, dann muss es halt das Melf-Package sein. - Also: Kommt drauf an. Distributor, Bestellnummer... hm. Viele Bauteile sind Rollenware, und da ist es mir eigentlich egal, ob ich die 10k 0805 oder den 7805 bei TME oder bei Farnell kaufe. Meistens liegen die eh auf Vorrat. Andere dagegen bekomme ich nur vom einem Distri, oder für spezielle Projekte als Bemusterung. Allerdings so selten, dass sich das Einpflegen in eine Datenbank hier auch nicht lohnt. Ich seh ja ein, dass Farnell das in Eagle gern hätte, um die Kundenbindung zu stärken. Aber mir ist das eigentlich egal. Anzahl... wichtig, wenn man größere Mengen braucht, um ausreichend nachzubestellen. Aber dann reicht eine BOM und ich brauche nicht die Zuordnung jedes Wertes zu jeder ID. Also bei mir reicht Stückliste von total unwichtig bei kleinen Projekten bis wichtig bei größeren, aber dann auch nur als BOM.
Possetitjel schrieb: > Lars R. schrieb: >> so wie das Kicad im Moment ein Stück weit erzwingt. > > Weil man nur den Weg Schaltplan --> Layout gehen kann, > nicht aber Layout --> Schaltplan, oder worauf willst Du > hinaus? Ja. >> Es ist eben nicht sinnvoll, bei der Programmentwicklung >> festzulegen, dass jede Änderung des Layouts auch automatisch >> im Schematic erfolgen muss. Das sollte einstellbar oder >> abstellbar sein. > > Hmm. Ja. > > Das setzt aber voraus, dass das System > 1. mit unvollständigen Daten arbeite kann und > 2. unvollständige von widersprüchlichen Daten unterscheiden kann. Widersprüchlich? Der Abgleich zweier, zueinander inkonsistenter Datensätze nach vorgegebenen Kriterien muss wohl erst noch erfunden werden? ;) Notfalls schreibe man bei Unison ab.
Possetitjel schrieb: > Was ist daran so kompliziert? > > Ich bin -- auch wenn es nicht so scheinen mag -- durchaus > lernwillig, aber dafür gibt es eine Bedingung: Wer meine > Gedanken durch Anwendung passender Argumente ändern möchte, > der möge sich BITTE auf das oben von mir skizzierte Modell > einlassen und mir zeigen, warum es nicht praxisgerecht ist. Nein. Ich z.B. lasse mich eben nicht auf krude Denkmodelle anderer ein, sondern messe selbige an der Realität. Der "real existierende Sozialismus" hatte sich ebenso krude Denkmodelle ausgedacht und wollte - wie du - daß man sich auf ihrem Denkmodell mit ihren Argumenten und ihren Axiomen unterhält. Daß dabei das ganze beim Messen an der Praxis glatt durchgefallen ist, wissen wir ja zur Genüge. Also: Dein Begriff von Stückliste entspricht in keinem Punkte der Realität. Das ist wohl dein Denkfehler. Richtig ist: Die Bauteil-Bibliothek enthält die Datensätze zu real existierenden Bauteilen, dazu die Symbole, mit denen diese Bauteile im Schematics dargestellt werden können, dazu auch die Footprints, die zum fachgerechten Verwenden der Bauteile auf der Leiterplatte benötigt werden. So man will, kann da auch noch weitere Information beigefügt sein, wie Lieferant, Hersteller, usw. Die V/R-Annotation ist das automatisierte Konsistenthalten zwischen Schematics und Leiterplatte - und das hat üblicherweise NICHTS mit Bibliotheken zu tun, auch nicht mit Stücklisten. Das ist eine Sicherheitsmaßnahme, die dazu da ist, daß Projekte, die auf einem System dargestellt werden, was nicht über exakt die gleichen Bibliotheken verfügt, unverfälscht bleibt. Stücklisten sind nachgeordnet - begreife das mal. Sie sind ein Mittel, um aus einem fertigen Projekt die Angaben herauszuziehen, die für den Einkäufer relevant sind. Sie sind eben kein Teil des eigentlichen Leiterplattenentwurfes. So, verstehst du das jetzt etwas besser? W.S.
Possetitjel schrieb: > Dauernd wird hier beschworen, dass Daten konsistent gehalten > werden müssen -- aber nirgendwo wird für mich nachvollziehbar > erklärt, warum man sie überhaupt mehrfach speiche... Weil es die allermeisten Firmen eben NICHT gern sehen, daß sie ihr gesamtes Projekt an Fertiger herausgeben müßten. Es ist ja nicht nur der LP-Fertiger, sondern auch der Bestücker, die Beschaffer und so weiter. All diese Leute kommen mit dem reinen Board zurecht und benötigen eben NICHT die Informationen, die im Schematic stecken. Natürlich könnte man - wenn einem der Behalt am Schematic egal ist - Schematic und Board in einer Datei zusammenfassen. Programmiertechnisch wäre das sogar die netteste Lösung. Aber das ist wie bei deiner Haustür: Theoretisch brauchst du nur ne Klinke, aber kein Schloß drin und es wäre technisch einfacher und auch billiger in der Herstellung - und im Handling. W.S.
W.S. schrieb: > Possetitjel schrieb: >> Dauernd wird hier beschworen, dass Daten konsistent gehalten >> werden müssen -- aber nirgendwo wird für mich nachvollziehbar >> erklärt, warum man sie überhaupt mehrfach speiche... > > Weil es die allermeisten Firmen eben NICHT gern sehen, daß sie ihr > gesamtes Projekt an Fertiger herausgeben müßten. Es ist ja nicht nur der > LP-Fertiger, sondern auch der Bestücker, die Beschaffer und so weiter. Nein, das ist nicht der Grund. Letztlich stehen Netze und Bauteile (sogar der Footprint und nicht nur das Symbol) auch im PCB. Der Grund des (bitte optionalen) automatischen Abgleiches ist, dass man nicht Gefahr läuft, beim manuellen Abgleich durcheinander zu kommen. Wobei es eben auch Situationen und Arbeitsweisen gibt, bei denen man den automatischen Abgleich nicht möchte. Beispielsweise möchtest Du persönlich wahrscheinlich auch mit automatischem Abgleich nicht, dass ein Löschen des Footprints automatisch das Symbol löscht. In anderen Situationen will man mehr Unterschiede zwischen Schematic und Layout.
Karl schrieb: > Was heisst hier leistungsfähige PCs? Das ging schon vor 15 Jahren auf > einem 700 MHz Pentium 3 mit 500MByte RAM. Ich seh auch nicht, wieso das > groß Leistung brauchen sollte? Du Witzbold! Denke mal an das damalige Orcad, was unter DOS in 640 K RAM lief. Damit hatte ich so manchen Stromlaufplan gemacht - und früher als dieses lief mein erstes Layoutsystem auf CP/M - jaja, Z80 und 64K RAM. DAS ist es, was man als FRÜHER so bezeichnet. Später war das allerdings erstmal ziemlich genau so bei PADS unter DOS. Der große Umbruch kam erst viel später, als Windows 95 und wesentlich mehr RAM aufkamen. Und dein Verständnis für frühere Zeiten endet beim Pentium3? OK, mit diesem Horizont sieht man ausgesprochen wenig. W.S.
Lars R. schrieb: > Ein Footprint hat eine Pinanzahl. Ein Symbol (Symbolgruppe) hat eine > Pinanzahl. Für die Zuordnung Footprint<>Symbol muss die Pinzahl überein > stimmen. Nö. Das stimmt hinten und vorn nicht. ich widerlege dich mal ganz einfach mit einem simplen SN7400. Das ist ja so altbekannt, daß ich voraussetze, daß du dieses Bauteil kennst. Da hast du ein NAND-Gatter als Symbol, das hat 3 Pins (Anschlüsse) - allerdings hast du gleich 4 davon in dem Chip. Dazu hast du noch einmal GND und VCC und die sind meistens in einem fünften Symbol enthalten. Fazit: Es kann keine "Zuordnung Footprint<>Symbol" geben, weil nirgendwo irgendwelche Pinzahlen übereinstimmen. W.S.
W.S. schrieb: > Lars R. schrieb: > ich widerlege dich mal ganz einfach mit einem simplen SN7400. Das ist ja > so altbekannt, daß ich voraussetze, daß du dieses Bauteil kennst. > > Da hast du ein NAND-Gatter als Symbol, das hat 3 Pins (Anschlüsse) - > allerdings hast du gleich 4 davon in dem Chip. Dazu hast du noch einmal > GND und VCC und die sind meistens in einem fünften Symbol enthalten. > > Fazit: Es kann keine "Zuordnung Footprint<>Symbol" geben, weil nirgendwo > irgendwelche Pinzahlen übereinstimmen. Von mehrteiligen Symbolen (Gruppe von Symbolen) habe ich bereits geschrieben. Bezog sich auch auf das Bauteil (Zuordnung Footprint<->Symbol) Erklär erst mal, warum ein Designer das Layout heraus gibt, aber bei der Herausgabe des Schematic Angst vor Offenlegung des Knowhow haben soll. Du beherrschst wohl die manuelle Annotation nicht? Zwing die Automatische nicht anderen auf und erspare die Ablenkungsmanöver.
Possetitjel schrieb: >> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch >> während des Designs die Zuordnung Footprint<>Symbol? > > Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem > Stand. Eagle kennt Bauteile. Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder BR207. Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre Symbole. Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren Symbol und dem im Layout sichtbaren Footprint bereits in der Bauteile-Bibliothek erledigt ist. Man kann (so man es tatsächlich will) diese Zuordnung zwar ändern, genauso wie man in Eagle auch ein Layout ganz ohne Schematics machen könnte - aber weitaus besser ist es allemal, auf derartiges zu verzichten. Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten des PC wissen sollte, was man für einen Widerstand einsetzen will. Für den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein fetter BR625 nötig, der die zu erwartende Verlustleistung abkann. Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des Schematics stattfinden muß. Man will bei einem EDA-System ja keine theoretischen Symbolschaltungen erzeugen, wie man sie in Veröffentlichungen in Zeitschriften so sehen kann, sondern es soll am Ende ja ein tatsächlich praktisch benutzbares Ding bei herauskommen. W.S.
Lars R. schrieb: > Es ist eben nicht sinnvoll, bei der Programmentwicklung festzulegen, > dass jede Änderung des Layouts auch automatisch im Schematic erfolgen > muss. Das sollte einstellbar oder abstellbar sein. Oh doch, denn die einzge Alternative dazu wäre, daß es jemanden geben müßte, der die Übereinstimmung von Hand erledigt - oder daß beides eben auseinander driftet. > Am Ende sieht man ohnehin, an welchen Stellen Schematic und Layout > voneinander abweichen. Ach, und wer soll das sein? Ich sag's dir: die Service-Leute, die dann vor Ort mit unzutreffenden Schematics nen Fehler suchen und nach Rückkehr dir den Hintern versohlen werden. Oder die Software-Abteilung, die nach zehn vergeblichen Versuchen, das richtige Signal am richtigen Pin rauszugeben feststellen müssen, daß der Stromlaufplan garnicht stimmt. W.S.
W.S. schrieb: > Und dein Verständnis für frühere Zeiten endet beim Pentium3? OK, mit > diesem Horizont sieht man ausgesprochen wenig. Na wenn Du meinst... mein Verständnis beginnt mit dem Amiga500 / 286er. Allerdings hab ich zu der Zeit meine Schaltpläne noch handgemalt. Wir hatten ja nichts... als Schüler und ohne Internet. W.S. schrieb: > Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des > Schematics stattfinden muß. Das ist wohl etwas einseitig betrachtet. Die Dimensionierung macht man anhand des Schaltplanes, und wenn bei der Dimensionierung rauskommt, der 0805er reicht leistungsmäßig nicht, es sollte doch ein 1206er sein, oder der Transistor im SOT89 ist grenzwertig, besser die nächstgrößere Bauform nehmen, dann wird das natürlich angepasst. Genauso wie das Layout die Schaltung beeinflussen kann, beeinflusst die Dimensionierung Schaltplan und Layout. Den Spannungsregler im SO-08, oder doch lieber im DPAK? Das ist ein Optimieren an mehreren Stellen, da schlägt die Praxis einfach die Theorie.
W.S. schrieb: > Eagle kennt Bauteile. > Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder > BR207. > Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre > Symbole. > > Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren > Symbol und dem im Layout sichtbaren Footprint bereits in der > Bauteile-Bibliothek erledigt ist. Ja, in der Welt der Sektensteuerzahler ist jedem Symbol ein Footprint zugeordnet und man muss sich schon im Schaltplan dafür entscheiden, ob es da jeweils Sinn macht oder nicht. In der freien Welt kann der Nutzer einem Symbol kein, ein, oder viele (eine sinnvolle Vorauswahl) Footprints zuordnen, ganz wie er mag. Außerdem kann er jedem Symbol Links zu Datenblatt und Spicemodell zuordnen, ebenso die Bestellnummern bei verschiedenen Lieferanten, Lagerpositionen oder was immer er möchte, wenn er denn möchte. In der freien Welt kann der Nutzer die Zuordnung von Footprint zum Symbol für jedes Bauteil bei dem es sinnvoll ist sofort im Schaltplan treffen, und da wo er sich noch nicht festlegen möchte auf später verschieben. > Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des > Schematics stattfinden muß. Sektenmitglieder lieben den Zwang. > Man will bei einem EDA-System ja keine > theoretischen Symbolschaltungen erzeugen, wie man sie in > Veröffentlichungen in Zeitschriften so sehen kann Genau, niemand fertigt Schaltpläne für Vorlesungen, Dokumentation oder Schaltschränke an.
@W.S.: Du bist selbst das, was Du andern vorwirfst zu sein. Was Du nicht brauchst, das hat nach Deiner Ansicht auch kein anderer zu brauchen. Alle haben es gleich zu machen und zwar so, wie Du das willst. > Ach, und wer soll das sein? > > Ich sag's dir: die Service-Leute, die dann vor Ort mit unzutreffenden > Schematics nen Fehler suchen und nach Rückkehr dir den Hintern versohlen > werden. Oder die Software-Abteilung, die nach zehn vergeblichen > Versuchen, das richtige Signal am richtigen Pin rauszugeben feststellen > müssen, daß der Stromlaufplan garnicht stimmt. Ja und? Sieht man doch im Programm, wenn das nicht überein stimmt. Wenn Du das nicht verkraftest (hab ich mir schon gedacht), dann nutze eben den manuellen Abgleich nicht. ...ich kann Dir auch eine beliebige alte Version vom Stromlaufplan geben. Die stimmt dann auch nicht.
W.S. schrieb: > Possetitjel schrieb: >>> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch >>> während des Designs die Zuordnung Footprint<>Symbol? >> >> Wie Eagle und KiCAD das handhaben, weiss ich nicht aus dem >> Stand. > > Eagle kennt Bauteile. > Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder > BR207. > Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre > Symbole. > > Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren > Symbol und dem im Layout sichtbaren Footprint bereits in der > Bauteile-Bibliothek erledigt ist. > > Man kann (so man es tatsächlich will) diese Zuordnung zwar ändern, > genauso wie man in Eagle auch ein Layout ganz ohne Schematics machen > könnte - aber weitaus besser ist es allemal, auf derartiges zu > verzichten. > > Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten > des PC wissen sollte, was man für einen Widerstand einsetzen will. Für > den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt > würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein > fetter BR625 nötig, der die zu erwartende Verlustleistung abkann. > > Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des > Schematics stattfinden muß. Man will bei einem EDA-System ja keine > theoretischen Symbolschaltungen erzeugen, wie man sie in > Veröffentlichungen in Zeitschriften so sehen kann, sondern es soll am > Ende ja ein tatsächlich praktisch benutzbares Ding bei herauskommen. > > W.S. Ich deute Dein Herumgeiere auf Eagle ausschließlich als Folge Deines Unvermögens den Knoten im eigenen Gehirn zu finden. Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole BE bestückt und entworfen worden war modernisiert auf SMD BE. Am Schaltplan hat sich dadurch so gut wie Nichts verändert und das ist auch gut so. Ich lege den Footprint eines BE fest wenn ich den Schaltplan gezeichnet habe, evtl. simuliert und die elektrischen Anforderungen an das BE ermittelt und die Verfügbarkeit im Schrank (beim Hauslieferanten etc.) ermittelt habe..nicht etwa bevor ich den Schaltplan zeichne. Das machen nur verkorkste Allesbesserwissenwollerabernichtkönner. Alles Lochstreifenrolle oder was? Gruß, Holm
Holm T. schrieb: > Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung > irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole > BE bestückt und entworfen worden war modernisiert auf SMD BE. Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf SMD aktualisiert habe. Und das Schöne: Man kann die Footprints im Layout ändern und gleich die Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan übernommen.
W.S. schrieb: > Possetitjel schrieb: >> Ich bin -- auch wenn es nicht so scheinen mag -- durchaus >> lernwillig, aber dafür gibt es eine Bedingung: Wer meine >> Gedanken durch Anwendung passender Argumente ändern möchte, >> der möge sich BITTE auf das oben von mir skizzierte Modell >> einlassen und mir zeigen, warum es nicht praxisgerecht ist. > > Nein. Nu -- dann lässt Du es halt bleiben. Du solltest dann allerdings auch nicht erwarten, dass Deine Argumente wesentliche Änderungen in meinen Gedanken ver- ursachen. > Also: Dein Begriff von Stückliste entspricht in keinem > Punkte der Realität. Das ist falsch. Mein Begriff von "Stückliste" entspricht nur nicht dem ALLGEMEIN ÜBLICHEN Begriff von "Stückliste". Das ist etwas ganz anderes. Meine Gedanken über Stücklisten sind Resultat meiner praktischen Beschäftigung mit Fertigungsorganisation. Ich war bei dieser Tätigkeit auch durchaus erfolgreich. Die (gewollte und von mir beabsichtigte) Provokation liegt darin, dass ich dazu einlade, den "üblichen Gebrauch" des Begriffes "Stückliste" zu hinterfragen, zu überdenken und ggf. zu verändern. Wer das nicht mag, braucht dieser Einladung nicht zu folgen. Kein Problem. > Die V/R-Annotation ist das automatisierte Konsistenthalten > zwischen Schematics und Leiterplatte - und das hat > üblicherweise NICHTS mit Bibliotheken zu tun, auch nicht > mit Stücklisten. Genau DAS ist einer meiner Kritikpunkte. > Stücklisten sind nachgeordnet - begreife das mal. Nein - ich "begreife" das nicht. Ich weiss, das einige (viele?) Leute Deiner Meinung sind, und ich halte diese Ansicht für schädlich. Für meine Ansicht habe ich Gründe. Da Du oben ausdrücklich erklärt hast, Dich "auf mein krudes Denkmodell" nicht einlassen zu wollen, sehe ich wenig Chance für Dich, meine Gründe zu entkräften. > So, verstehst du das jetzt etwas besser? Nein. :)
Ein Bauteil ist eine Beziehung Footprint<>Symbol, ggf. +Attribute Diese Beziehung (Bauteil) kann man auch in eine Library packen. Das wäre in der Library eine dritte Kategorie (Bauteil, Footprint, Symbol). Für die Instanzen, dh im Projekt, könnte man es vielleicht so realisieren: 1. Bauteil (Footprint, kein Symbol) 2. Bauteil (kein Footprint, Symbol) 3. Bauteil (Footprint, Symbol) Im Layout wird mit dem Footprint gearbeitet, im Schematic mit dem Symbol. Im Zuordnungsdialog und bei den Annotations mit beidem.
W.S. schrieb: > Eagle kennt Bauteile. > Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder > BR207. > Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre Was heisst denn hier "richtige Bauteile"? Wenn ich in einen Laden gehe und sage: "Ich hätte gerne einen Widerstand", dann wird mich der Verkäufer erst mal fragen: "ja, was denn für ein Widerstand?" Wenn ich aber sage: "Ich hätte gerne einen Widerstand in 1206", dann... hm... fragt mich der Verkäufer ebenfalls: "Ja was wollen Sie denn nun für einen Widerstand haben?" Ich habe das schon in anderen Threads zum Thema nicht nachvollziehen können. Man spricht im Bezug auf diese "Bauteile-Philosophie" von Eagle immer davon, dass es "physikalische Bauteile" sind, und nicht bloss Abstraktionen. Doch, das sind sie immernoch! Es sind bloss Abstraktionen, die ein bisschen stärker konkretisiert sind. Aber es ist immernoch IRGENDEIN Widerstand in einem konkreten Gehäuse. Der Aussage, dass grundsätzlich der Footprint immer VOR dem Schemazeichnen klar sein soll, widerspreche ich vehement. Natürlich weiss ich, dass ein 100A Messshunt nicht in einem 0402 Gehäuse daherkommt. Aber in welchem denn? Wenn ich das Schema zeichne interessiert mich das erstmal kein bisschen. Oder nehmen wir Kondensatoren. 47uF, 10V. Gibt es die im 0402? Oder in 0603? Oder muss ich gar auf 0805 gehen? Das alles sind Überlegungen, die mich beim Schemazeichnen kein bisschen interessieren. Beim Schemazeichnen platziere ich oft konkrete Bauteile, von denen ich eine genaue Ahnung habe, was GENAU ich haben möchte. Bei den meisten Bauteilen platziere ich aber wirklich NUR ein Symbol für etwas, das ich in einer späteren Phase des Designs noch genauer spezifizieren werde.
Possetitjel schrieb: >> Die V/R-Annotation ist das automatisierte Konsistenthalten >> zwischen Schematics und Leiterplatte - und das hat >> üblicherweise NICHTS mit Bibliotheken zu tun, auch nicht >> mit Stücklisten. > > Genau DAS ist einer meiner Kritikpunkte. Das stimmt halt nicht. Wenn das zu absolut jeder Zeit zu 100% konsistent wäre, dann bräuchte man es nicht mehrfach speichern.
Ja, die Synchronisation von Schaltplan und Layout ist bei KiCAD umständlich, um nicht zu sagen altbacken. So haben wir das schom um 1990 herum mit OrCAD als Schaltplaneditor und Tango-Netzlisten Export gehandhabt. Ist aber nun kein ko-Kriterium für KiCAD. Nach rund 25 Jahren Eagle bin ich umgestiegen auf KiCAD, und in der Tat gibt es da aus meiner Sicht eine Menge zu kritisieren. Das quelloffene System, wo die Projektdateien im KLARTEXT abgespeichert werden, die große community und die deutlich besser gepflegten Bibliotheken sind für mich aber gewichtigere Argumente, so daß ich Eagle inzwischen keine Träne mehr nachweine. Ist eben Ansichtssache...
W.S. schrieb: > In die Stückliste kommt später dann nur noch, ob > der Widerstand von Beyschlag oder Isabellenhütte oder anonym per Distri > und dessen Katalognummer bezogen wird. Das interessiert den Entwickler > und Layouter hingegen garnicht, der will lediglich einen 4k7 in 0603 > dort haben. Warum sollte den Entwickler interessieren, ob der 4k7 in 0603 oder in 0805 verbaut wird?
W.S. schrieb: > Possetitjel schrieb: >>> Warum machst Du (bzw warum macht Ihr) dann überhaupt noch >>> während des Designs die Zuordnung Footprint<>Symbol? >> >> Wie Eagle und KiCAD das handhaben, weiss ich nicht aus >> dem Stand. > > Eagle kennt Bauteile. Ja, das ist klar. Der Knackpunkt war: Kennt Eagle nur (komplette) Bauteile? Ich bin kein Eagle-User, aber so, wie ich die zahlreichen Diskussionen verstehe, lautet die Antwort: JA! Man kann zwar den Footprint nachträglich ändern, aber man kann kein Symbol ganz ohne Footprint in den Schaltplan einfügen. Entspricht das so den Tatsachen? > Und in's Schematic fügt man Bauteile ein, repräsentiert > durch ihre Symbole. Ja. Genau das ist mein Kritikpunkt. :) Das komplette Bauteil gehört in die interne "Super- stückliste". In den Schaltplan gehört eine Referenz auf die entsprechende Position der "Super-Stückliste"; der Schaltplaneditor zeigt das zugehörige Symbol an. In das Layout gehört eine Referenz auf die entsprechende Position der "Super-Stückliste"; der Layouteditor zeigt den zugehörigen Footprint an. Eigentlich ganz einfach und logisch... > Bedenke mal, daß man als Schaltungsentwickler schon vor > dem Einschalten des PC wissen sollte, was man für einen > Widerstand einsetzen will. Genau das stimmt nicht. Das schränkt (ähnlich wie es Lukas bei horizon mMn getan hat) das Anwendungsfeld unmotiviert ein. > Man will bei einem EDA-System ja keine theoretischen > Symbolschaltungen erzeugen, wie man sie in > Veröffentlichungen in Zeitschriften so sehen kann, Doch! Manchmal will man GENAU DAS ! Zum Beispiel dann, wenn man eine Schaltungsidee hat und davon eine SPICE-Simulation machen will. Oder wenn man eine Prinzipskizze für das Mikrocontroller-Forum erstellen will. Oder wenn man wiederverwendbare Grundschaltungen definieren will...
Possetitjel schrieb: > Das komplette Bauteil gehört in die interne "Super- > stückliste". > In den Schaltplan gehört eine Referenz auf die entsprechende > Position der "Super-Stückliste"; der Schaltplaneditor zeigt > das zugehörige Symbol an. > In das Layout gehört eine Referenz auf die entsprechende > Position der "Super-Stückliste"; der Layouteditor zeigt den > zugehörigen Footprint an. > > Eigentlich ganz einfach und logisch... Und was passiert dann Deiner Ansicht nach, wenn Du die Verlustleistung vom Symbol änderst? Geht dann die Datenstruktur "Bauteil" kaputt? Bekommt der 0402-Footprint plötzlich 5W Verlustleistung? Willst Du es einfach verbieten, dass beim Symbol die Verlustleistung geändert wird? usw.
Ich komme nochmals auf mein Beispiel mit den Kondensatoren zurück, weil ich finde, dass da noch ein Aspekt drin steckt, der mir erst jetzt wirklich eingefallen ist: Ich denke, es geht nicht nur mir so, dass ich während dem Schemazeichnen keine Lust habe, immer wieder auf mouser.com zu wechseln um zu schauen, in welcher Bauform denn ein bestimmter Kondensator erhältlich ist. Also werde ich, egal, ob ich mit KiCad oder mit Eagle arbeite, erst mal in meinen Gedanken IRGENDEINEN Kondensator platzieren. Wenn ich das richtig verstanden habe, muss ich in Eagle also irgendeinen Kondi in irgendeinem Gehäuse platzieren. Ich muss mich entscheiden. Bei KiCad muss ich das nicht. Ich darf. Aber ich muss nicht. Beim Standard-Hühnerfutter (100nF Kondis etc.) weiss ich, dass ich auf 0402 gehe. Da muss ich sicher nicht nachschauen. Nich jetzt, nicht später. Nun, Tage später, ist also mein Schema fertig. Und ich bin schon ganz wuschig auf's Layouten. Also ran ans Werk! Bei KiCad kommt die Enttäuschung sogleich: So schön es wäre, jetzt sofort ein paar Tracks zu legen; ich muss mich erst mal mit den Footprints befassen! Viele habe ich ja schon zugeordnet. Nur bei einigen Knacknüssen hat es noch keinen. Ok, jetzt kommt halt das mühselige Durchsuchen der Mouser-Homepage. Wenigstens kann ich gleich alles auf einmal machen. Und bei Eagle? Da lege ich sofort los! Schliesslich sind ja alle Footprints definiert! Müssen ja! Aber Moment mal... war ich nicht bei einem Kondensator unsicher, ob der in diesem Gehäuse wirklich erhältlich ist? Welcher war das noch gleich? ... Das hat jetzt nicht direkt mit F/B Annotation zu tun, sondern mit dem von vielen als einzig vernünftiges Datenmodell verkaufte Prinzip der "Bauteile" in Eagle.
W.S. schrieb: > Eagle kennt Bauteile. > Richtige Bauteile, also z.B. den Widerstand in 1206 oder in BR614 oder > BR207. > Und in's Schematic fügt man Bauteile ein, repräsentiert durch ihre > Symbole. Und das muß so sein? Warum denn? > Merke also, daß die Zuordnung zwischen dem im Schematic sichtbaren > Symbol und dem im Layout sichtbaren Footprint bereits in der > Bauteile-Bibliothek erledigt ist. Das ist eine Frage, wie man die Bibliothek designt. Ich halte das, was Eagle da zu machen scheint, allerdings für einen groben Fehler. Wenn der Layouter nämlich keinen Bauraum für einen 1206 hat, sondern nur für einen 0402, dann muß genau das passieren, dessen Fehlen Du bei KiCad bemäkelst: eine Backward-Annotation: der geänderte Footprint muß also zurück in den Schaltplan übernommen werden. Und genau das wird Dir früher oder später gewaltig auf die Füße fallen. > Bedenke mal, daß man als Schaltungsentwickler schon vor dem Einschalten > des PC wissen sollte, was man für einen Widerstand einsetzen will. Für > den kleinen Hochzieher am µC reicht ein 0603 aus, für den Strommeß-Shunt > würde man so einen jedoch sofort in die Luft jagen, da wäre eher ein > fetter BR625 nötig, der die zu erwartende Verlustleistung abkann. Das ist aber keine Frage des Footprint, sondern eine Frage von Nennwert, Belastbarkeit, Güte und Toleranz. Diese Werte kann, darf, soll und muß unser Entwickler natürlich vorgeben. Danach muß dann der Layouter einen Footprint auswählen, der diese Vorgaben erfüllt. > Also: die Bauteil-Auswahl ist ein Akt, der noch VOR dem Zeichnen des > Schematics stattfinden muß. Die Auswahl der Bauteile, ja. Aber eben nicht die der Footprints.
ZF schrieb: > Ja, in der Welt der Sektensteuerzahler ist jedem > Symbol ein Footprint zugeordnet und man muss sich > schon im Schaltplan dafür entscheiden, ob es da > jeweils Sinn macht oder nicht. :-) Eine dämliche Folge dessen ist, dass man nicht einfach per Knopfdruck einen Schaltplan von "amerikanischen" auf "DIN"-Symbole umstellen kann, denn die Software weiss ja nicht, die Symbole zwar unterschiedlich aussehen, aber elektrisch gleichwertig sind. >> Man will bei einem EDA-System ja keine theoretischen >> Symbolschaltungen erzeugen, wie man sie in >> Veröffentlichungen in Zeitschriften so sehen kann > > Genau, niemand fertigt Schaltpläne für Vorlesungen, > Dokumentation oder Schaltschränke an. Sehr schön. :)
Simon H. schrieb: > Ich habe das schon in anderen Threads zum Thema nicht > nachvollziehen können. Man spricht im Bezug auf diese > "Bauteile-Philosophie" von Eagle immer davon, dass es > "physikalische Bauteile" sind, und nicht bloss > Abstraktionen. Doch, das sind sie immernoch! Es sind > bloss Abstraktionen, die ein bisschen stärker > konkretisiert sind. Aber es ist immernoch IRGENDEIN > Widerstand in einem konkreten Gehäuse. Sehr schön. Super! Es besteht noch Hoffnung... Es ist genau, wie Du schreibst: Es gibt durchaus nicht nur "abstrakte" und "physikalische" Bauteile, sondern es gibt EINE GANZE REIHE unterschiedlicher Abstraktions- ebenen, auf denen die Auswahl der "zulässigen Kandidaten" mehr oder weniger stark eingeschränkt wird. > Beim Schemazeichnen platziere ich oft konkrete Bauteile, > von denen ich eine genaue Ahnung habe, was GENAU ich > haben möchte. Bei den meisten Bauteilen platziere ich > aber wirklich NUR ein Symbol für etwas, das ich in einer > späteren Phase des Designs noch genauer spezifizieren > werde. Genau; das ist der nächste Punkt: Es STIMMT EINFACH NICHT, dass man in einem bestimmten Arbeitsschritt IMMER schon bestimmte Informationen hat, und andere noch nicht. DAS IST NICHT WAHR! Es tritt immer wieder auf, dass das Wissen in einer bestimmten Bearbeitungsstufe noch unvollständig ist, und man trotzdem weiterarbeiten will. Die Software muss das ermöglichen!
Ein weiterer Grund, warum ich überhaupt nicht der Meinung bin, dass jeder Schemasymbol a priori einem Footprint zugeordnet sein muss: Ich möchte irgendein exotisches Bauteil einsetzen. Vor mir liegt das Datenblatt mit Footprint-Vorschlag. Ich sehe, dass dieser Footprint für mich ok ist. Und das reicht mir erst mal. Im Moment bin ich am Designen der Schaltung. Das Schemasymbol muss ich zeichnen, da komme ich jetzt nicht drum herum. Ist aber auch kein Hexenwerk. Ganz sicher möchte ich mich jetzt aber nicht mit dem Zeichnen des Footprints befassen. Das macht entweder mein Layouter, oder ich, wenn ich später mal die Laouter-Mütze aufhabe. Jetzt bin ich am Entwickeln. Und das möchte ich nicht unterbrechen. Also nochmals: JA, ein Schema beinhaltet Symbole, die a priori ABSTRAKT sind. Ich weiss mehr oder weniger genau, was für ein Footprint ein Symbol repräsentiert (neben anderem), aber dieser ist oft erst mal noch gar nicht definiert resp. in der Bibliothek angelegt! Das ist nicht, wie vielfach gesagt wurde, Schlamperei, sondern schicht effizientes Arbeiten.
Karl schrieb: > Holm T. schrieb: >> Nicht nur einmal habe ich für Bastelzwecke die historische Schaltung >> irgend eines veröffentlichen Projekts das ausschließlich mit trough Hole >> BE bestückt und entworfen worden war modernisiert auf SMD BE. > > Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für > eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf > SMD aktualisiert habe. > > Und das Schöne: Man kann die Footprints im Layout ändern und gleich die > Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan > übernommen. Tja, nachdem Du jetzt Das Schöne vorbringst, muß ich leider auf Das Dumme hinweisen: redundante Datenhaltung ist aus Informatikersicht ein Disaster waiting to happen. Auch dann, wenn Du Automatismen für den Abgleich der redundanten Daten implementierst. Aus diesem Grund wird bei relationalen Datenbanken ein hoher Aufwand betrieben, um die Daten zu normalisieren, also: Redundanzen und damit die Möglichkeit von Inkonsistenzen zu vermeiden. Trotzdem betreiben derartige Systeme einen nochmals enorm hohen internen Aufwand, um die referentielle Integrität der Daten sicherzustellen. Denn es ist nicht einmal innerhalb eines einzelnen Softwareprozesses möglich, die Integrität und Konsistenz redundanter Daten auch dann zu garantieren, wenn er etwa abstürzt. Ich persönlich halte es bis zum Beweis des Gegenteils für einen Fehler im Design von Eagle, Footprints in den Schaltplan zu schreiben. Ein Footprint gehört aus logischer Sicht IMHO nicht zum Schaltplan, sondern zum Layout, und zwar NUR zum Layout.
:
Bearbeitet durch User
Possetitjel schrieb: > Es tritt immer wieder auf, dass das Wissen in einer bestimmten > Bearbeitungsstufe noch unvollständig ist, und man trotzdem > weiterarbeiten will. Die Software muss das ermöglichen! Eben! Und KiCad macht das, indem es sagt: "Falls Du schon weisst, welchen Footprint das sein soll, sag's mir. Ansonsten lasse ich dieses Feld erst mal noch offen. Possetitjel schrieb: > Es ist genau, wie Du schreibst: Es gibt durchaus nicht > nur "abstrakte" und "physikalische" Bauteile, sondern > es gibt EINE GANZE REIHE unterschiedlicher Abstraktions- > ebenen, auf denen die Auswahl der "zulässigen Kandidaten" > mehr oder weniger stark eingeschränkt wird. Genau so bei KiCad. Du kannst in der Bibliothek ein Bautel anlegen für einen 100 Ohm Widerstand im 0605 Gehäuse mit 1% Genauigkeit und der Farbe Rot. Und ein weiteres Bauteil mit exakt denselben Werten, jedoch der Farbe Grün. Wie geht denn das bei Eagle? Wenn ich den Footprint nicht weiss, kann ich dann das Symbol dennoch platzieren? Ist das dann halt ein "generischer Widerstand" ohne Footprint? Und wie gebe ich dem dann einen Footprint? Indem ich den Widerstand im Schema durch einen "konkreten" Widerstand ersetze? Nachtrag: Ich habe gerade ein Deja-vu. Zu Folgender Erkenntnis bin ich mal in einem anderen Thread gekommen: > 1. KiCad lässt eine a-priori Festlegung auf einen Footprint zu. > 2. KiCad zwingt niemanden dazu. > 3. Eagle lässt eine a-priori Festlegung auf einen Footprint zu. > 4. Eagle zwingt niemanden dazu. > Aus 1 und 2 folgt, dass KiCad ein Basteltool ist. > Aus 3 und 4 folgt, dass Eagle ein Profitool ist. (fairerweise muss man sagen, dass man die letzten Zeilen auch umgekehrt formulieren kann - je nach Sichtweise ;-) Ausserdem ist dieser Thread hier weit weniger polemisch. :-)
:
Bearbeitet durch User
Lars R. schrieb: > Possetitjel schrieb: >> Das komplette Bauteil gehört in die interne "Super- >> stückliste". >> In den Schaltplan gehört eine Referenz auf die entsprechende >> Position der "Super-Stückliste"; der Schaltplaneditor zeigt >> das zugehörige Symbol an. >> In das Layout gehört eine Referenz auf die entsprechende >> Position der "Super-Stückliste"; der Layouteditor zeigt den >> zugehörigen Footprint an. >> >> Eigentlich ganz einfach und logisch... > > Und was passiert dann Deiner Ansicht nach, wenn Du die > Verlustleistung vom Symbol änderst? Erstmal die "naive" Variante: Nach meiner Ansicht hat das Symbol keine Verlustleistung, sondern nur das Bauteil (also eine bestimmte "Zeile" in der internen "Super-Stückliste"). Wenn Du die Verlustleistung ändern willst, musst Du das entsprechende (Exemplar des) Bauteil(s) in der internen "Super-Stückliste" durch ein anderes ersetzen, das die gewünschte Verlustleistung verträgt. (Das könnte durchaus das GUI des Schaltplaneditors mit erledigen -- die Variable, die die Daten tatsächlich enthält, befindet sich aber in der Super-Stückliste.) > Geht dann die Datenstruktur "Bauteil" kaputt? Jein :) Wenn Du verbindlich Footprint 0402 und Verlustleistung 5W forderst, dann stehen zwar diese Werte in der "Super-Stückliste", aber sie entsprechen keinem Bauteil in der Bauteil-Datenbank mehr -- einfach weil es diese Kombination nicht gibt. > Bekommt der 0402-Footprint plötzlich 5W Verlustleistung? Nein. Wenn Du im entsprechenden Dialog nach der Verlustleistung selektierst, wird 0402 nicht in der Treffermenge angezeigt, weil es keine 5W verträgt. Wenn Du 0402 auswählst, wird als Verlustleistung 60mW (oder was immer da herauskommt) eingetragen. > Willst Du es einfach verbieten, dass beim Symbol die > Verlustleistung geändert wird? Jein: Ein Schaltplansymbol hat einfach keine Verlust- leistung. (Die hat es ja WIRKLICH nicht.) Jetzt die "nicht ganz so naive" Variante: Ich sehe durchaus das Problem, das Du ansprichst; ich hatte es bis jetzt nicht auf dem Schirm, einfach weil ich von dessen Existenz bisher nichts wusste :) Als Lösungsvorschlag werfe ich mal folgendes in den Raum: Man schafft im GUI des Schaltplaneditors die Möglichkeit, den einzelnen Bauteilen bestimmte Restriktionen zuordnen zu können. Die konkreten Vertreter, die in der "Super- Stückliste" aufgeführt sind, erfüllen entweder diese Restriktionen, dann ist alles gut, oder sie erfüllen sie nicht, dann wird das angezeigt. Die Weiterbearbeitung wird nicht verhindert, aber trotzdem ist das automatisiert prüfbar. Der Trick dabei ist, dass die Verlustleistung des Bauteil eine Verlustleistung, also ein Kennwert (=eine Zahl) ist, während die Restriktion "Pv >= 5W" eben KEINE Leistung, sondern eine Restriktion (in Form einer Ungleichung) ist, die erfüllt oder nicht erfüllt sein kann. > usw. Neinein, das ist super. Sachliche Kritik ist willkommen.
ZF schrieb: > In der freien Welt kann der Nutzer einem Symbol kein, ein, oder viele > (eine sinnvolle Vorauswahl) Footprints zuordnen, ganz wie er mag. Das ist doch Käse. Ein reales Bauelement hat einen (mehrere)Footprint(s). Bei der Schaltungsentwicklung lege ich bereits die Anforderungen an die BE fest und ich entscheide schon beim Entwurf ob ich Durchsteckmontage oder SMD möchte. Falls ich mich dann später umentscheiden möchte ist das kein Problem. Es ist auch kein Problem, wenn ich beim Layouten merke, das eine andere Bauform, Größe etc. besser geeignet ist als ursprünglich im Schematic vorgeshen war, das erledige ich das bei Eagle mit 3 Klicks im Layouteditor ("Element ersetzen" wählen >> neues BE auswählen >> das zu ändernde BE im Layouteditor anklicken). Am Schematic ändert das zumindest optisch erst mal nichts. Wenn ich mir dann allerdings Informationen zum Device im Schematic anzeigen lasse, dann sehe ich sehr wohl, das BE jetzt einen neuen Footprint hat. Umgekehrt, also bei Änderungen im Schematic, dann wirkt sich das natürlich auch im Layout aus, sofern das neue BE einen anderen Footprint hat. Ich habe also auch bei dem Konzept von Eagle alle Freiheiten. Ich kann auch in Eagle generische Symbole, also solche ohne Footprint benutzen. Und ja solche Symbole werden natürlich nicht im Layout angezeigt - wie soll das auch funktionieren, wenn sie keinen Footprint haben Noch was zu FB: Das ist natürlich essentiell. Wie anders will ich sonst sicherstellen, das Bord und Schematic konsistent sind? Bei wenigen BE kann ich das zur Not noch selbst manuell erledigen, wenn's dann aber viele BE sind wird's schon schwierig und die Wahrscheinlichkeit das man etwas übersieht wird sich 100% nähern. Es hat schon einen Grund warum z.B. Profiprogramme wie z.B. Pulsonix auf dieses Feature nicht verzichten. Letztendlich bleibt es jedem selbst überlassen welches Programm er benutzt. Dennoch sollte man in der Lage sein Fehler im Programm bzw. konzeptionelle Schwächen zu benennen und nicht schön zu reden. Es gibt keine fehlerfreien Programme. Eine steile Lernkurve ist eben kein Feature sondern ein konzeptioneller Fehler. Selbst ein Profiprogramm wie Pulsonic leistet sich solch eine Schwäche bei den grundlegenden Funktionen nicht. Man ist bei diesem Programm durchaus in der Lage ohne Studium eines Tutorial ein einfaches Schematic + Board zu erstellen.
Lars R. schrieb: > Ein Bauteil ist eine Beziehung Footprint<>Symbol, ggf. +Attribute > > Diese Beziehung (Bauteil) kann man auch in eine Library packen. Das wäre > in der Library eine dritte Kategorie (Bauteil, Footprint, Symbol). > > Für die Instanzen, dh im Projekt, könnte man es vielleicht so > realisieren: > 1. Bauteil (Footprint, kein Symbol) > 2. Bauteil (kein Footprint, Symbol) > 3. Bauteil (Footprint, Symbol) > > Im Layout wird mit dem Footprint gearbeitet, im Schematic mit dem > Symbol. > Im Zuordnungsdialog und bei den Annotations mit beidem. So ganz grundsätzlich würde ich die Datenstruktur einer Library im ersten Schritt etwa so designen, wie in den Anhängen beschrieben. Ist aber bisher nur ein erster Gedanke, mehr nicht. Unbedingt sollte man dort sogar noch Datasheets, Distributoren/Lieferanten und / oder Simulationsmodelle oder weitere Dinge einbauen. Das Ganze ließe sich, mal ins Blaue gedacht, im Backend wunderbar mit einer Volltext-Suchmaschine wie Apache Solr oder Elasticsearch abbilden. Dadurch gewänne man die Möglichkeit, den Daten im Volltext durchsuchen zu können -- und wenn die Datenblätter eingebunden wären, sogar in denen. Obendrein wäre solch eine Lösung zweifellos gut skalierbar, Elasticsearch und Apache Solr unterstützen verteilte Cluster-Modus mit Replikation und Sharding. HINWEIS: ja, ich habe viele naheliegende Datenfelder für die einzelnen "Datenstrukturen" bewußt ausgelassen. Danke für den Hinweis. :-)
Possetitjel schrieb: > Man kann zwar den Footprint nachträglich ändern, aber man > kann kein Symbol ganz ohne Footprint in den Schaltplan > einfügen. Entspricht das so den Tatsachen? Man kann.
Das Problem mit dem Footprint liegt eigentlich schon im Workflow bei einer Produktentwicklung. Bei mir ist es so, das nach dem Schematic Entwurf der Einkauf sofort die BOM haben möchte um zu sehen ob das überhaupt finanziell im Rahmen liegt. Also weit bevor irgend eine einzige Leiterbahn geroutet ist. Ich brauche da also schon das komplette Bauteil mit Footprint und Bestellnummer. Zusätzlich gibt es eine firmeninterne Bauteilbibliothek mit getesteten Bauteilen auf die im optimalen Fall zu 100% zurückgegriffen werden muss. Neue Bauteile muss man dann als Entwickler teilweise mit Händen und Füßen verteidigen:-) Wenn ich beim Routen feststelle das geht auf keinen Fall, werden einzelne Bauteile in der BOM geändert. Aber im großen Stil mal eben 50% aller Bauteile zu ändern ist ein No-go.
Thomas F. schrieb: > Das Problem mit dem Footprint liegt eigentlich schon im Workflow bei > einer Produktentwicklung. Bei mir ist es so, das nach dem Schematic > Entwurf der Einkauf sofort die BOM haben möchte um zu sehen ob das > überhaupt finanziell im Rahmen liegt. Also weit bevor irgend eine > einzige Leiterbahn geroutet ist. Sehr guter Einwurf!
Zeno schrieb: > Das ist doch Käse. Ein reales Bauelement hat einen > (mehrere)Footprint(s). Bei der Schaltungsentwicklung lege ich bereits > die Anforderungen an die BE fest und ich entscheide schon beim Entwurf > ob ich Durchsteckmontage oder SMD möchte. Für dich mag das gelten, andere möchten sich nicht immer schon beim Zeichnen des Schaltplans auf jeden Footprint und damit auch auf das Lötverfahren (z.B. Welle oder Reflow) festlegen müssen. Sie finden es schön sich festlegen zu können, wo Bauteil und Lötverfahren feststehen, und die Festlegung auf später verschieben zu können, wenn Bauteil und Lötverfahren noch nicht feststehen. > Letztendlich bleibt es jedem selbst überlassen welches Programm er > benutzt. Genau, ist doch schön, dass es für Jeden was passendes gibt.
Possetitjel schrieb: > [...] Wird sind uns einig, dass man ein Symbol ohne Footprint im Schematic haben kann? Wir sind uns einig, dass man ein Symbol mit Footprint im Schematic haben kann? Mit dem Footprint ist bereits ein Layout gebaut. Wir sind uns einig, dass man ein Symbol ohne Footprint im Schematic haben kann und der Entwickler sagt: An diesem Widerstand (egal welcher Footprint das auch sein möge) benötige ich 5Watt Verlustleistung? Folgendes Szenario: Symbol im Schematic. Footprint im Layout, dh es existiert bereits ein Layout mit dem Footprint 0402 (in welchem Stadium sich das Layout befindet, das sei dahin gestellt). Nun möchte der Entwickler im Schematic die Vorgabe 5W Verlust an diesem Widerstand eintragen. Nochmal meine Fragen: . Geht dann die Datenstruktur "Bauteil" kaputt? . Bekommt der 0402-Footprint plötzlich 5W Verlustleistung? . Willst Du es einfach verbieten, dass beim Symbol die Verlustleistung geändert wird? Genauer entsprechend Deinem Ansatz: Sobald ein Footprint gewählt wurde, darf im Schematic die Verlustleistung nicht mehr beliebig geändert werden. Zuerst muss vorher der Footprint aus dem Layout gelöscht werden. > Der Trick dabei ist, dass die Verlustleistung des Bauteil > eine Verlustleistung, also ein Kennwert (=eine Zahl) ist, > während die Restriktion "Pv >= 5W" eben KEINE Leistung, > sondern eine Restriktion (in Form einer Ungleichung) ist, die > erfüllt oder nicht erfüllt sein kann. So ähnlich wird das gemacht. Man kann beliebige Attribute anlegen. Warum schaust Du Dir nicht mal an einer Uni/FH bei Elektrotechnik die großen Suiten (Mentor, Cadence) an, bevor Du unbedingt mit dem Kopf durch die Wand gehst?
Kleiner Nachtrag: Man kann sich in Kicad eine Symbol-lib erstellen, in der jedem Symbol exakt ein Bauteil mit exakt einem Footprint für exakt ein Lötverfahren zugewiesen ist. Aber, auch wenn eine spätere Änderung möglich ist, warum sollte man sich selbst so gängeln? Doch wer Gängelung mag, der kann auch mit Kicad glücklich werden.
Was ist das nur immer und immer noch mit dem Eagle? Soll das wirklich für immer der Maßstab sein? Dann wird's Zeit für Kicad-Subscription.
Sheeva P. schrieb: > [aufteilung.png] Der Footprint in der Footprint-Library kann eine Verlustleistung haben Jeder Footprint im Layout kann eine andere Verlustleistung haben, obwohl es in der Library alles der selbe Footprint ist. Das Symbol in der Symbol-Library kann eine Verlustleistung haben Jedes Symbol im Schematic kann eine andere Verlustleistung haben, obwohl es in der Library alles das selbe Symbol ist. Ergo: Class Footprint (Library) Instanz Footprint (Projekt) weitere Funktion: Überschreibe Eigenschaften der Klasse mit den aktuellen Eigenschaften der Instanz selbiges für Symbol. Annotations: Synchronisation der Datensätze Schematic und Layout.
:
Bearbeitet durch User
Leute der wievielte Therad ist das eigentlich in dem wir uns mit W.S. kruden Ansichten über die KiCad vs. Eagle Verfahrensweise auseinandersetzen? Das ist doch mindestens der 5. oder 6... Meint Ihr das hat Sinn? Ich denke nicht das W.S. das mal einsehen wird, so lange KiCad nicht gleich Eagle ist wird es für ihn nicht taugen, aber ist das wirklich das Problem einer ganzen Community? Gruß, Holm
Ich mag KiCAD :) Hab es um Weihnachten rum in 2 Tagen so weit gebracht meine, zu dem Zeitpunkt, in Entwicklungsstadium befindlichen Schaltpläne damit zu zeichnen. Der Workflow ist tatsächlich etwas gewöhnungsbedürftig. Gut fand ich: - Gratis - Umfangreich - Habe mit den OnlineTutorials alle Standardthemen verstanden Kritik von mir: - Auswählen von Bauteilen und Scrollen ist teilweise doch etwas unangenehm (Bauteil packen, an den Fensterrand schieben um weiterzuscrollen, plötzlich 30cm weiter) - Autorouter muss man von Hand reinstricken Gescheitert bin ich mit: dem Export der Echtzeit 3D Darstellung und dem folgenden Import in FreeCAD
Vielleicht sollte man mal schauen wie die großen Firmen das mit ihren Bauteilen machen. Beispiel: http://www.sphere.bc.ca/download/hp_xref-free.pdf Dort hat jedes Bauteil eine Nummer. Die Nummern sind dabei nach Kategorien geordnet. Hinter jeder Nummer steckt eine Liste der dafür gültigen Teile, footprints und weiterer Informationen. Meines Wissens nach machen das viele große Firmen so. Das ist zwar für den Bastler etwas abstrakt aber im Profibereich finde ich das eine gute Sache.
Ich war lange Zeit Eage user, weil nix anderes brauchbares für kleines Geld gab. Ich habe diese Diskussion nun genutzt mich endlich mal näher mit KiCAD auseinander zu setzen. Ich hab also inzwischen mehrere Tage mit der sw gespielt und ein (wenn auch klitzekleines) Projekt erstellt. Mein erster Eindruck ist erst mal nicht schlecht. Ob ein footprint nun im Schaltbild oder während der Layoutphase gesetzt wird ist mir erst mal egal. Wahrscheinlich würde ich mir sowieso eine eigene Bibliothek anlegen bei der die gängigen Bauteile (R,C, usw) mit einem footprint vorbelegt sind. Ich sehe an dieser Stelle kein wirkliches Problem, im Gegenteil. Wenn ich an die (in meinen Augen) wirklich vermurkste Bibliotheksverwaltung bei Eagle denke, hab ich den KiCAD Workflow nach wenigen Stunden schon mehr oder weniger verinnerlicht. Die Kritik von einigen, dass KiCAD am user vorbei programmiert wurde würde ich nicht so krass formulieren, aber ganz unberechtigt ist die in meinen Augen auch nicht. Leider gibt's wiklich ein paar "Eigenheiten" in der die echt gar nicht nachvollziehen kann. Ein Beispiel wäre das verschieben von Bauteilen mitsamt Leiterbahnen. Im Schaltbild: Einzelbauteil verschieben mit "g". Bauteilgruppe verschieben mit "m", dann "TAB". Das Gradeziehen der danach schiefen Leitungen ist ziemlich mühselig. Warum bleicbt ihre Ausrichtung nicht einfach erhalten? Wenn Zwei Bauteil direkt zusammenhängen (Pin auf Pin) verschieben sich beide Bauteile hmmm. Im Layout: Bauteil verschieben mit "m". Die Leiterbahnen reisen aber ab. Verschieben mit Leiterbahnen hab ich gar nicht geschafft. Dann verhält sich das Verschieben von Leiterbahnen auch noch unterschiedlich je nachdem ob Canvas "Standart" oder "OpenGL" oder "Cairo" angewählt ist. Außerdem muß auch noch vorher der Punkt "Leiterbahn hinzufügen" angewählt sein, während im Schaltbild der "Pfeil" angewählt sein muß. Nach meinem Gefühl ein ziemliches Wirrwarr... (vlt. habe ich's auch noch nicht ganz kapiert). Was ich an Eagle noch sehr geschätzt habe war die komfortable Auswahl von bestimmten Bereichen mit einem beliebigen Polygon. Das ist was ich sehr an KiCAD vermisse. Generell empfinde ich das nachträgliche "optimieren" von Schaltbild oder Layouts nicht sehr gut gelungen. Alles was mit ändern, schieben, bewegen zu tun hat ist doch sehr mühselig. Es gibt also noch Luft nache oben ;-)
Holm T. schrieb: > Leute der wievielte Therad ist das eigentlich in dem wir uns mit W.S. > kruden Ansichten über die KiCad vs. Eagle Verfahrensweise > auseinandersetzen? > Das ist doch mindestens der 5. oder 6... > Meint Ihr das hat Sinn? Ja, nicht wegen W.S., aber wegen der Leute, die es lesen und seinen Unsinn sonst vielleicht glauben würden. > Ich denke nicht das W.S. das mal einsehen wird, > so lange KiCad nicht gleich Eagle ist wird es für ihn nicht taugen, aber > ist das wirklich das Problem einer ganzen Community? Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser sein als etwas für das er Geld bezahlt hat. Das ist gegen sein Werteverständnis.
As-I-Roved-Out schrieb: > Auswählen von Bauteilen und Scrollen ist teilweise doch etwas > unangenehm > (Bauteil packen, an den Fensterrand schieben um weiterzuscrollen, > plötzlich 30cm weiter) Es gibt die Möglichkeit mit Ctrl + Mausrad horizontal zu scrollen. Shift + Mausrad scrollt vertikal.
As-I-Roved-Out schrieb: > Kritik von mir: > ..... > - Autorouter muss man von Hand reinstricken Frag mal in die Runde wer den vermisst ? ich nicht. As-I-Roved-Out schrieb: > Gescheitert bin ich mit: > dem Export der Echtzeit 3D Darstellung und dem folgenden Import in > FreeCAD Frag mal Tante Google nach "KiCad ist geil" gleich der erste Treffer kann dir vieleicht weiterhelfen. So am Rande: Das ist übrigens ein Beispiel für eine gut gemachte SEO Optimierung. Immer hin gibt es da eine Klickzahl auf die Bilder von über 1000. (sowas würde man einen Azubi gar nicht zutrauen :O )
Gu. F. schrieb: > Ich hab also inzwischen mehrere Tage mit der sw > gespielt und ein (wenn auch klitzekleines) Projekt erstellt. Deine Vorgehensweise sich in ein neues CAD einzuarbeiten ist gut! Aber daraus einen Bericht zu stricken, wo man den Eindruck hat das war dein 10. Großprojekt ist weniger gut. Warte es mal eine Zeit lang ab, dann wird sich der Inhalt deines Berichtes umdrehen. Lese dir dazu nochmals den Eingangsbeitrag vom TO (Bob A.) durch.
ZF schrieb: > Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser > sein als etwas für das er Geld bezahlt hat. Das ist gegen sein > Werteverständnis. Da ist W.S bestimmt nicht alleine unterwegs :-(
Naja, ein paar "Eigenheiten" nimmt man ja in der Tat nur hin weil das Programm für lau daher kommt... Andererseits... falls man sich einbringen möchte, und sei es nur mit (hoffentlich) konstruktiver Kritik... @KiCadSuperman: Ich deute dein Nickname mal so dass du dich mit KiCAD recht intensiv befasst hast, deswegen die Frage an deine Adresse: gibt es da eine zentrale Annahmestelle für?
:
Bearbeitet durch User
Bob A. schrieb: > gibt > es da eine zentrale Annahmestelle für? für was ?? Meistens entscheidet man sich für einen Nicknamen wenn man auf den ersten Beitrag im Thread antwortet, weil er dazu am besten passt. Gemäß den Forenregeln hier ist man dann aber gezwungen den gewählten Namen beizubehalten. Meistens ist es bei mir aber so, dass meine Nicknamen eher als Understatement daherkommen.
KiCadSuperman schrieb: >> gibt es da eine zentrale Annahmestelle für? > > für was ?? für jenes was ich davor schrub: Bob A. schrieb: > falls man sich einbringen möchte, und sei es nur mit (hoffentlich) > konstruktiver Kritik...
Bob A. schrieb: > gibt > es da eine zentrale Annahmestelle für? meinst du das hier ? https://bugs.launchpad.net/kicad/+bugs?orderby=-date_last_updated&start=0 Um da zu posten musst du angemeldet sein. Die reagieren recht flott - so meine Erfahrung. Aber einen Newcomer würde ich nicht dazu raten da sofort "Vorschläge zu machen" Die werden dann meistens sofort wiederlegt und man selber verliert die Lust dabei. Hingegen echte "Kinken" kann man sehr wohl posten. Die müssen aber gut belegbar und nachvollziehbar / reproduzierbar sein!
KiCadSuperman schrieb: > Warte es mal eine Zeit lang ab, Warten bringt mir nichts. Wie wärs, wenn du mir eine Lösung hierfür erklärst. Gu. F. schrieb: > Bauteil verschieben mit "m". Die Leiterbahnen reisen aber ab. > Verschieben mit Leiterbahnen hab ich gar nicht geschafft. Und diese "Bemerkung" versteh ich jetzt grad gar nicht. KiCadSuperman schrieb: > Aber daraus einen Bericht zu stricken, wo man den Eindruck hat > das war dein 10. Großprojekt ist weniger gut. P.S. ... siehe Titel des Fadens!
:
Bearbeitet durch User
Gu. F. schrieb: > Leider gibt's wiklich ein paar "Eigenheiten" in > der die echt gar nicht nachvollziehen kann. > > Ein Beispiel wäre das verschieben von Bauteilen mitsamt Leiterbahnen. Du kommst halt von einem anderm CAD-Welt. Das kann ich ja nochvollziehen. Ich z.B. kann keinen Vorteil darin sehen, dass z.B. beim Verschieben eines Bauteils quer über die Platine die Leiterbahnen angeheftet bleiben. Sie bedecken dann sofort alle möglichen Bauteile - und wie gehts dann weiter ? Der Weg hier ist (bei KiCad), dass man das Bauteil dort hin bewegt wo man es will (die Netzlinien gehen ja mit). Dann löscht man die alten Leiterbahn-Stummel und verbindet neu. (Am besten dann mit P&S) - fertig ist die Schose. Wie gesagt, warte es mal ab in spätestens einem Jahr siehst du das anders.
KiCadSuperman schrieb: > Ich z.B. kann keinen Vorteil darin sehen, dass > z.B. beim Verschieben eines Bauteils quer über die Platine die > Leiterbahnen angeheftet bleiben. Ach so, braucht man also nicht. Ich hab's schon verstanden...
Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß ich 84 Leitungen neu verlegen???
:
Bearbeitet durch User
Gu. F. schrieb: > Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß > ich also 84 Leitungen neu verlegen??? JA und was ist so schlimm dabei? Hast du sowas mit EAGLE jeden Tag 2x gemacht? Das schlimmste was einem im realem CAD Leben passiert ist, dass man z.B. einen 64er QFN Bauteil verschieben muss, das geht aber leider nicht so schön linear wie im deinem schönen Beispiel :-(
KiCadSuperman schrieb: > JA und was ist so schlimm dabei? > Hast du sowas mit EAGLE jeden Tag 2x gemacht? Wie bitte? Also zumindest ich mach das dauernd... und solange die Verschiebung in Richtung der Leiterbahn erfolgt, soll sich diese gefälligst verkürzen/verlängern, sodass NULL Nacharbeit nötig ist. bei anderen Winkeln muss man sowieso ran...
:
Bearbeitet durch User
ZF schrieb: > Sein Problem sitzt tiefer: Etwas was nichts kostet darf nicht besser > sein als etwas für das er Geld bezahlt hat. Das ist gegen sein > Werteverständnis. Oh, keine Panik. Bis es soweit ist, wird Kicad noch ein paar Jährchen brauchen. Possetitjel schrieb: > Man kann zwar den Footprint nachträglich ändern, aber man > kann kein Symbol ganz ohne Footprint in den Schaltplan > einfügen. Natürlich kann man Symbole ohne Footprint einfügen. Possetitjel schrieb: > Das komplette Bauteil gehört in die interne "Super- > stückliste". > In den Schaltplan gehört eine Referenz auf die entsprechende > Position der "Super-Stückliste"; der Schaltplaneditor zeigt > das zugehörige Symbol an. Deine "Superstückliste" hat einen entscheidenden Denkfehler. Sie ist als solche nichts wert. Warum? Darum: > Zum Beispiel dann, wenn man eine Schaltungsidee hat und > davon eine SPICE-Simulation machen will. Eine Stückliste ohne Netzliste ist weder für Schaltplan noch für Layout sinnvoll. Es bringt Dir gar nichts alles über die Eigenschaften der Bauteile zu wissen, wenn Du nicht weisst wie sie verbunden werden.
KiCadSuperman schrieb: > JA und was ist so schlimm dabei? > Hast du sowas mit EAGLE jeden Tag 2x gemacht? Muhaha, ist das geil! Hier fehlen grundlegende Funktionen und Du säufst Dir das schön, weil Du es um jeden Preis verteidigen musst. Junge, wenn etwas Scheisse ist, dann darf man das auch Scheisse nennen und muss es nicht als Schokotorte verkaufen.
Michael R. schrieb: > Wie bitte? Also zumindest ich mach das dauernd... und solange die > Verschiebung in Richtung der Leiterbahn erfolgt, soll sich diese > gefälligst verkürzen/verlängern, sodass NULL Nacharbeit nötig ist. bei > anderen Winkeln ... muss man sowieso ran... ach ja? Karl schrieb: > Hier fehlen grundlegende Funktionen und Du säufst Dir das schön, weil Du > es um jeden Preis verteidigen musst. Deine Formulierungen sind richtig geil - die gefallen mir. Karl schrieb: > Junge, wenn etwas Scheisse ist, dann darf man das auch Scheisse nennen > und muss es nicht als Schokotorte verkaufen. Da hab ich ja komplett in ein Wespennest gestossen. (das wollte ich aber nicht :-) Karl schrieb: > Muhaha, ist das geil! ... wie die so rumschwirren :-))
KiCadSuperman schrieb: > JA und was ist so schlimm dabei? Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen. Aber meinem Chef möchte ich dann nicht erklären müssen warum ich eine Stunde brauche um ein paar mm Platz zu schaffen. Du hört sich an als hättest du noch nie ein Layout erstellt, zumindest außerhalb deiner Freizeit.
> KiCadSuperman schrieb: >> JA und was ist so schlimm dabei? JA und ich bleib dabei. Notfalls kann man im KiCad den externen Autorouter bemühen wenn es um solche lineare Verschiebungen (wie oben beschrieben) geht. Das geht ratzi fatzi. @Karl Für mich ist KiCad geil geiler am geilsten. Das kommt bei mir gleich nach den Frauen :-))
Gu. F. schrieb: > KiCadSuperman schrieb: >> JA und was ist so schlimm dabei? > > > Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen. > Aber meinem Chef möchte ich dann nicht erklären müssen warum ich eine > Stunde brauche um ein paar mm Platz zu schaffen. > > Du hört sich an als hättest du noch nie ein Layout erstellt, zumindest > außerhalb deiner Freizeit. Ist ja recht..aber laß KiCad mal ein Bisschen älter und reifer werden. Das nächste freie CAD System steht ja auch schon in den Startlöchern (Beitrag "Horizon EDA [War: Neues, halbfertiges Elektronik-CAD-Programm]") und Eagle sollte eine "erfahrene" und durchentwickelte Plattform sein..trotzdem hat es etliche Unzulänglichkeiten. KiCad kostet mich nix und es macht keinen Unterschied ob ich damit für mich privat oder in meiner kleinen Firma kommerziell entwickle..das was Autodesk sich da denkt geht aber aus beiden Sichten gar nicht. Die "Freeware" ist nicht mehr zeitgemäß und zu restriktiv, die möglichen Platinen zu klein, das was ich kommerziell bräuchte rechnet sich nicht und mit der neuen Lizensierung nie mehr.. so wo bitte ist der Vorteil? ..da lebe ich doch lieber mit einem CAD System mit dem ich Alles tun kann, das aber u.U. noch nicht ganz fertig ist. Gruß, Holm
Gu. F. schrieb: > Klar, mit genügend Spieltrieb kann man auch ein TQP96 neu anschließen. Schlags den Jungs vor. Frage sie, ob es möglich ist P&S auf das Verschieben von Bauteilen mit den angeschlossenen Leiterbahnen zu erweitern. Oder arbeite an einer entsprechenden Lösung mit.
Holm T. schrieb: > das was ich kommerziell bräuchte rechnet sich nicht > und mit der neuen Lizensierung nie mehr.. Sehe ich bei mir genauso. Ich mach mal monatelang keine Leiterplatten, dann wieder mehrere. Da hab ich keine Lust ständig die Lizenz anzupassen. Also bleib ich erstmal bei der gut abgehangenen 6.5 im Wissen, dass ich die noch ein paar Jahre nutzen und zur Not auch in Kicad importieren kann, und schau mal wie sich das entwickelt. KiCadSuperman schrieb: > Deine Formulierungen sind richtig geil - die gefallen mir. Das freut mich. Ich finde es halt immer witzig, wenn Leute Kritik an der Sache gleich als Kritik an sich auffassen und sich dann die blödesten Argumente ausdenken, warum die eigentlich doofe Umsetzung jetzt doch ganz toll ist. Leider kommt man dabei technisch nicht weiter, weil eine Diskussion abgewürgt wird. Vor einiger Zeit hiess es bei Kicad zu FB-Anno: Braucht kein Mensch, machen wir nicht. Inzwischen gibt es Ansätze dafür und in 1-2 Jahren werden sie das wohl implementiert haben. Auch das mit den anhängenen Leiterbahnen werden sie implementieren. Aber dazu muss man halt drüber reden können, und da sind Leute wie Du eher hinderlich.
Karl schrieb: > Holm T. schrieb: >> das was ich kommerziell bräuchte rechnet sich nicht >> und mit der neuen Lizensierung nie mehr.. > > Sehe ich bei mir genauso. Ich mach mal monatelang keine Leiterplatten, > dann wieder mehrere. Da hab ich keine Lust ständig die Lizenz > anzupassen. > > Also bleib ich erstmal bei der gut abgehangenen 6.5 im Wissen, dass ich > die noch ein paar Jahre nutzen und zur Not auch in Kicad importieren > kann, und schau mal wie sich das entwickelt. > [..] Bin völlig Deiner Meinung nur kommt bei mir hinzu das ich i.A. kein Windows auf den Rechnern habe sondern FreeBSD, hier existiert deshalb auch keine alte Version von Eagle, das war noch nie praktikabel. Ich für meinen Teil kann mit KiCad relativ gut arbeiten ..wie Dus mit Deiner alten Version E. wahrscheinlich auch kannst. Der einzige Grund da ich hier überhaupt das Maul aufgerissen habe sind W.S.s seltsame Ansichten. >Und warum sollte das mit Eagle nicht gehen? Hab ich auch schon für >eigene Projekte gemacht, die ich vor Jahren mit THT gebaut und dann auf >SMD aktualisiert habe. > >Und das Schöne: Man kann die Footprints im Layout ändern und gleich die >Platzierung überprüfen - und dank FB-Anno wird das für den Schaltplan >übernommen. Man kann auch bei KiCad die Footprints im Layout ändern wenn man unbedingt möchte, man muß aber nicht. Der Aufwand das an der richtigen Stelle zu machen ist vergleichsweise gering, das übergeordnete KiCad fenster mit dem man EEschema und auch PCBnew startet ist doch im Hintergrund ständig offen. es gibt also keinen Grund die Änderung unbedingt im Layouteditor durchführen zu müssen, aber man kann es auch tun. Ich werde Keinem vorschreiben das er nur grüne Schraubendreher zu verwenden hat und das Blaue Mist sind. Gruß, Holm