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
Thomas F. schrieb: > Das Problem mit dem Footprint Verzeihung: Welches Problem genau? > 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. Hmm, okay. > 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:-) Hmm. Wenn ich das richtig verstehe, so ist das doch mit meiner Idee der Super-Stückliste vollkommen kompatibel, oder nicht? Du müsstest halt am Anfang der Entwicklungsarbeiten die programminterne Super-Stückliste mit Bauteilen aus der Bauteildatenbank befüllen -- wobei Du halt nur keine einzelnen Symbole und keine einzelnen Footprints in die Super-Stückliste übernehmen darfst, sondern immer nur komplette Bauteile. Da tritt doch ansonsten kein Problem auf?! > Wenn ich beim Routen feststelle das geht auf keinen Fall, > werden einzelne Bauteile in der BOM geändert. Ja, klar. Nachträglich ändern geht immer.
Holm T. schrieb: > Ist ja recht..aber laß KiCad mal ein Bisschen älter und reifer werden. Wie lange dauert das noch? > Das nächste freie CAD System steht ja auch schon in den Startlöchern Geil. Lasst alles stehen und liegen! > Eagle sollte > eine "erfahrene" und durchentwickelte Plattform sein..trotzdem hat es > etliche Unzulänglichkeiten. Welche im Vergleich zu KiCad? > KiCad kostet mich nix und es macht keinen Unterschied ob ich damit für > mich privat oder in meiner kleinen Firma kommerziell entwickle Ok, wenn Du dabei frustfrei zum gewünschten Ergebnis kommst. > Die "Freeware" ist nicht mehr zeitgemäß Was ist an der Eagle Freeware nicht zeitgemäß? > die möglichen > Platinen zu klein Mit frei dimensionierbsren 80cm2 lässt sich aber eine ganze Menge anstellen! Karl schrieb: > Ich mach mal monatelang keine Leiterplatten, > dann wieder mehrere. Da hab ich keine Lust ständig die Lizenz > anzupassen. Also ideale Situation für die Miete. Was gibts da ständig anzupassen? Die 3 Mausklicks fürs benötigte Abo sind schon zuviel? Alle paar Monate?
Hallo Gu. F. Gu. F. schrieb: > Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß > ich 84 Leitungen neu verlegen??? Solange Du nur einen Footprint (oder andere Objekte) verschiebst, nimmst Du "drag" statt "move" und die Leiterbahnen werden mitgezogen. Leider gibt es diese Option noch nicht für Blöcke. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Karl schrieb: > 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. Mein lieber Schokotortenverschmäher, es kann aber auch so sein, dass getreue EAGLE User (die werden es nicht zugeben) durch AD quasi über Nacht zu einer Umorientierung gezwungen wurden und müssen nun mit ihrem Trennungsschmerz irgendwie zurechtkommen :-( (die bräuchten eigendlich sowas wie ne Trauerhilfe;-) Da reicht eine Kleinigkeit dass sowas wie hier hochkocht. Im Übrigen war mir schon bewusst das meine Bemerkung "JA und was ist so schlimm dabei? " bei euch was auslöst, war dann aber doch über die Heftigkeit erstaunt. Ja, ich stehe dazu, das die Verschiebung von Bauteilen mit angehefteten Leiterbahnen in den allermeisten Fällen nichts bringt und zwar aus besagten Gründen siehe oben. (Scheise hin oder her ;-)
Hallo Karl. Karl schrieb: > 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. Das ist ganz normales Menschliches Verhalten. > 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. Nunja. Wenn es jemandem so unter den Nägeln brennt, dann schreibt er halt sich halt z.b. ein Pythonskript dazu, dass die Footprint Referenzbezeichner aus dem Board mit den Symbolreferenzbezeichnern aus dem Schaltplan vergleicht, und den Verbindungen dazu im Board provisorische Netznamen zuteilt. Für Referenzbezeichner, die nur im Board auftauchen, gibt es dann ein auswahlfenster, wo man sich passende Symbole aussuchen kann, und die Symbole werden dann zusammen mit den neuen Verbindungen in den Schaltplan geschrieben. Anschliessend öffnest Du mit EEschema den Schaltplan, und nimmst die endgültige Positionierung vor. Und dann, um sauber zu sein, noch einmal eine Vorwärtsannotation. Das Skript sollte nicht all zu kompliziert sein, und der, der es wirklich benötigt, wird es sich selber schreiben. Das bisher ein solches Skript noch nicht kursiert, sagt wohl eher, dass der Bedarf daran nicht groß ist. Ich habe jedenfalls bei Eagle immer gehörigen Abstand von der Backannotation gehalten, nachdem ich mich ein paarmal damit zimlich durcheinander gebracht habe. ;O) Und da war ich 15 Jahre jünger als heute und noch besser drauf. > Auch das mit den anhängenen > Leiterbahnen werden sie implementieren. Das ist ja auch wesentlich wichtiger. Bei Einzelobjekten gibt es das schon ewig, nur bei Blocks halt noch nicht. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
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 egal. "Freiheit ist immer die Freiheit der Nervensägen..." oder so ähnlich. Kritikwürdig an W.S. ist doch gar nicht seine abweichende Meinung (wo kämen wir hin, wenn wir nur konforme Meinungen zulassen würden?), sondern sein unseliger Drang, unanfecht- bare Wahrheiten postulieren zu wollen. > Das ist doch mindestens der 5. oder 6... > Meint Ihr das hat Sinn? Ja, auf jeden Fall. > 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? Wieso? Ich verstehe diese Diskussionen als Austausch nicht nur über existierende CAD-Programme, sondern auch über Arbeits- abläufe, Wünsche und Kritikpunkte. Ich finde das immer äußerst lehrreich.
Possetitjel schrieb: > Ich verstehe diese Diskussionen als Austausch nicht nur > über existierende CAD-Programme, sondern auch über Arbeits- > abläufe, Wünsche und Kritikpunkte. > Ich finde das immer äußerst lehrreich. Dem kann ich nur zustimmen! Und wenn wir schon dabei sind: Ich hab jetzt hier ein paarmal gelesen, das lib-Konzept in Eagle wäre schei... Schokotorte ;-) Ich komm eigentlich ganz gut damit zurecht (ich verwende aber auch nur eigene Libs). Was genau ist daran so schlecht, was ist in anderen Systemen besser?
:
Bearbeitet durch User
Das deckt sich mit meinen Erfahrungen ;-) Die Lernklippe am Anfang war steil, aber sobald man mal drin ist, ist es ein vollwertiger Ersatz. Das dickste Minus ist die Annotation - wenn ich im Schalplan etwas ändere, muss man das umständlich manuell rüberziehen. Das dickste Plus sind die Halbautomatikfunktionen des Open-GL Routers. Dieses push and shove, und das automatische herunmfahren um Hindernisse. Das Trennen von Bauteil und Schaltplansymbol sehe ich eher neutral. Zu Beginn fand ich das komisch, es macht in vielen Fällen aber Sinn. Bei vielen PICs zum Beispiel, den PIC24FV32KA301 habe ich schon in zwei verschiedenen Packages mit dem gleichen Symbol verwendet. In Summe: Man ist, wenn man es mal eingeübt hat, gleich schnell oder schneller als mit Eagle. Man kann bedenkenlos zu 100% darauf umsteigen. Man sollte sogar, es ist in mehrerlei Hinsicht Eagle überlegen. Also aus Hobbyistensicht zumindest. Lustig ist auch: Ohne den Lizenztanz mit Online-Zwang für Hobyisten hätte ich KICAD nie ausprobiert. Ein klares Eigentor von Autodesk, die Hobby-Lizenz war nämlich schon geplant...
Hallo Possetitjel, Holm und W.S. Possetitjel schrieb: > Kritikwürdig an W.S. ist doch gar nicht seine abweichende > Meinung (wo kämen wir hin, wenn wir nur konforme Meinungen > zulassen würden?), sondern sein unseliger Drang, unanfecht- > bare Wahrheiten postulieren zu wollen. Richtig. der ton macht die Musik. >> 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? Ich werde auch mit zunehmendem Alter immer starrsinniger. Das ist halt so. > Ich verstehe diese Diskussionen als Austausch nicht nur > über existierende CAD-Programme, sondern auch über Arbeits- > abläufe, Wünsche und Kritikpunkte. > Ich finde das immer äußerst lehrreich. Ich auch. Und letztlich sind sich alle Layoutprograme irgendwie ähnlich. Kennt man eins, kennt man alle anderen auch fast. Bis auf Detais der Handhabung. Man diskutiert hier letztlich über Kleinkram. Die nach meiner Ansicht grottigsten Layoutprogramme, die ich je gesehen habe, waren pcad und Sprint. Und trozdem gibt es Leute, die damit hervorragendes zustande bringen. ;O) Ein Highlight aus der DOS Aera war Orcad. Hervorragend zu benutzen. Aber wenn ich eine Woche in Urlaub war, musste ich anschliessend immer die Shortcuts nachschlagen.... Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
KiCadSuperman schrieb: > Ja, ich stehe dazu, das die Verschiebung von Bauteilen mit angehefteten > Leiterbahnen in den allermeisten > Fällen nichts bringt und zwar aus besagten Gründen siehe oben. > (Scheise hin oder her ;-) Ich möchte meine Ausage mal mit 2 Bildern unterfüttern. Da soll mir keiner kommen und sagen, dass eine Neuverlegung der Leitungen schlechter wäre. Ich kann auch den Wunsch von Bernd nicht nachvollziehen ganze Blöcke im diesen Stiel zu verschieben. Ich sehe keinen Vorteil.
Karl schrieb: > 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. Was Du sagst, stimmt -- aber das ist schon die nächste Runde :) Bis jetzt ging es ja noch darum, dass die Idee der Super- stückliste an sich (angeblich) schon völlig wirr und abseitig ist. Dein Einwand dagegen führt zum nächsten Schritt: Natürlich ist die Super-Stückliste allein nicht ausreichend, denn zum Projekt gehören nicht nur die Informationen über die Bauteile, sondern auch über deren gegenseitige Verbindung! Das ist ja gerade das Wesentliche an einer Leiterplatte :) Für das von Dir formulierte Problem lassen sich mindestens drei Lösungsansätze finden; welcher am aussichtsreichsten erscheint, habe ich noch nicht bedacht. Mal sehen.
Hallo Michael. Michael R. schrieb: > Ich komm eigentlich ganz gut damit zurecht (ich verwende aber auch nur > eigene Libs). Wenn du eigene Libs verwendest, dann hast Du in wohl keinem System ein Problem damit, und die ganze Diskussion dazu dürfte Dir fremd sein. ,O) > Was genau ist daran so schlecht, was ist in anderen > Systemen besser? Genaugenommen gibt es fast keinen. In Eagle plazierst Du Devices im Schaltplan, die aus einem Symbol und einem Package (Footprint) bestehen. Wenn Du aus einem Schaltplan ein Board machst, werden die footprints dort eingebunden und sind vorläufig mit Airwires verbunden. In Kicad plazierst Du Symbole im Schaltplan, die aus sich selber und einem eingetragenen Modul (Footprint) bestehen. Aber dieser Eintrag kann auch fehlen. Wenn Du aus einem Schaltplan ein Board machst, musst du einen Zwischenschritt machen, wo die eingetragenen Module in eine Netzliste übertragen werden (und auch geändert werden können), und wo fehlende Einträge entweder offengelassen werden oder nachgetragen werden. Diese Netzliste wird ins Board eingelesen und die Footprints dort eingebunden und sind vorläufig mit Airwires verbunden. Der Zwischenschritt macht das ganze etwas flexibler, wenn Du mit hierarchischen Schaltplänen als Bausteinen*) arbeitest, und für ständige Anwendungen kannst Du dir generische Schaltpläne machen, in die Du erst dann konkrete Footprints einträgst, wenn du weisst was Du dort einsetzen willst. Du sparst eine Menge an Bibliothekswirrwar, weil Du nur ein paar Symbole und ein paar Footprints brauchst, und dann daraus fast alle z.B. Transistoren verwenden kannst, indem Du das passende einträgst. Für ständig verwendete hast Du natürlich ein Symbol mit dem Namen und passendem Footprinteintrag, aber für Exoten stöpselst Du Dir das erst nach Datenblatt zusammen, wenn du es brauchst. Bei großen ICs mit zig Pins machst Du dass natürlich auch nicht. Da hast Du ein Symbol mit passendem eingetragenem Footprint. Änderungen sind über den Zwischenschritt natürlich auch wie in einer Tabelle machbar. Ein KiCad Footprint kann (aber muss nicht) selber wiederum einen Eintrag auf ein 3D-Modell enthalten. Damit wird dann paralell zum Routen auch ein 3D-Modell der Platine angefertigt. *) Detais siehe hier: https://www.mikrocontroller.net/wikifiles/7/79/HierarchischeSchaltplaeneAlsBausteineInKicad_RevC_23Dec2013.pdf Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Und letztlich sind sich alle Layoutprograme irgendwie > ähnlich. Kennt man eins, kennt man alle anderen auch > fast. Bis auf Detais der Handhabung. Man diskutiert > hier letztlich über Kleinkram. Sicher -- aber sind es denn nicht gerade die Details, die einen zum Wahnsinn treiben? Wenn ich im gschem x-mal klicken muss, um ein Schaltplan- symbol zu drehen, bekomme ich jedesmal eine Krise...
Hallo Clark Kent. KiCadSuperman schrieb: > Ich kann auch den Wunsch von Bernd nicht nachvollziehen > ganze Blöcke im diesen Stiel zu verschieben. > Ich sehe keinen Vorteil. Ich gebe auch zu, dass ich einen Bedarf dazu nur in gut der Hälfte aller Fälle sehe, vor allem weil gerade bei Blöcken mit vielen Verbindungen dann die Übersicht wegen der durcheinandergezogenen Tracks verloren geht. Wenn man aber Platinen aus vorgerouteten Stücken per copy und past zusammensetzt, und man vorsichtig zu Werke geht aber letztlich dann irgendwann einen Block doch noch ein wenig versetzten muss, könnte es nett sein. Das Verhalten sollte daher wählbar sein, mal ist so besser, und im nächsten Fall halt anders. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Hallo Clark Kent. In Wiki steht dazu: >> Clark Kent, die bürgerliche Tarnidentität von Superman << weit gefehlt ;-)
Possetitjel schrieb: > Sicher -- aber sind es denn nicht gerade die Details, > die einen zum Wahnsinn treiben? Durchaus haben gerade Details oft hohes Potential an Verbesserungsmöglichkeiten. ;O) Der Grund ist der, dass beim Lehren von Programmiertechniken immer darauf gepocht wird, "nicht in Schönheit zu sterben", sondern sich auf das wesentliche zu beschränken. Das ist ja auch nicht falsch, gerade bei kommerzieller Software. Aber solche Details fallen dabei eben schnell unter den Tisch. > > Wenn ich im gschem x-mal klicken muss, um ein Schaltplan- > symbol zu drehen, bekomme ich jedesmal eine Krise... gschem ist ja auch uralt. Und ich vermute fast, dass jemand aus so einer Krise heraus KiCad gemacht hat, weil wenn Du Dir ganz alte KiCad Schematic Dateien ansiehst, haben die eine hohe Ähnlichkeit mit alten gEDA Daten. ;O) Ok, Vieleicht ist das ja eine Abwandlung eines bekannten Formates. So ähnlich wie sich Eagle 7 (?) an XML oder moderneres Kicad an Lisp (Symbolischer Ausdruck) anlehnt Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
KiCadSuperman schrieb: > Ich möchte meine Ausage mal mit 2 Bildern unterfüttern. > Da soll mir keiner kommen und sagen, dass eine Neuverlegung der > Leitungen schlechter wäre. Ich wiederhole mich ungern. Für dich mach ich mal ne Ausnahme Gu. F. schrieb: > Wenn ich also zwischen DDR-RAM und Controller 5mm mehr Platz brauche muß > ich 84 Leitungen neu verlegen??? KiCadSuperman schrieb: > Ich möchte meine Ausage mal mit 2 Bildern unterfüttern. Was willst du denn mit dem popeligen 4-pol Stecker beweisen? Mach das Mal mit einem TQFP94 (auf Top und Bottom verdrahtet) o.ä., dann kannst du vlt. mitreden. Ich bin jedenfalls hier raus.
:
Bearbeitet durch User
Possetitjel schrieb: > 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? Nö. Also, es gibt Bauteile. Und diese Bauteile fügt man ins Schematic ein. Dort werden sie durch ihre Symbole dargestellt. Klar soweit? OK. Manche Bauteile sind reich an Pins, so daß sie aus Platzgründen im Schematic besser durch mehrere Symbole dargestellt werden. Bei Eagle kann man diese Symbole bei Bedarf auf verschiedenen Seiten des Schematics haben. Auch klar soweit? OK. Ein Bauteil kann haben: - einen Footprint oder mehrere verschiedene Footprints (nennt sich Varianten). - ein Symbol oder mehrere Symbole. - einen Namen - eine Bezeichnung (z.B. R47 für den 47. Widerstand im Projekt) - weitere Dinge, wie z.B. einen Wert - bei einem Footprint eine Zuordnungstabelle zwischen den Pins der Symbole und dem Footprint - bei mehreren Footprints mehrere Zuordnungstabellen Und nun kommt, was dich verunsichert hat: Ja, es gibt Bauteile ohne Footprint, die folglich auf der LP niemals auftauchen. Das sind z.B. die Spannungs-Symbole (GND, VCC und Konsorten). Diese dienen dazu, einem Netzstück im Schematic einen Rail-Wert zu geben, so daß das Netz dann eben z.B. VCC heißt - oder das, was man an das GND Symbol anschließt, eben zum Netz GND gehört. Merke: bei Eagle gibt es keinen besonderen Befehl, um Rails im Schematic zu verlegen, man benutzt dazu eben so ein footprintloses Bauteil aus der Bibliothek. Da ist bei anderen Systemen umständlicher, da gibt es spezielle Befehle zum Einfügen von Rails - und gelegentlich hat man grad das eben nicht dabei, was man braucht. Und es sind Bauteile möglich, die kein Symbol haben. Zum Beispiel Befestigungsbohrungen, Passermarken, Logos und so. OK, das ist nicht zwingend. Befestigungslöchern und Passermarken kann man auch ein Symbol geben, aber das ist für die Korrektheit der Schaltung nicht zwingend notwendig. So. Was mich mittlerweile richtig nervt ist, daß der Horizont vieler Mitdiskutierer hier nicht hinausgeht über Widerstände und Kondensatoren - und ständig die immer wiederkehrende Leier von "Footprint zum Symbol zuordnen". Diese Leute scheinen mir in ihren Ansichten über Schematics etwa so orientiert zu sein, wie vor gefühlten 100 Jahren die Bilder im Elektor: als Symbol für den 7400 ein Kästchen mit links und rechts je 7 Kullern zum Anschließen von Leitungen, also keine funktionalen Symbole, sondern eine Art Footprint-Darstellung. W.S.
Sheeva P. schrieb: > So ganz grundsätzlich würde ich die Datenstruktur einer Library im > ersten Schritt etwa so designen, wie... > ... > Das Ganze ließe sich, mal ins Blaue gedacht, im Backend wunderbar mit > einer Volltext-Suchmaschine wie Apache Solr oder Elasticsearch abbilden. Ja, eben genau DAS, was ich schon viel weiter oben bemängelt habe: Deine Gedanken kreisen immerzu nur um den Blickwinkel des Programmierers - aber sie lassen den Blickwinkel des Benutzers und in diesem Falle auch aller anderen (Entwickler, Service, Beschaffung, Fertigung) einfach außen vor. Das ist in ganz vielen Fällen ein Grundübel bei allen OS-Projekten. Eben weil die Programmierer, die sowas starten, immerzu nur ihre eigenen Probleme im Sin haben und schlichtweg niemand da ist, ihnen aufzuzeigen, wie es für den Benutzer sein muß. Und im schlimmeren Falle wie hier wird geklagt, daß es ja immerzu Einwürfe wegen mangelnder Ergonomie beim Benutzen gibt, anstatt daß sich die Benutzer auf die steile Lernkurve begeben oder sonstwie sich der Hakeligkeit des Programms anpassen müßten. W.S.
Thomas F. schrieb: > 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. Ja. Für dich und mich und andere professionelle Entwickler ist das eine schlichte Selbstverständlichhkeit. Aber die hier heiß dagegen sprechenden Leute scheinen von derartigen Dingen keinerlei Notiz zu nehmen. OK, bei Bastlern ohne ökonomischen Druck spielen solche Dinge wohl auch keine Rolle. Da zählt viel mehr ein kostenloses EDA-Tool. Kann ich ja verstehen. Mich nervt bloß, wenn die ihre Sicht als allgemeingültig erklären wollen. Von Serviceleuten oder Lohn-Layoutern werden solche Dinge auch nicht gesehen, denn das liegt schlichtweg außerhalb deren Arbeitsfeld. W.S.
ZF schrieb: > Für dich mag das gelten, andere möchten sich nicht immer schon beim > Zeichnen des Schaltplans Ich übersetze das mal: "Ich (ZF) streite das ab, denn ich bin ein Bastler, der ohne greifbaren Plan erstmal irgend etwas anfängt." So liest sich das doch viel klarer! W.S.
Gu. F. schrieb: > Mach das Mal mit einem TQFP94 (auf Top und Bottom verdrahtet) o.ä., dann > kannst du vlt. mitreden. Was regst du dich auf - das geht doch in KiCad - siehe Bild 2" Das heißt aber noch lange nicht dass andere das genauso machen müssen wie du und schon gleich dreimal nicht ich. Gu. F. schrieb: > 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. Klitzekleines Projekt aber hier ne dicke Lippe .... Gu. F. schrieb: > Mein erster Eindruck ist erst mal nicht schlecht. Anscheinend doch nicht :-(
W.S. schrieb: > Ich übersetze das mal: > "Ich (ZF) streite das ab, denn ich bin ein Bastler, der ohne greifbaren > Plan erstmal irgend etwas anfängt." > > So liest sich das doch viel klarer! So muss es wohl sein. Hoffen wir, dass du den Plan, um genau zu sein: den Zahlungsplan nie verlierst, damit auch in Zukunft hier für Unterhaltung gesorgt ist. :-)
W.S. schrieb: > Für dich und mich und andere professionelle Entwickler ist das eine > schlichte Selbstverständlichhkeit. Und dabei siehst Du das auch selektiv. Bei Deinen Projekten mag der Bauteilpreis eine entscheidende Rolle spielen. Bei meinen Projekten ist der Bauteilpreis nahezu rille. Der Wert steckt in der Funktion. Ich könnte da aus Jux und Dollerei noch 2-3 Controller mehr drauflöten, oder Widerstände von Conrad statt von TME, würde am Endpreis nichts wesentlich ändern. Also auch hier: Kommt halt drauf an...
Robert schrieb: > Holm T. schrieb: >> Ist ja recht..aber laß KiCad mal ein Bisschen älter und reifer werden. > > Wie lange dauert das noch? > Was fragst Du mich das? wie viele Zeilen hast Du letzten Monat dafür programmiert..nur wegen einer Abschätzung? >> Das nächste freie CAD System steht ja auch schon in den Startlöchern > > Geil. Lasst alles stehen und liegen! > Hmm. >> Eagle sollte >> eine "erfahrene" und durchentwickelte Plattform sein..trotzdem hat es >> etliche Unzulänglichkeiten. > > Welche im Vergleich zu KiCad? Na die unmögliche Art der Bedienung beispielsweise..kann die Gurke mittlerweile P&S? Die Lizensierung wäre mir noch unangenehm ..und das es kein binarie für mein Betriebssystem gibt. Muß Du mehr wissen? > >> KiCad kostet mich nix und es macht keinen Unterschied ob ich damit für >> mich privat oder in meiner kleinen Firma kommerziell entwickle > > Ok, wenn Du dabei frustfrei zum gewünschten Ergebnis kommst. > Frustfreier als mit Igel, das dürfte doch wohl ausreichend sein. In der "freien Version" stoße ich dauernd an Boardkanten.. >> Die "Freeware" ist nicht mehr zeitgemäß > > Was ist an der Eagle Freeware nicht zeitgemäß? Na eigentlich Alles. Erkläre mir mal wie ich damit eine 2seitige Doppel-Eurokarte hin kriege... > >> die möglichen >> Platinen zu klein > > Mit frei dimensionierbsren 80cm2 lässt sich aber eine ganze Menge > anstellen! Jawoll! Wenn man Chipdesigner ist dann schon... Man...Junge. Du warst wohl erst in der Eagle Kirche zur Bestrahlung? Du bist mir ein ganzes Stück zu primitiv. Du solltest über den Spruch mit dem Hammer als einzigem Werkzeug nochmal nachdenken..gründlich. Gruß, Holm
Possetitjel schrieb: [..] > Wieso? > Ich verstehe diese Diskussionen als Austausch nicht nur > über existierende CAD-Programme, sondern auch über Arbeits- > abläufe, Wünsche und Kritikpunkte. > Ich finde das immer äußerst lehrreich. Naja..kurze Zeit schon, allerdings gehöre ich nicht zu Denjenigen die einer Kuh eine Viertelstunde lang gespannt beim Wiederkäuen zusehen können ohne anzufangen sich zu langweilen. Sein Argument kann ich durchaus akzeptieren auch wenn ich seine Meinung nicht teile, die unumstößliche Allgemeingültigkeit seines Argumentes dagegen nicht, auch nicht wenn ich ein 10. mal mit dem selben Argument bestrahlt werde. Ich fange dann an am Geist der 1-Mann Agit-Prop Gruppe zu zweifeln, kannst Du das nachvollziehen? Gruß, Holm
W.S. schrieb: [..] > So. > Was mich mittlerweile richtig nervt ist, daß der Horizont vieler > Mitdiskutierer hier nicht hinausgeht über Widerstände und Kondensatoren > - und ständig die immer wiederkehrende Leier von "Footprint zum Symbol > zuordnen". Na hoffen wir mal das das so bleibt, selbst wenn ich das obige erst noch für Dich erlernen müßte, so hätte ich doch gerne eine Möglickeit Dich zu nerven, weil Du selbst ungeheuerlich nervst. > > Diese Leute scheinen mir in ihren Ansichten über Schematics etwa so > orientiert zu sein, wie vor gefühlten 100 Jahren die Bilder im Elektor: > als Symbol für den 7400 ein Kästchen mit links und rechts je 7 Kullern > zum Anschließen von Leitungen, also keine funktionalen Symbole, sondern > eine Art Footprint-Darstellung. > > W.S. Jojo, der Mensch schließt immer von sich selbst auf Andere..schätze Du bist auch nur ein Mensch. Nimm doch einfach Eagle und sei glücklich, aber verschone uns doch bitte von Deiner ewigen Wiederkäuerei Deines celebralen Unvermögens. Gruß, Holm
W.S. schrieb: > Also, es gibt Bauteile. > Und diese Bauteile fügt man ins Schematic ein. > Dort werden sie durch ihre Symbole dargestellt. > [...] > Und nun kommt, was dich verunsichert hat: > Ja, es gibt Bauteile ohne Footprint, die folglich auf > der LP niemals auftauchen. Das sind z.B. die Spannungs- > Symbole (GND, VCC und Konsorten). Ach ja, stimmt, das gibt's. (Ist für mein Empfinden zwar eine krampfige Notlösung, aber das ist ja nicht das Thema.) > Und es sind Bauteile möglich, die kein Symbol haben. Ja, DAS war die eigentliche Frage. - Okay, danke für die Klarstellung. Wie ich jetzt verstanden habe, ist der Normalfall in Eagle zwar das komplette Bauteil, das sowohl Symbol als auch Footprint hat, aber offensichtlich kennt Eagle auch Symbole ohne Footprint - genauso wie Footprints ohne Symbol. Gut. > Was mich mittlerweile richtig nervt ist, daß der > Horizont vieler Mitdiskutierer hier nicht hinausgeht > über Widerstände und Kondensatoren - und ständig die > immer wiederkehrende Leier von "Footprint zum Symbol > zuordnen". Ich kann Dir nicht folgen. Ein Vierfach-OPV sollte im Schaltplan als vier einzelne OPVs darstellbar sein -- trotzdem ist das EIN Footprint. Natürlich muss diese Zuordnung mal irgendwo definiert sein -- eben weil Footprint und Symbol ganz offensichtlich NICHT identisch sind. > Diese Leute scheinen mir in ihren Ansichten über > Schematics etwa so orientiert zu sein, wie vor gefühlten > 100 Jahren die Bilder im Elektor: als Symbol für den > 7400 ein Kästchen mit links und rechts je 7 Kullern > zum Anschließen von Leitungen, also keine funktionalen > Symbole, sondern eine Art Footprint-Darstellung. Verstehe ich nicht. Gerade weil Symbol und Footprint NICHT identisch sind, ist die Frage nach der Zuordnung so interessant. Wenn es dasselbe wäre, könnte man auf eins von beiden verzichten...
Eagle und KiCAD sind beides äusserst brauchbare Layoutprogramme, wenn nur die bescheuerten Namen nicht wären. Das geht so garnicht, ich werde weiter auf Papier malen.
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? 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? Hast Du keine anderen Probleme?
KiCadSuperman schrieb: > 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. Das kommt darauf an wo ich das Bauteil hinschiebe. Bei nur geringfügigen Korrekturen wäre es schon schön wenn die Leiterbahnen nicht abreißen. Da Du ja die Leiterbahnen eh löschst wie Du schreibst, würde es auch nichts machen, wenn sie beim Verschieben andere Bereiche überdecken - man löscht sie dann einfach. In vielen Fällen reicht es sogar wenn man die Leiterbahnen wieder ordentlich hin schiebt. Die Frage Gu.F. hast Du mit Deinem Post nicht wirklich beantwortet. Das scheint aber bei den KiCAD Leuten so üblich zu sein. Man lebt halt mit den Unzulänglichkeiten des Programmes - sind halt Features.
Beitrag #5350766 wurde von einem Moderator gelöscht.
KiCadSuperman schrieb: > 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 :-( Wo lebst Du denn? Gu.F. hat recht das ist ein Unding und eine echte Schwäche von KiCAD. So Wie Du ihm auf seine Fragen antwortest wird er wohl eher nicht zu KiCAD wechseln obwohl er eigentlich willig war/ist.
Trouble Shooter schrieb im Beitrag #5350766: > Zeno schrieb: >> Hast Du keine anderen Probleme? > > Die Probleme hast du. > Du bist hier ein absoluter Noname. > Bei deinem Gesuelze was du hier absonders, müsstest du eigentlich vorher > um Erlaubnis fragen. Nö muß ich nicht und Dich schon gar nicht.
Possetitjel schrieb: > Ein Vierfach-OPV sollte im Schaltplan als vier einzelne > OPVs darstellbar sein -- trotzdem ist das EIN Footprint. > Natürlich muss diese Zuordnung mal irgendwo definiert > sein Ja, ist sie. In der Library. Es gibt zumindest in meiner Lib: 1-fach OPV - Symbole OPV + PowerSupply - Footprints DIL08, SO08 2-fach OPV - Symbole 2xOPV + PS - Footprints DIL08, SO08 4-fach OPV - Symbole 4xOPV + PS - Footprints DIL14, SO14 Interessanter wird es mit Transistoren. Da gibt es zum Beispiel: NPN - Symbol NPN - Footprint TO92, TO92lang, TO92winkel, SOT23, SOT23wide, SOT89, SOT223, SOT232 ohne Pin2, TO126 stehend, TO126 liegend, TO220 stehend, TO220 liegend, DPAK, D2PAK Und je nach Bedarf kann ich zwischen allen Footprints wechseln. Ich will die Leiterplatte von THT auf SMD umbauen? Kein Problem, wird aus dem TO92 ein SOT23 und die Bezeichnung angepasst. Die Leistung ist für SOT89 zu groß? Kein Problem, wie der große Bruder in SOT223 genommen.
Holm T. schrieb: > Du warst wohl erst in der Eagle Kirche zur Bestrahlung? > Du bist mir ein ganzes Stück zu primitiv. Holm T. schrieb: > aber verschone uns doch bitte > von Deiner ewigen Wiederkäuerei Deines celebralen Unvermögens Sag mal stehst Du hier dermaßen mit dem Rücken zur Wand daß Du nur noch so ungehobelt um Dich schlagen mußt? Sorry, Dich kann man doch kaum ernst nehmen, deshalb spare ich mir jede weitere Antwort auf Deine unreifen Ergüsse :(
Zeno schrieb: > 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? 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? > > Hast Du keine anderen Probleme? Doch .. und Du? Hast Du noch andere Probleme als Leute zu fragen ob sie noch andere Probleme haben? Gruß, Holm
Robert schrieb: > Holm T. schrieb: >> Du warst wohl erst in der Eagle Kirche zur Bestrahlung? >> Du bist mir ein ganzes Stück zu primitiv. > > Holm T. schrieb: >> aber verschone uns doch bitte >> von Deiner ewigen Wiederkäuerei Deines celebralen Unvermögens > > Sag mal stehst Du hier dermaßen mit dem Rücken zur Wand daß Du nur noch > so ungehobelt um Dich schlagen mußt? Sorry, Dich kann man doch kaum > ernst nehmen, deshalb spare ich mir jede weitere Antwort auf Deine > unreifen Ergüsse :( Ja, es wäre nett von dir wenn Du mich einfach in Zukunft nicht ernst nehmen würdest. ignoriere mich bitte. Gruß, Holm
Zeno schrieb: > KiCadSuperman schrieb: >> 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. > > Das kommt darauf an wo ich das Bauteil hinschiebe. Bei nur geringfügigen > Korrekturen wäre es schon schön wenn die Leiterbahnen nicht abreißen. > Da Du ja die Leiterbahnen eh löschst wie Du schreibst, würde es auch > nichts machen, wenn sie beim Verschieben andere Bereiche überdecken - > man löscht sie dann einfach. In vielen Fällen reicht es sogar wenn man > die Leiterbahnen wieder ordentlich hin schiebt. [..] Das Problem das KiCad damit hat ist wohl das es in PCBnew nicht erlaubt das sich beim Zeichnen von Leiterbahnen unterschiedliche Netze auch nur berühren, man kann keine Leitungskreuzung zeichnen. Genau das würde hier aber passieren. Man ist sich wohl nicht einig wie das prinzipiell zu Lösen wäre, deswegen gibt es dieses Feature so (bisher) nicht. Ich sehe ja ein das es für Dich absolut unmöglich ist damit zu arbeiten, aber denke das für das was Du für KiCad bezahlt hast, es immer noch seinen sehr guten Job macht. Du kannst also aufhören darüber zu schimpfen. Gruß, Holm
Karl schrieb: > Possetitjel schrieb: >> Ein Vierfach-OPV sollte im Schaltplan als vier einzelne >> OPVs darstellbar sein -- trotzdem ist das EIN Footprint. >> Natürlich muss diese Zuordnung mal irgendwo definiert >> sein > > Ja, ist sie. In der Library. > > Es gibt zumindest in meiner Lib: > 1-fach OPV > - Symbole OPV + PowerSupply > - Footprints DIL08, SO08 > 2-fach OPV > - Symbole 2xOPV + PS > - Footprints DIL08, SO08 > 4-fach OPV > - Symbole 4xOPV + PS > - Footprints DIL14, SO14 > > Interessanter wird es mit Transistoren. Da gibt es zum Beispiel: > NPN > - Symbol NPN > - Footprint TO92, TO92lang, TO92winkel, SOT23, SOT23wide, SOT89, SOT223, > SOT232 ohne Pin2, TO126 stehend, TO126 liegend, TO220 stehend, TO220 > liegend, DPAK, D2PAK > > Und je nach Bedarf kann ich zwischen allen Footprints wechseln. Ich will > die Leiterplatte von THT auf SMD umbauen? Kein Problem, wird aus dem > TO92 ein SOT23 und die Bezeichnung angepasst. Die Leistung ist für SOT89 > zu groß? Kein Problem, wie der große Bruder in SOT223 genommen. Ja Karl und nun was? Genau das kann man bei KiCad auch tun, man kann so gar einen Footprint auswählen der gar nicht existiert und den am nächsten Tag da nachrüsten. Du kannst auch ein Footprint eines Kondensators einem Widerstand zuordnen..wird funktionieren. Du solltest aber wissen was Du da tust, ein 7400 wird unzufrieden mit einer Novalfassung sein. Wo also ist da Dein Problem? Gruß, Holm
Noch ne Info hinterher, irgend so ein ausländischer Hinterhofladen hat begonnen sein Inventar als KiCad Library zu strukturieren und diese kostenfrei zur Verfügung zu stellen (creative commons license). Zumindest für die 3 Bauteile die der handelt sollte es in naher Zukunft konsistente Schematic- und Footprintsymbole geben: https://forum.kicad.info/t/digi-key-open-sources-alpha-version-of-an-atomic-parts-library/8520 Gruß, Holm
Holm T. schrieb: > Noch ne Info hinterher, irgend so ein ausländischer Hinterhofladen hat > begonnen sein Inventar als KiCad Library zu strukturieren und diese > kostenfrei zur Verfügung zu stellen (creative commons license). Deine Aussage hat ein bisserl einen negativen Touch. Ich denke aber wenn Mouser, Farnell und Bürklin da mitziehen. dann könnte das ein Gewinn sein für uns. Die leidige Artikel- und Bestellnummernsuche könnte man abkürzen und dadurch die Produktivität steigen. Da müssten aber alle mit machen sonst bringt es nichts.
Hier wurde schonmal ausführlich über diverse Layout Programme diskutiert. Eventuell eine kleine Stütze. Beitrag "Layout Programme"
:
Bearbeitet durch User
KiCadSuperman schrieb: > Holm T. schrieb: >> Noch ne Info hinterher, irgend so ein ausländischer Hinterhofladen hat >> begonnen sein Inventar als KiCad Library zu strukturieren und diese >> kostenfrei zur Verfügung zu stellen (creative commons license). > > Deine Aussage hat ein bisserl einen negativen Touch. Hat sie das wirklich oder ist den Sarkasmusdetektor defekt? > Ich denke aber wenn Mouser, Farnell und Bürklin da mitziehen. > dann könnte das ein Gewinn sein für uns. > Die leidige Artikel- und Bestellnummernsuche könnte > man abkürzen und dadurch die Produktivität steigen. > Da müssten aber alle mit machen sonst bringt es nichts. ..was wohl der Grund sein dürfte warum die das machen. Ich kaufe kaum mal bei Digikey ein, meine Mengen sind zu gering und das Verfahren inkl. Versand zu komliziert. Es hat aber den positiven Nebeneffekt der Verfügbarkeit interessanter Daten, eben halt Footprints und Schaltplansymbole..Links zu Datenblättern inklusive. Gruß, Holm
Possetitjel schrieb: >> .. Bauteile ohne Footprint... > > Ach ja, stimmt, das gibt's. > > (Ist für mein Empfinden zwar eine krampfige Notlösung, > aber das ist ja nicht das Thema.) > >> Und es sind Bauteile möglich, die kein Symbol haben. > > Ja, DAS war die eigentliche Frage. - Okay, danke für > die Klarstellung. > > Wie ich jetzt verstanden habe, ist der Normalfall in > Eagle zwar das komplette Bauteil, das sowohl Symbol als > auch Footprint hat, aber offensichtlich kennt Eagle auch > Symbole ohne Footprint - genauso wie Footprints ohne > Symbol. Gut. Nee, die Bauteile ohne Footprint sind eine sowohl elegante als auch systematische Lösung. Ich erklär's dir: Bei anderen Systemen hat man spezielle Kommandos, um sowas wie z.B. VCC oder GND ins Schematic zu plazieren. Warum eigentlich so eine Extrawurst? Bei den Pins von realen Bauteilen hat man ja neben anderen Pin-Sorten auch solche, die "Supply" sind, also im realen Leben als Quelle eines Versorgungs-Rails herhalten müssen. Beispiel: Ausgang eines 7805, der eben +5Volt hergeben soll, was man dann woanders benötigt. Da liegt es nahe, eben auch Symbole in einer Bibliothek zu haben, die einem Netz-Stück auf einem Blatt des Schematics eben diese Versorgungs-Rail-Eigenschaft geben. Man will ja der Übersichtlichkeit zuliebe nicht die ganzen VCC-Linien im Schematic durch die Gegend ziehen. Bei GND ist das noch viel offensichtlicher. Und nun bedenke mal, daß Systeme, die ein Extrakommando für GND, VCC usw. haben, sowas ja auch irgendwie im Schematic darstellen müssen, sonst kann man das ja nicht erkennen. Entweder man richtet für solche Symbole eine Extrawurst ein, also irgendwelche Symbole, die fest im EDA-System oder sonstwo codiert sind - oder man macht es so wie Eagle, wo solche Dinge schlichtweg Bauteile in gewöhnlichen Bibliotheken sind, wo man sie bei Nichtgefallen auch editieren kann. Oder wo man sich solche für Rails, die das System bislang noch nicht kannte, selber machen kann (ohne auf ein Update der Software zu warten). Also die Sache mit den Bauteilen ohne Footprint ist durchaus logisch und m.E. überhaupt keine krampfige Notlösung. Possetitjel schrieb: > Ich kann Dir nicht folgen. > > Ein Vierfach-OPV sollte im Schaltplan als vier einzelne > OPVs darstellbar sein -- trotzdem ist das EIN Footprint. > Natürlich muss diese Zuordnung mal irgendwo definiert > sein -- eben weil Footprint und Symbol ganz offensichtlich > NICHT identisch sind. Mit dem Vierfach-OpV hast du ja genau ins Schwarze getroffen. Das ist exakt dasselbe wie beim 7400. Der Schaltkreis hat 4 Elemente (4 OpV's oder 4 NAND's und dazu ein Versorgungs-Element) und dafür braucht man eben viermal das gleiche Symbol und ein Versorgungs-Symbol. Und all diese Symbole sollen frei an verschiedenen Stellen des Schematic verwendbar sein. Genau DESHALB geht so eine Zuordnung nur von einem Bauteil aus zu machen. Also ein Bauteil, das 0 oder 1 oder N Symbole haben kann. Nicht umgekehrt. Nochmal zur Zuordnung: Bauteil --> zugeordnete Symbole Bauteil --> zugeordnete Footprints und nicht Symbole --> Footprints auch nicht Footprints --> Symbole Das mit dem "Ich kann dir nicht folgen" war so: Anstelle von 4 OpV-Symbolen hatten die Schaltungs-Zeichner damals einen symbolischen Schaltkreis gezeichnet, also ein längliches Kästchen mit ner Delle auf der Oberseite, dann links und rechts soviele Kringel dran, wie Anschlüsse waren und (wenn sie gut drauf waren) die 4 OpV's innerhalb des Kästchens gezeichnet. Damit konnten sie die OpV-Symbole eben NICHT frei in der Schaltung plazieren, was zu herzlich unleserlichen Schematics führte. Vielleicht war das gut für Leute, die dann ihre Schaltung auf Lochraster und WireWrap-Technik mit dünnen Drähten gelegt hatten. Für sowas gab es spezielle IC-Sockel mit ganz langen Anschlüssen und spezielles Wickelwerkzeug. Aus dieser Art des Denkens kam vermutlich die Idee von einem Symbol, das einen Footprint hatte (ich sag dazu: einen Footprint nicht hatte, sondern darstellen sollte). Und genau diese Denkweise ist das, was mir hier im Forum immer entgegen geschlagen ist, wenn es um Kicad ging. Insbesondere der Bernd Wiebus hat nichts unversucht gelassen, um mich davon zu überzeugen. Er meinte da einmal, daß eine solche Darstellung mit symbolischen Footprints gerade für den Service-Techniker vorteilhaft sei - was ich durchaus so lala verstehen kann, was aber zum tatsächlichen Verstehen der Schaltung keineswegs beiträgt - und was den heutigen Bauteilen auch nicht mehr wirklich gerecht wird. W.S.
Hallo W.S. W.S. schrieb: > Er meinte da > einmal, daß eine solche Darstellung mit symbolischen Footprints gerade > für den Service-Techniker vorteilhaft sei - was ich durchaus so lala > verstehen kann, was aber zum tatsächlichen Verstehen der Schaltung > keineswegs beiträgt Ich bin immer noch der Meinung, dass das eine monolitische Darstellung von Symbolen dicht am Footprint für sehr kleine Schaltungen, Bausätze, Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung ist. Mit zunehmender Komplexität der Schaltung kippt das ganze natürlich, und eine aufgelöste Darstellung von Symbolen wird dann sinnvoller. Ich habe nie behauptet, das eine der Lösungen für alle Fälle die beste ist. ;O) Es sollten beide Möglichkeiten existieren, aus denen man dann je nach Situation wählen kann. > - und was den heutigen Bauteilen auch nicht mehr > wirklich gerecht wird. Es ist rein eine Frage der Komplexität. Große Controller sind komplex. Du stellst öfters Aussagen so schräg dar. Und mit "Abwägen" hast Du auch ein Problem, stimmts? ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Ich bin immer noch der Meinung, dass das eine monolitische Darstellung > dicht am Footprint für sehr kleine Schaltungen, Bausätze, > Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung > ist. Ja toll, da sind wir dann bei Fritzing und den Arduino-Bastlern, wo ein Transistor ein schwarzer Klecks mit drei Beinen ist. Ups, ein Spannungsregler ja auch. Wenn ich eine Schaltung mit OPV habe, dann will ich die auch als solche erkennen und nicht erst an einem Rechteck mit Beinchen abzählen müssen, wo Eingang und wo Ausgang ist und welcher zu welchem OPV gehört. Den Sprung von den Kästchen mit Beinchen zum Schaltsymbol haben wir doch eigentlich geschafft, als wir "Das kleine Elektronikbastelbuch"* weggelegt und uns "Das große Elektronikbastelbuch" gegriffen haben. *) Ja, das gab es auch, vom gleichen Autor.
Hallo Karl. Karl schrieb: >> Ich bin immer noch der Meinung, dass das eine monolitische Darstellung >> dicht am Footprint für sehr kleine Schaltungen, Bausätze, >> Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung >> ist. > Ja toll, da sind wir dann bei Fritzing und den Arduino-Bastlern, wo ein > Transistor ein schwarzer Klecks mit drei Beinen ist. Ups, ein > Spannungsregler ja auch. Das ist jetzt einfach nur Polemik. Du willst es falsch verstehen. Einmal ist ein vierfach OP-Amp eben ein Rechteck mit 14 Anschlüssen entsprechend dem Pinning, und einmal eben eine aufgelöste Darstellung mit vier einzel Op_amps mit drei Anschlüssen plus einmal was mit zwei Anschlüssen für die Versorgung. > Wenn ich eine Schaltung mit OPV habe, dann will ich die auch als solche > erkennen und nicht erst an einem Rechteck mit Beinchen abzählen müssen, > wo Eingang und wo Ausgang ist und welcher zu welchem OPV gehört. Dein gutes Recht. Wenn ich am Rechner sitze und einen Schaltplan lese, will ich das genauso wie Du. Wenn ich aber im Service auf einer Leiter stehe und Löte, hätte ich gerne was, wo ich direkt am Schaltplan das Pinning sehe, OHNE weitere Literatur zu Rate zu ziehen. ;O) Es spricht nichts dagegen, wahlweise das eine oder andere zu verwenden.*) > Den Sprung von den Kästchen mit Beinchen zum Schaltsymbol haben wir doch > eigentlich geschafft, als wir "Das kleine Elektronikbastelbuch"* > weggelegt und uns "Das große Elektronikbastelbuch" gegriffen haben. Das ist schon richtig, aber in der Formulierung reichlich Arrogant. Auch der Gelegenheitsbastler, der nur eine Schaltung für sein Modellboot benötigt, und den der Hintergrund eher wenig interessiert sollte berücksichtigt werden. Abstrahierung ist kein Selbstzweck. *) Eine Alternative wäre die Pinninginformation irgendwo auf dem Rand des Schaltplanes unterzubringen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Beitrag #5353259 wurde von einem Moderator gelöscht.
Karl schrieb: > Bernd W. schrieb: >> Ich bin immer noch der Meinung, dass das eine monolitische Darstellung >> dicht am Footprint für sehr kleine Schaltungen, Bausätze, >> Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung >> ist. > > Ja toll, da sind wir dann bei Fritzing und den Arduino-Bastlern, wo ein > Transistor ein schwarzer Klecks mit drei Beinen ist. Ups, ein > Spannungsregler ja auch. > > Wenn ich eine Schaltung mit OPV habe, dann will ich die auch als solche > erkennen und nicht erst an einem Rechteck mit Beinchen abzählen müssen, > wo Eingang und wo Ausgang ist und welcher zu welchem OPV gehört. > > Den Sprung von den Kästchen mit Beinchen zum Schaltsymbol haben wir doch > eigentlich geschafft, als wir "Das kleine Elektronikbastelbuch"* > weggelegt und uns "Das große Elektronikbastelbuch" gegriffen haben. > > *) Ja, das gab es auch, vom gleichen Autor. Karl hast Du mal bei Kicad probiert wie sich das mit einem 7400 wirklich verhält oder redest Du nur drüber? Gruß, Holm
Beitrag #5353268 wurde von einem Moderator gelöscht.
Na, haben wir mal wieder die Tabletten vergessen ?
:
Bearbeitet durch User
Holm T. schrieb: > Ich sehe ja ein das es für Dich absolut unmöglich ist damit zu arbeiten, > aber denke das für das was Du für KiCad bezahlt hast, es immer noch > seinen sehr guten Job macht. Du kannst also aufhören darüber zu > schimpfen. Du solltest mich mal schimpfen hören! Wo kommen wir hin wenn wir alles schön reden? Es ist doch völlig Rille ob es Open Source oder Bezahlsoftware ist, man muß bei beiden die Fehler benennen dürfen, selbst wenn das subjektiv wäre. Genauso muß jeder für sich selbst entscheiden welche Software er benutzt. Selbst wenn ich eine bestimmte Software bevorzuge/benutze heißt das noch lange nicht das diese Software fehlerfrei ist oder das man auch dort das eine oder andere besser machen kann. Allerdings hat man i.d.R. seine Gründe warum man sich für die eine oder andere Software entscheidet und jeder setzt da seine Prioritäten anders. Bei Dir scheint ist offensichtlich der Preis das Hauptargument diese Software einzusetzen. Bei mir steht der Preis nicht unbedingt an erster Stelle. Für mich haben da andere Dinge mehr Gewicht, aber das jetzt weiter auszudiskutieren würde wieder eine unendliche Diskussion KiCAD vs. Eagle los treten, also lasse ich es.
Bernd W. schrieb: > *) Eine Alternative wäre die Pinninginformation irgendwo auf dem Rand > des Schaltplanes unterzubringen. Bei unseren Schaltplänen in der Firma waren eigentlich immer die Pinnummern des realen Bauteiles am Symbol eingetragen. Bei meinen Schematics mit Eagle ist das genau so. Aber so etwas funktioniert eben nur, wenn schon im Schematic der Footprint bekannt ist. Und ja, wenn ich im Schematic oder im Layout die Bauform, also den Footprint ändere, dann werden selbstverständlich die Pinnummern angepasst, wenn es erforderlich ist. Also Eagle bietet Dir hier genau das was du willst.
Beitrag #5353298 wurde von einem Moderator gelöscht.
Bernd W. schrieb: > Eine Alternative wäre die Pinninginformation irgendwo auf dem Rand > des Schaltplanes unterzubringen. In meinen Schaltplänen steht das Pinout bei ICs direkt an den Symbolen. Jetzt muss man natürlich noch den Punkt auf dem realen IC finden, bei dem man mit zählen beginnt. Alternativ habe ich im Service zu den Schaltplänen auch das Layout dazu.
Hallo Karl und Zeno. Karl schrieb: >> Eine Alternative wäre die Pinninginformation irgendwo auf dem Rand >> des Schaltplanes unterzubringen. > > In meinen Schaltplänen steht das Pinout bei ICs direkt an den Symbolen. > Jetzt muss man natürlich noch den Punkt auf dem realen IC finden, bei > dem man mit zählen beginnt. > Zeno schrieb: >> *) Eine Alternative wäre die Pinninginformation irgendwo auf dem Rand >> des Schaltplanes unterzubringen. > > Bei unseren Schaltplänen in der Firma waren eigentlich immer die > Pinnummern des realen Bauteiles am Symbol eingetragen. Diese Möglichkeit bietet grundsätzlich jedes Programm, das ich bisher kennengelernt habe. Das mache ich Grundsätzlich so. Aber ich kenne eben auch viele Firmen, die das weglassen. Besonders wenn der Schaltplan über Gebühr verkleinert wurde, und solche Nummern nicht mehr vernünftig zu lesen wären. Eine Darstellung entsprechend dem Footprint ist bis ca. einem 16 pinner schon sinnvoll. Bedenke auch verschmutzte Schaltpläne. Ausserdem geht es viel schneller, wenn ich "intuitiv" von der Pin Position im Schaltplan auf die im Layout schliessen kan. Karl schrieb: > Alternativ habe ich im Service zu den Schaltplänen auch das Layout dazu. Das wollen viele nicht herausgeben, und bei mehr als zwei Lagen ist es auch krampfig. Ein Bestückungsplan ist aber schon mal ganz nett. Zeno schrieb: > Bei meinen Schematics mit Eagle ist das genau so. Aber so etwas > funktioniert eben nur, wenn schon im Schematic der Footprint bekannt > ist. Das ist nun kein Eagle Alleinstellungsmerkmal. Wenn allerdings ein fertiges Board existiert, dann ist zumindest dem Entwickler zu diesem Zeitpunkt der Footprint bekannt, und er kann den Schaltplan entsprechend anpassen, falls dieses aufgrund des geänderten Pinnings nötig sein sollte.*) Wo ist da das Problem? > Und ja, wenn ich im Schematic oder im Layout die Bauform, also den > Footprint ändere, dann werden selbstverständlich die Pinnummern > angepasst, wenn es erforderlich ist. > Also Eagle bietet Dir hier genau das was du willst. Auch das ist kein Eagle Alleinstellungsmerkmal. Mir ist kein ernstzunehmendes Layoutprogramm bekannt, wo das nicht geht. *) Der korrekte Weg in KiCad wäre ja onehin, den Footprinteintrag entweder im Symbol oder in der Netzliste anzupassen, dabei nach Bedarf die Pinnummerierung im Schaltplan zu ändern (entweder direkt oder durch Austausch des Symbols), und die Netzliste neu ins Board einzulesen. Der Workflow in KiCad reibt Dir insofern die von Dir vorgeschriebene Lösung unter die Nase. Eagle und KiCad und alle andere Layoutprogramme sind sich genaugenommen sehr ähnlich. Der Streit geht hier wirklich nur um winzige Details. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Zeno schrieb: > Holm T. schrieb: >> Ich sehe ja ein das es für Dich absolut unmöglich ist damit zu arbeiten, >> aber denke das für das was Du für KiCad bezahlt hast, es immer noch >> seinen sehr guten Job macht. Du kannst also aufhören darüber zu >> schimpfen. > > Du solltest mich mal schimpfen hören! Dann rufe mich doch an. Die Nummer findest Du bestimmt.. > Wo kommen wir hin wenn wir alles schön reden? Es ist doch völlig Rille > ob es Open Source oder Bezahlsoftware ist, man muß bei beiden die Fehler > benennen dürfen, selbst wenn das subjektiv wäre. Natürlich kannst Du das tun, es wird halt nur nicht helfen. Ich weiß das man mit KiCad ordentliche Platinen machen kann und habe mir vorher Eagle nicht "angewöhnt" so das ich mich jetzt umgewöhnen müßte, das ist der Hauptunterschied denke ich. > Genauso muß jeder für > sich selbst entscheiden welche Software er benutzt. Selbst wenn ich eine > bestimmte Software bevorzuge/benutze heißt das noch lange nicht das > diese Software fehlerfrei ist oder das man auch dort das eine oder > andere besser machen kann. Allerdings hat man i.d.R. seine Gründe warum > man sich für die eine oder andere Software entscheidet und jeder setzt > da seine Prioritäten anders. Ja. > Bei Dir scheint ist offensichtlich der Preis das Hauptargument diese > Software einzusetzen. Bei mir steht der Preis nicht unbedingt an erster > Stelle. Für mich haben da andere Dinge mehr Gewicht, aber das jetzt > weiter auszudiskutieren würde wieder eine unendliche Diskussion KiCAD > vs. Eagle los treten, also lasse ich es. Ich habe FreeBSD auf dem Rechner, Eagle wäre nur mit emuliertem Windows oder Linux gelaufen, ich habe das schon ein paar Mal erklärt denke ich. Einen BAE habe ich schon mal gekauft. Dann solltest Du mal genau verinnerlichen was ich hier die ganze Zeit schreibe: Ich versuche Dir nicht einzureden das Du KiCad benutzen sollst, Geld spielt ja bei Dir offensichtlich eine untergeordnete Rolle, aber Du versuchst u.a. mich zu agitieren das KiCad unbrauchbar ist. Warum eigentlich? Für mich ist es überhaupt nicht verwunderlich und gar kein Grund zur Aufregung das Weißwein nicht wie Bier schmeckt, Du aber insistierst darauf, das das so zu sein hätte (Andere auch). Die unendliche Diskussion haben wir doch schon, oder was denkst du was das ist was W.S. hier in jedem Thread zelebriert? Gruß, Holm
Beitrag #5353386 wurde von einem Moderator gelöscht.
Holm T. schrieb: > oder was denkst du was > das ist was W.S. hier in jedem Thread zelebriert? Tatsächlich hast Du auch nicht viel dagegen vorzubringen weil W. S. Recht hat!
Helmut schrieb: > Holm T. schrieb: >> oder was denkst du was >> das ist was W.S. hier in jedem Thread zelebriert? > > Tatsächlich hast Du auch nicht viel dagegen vorzubringen weil W. S. > Recht hat! Meinst Du ich könnte die Tatsache noch kippen wenn ich 2 Ausrufezeichen hinter meine Aussage setze? !! @Zeno: 0589.. warst Du das? Gruß, Holm
W.S. schrieb: > Nee, die Bauteile ohne Footprint sind eine sowohl > elegante als auch systematische Lösung. Hmm... jein. Lass' mich erstmal (nicht zu Deiner Belehrung, sondern als gemeinsamen begrifflichen Bezugspunkt) einen Gedanken von Michael aufgreifen und weiterführen: Das Wort "Schaltplan" ("schematic") hat im EDA-Kontext drei subtil unterschiedliche Bedeutungen: 1. ein "Dokument" (das man anfassen kann), 2. einen "Fenster-Inhalt", (die Art und Weise, wie das GUI bestimmte Informationen mittels bunter Striche darstellt), 3. eine (programminterne) "Datenstruktur". Bedeutung 1 ist hier nicht mein Thema; es geht mir um die Wechselwirkung von Bedeutung 2 und 3. Das nur als Vorbemerkung. > Bei anderen Systemen hat man spezielle Kommandos, um > sowas wie z.B. VCC oder GND ins Schematic zu plazieren. > Warum eigentlich so eine Extrawurst? Naja, weil es keine Bauteile sind , sondern eigentlich Netz-Attribute. > Bei den Pins von realen Bauteilen hat man ja neben anderen > Pin-Sorten auch solche, die "Supply" sind, also im realen > Leben als Quelle eines Versorgungs-Rails herhalten müssen. > Beispiel: Ausgang eines 7805, der eben +5Volt hergeben soll, > was man dann woanders benötigt. Ja. > Da liegt es nahe, eben auch Symbole in einer Bibliothek zu > haben, die einem Netz-Stück auf einem Blatt des Schematics > eben diese Versorgungs-Rail-Eigenschaft geben. Nur teilweise. Ich verstehe und akzeptiere, dass der Programmautor diese Lösung in einer bestimmten Ära der IT naheliegend und elegant gefunden hat, weil so mit wenig internen Umbauten ein Zusatz- nutzen für den Anwender erzielt werden konnte. Das ist völlig ernst und nicht spöttisch gemeint. Ich bin nur der Meinung, dass diese Lösung nicht mehr zeitgemäß ist. Die Datenbank-Theorie ist ausgearbeitet und etabliert, relationale Datenbanken sind weit verbreitet, und auch tabellarische Darstellung von Informationen ("Excel") sind längst beim Endanwender angekommen. Ich sehe keinen Grund, warum man zwanghaft alles in "Schaltplan-Symbole" umdeuten muss. > Man will ja der Übersichtlichkeit zuliebe nicht die ganzen > VCC-Linien im Schematic durch die Gegend ziehen. Bei GND > ist das noch viel offensichtlicher. Ja -- ich verstehe ja den Wunsch, ich kritisiere nur die Implementierung. Gewünscht wird, dass ein bestimmtes Netz nicht -- wie sonst üblich -- durch Verbindungslinien im Schaltplan dargestellt wird, sondern ersatzweise durch bestimmte Symbole (ähnlich einer Abkürzung in einem Text etwa). Also wäre es aus meiner Sicht völlig konsistent, wenn man zum Beispiel das Netz selektieren könnte, mittels rechter Maustaste ein lokales Menü öffnet und dann den Punkt "Dieses Netz darstellen als..." wählt. Dort ordnet man das zugehörige Symbol (=Attribut) zu und ist fertig. Um meinem Punkt nochmal klar herauszustellen: Ich kritisiere nicht, dass im "ausgedruckten Schaltplan- dokument" (=Bedeutung 1) z.B. Verbindungen ersatzweise durch bestimmte Symbole dargestellt werden sollen. Ich kritisiere auch nicht, dass man diese Darstellung durch Mausklicks und Tastendrücke im "Schaltplaneditor- fenster" (=Bedeutung 2) auswählt. Ich kritisiere, dass man, um eine bestimmte Darstellung eines Netzes zu aktivieren, ein bestimmtes "Bauteil" in den "Schaltplan" (Bedeutung 3) einfügen muss! Das ist nämlich aus Sicht der Anwendungslogik widersinnig! > Und nun bedenke mal, daß Systeme, die ein Extrakommando für > GND, VCC usw. haben, sowas ja auch irgendwie im Schematic > darstellen müssen, sonst kann man das ja nicht erkennen. Ja -- Moment. Dass man (je nach Wunsch) die Möglichkeit hat, bestimmte Zusatzinformationen im Schaltplan DARZUSTELLEN , heißt nicht, dass sie auch primär dort VERWALTET und GESPEICHERT werden müssen, und schon gar nicht zwingend in Form von Pseudo-Bauteilen. > Entweder man richtet für solche Symbole eine Extrawurst > ein, also irgendwelche Symbole, die fest im EDA-System > oder sonstwo codiert sind - oder man macht es so wie > Eagle, wo solche Dinge schlichtweg Bauteile in gewöhnlichen > Bibliotheken sind, wo man sie bei Nichtgefallen auch > editieren kann. Ja -- aber die dritte Möglichkeit hast Du ausgelassen: Man wird sich darüber klar, dass es völlig legitim ist, im Schaltplan ZUSÄTZLICHE Informationen darstellen zu wollen, denen KEINE Bauteile entsprechen. Diese Zusatzinformationen werden dann logischerweise auch nicht durch den "Bauteil einfügen..."-Dialog in den Schaltplan gebracht, sondern irgendwie anders. Mir ist dieser Punkt deshalb so wichtig, weil ich bis jetzt noch kein EDA-Programm ausprobiert habe, bei dem der Zugriff auf die Library sich nicht irgendwo zwischen gräuslich und völlig indiskutabel bewegt hätte. Die Ursache dafür ist meiner Meinung nach, dass die Library als undifferenzierter Gemischtwarenladen für alles Mögliche angesehen wird, statt die einzelnen Anwendungsfälle sinnvoll zu trennen und getrennt zu optimieren. Man sollte in der Bauteilbibliothek keine Dinge unter- bringen, die keine Bauteile sind! > [...] > Genau DESHALB geht so eine Zuordnung nur von einem > Bauteil aus zu machen. Also ein Bauteil, das 0 oder 1 > oder N Symbole haben kann. Nicht umgekehrt. > > Nochmal zur Zuordnung: > Bauteil --> zugeordnete Symbole > Bauteil --> zugeordnete Footprints > > und nicht > Symbole --> Footprints > auch nicht > Footprints --> Symbole Äh... ja. Schön und überraschend, dass es auch einen Punkt gibt, in dem wir übereinstimmen :) > Anstelle von 4 OpV-Symbolen hatten die Schaltungs-Zeichner > damals einen symbolischen Schaltkreis gezeichnet, also ein > längliches Kästchen mit ner Delle auf der Oberseite, dann > links und rechts soviele Kringel dran, wie Anschlüsse waren > und (wenn sie gut drauf waren) die 4 OpV's innerhalb des > Kästchens gezeichnet. > > Damit konnten sie die OpV-Symbole eben NICHT frei in der > Schaltung plazieren, [...] Jaja... ich habe verstanden, wovon Du sprichst -- mir ist nur nicht klar, wieso Du mir dieselbe Denkweise unterstellst. > Aus dieser Art des Denkens kam vermutlich die Idee von > einem Symbol, das einen Footprint hatte (ich sag dazu: > einen Footprint nicht hatte, sondern darstellen sollte). > > Und genau diese Denkweise ist das, was mir hier im Forum > immer entgegen geschlagen ist, wenn es um Kicad ging. Das verstehe ich nicht. Ich kann natürlich nur für mich selbst sprechen, aber ich bin ja (nach meinem Gefühl) immer darauf herumgeritten, dass es nicht nur (Schaltplan-)Symbole und Footprints gibt, sondern außerdem auch BAUTEILE (was Du ja weiter oben im Prinzip genauso formulierst). > Insbesondere der Bernd Wiebus hat nichts unversucht > gelassen, um mich davon zu überzeugen. Er meinte da > einmal, daß eine solche Darstellung mit symbolischen > Footprints gerade für den Service-Techniker vorteilhaft > sei - [...] Nun ja, ich bin in diesem Punkt zwar anderer Meinung als Bernd, sehe aber das grundsätzliche Problem nicht. Meiner Meinung nach liegt die tiefere Ursache für den Konflikt darin, dass (nach meinem Verständnis auch -- aber nicht nur -- z.B. von Dir) die Meinung vertreten wird, der Schaltplan (die interne Datenstruktur = Bedeutung 3) sei die primäre Autorität für alles, was mit dem Projekt zu tun hat. Als Folge dieser Ansicht wird also (z.B. durch Zugriff auf die Library) ein "Bauteil" in den "Schaltplan" eingefügt (aber natürlich stellvertretend nur das/ein Symbol angezeigt). Die Auffassung ist naheliegend (und offenbar auch recht verbreitet), aber meiner Meinung nach für computergestützte Bearbeitung aus einer Reihe von Gründen nicht zweckmäßig. Meiner Ansicht nach sollten, wenn ein Bauteil aus der Bauteilbibliothek ausgewählt wurde, synchron ZWEI Aktionen ablaufen: - das Bauteil wird in die "Super-Stückliste" aufgenommen - in den "Schaltplan" wird eine REFERENZ auf die entsprechende Zeile in der Superstückliste aufgenommen; im Schaltplan dargestellt wird natürlich eines der Symbole, die das Bauteil ja mitgebracht hat. Die Folge aus dieser Sichtweise ist beispielsweise, dass Bauteile sowohl Symbole für aufgelöste wie auch solche für zusammengefasste Darstellung mitbringen können. Da im Schaltplan (Datenstruktur = Bedeutung 3) nicht das Bauteil, sondern nur ein VERWEIS auf die Stücklistenposition steht, über die die Symbol-Information beschafft wird, kostet es nur einen Mausklick, den gesamten Schaltplan von der kompakten in die aufgelöste Darstellung zu überführen, oder auch alle Ami-Symbole durch DIN-Symbole zu ersetzen. Ebenso kostet es nur einen Mausklick, R42 durch Diode D21 zu ersetzen, ohne dass die Verbindungen im Schaltplan oder die Leiterzüge im Layout irgendwie betroffen wären -- es wird einfach der Inhalt der entsprechenden Zeile der Super-Stückliste ausgetauscht. Sofern die Footprins hinreichend ähnlich sind, passiert im Layout nichts Schlimmes -- im Schaltplan sowieso nicht.
Ich verstehe nicht, was das Problem von W.S. ist? Alles was er da anspricht können doch Eagle und KiCad, oder etwa nicht? Geht es da nur mir so?
Robin schrieb: > Ich verstehe nicht, was das Problem von W.S. ist? > Alles was er da anspricht können doch Eagle und KiCad, oder etwa nicht? Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. Punkt.
Robin schrieb: > Ich verstehe nicht, was das Problem von W.S. ist? Nun, ich diskutiere ja mit ihm, um genau das zu verstehen. Und wenn ich nicht vernünftig mit ihm rede, kann ich nie herausfinden, was er an Eagle gut und an KiCAD schlecht findet. > Alles was er da anspricht können doch Eagle und > KiCad, oder etwa nicht? Erstens will ich ja gerade herausfinden ob das so ist, und zweitens: Selbst wenn es beide Programme können, so heißt das nicht, dass sie es gleich gut können. > Geht es da nur mir so? Naja, ich fühle mich in einer komfortablen Lage: Da ich alle bisher ausprobierten EDA-Systeme furchtbar finde, bin ich relativ unvoreingenommen :)
2⁵ schrieb: > Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle > kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig > Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. > Punkt. Was denn zum Beispiel? Könnt ihr nicht einmal genauer werden mit euren Behauptungen? Und jetzt nicht, was evtl etwas anders gelöst wurde und deshalb möglicherweise dem Eagle Nutzer nicht passt, sondern was es nicht kann.
Robin schrieb: > 2⁵ schrieb: >> Nein, W.S. hat Recht. KiCad kann halt einfach nicht >> alles, was Eagle kann. Punkt. [...] > > Was denn zum Beispiel? Forward-Backward-Annotation? SCNR
Possetitjel schrieb: > Ich kritisiere, dass man, um eine bestimmte Darstellung > eines Netzes zu aktivieren, ein bestimmtes "Bauteil" in > den "Schaltplan" (Bedeutung 3) einfügen muss! > > Das ist nämlich aus Sicht der Anwendungslogik widersinnig! Ach, du und deine epische breite :-) a) muss man nicht, es gibt andere Möglichkeiten. Man kann ein Netz "einfach so" umbenennen, man kann zur Visualisierung ein Label hinzufügen. b) finde ich es nicht widersinnig, sondern sogar unheimlich praktisch. Das (visuelle) Ergebnis ebenso wie die Vorgehensweise das zu erreichen. Meine Supply-Symbole lass ich mir nicht wegnehmen ;-) Possetitjel schrieb: > Meiner Ansicht nach sollten, wenn ein Bauteil aus der > Bauteilbibliothek ausgewählt wurde, synchron ZWEI > Aktionen ablaufen: [...] Zumindest in Eagle passiert genau das was du beschreibst. Auch wenn man den Code von Eagle nicht kennt, die "Datenstruktur" (= die xml-Files) spiegeln genau das wider.
2⁵ schrieb: > Robin schrieb: >> Ich verstehe nicht, was das Problem von W.S. ist? >> Alles was er da anspricht können doch Eagle und KiCad, oder etwa nicht? > > Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle > kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig > Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. > Punkt. Du hast auch Recht. Eagle kann einfach nicht Alles was KiCad kann. Mit ein wenig Flexibilität im Hirn kann man ganz arbeiten. Die Unflexibilität von der Lizensierungspolitik seitens AutoDesk Inc. läßt sich allerdings auch durch scharfes Nachdenken nicht verbessern. Gruß, Holm
Possetitjel schrieb: > Robin schrieb: > >> 2⁵ schrieb: >>> Nein, W.S. hat Recht. KiCad kann halt einfach nicht >>> alles, was Eagle kann. Punkt. [...] >> >> Was denn zum Beispiel? > > Forward-Backward-Annotation? > SCNR Push&Shove Routing? SCNR; Holm
Michael R. schrieb: > Possetitjel schrieb: >> Ich kritisiere, dass man, um eine bestimmte Darstellung >> eines Netzes zu aktivieren, ein bestimmtes "Bauteil" in >> den "Schaltplan" (Bedeutung 3) einfügen muss! >> >> Das ist nämlich aus Sicht der Anwendungslogik widersinnig! > > Ach, du und deine epische breite :-) <Heul!> > a) muss man nicht, es gibt andere Möglichkeiten. Man > kann ein Netz "einfach so" umbenennen, man kann zur > Visualisierung ein Label hinzufügen. Okay. > b) finde ich es nicht widersinnig, sondern sogar unheimlich > praktisch. Das (visuelle) Ergebnis ebenso wie die > Vorgehensweise das zu erreichen. Meine Supply-Symbole lass > ich mir nicht wegnehmen ;-) Software soll weltanschaulich neutral sein -- sie soll auch Arbeitsweisen unterstützen, die ich unsinnig finde :) Nein, im Ernst: Mir ist bisher noch keine Software untergekommen, bei der ich NICHT erst stundenlang frustriert in der Rumpelkammer namens "Library" herumstochern musste. Deshalb bin ich nur sehr mäßig begeistert, wenn alles und jedes durch spezielle Pseudo-Bauteile ausgedrückt wird. Das ist aber keine Frage des "gefühlten Datenmodells", sondern des GUI, das gebe ich zu. > Possetitjel schrieb: >> Meiner Ansicht nach sollten, wenn ein Bauteil aus der >> Bauteilbibliothek ausgewählt wurde, synchron ZWEI >> Aktionen ablaufen: [...] > > Zumindest in Eagle passiert genau das was du beschreibst. Okay, um so besser. Speziell, was Vergleiche Eagle <-> KiCAD angeht, habe ich das Problem, dass ich zwar KiCAD einfach ausprobieren kann, aber keine Zugriff auf Eagle habe. Ich bin also darauf angewiesen, dass ich verstehe, was mir kundige Eagle-User hier erklären. Dazu kommt noch, dass einige meiner Aussagen schätzungsweise missverständlich (weil grob vereinfachend) waren: Das eine Thema ist, wie gut das "gefühlte Datenmodell" des Programmes die realen Verhältnisse abbildet, die im realen Arbeitsablauf des Nutzers auftreten. Eine andere Frage ist, wie sicher sich der Benutzer bei der Orientierung im GUI fühlt, d.h. ob er jederzeit ein sicheres Gefühl dafür hat, welche Datentransformation diese oder jene GUI-Aktion bewirken wird. Obwohl natürlich ein realitätsnahes "gefühltes Datenmodell" wünschenswert ist, ziehe ich im Zweifelsfall eine Software vor, die zwar ein primitiveres "gefühltes Datenmodell" hat, dieses aber klar und wohlstrukturiert im GUI abbildet. Unerwartetes komplexes Verhalten der Software ist schädlicher als erwartetes primitives :)
Holm T. schrieb: > Push&Shove Routing? schade, direkter Link klappt nicht. sieh selber nach, P&S gibt es. https://www.autodesk.com/products/eagle/features
Possetitjel schrieb: > dass ich... aber keine Zugriff auf > Eagle habe Nichts einfacher als das. Freeware runterladen und auf gehts!
Johannes S. schrieb: > Holm T. schrieb: >> Push&Shove Routing? > > schade, direkter Link klappt nicht. sieh selber nach, P&S gibt es. > > https://www.autodesk.com/products/eagle/features ..hab nachgesehen...beschissenes Preis/Leistungsverhältnis.. Gruß, Holm
Beitrag #5354332 wurde von einem Moderator gelöscht.
Beitrag #5354375 wurde von einem Moderator gelöscht.
Es gibt eine ganz einfache Methode zu erkennen wer hier mit dem Rücken zur Wand steht. Die Betroffenen sehen sich genötigt mit allen Rohren auch unter die Gürtellinie zu schießen (weils obendrüber fachlich nicht mehr langt): > Holm T. schrieb: > Du warst wohl erst in der Eagle Kirche zur Bestrahlung? > Du bist mir ein ganzes Stück zu primitiv. Holm T. schrieb: > verschone uns doch bitte > von Deiner ewigen Wiederkäuerei Deines celebralen Unvermögens Trouble Shooter schrieb im Beitrag #5350766: > Du bist hier ein absoluter Noname. > Bei deinem Gesuelze was du hier absonders, müsstest du eigentlich vorher > um Erlaubnis fragen. Latrinenwärter schrieb im Beitrag #5354332: > Wenn dich diese versprengten, desorientierten > EAGLE Sektierer noch weiter belästigen Sollte ich Beleidigungen vergessen haben- bitte melden. Man muß es schon verstehen: Unbequeme Wahrheiten die man noch dazu immer wieder hören muß können schon verdammt nerven und aggressiv machen...
Bernd W. schrieb: > Zeno schrieb: > >> Bei meinen Schematics mit Eagle ist das genau so. Aber so etwas >> funktioniert eben nur, wenn schon im Schematic der Footprint bekannt >> ist. > > Das ist nun kein Eagle Alleinstellungsmerkmal. Das habe ich auch nicht behauptet.
Holm T. schrieb: > eld spielt ja bei Dir offensichtlich eine untergeordnete Rolle, > aber Du versuchst u.a. mich zu agitieren das KiCad unbrauchbar ist. > Warum eigentlich? Bei mir spielt Geld überhaupt keine untergeordnete Rolle. Aber es ist eben auch nicht Prio 1. Wo liest Du raus das ich Dich agitieren will das KiCAD unbrauchbar ist. Ich für mich persönlich empfinde es als zu sperrig. Ich komme mit Eagle besser zurecht als mit KiCAD und empfinde ersteres deutlich intuitiver. Das ist aber meine persönliche Meinung. Mir ist völlig egal welches Programm Du benutzt. Ich frage mich langsam aber warum KiCAD User Kritik an KiCAD oftmals so interpretieren als wolle man ihnen selbiges abspenstig machen. Jeder muß auf seine Art glücklich werden, aber Kritik sollte man dennoch zulassen.
Holm T. schrieb: > Die unendliche Diskussion haben wir doch schon, oder was denkst du was > das ist was W.S. hier in jedem Thread zelebriert? W.S. hat hat zu diesem Thema eben seine eigene Meinung, so wie Du, ich und viele andere hier im Forum. Das ist doch auch völlig legitim und wo kommen wir hin, wenn wir einen Einheitsbrei machen. Immerhin muß ich ihm zu Gute halten, das er seine Aussagen i.d.R. auch begründet und nicht einfach in den Raum wirft, wie das viele hier tun. Mir schmecken auch nicht alle seine Posts, aber da muß man doch kein Drama daraus machen. Er wird sicher seine Gründe haben warum er so argumentiert - so wie Du auch.
2⁵ schrieb: > Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle > kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig > Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. > Punkt. Du bringst es auf den Punkt.
Helmut schrieb: > Es gibt eine ganz einfache Methode zu erkennen wer hier mit dem Rücken > zur Wand steht. Die Betroffenen sehen sich genötigt mit allen Rohren > auch unter die Gürtellinie zu schießen (weils obendrüber fachlich nicht > mehr langt): Ach lass mal - da steht man doch drüber.
@Helmut Kleiner Nachtrag: Bei einigen Dir, in Deinen letzten Post, zitierten Leuten, sagt doch alleine der Nickname einiges über den geistigen Horizont aus. Solche Leute kann/muß man einfach nur ignorieren. Da ist auch jegliche Diskussion zwecklos.
Hi, ob der ausufernden Streitereien wollte ich mich eigentlich nicht mehr an dieser Diskussion beteiligen, tu es aber trotzdem. Zunächst: Ich bin seit Jahren bis zur Version 6.5 Eagle nutzer und betreibe es als Hobby. Habe mir auch vor Jahren die Hobby Lizenz gekauft, weil ich mal 4-lagige Platinen machen wollte und auch der Ansicht bin, daß man für gute SW durchaus mal was bezahlen kann. Mit der aktuellen Lizenspolitik des Adlers habe ich aber auch erhebliche Schwierigkeiten und schaue auch ab und zu mal was sich an der Front tut. Ich habe mir jetzt mal die Kicad 5 heruntergeladen und 2h damit gespielt. Und ich muß sagen: Nicht schlecht, da hat sich einiges getan. Der Workflow ist natürlich anders, aber da gewöhnt man sich dran. Insgesamt erscheint mir Kicad logischer, insbesondere weil Schaltplan und Footprint strikt getrennt sind. Dadurch, daß beim Adler alle Bauteile x mal in der library vorkommen (wg. der verschiedenen Footprints) werden die libs ziemlich aufgebläht. Ich verliere da etwas den Überblick. Mein Workflow beim Entwickeln sieht auch so aus, daß ich zunächst einen Schaltplan zeichne, mir dann überlege wo ich die Bauteile herbekomme (dann entscheidet sich meist erst der Footprint) und dann die Platine mache. Da passt Kicad irgendwie besser dazu. Backward annotation habe ich bei Kicad nicht vermißt, da nie gebraucht. Super finde ich auch die 3D Ansicht von Kicad. Erstes Fazit: Es lohnt sich, sich mit Kicad mal etwas näher zu befassen.
Beitrag #5354584 wurde von einem Moderator gelöscht.
Mein Hobby-Workflow schaut so aus daß ich mir gern unnütze Bürokratie spare. Das bedeutet es geht gleich mit dem Layout los. Dazu ist KiCad leider völlig inkompatibel, da wird auf dem Zeichnen des Schaltplans als Grundlage aller weiteren Arbeit bestanden. Mag ja die professionellere Arbeitsweise sein, zugegeben. Mit den ausufernden Eagle Bibliotheken hatte ich auch zu kämpfen. Hier kommt es freilich entscheidend darauf an daß man ein eigenes System findet und sich konsequent daran hält. Von neumodischen Erfindungen wie 3D Darstellung wie von Eagle und KiCad geboten halte ich gar nichts. Schaut hübsch aus, bläht die nötige Bürokratie aber nur unnütz auf. Kann man vielleicht im Zusammenhang mit professioneller Gehäuseplanung brauchen, sonst bleibts eher Spielerei. Das Vorstellungsvermögen in meinem Kopf bei den meist kleineren Hobbyprojekten langt völlig. Schaun wir mal wie das völlig kostenlose KiCad weiter gedeiht. Da bin ich allerdings skeptisch weil ich wie W.S. glaube daß es schon von grundauf falsch angelegt ist. Wenn es allerdings immer mehr Nutzer finden sollte wird das dem Programm und wird das dem ganzen (bezahlten) Markt sicher gut tun.
Zeno schrieb: > Holm T. schrieb: >> eld spielt ja bei Dir offensichtlich eine untergeordnete Rolle, >> aber Du versuchst u.a. mich zu agitieren das KiCad unbrauchbar ist. >> Warum eigentlich? > > Bei mir spielt Geld überhaupt keine untergeordnete Rolle. Aber es ist > eben auch nicht Prio 1. > > Wo liest Du raus das ich Dich agitieren will das KiCAD unbrauchbar ist. > Ich für mich persönlich empfinde es als zu sperrig. Ich komme mit Eagle > besser zurecht als mit KiCAD und empfinde ersteres deutlich intuitiver. > Das ist aber meine persönliche Meinung. Die ist doch auch völlig ok. Wenn KiCad zu sperrig für Dich ist und Eagle besser funktioniert..dann nimm doch einfach dieses. Mein Problem dabei ist nur, das Du nicht akzeptieren willst das es für andere Leute eben auch anders aussieht. Ich komme gut mit KiCad klar, weiß sehr wohl das es nicht perfekt ist. Eagle kommt bei mit nicht auf die Platte weil ich kein Mainstream-OS benutzte, weil die Freeware-Version zu restriktiv mit Platinenmaßen umgeht und weil sich eine Lizenz für meine Firma auf Grund seltener Benutzung niemals rechnen würde..nun seit Mietware-Zeiten gleich gar nicht mehr. Jetzt sage mir bitte was daran falsch ist? > Mir ist völlig egal welches Programm Du benutzt. Das ist es eben nicht. > Ich frage mich langsam > aber warum KiCAD User Kritik an KiCAD oftmals so interpretieren als > wolle man ihnen selbiges abspenstig machen. Jeder muß auf seine Art > glücklich werden, aber Kritik sollte man dennoch zulassen. Genau das frage ich mich bei Dir andersherum ..Du schimpfst wie ein Rohrspatz ..legs doch einfach Beiseite...? Du kritisierst eben nicht nur..Du sortierst K. als ungeeignet ein und vertrittst diese Einschätzung laut und allgemeingültig. Ich sage leben und leben lassen, wenn es Eagle für Dich tut dann nimm doch das. Ich habe hier das Gefühl das die "Eagler" hier schon KiCad wollen..aber bitteschön angepaßt auf ihre Bedürfnisse..es soll gefälligst so funktionieren wie sie es gewöhnt sind. Sinngemäß: "..und wann kommt das endlich, wie lange soll das noch dauern?" ..dabei ist aber natürlich eigene Mitarbeit in der entsprechenden Community zu viel verlangt. W.S. reißt seinen Hals auf (..völlig unbrauchbar..") aber der beschwert sich auch nicht da wo er gehört werden könnte..sondern hier, penetrant und in allen verwandten Threads sich ständig wiederholend...dabei ist er doch eigentlich auch Superprogrammierer..? Gruß, Holm
Helmut schrieb: > Es gibt eine ganz einfache Methode zu erkennen wer hier mit dem Rücken > zur Wand steht. Die Betroffenen sehen sich genötigt mit allen Rohren > auch unter die Gürtellinie zu schießen (weils obendrüber fachlich nicht > mehr langt): > >> Holm T. schrieb: >> Du warst wohl erst in der Eagle Kirche zur Bestrahlung? >> Du bist mir ein ganzes Stück zu primitiv. > > Holm T. schrieb: >> verschone uns doch bitte >> von Deiner ewigen Wiederkäuerei Deines celebralen Unvermögens > > Trouble Shooter schrieb im Beitrag #5350766: >> Du bist hier ein absoluter Noname. >> Bei deinem Gesuelze was du hier absonders, müsstest du eigentlich vorher >> um Erlaubnis fragen. > > Latrinenwärter schrieb im Beitrag #5354332: >> Wenn dich diese versprengten, desorientierten >> EAGLE Sektierer noch weiter belästigen > > Sollte ich Beleidigungen vergessen haben- bitte melden. > > Man muß es schon verstehen: Unbequeme Wahrheiten die man noch dazu immer > wieder hören muß können schon verdammt nerven und aggressiv machen... Och Helmut..ich habe mich schon bei Anderen darüber beklagt das sie mir zu primitiv seien..einer der aus dem Kontext gerissene Zitate auffädelt und abrechnet hat mir dabei noch gefehlt. Kannst Du bitte entweder unter dem Teppich hervor kommen oder Deinen Schacht halten? Gruß, Holm
Zeno schrieb: > Holm T. schrieb: >> @Zeno: 0589.. warst Du das? > > Sagt mir jetzt nichts? Was meinst Du damit? Bei mir hat Jemand 2 mal kurz hintereinander versucht anzurufen, aber eben so das ich es nicht geschafft habe ans Tel. zu gehen.. 0589 war der Beginn der Vorwahl. Gruß, Holm
Zeno schrieb: > 2⁵ schrieb: >> Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle >> kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig >> Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. >> Punkt. > > Du bringst es auf den Punkt. Du kannst das drehen wie Du willst. Auch die Philosophie von KiCad ist berechtigt und mit Eagle ist es möglich Platinen zu erstellen. Beide sind miteinander verglichen einfach "anders". Es fährt nicht jeder VW .obwohl mir schon zu Ohren gekommen ist das angeblich auch damit schon Leute Ihr Ziel erreicht haben sollen. Eagle ist aus KiCads Sicht steinalt, da steckt viel mehr Manpower drin als die halbe Stelle die das Cern den beiden Hauptentwicklern von KiCad zahlt. Warum darf Kiad nicth anders sein und warum wird erwartet das es sich in jeder Beziehung auf derselben Ebene zum Vergleich bewegen muß? W.S. hat nicht Recht. Die Art und Weise wie er seine Meinung vertritt ist falsch und er vertritt sie an der falschen Stelle auf die falsche Weise, genau deshalb ist sie falsch. Gruß, Holm
Ich wollte nur mal klarstellen, dass ich nicht derjenige bin der hier ohne Anmeldung (Gast) unter dem Namen "Helmut" schreibt.
Holm T. schrieb: > weil sich eine Lizenz für meine Firma auf Grund seltener > Benutzung niemals rechnen würde..nun seit Mietware-Zeiten gleich gar > nicht mehr. Mensch gerade für seltene Benutzung ist doch die Miete von Vorteil. Was ist daran so schwer zu begreifen? Aber wenn Du LP-Design Software eh so selten verwendest verstehe ich jetzt auch warum Du hier soviel Zeit hast darüber zu pallavern und die Leute zu bepöbeln.
Holm T. schrieb: > einer der aus dem Kontext gerissene Zitate auffädelt > und abrechnet hat mir dabei noch gefehlt. Ja, der fehlt Dir wirklich. Der angemahnte Kontext macht es auch nicht besser :( Helmut S. schrieb: > Ich wollte nur mal klarstellen, dass ich nicht derjenige bin der > hier ohne Anmeldung (Gast) unter dem Namen "Helmut" schreibt. Dann stelle ich mal klar daß ich nicht Helmut S. bin :)
Jonas schrieb: > Holm T. schrieb: >> weil sich eine Lizenz für meine Firma auf Grund seltener >> Benutzung niemals rechnen würde..nun seit Mietware-Zeiten gleich gar >> nicht mehr. > > Mensch gerade für seltene Benutzung ist doch die Miete von Vorteil. Wenn man alle meine anderen Gegenargumente außer Acht läßt und Miete gegenüber Kostenlos als preiswert einstuft..dann hast Du Recht. > Was > ist daran so schwer zu begreifen? Deine Mission.. > Aber wenn Du LP-Design Software eh so > selten verwendest verstehe ich jetzt auch warum Du hier soviel Zeit hast > darüber zu pallavern und die Leute zu bepöbeln. Das liegt daran dass ich selbständig bin, Geld wie Heu mache und den ganzen Tag nur den Finger im Arsch habe. Die dabei aufkommende Langeweile muß ich irgendwie kompensieren ..weißt Du? Gruß, Holm
Helmut schrieb: > Holm T. schrieb: >> einer der aus dem Kontext gerissene Zitate auffädelt >> und abrechnet hat mir dabei noch gefehlt. > > Ja, der fehlt Dir wirklich. Der angemahnte Kontext macht es auch nicht > besser :( > > Helmut S. schrieb: >> Ich wollte nur mal klarstellen, dass ich nicht derjenige bin der >> hier ohne Anmeldung (Gast) unter dem Namen "Helmut" schreibt. > > Dann stelle ich mal klar daß ich nicht Helmut S. bin :) ..und wir auch sonst auf dich verzichten können.. Gruß, Holm
Holm T. schrieb: > Eagle ist aus KiCads Sicht steinalt, da steckt viel mehr Manpower drin > als die halbe Stelle die das Cern den beiden Hauptentwicklern von KiCad > zahlt. Das hast Du gut erkannt Holm. Klar, ohne die "steinalt" Abwertung wärs jetzt nicht über Deine Lippen gekommen. Aber immerhin. Nun sollte doch auch Dir klar sein daß sich bei dieser Ausgangslage ein kleiner leichter Kutter wie KiCad (meist mit ein paar Leichtmatrosen an Bord) nur schwer mit einem großen Tanker wie Eagle vergleichen kann. Das geht maximal über den Preis- doch selbst Eagle dient sich ja immer noch bis zu einer gewissen Boardgröße und 2 Lagen als vollwertige Freeware an. Für KiCad ist also noch viel Luft nach oben und es dürfte schwer werden, gegenüber kostenpflichtiger Software nachhaltig aufzuholen. Hinsichtlich Funktionsumfang, vor allem aber im Handling und Bedienkomfort.
P. Manfelder schrieb: > Holm T. schrieb: >> Eagle ist aus KiCads Sicht steinalt, da steckt viel mehr Manpower drin >> als die halbe Stelle die das Cern den beiden Hauptentwicklern von KiCad >> zahlt. > > Das hast Du gut erkannt Holm. Klar, ohne die "steinalt" Abwertung wärs > jetzt nicht über Deine Lippen gekommen. Aber immerhin. Das ist doch Blödsinn! Hilft es Dir wenn es mit völlig egal ist ob Du Dein Eagle verchromst oder vergoldest? > Nun sollte doch > auch Dir klar sein daß sich bei dieser Ausgangslage ein kleiner leichter > Kutter wie KiCad (meist mit ein paar Leichtmatrosen an Bord) nur schwer > mit einem großen Tanker wie Eagle vergleichen kann. Prust...klar kann man den vergleichen, beim Ölverbrauch... Es ist halt Scheiße wenn man nur einen schukarton transportieren will einen Tanker chartern zu müssen/sollen. > Das geht maximal > über den Preis- doch selbst Eagle dient sich ja immer noch bis zu einer > gewissen ..für meine Bedürfnisse völlig untauglichen.. >Boardgröße und 2 Lagen als vollwertige Freeware an. "Leerwertig" wäre auch ein seltsames Marketingargument. Nutzlos beschreibt es besser. Aus meiner Sicht völlig nutzlos und mit der Miete überteuert. Du hast keine Ahnungwas Freeware ist. Eagle in der Ausführung ist ne kostenlose Demo, Werbematerial...aber kein Werkzeug. > Für KiCad > ist also noch viel Luft nach oben und es dürfte schwer werden, gegenüber > kostenpflichtiger Software nachhaltig aufzuholen. Hinsichtlich > Funktionsumfang, vor allem aber im Handling und Bedienkomfort. ..dürfte..hätte..könnte..Fahrradkette? Nimm das Ding doch bis an Dein Lebensende oder bis Du den Marinediesel Deines Tankers nicht mehr bezahlen kannst. Mir ist das völlig egal und es ist auch nicht das kleinste Argument für mich das benutzen zu wollen. Mal als Erinnerung, es geht hier um die Erfahrungen von Eagle->KiCad Wechslern, nicht darum Jemandem der mit KiCad klar kommt den Umstieg zum momentan am eigenen Marketing scheiternden Eagle schmackhaft machen zu wollen. Es gibt nicht ein einziges Argument für mich das in diese Richtung weist, Eure Idee ist zum scheitern verurteilt. BTW: Ich bin einer der ab und an mal in den Sourcecode guckt, nach der Ursache für Ärger sucht und den Kram selber kompiliert, deswegen kann ich mir auch ein FreeBSD als OS leisten. Eagle ist Closed Source.. interessiert mich nicht. Gruß, Holm
@Holm: Ich habe langsam den Eindruck Du willst mich nicht verstehen oder liest meine Posts nicht sorgfältig genug. Ich habe mehrfach geschrieben das es Deine Sache ist welches Programm Du zum Erstellen Deiner LP's benutzt. Wenn Dir der Workflow von KICAD halt besser gefällt, aus welchen Gründen auch immer -z.B. weil es besser zu Deinem OS passt -, dann benutze es einfach. Aber versuch nicht das, was Du mir hier vorwirfst, nämlich andere zur Benutzung von KiCAD zu überzeugen. Du verlierst dabei leider Schnell den Faden zur Sachlichkeit. Bleibe einfach cool und benutze Du KiCAD so wie ich weiterhin mit Eagle arbeiten werde. Ich benutze noch eine Version vor dem Mietmodell, da diese für meine Belange völlig ausreicht und das aller Wahrscheinlichkeit in Zukunft auch noch tun wird. Ich halte von dem Mietmodell genauso wie die meisten hier nicht viel. Für mich gibt es derzeit keinen driftigen Grund zu KiCAD zu wechseln, ich finde es eben wenig intuitiv und habe keine Zeit stundenlang Tutorials zu wälzen um nur erst einen Schaltplan erstellen zu können (s. hier Beitrag "KiCad Anfänger benötigt Hilfe bei Schaltplan Erstellung"). Er hat sich, so wie er schreibt, schon bemüht einen Faden zu KiCAD zufinden, aber es scheint ja schon am simplen Verbinden von einer Handvoll Bauteilen mit Leiterzügen zu scheitern. An dieser Stelle hatte ich mit Eagle nie Probleme gehabt, das hatte ich innerhalb weniger Minuten raus - ohne ein Tutorial zu bemühen. In Eagle gibt es ganz andere, auch große, Steine die einem in den Weg gelegt werden und wo man auch zu knabbern hat. Aber die Basics sind relativ einfach und man hat schnell einen Erfolg. Wie gesagt alles nur meine persönliche Meinung, das mögen andere ganz anders sehen und das ist so auch in Ordnung. Dennoch sollte Kritik möglich sein und ein Forum lebt schließlich von Meinungsvielfalt, oder mit anderen Worten "Leben und Leben lassen".
Holm T. schrieb: > das ich es nicht geschafft habe ans Tel. zu gehen.. 0589 war der Beginn > der Vorwahl. Ach so! Nö war ich nicht! Warum sollte ich hier bei irgend jemanden anrufen. Ich wüßte noch nicht mal Deine Telefonnummer.
Holm T. schrieb: > ..und wir auch sonst auf dich verzichten können.. Dur wirst schon wieder aggressiv. Du solltest Dich besser kontrollieren. Du schießt hier gegen jeden der nur etwas Positives zu Eagle sagt, er muß da noch nicht einmal etwas gegen KiCAD sagen. Alleine die Tatsache das derjenige positiv gegenüber Eagle eingestellt ist, reicht Dir schon um teilweise beileidigend zu werden. Du benutzt Eagle nicht weil es mit Deinem OS nicht funktioniert aber machst es nieder obwohl Du es vermutlich nicht beurteilen kannst. Es wird wohl nur sehr wenig PCB Software geben die unter BSD direkt läuft und KiCAD ist da offensichtlich die Ausnahme, weshalb Du darauf auch mehr oder weniger angewiesen bist. Und ja Du darfst BSD benutzen und Du darfst ebenso jede andere Software nutzen von der Du meinst, daß sie Deinen Ansprüchen gerecht wird - es wird hier eh niemanden interessieren. Aber unterlasse es bitte Leute zu beschimpfen die anderer Meinung sind als Du. Gegen sachliche Kritik hat hier keiner etwas. Ach ja und das mit dem Telefon grenzt schon an leichte Paranoia.
@P.Manfelder Was du hier an geistigen Extrakt zu bieten hast, ist wohl nicht zu überbieten:-( Wie Joungster lachen nur über eure Gestrigkeit. Die Zukunft gehört KICAD. Ich frage mich, was seit ihr nur für Vorbilder?
Zeno schrieb: > @Holm: > > Ich habe langsam den Eindruck Du willst mich nicht verstehen oder liest > meine Posts nicht sorgfältig genug. Ich habe mehrfach geschrieben das es > Deine Sache ist welches Programm Du zum Erstellen Deiner LP's benutzt. > Wenn Dir der Workflow von KICAD halt besser gefällt, aus welchen Gründen > auch immer -z.B. weil es besser zu Deinem OS passt -, dann benutze es > einfach. Aber versuch nicht das, was Du mir hier vorwirfst, nämlich > andere zur Benutzung von KiCAD zu überzeugen. Du verlierst dabei leider > Schnell den Faden zur Sachlichkeit. Bleibe einfach cool und benutze Du > KiCAD so wie ich weiterhin mit Eagle arbeiten werde. Den Vorschlag habe ich Dir aber weiter oben schon vor langer Zeit gemacht. > Ich benutze noch eine Version vor dem Mietmodell, da diese für meine > Belange völlig ausreicht und das aller Wahrscheinlichkeit in Zukunft > auch noch tun wird. Ich halte von dem Mietmodell genauso wie die meisten > hier nicht viel. Für mich gibt es derzeit keinen driftigen Grund zu driftig :-)) > KiCAD zu wechseln, ich finde es eben wenig intuitiv und habe keine Zeit > stundenlang Tutorials zu wälzen um nur erst einen Schaltplan erstellen > zu können Das ist aber eine völlig normale Sache und würde Dir umgekehrt genauso passieren. Auch dieses Beispiel (Editor/Programmiersprache) habe ich oben schon aufgeführt. Das geht also weder in die eine, noch in die andere Richtung und ist auch kein KiCad Problem, sondern eins der Gewohnheit. > (s. hier > Beitrag "KiCad Anfänger benötigt Hilfe bei Schaltplan Erstellung"). Er hat sich, > so wie er schreibt, schon bemüht einen Faden zu KiCAD zufinden, aber es > scheint ja schon am simplen Verbinden von einer Handvoll Bauteilen mit > Leiterzügen zu scheitern. Ohne das jetzt gelesen zu haben (mach ich nachher) ..ja, kann sein. Umgekehrt aber auch. > An dieser Stelle hatte ich mit Eagle nie > Probleme gehabt, das hatte ich innerhalb weniger Minuten raus - ohne ein > Tutorial zu bemühen. In Eagle gibt es ganz andere, auch große, Steine > die einem in den Weg gelegt werden und wo man auch zu knabbern hat. Aber > die Basics sind relativ einfach und man hat schnell einen Erfolg. Ich habe bisher bei Kicad nur anfangs mal hinsichtlich hierarischer Schaltpläne nachlesen müssen und mich über die strikte Durchnummerierung von Bussen geärgert. Der Rest war auch intuitiv. > > Wie gesagt alles nur meine persönliche Meinung, das mögen andere ganz > anders sehen und das ist so auch in Ordnung. Dennoch sollte Kritik > möglich sein und ein Forum lebt schließlich von Meinungsvielfalt, oder > mit anderen Worten "Leben und Leben lassen". Na genau. Du solltest Dir nur merken das genau der selbe Effekt an anderen Stellen wieder passieren kann und wird. Mal Eagle beiseite: Es gibt derzeit viele Leutchen die Microsoft Windows satt haben..ständige Updateorgien, Gängelei, Spionage. Was glaubst Du wie es den nach Linux Umsteigern da geht? Die Programme sind eben nicht IE und rausguck ganzfix, sie sind aber ähnlich..nicht gleich. Linux wird nie Windows sein, KiCad nie Eagle und notepad niemals vi. Wenn dann Einer es mal geschafft hat umzusteigen hört man oft das er es bitter bereut hat das nicht schon viel eher versucht zu haben..und man hört auch die "geht gar nicht" Meinungen von den Leuten denen die süßen Trauben zu hoch hingen. Ich kenne aber Keinen der ernsthaft wieder zurück will, genauso wie es mir nicht im Traume einfiele jetzt auf Eagle umsteigen zu wollen. Wenn man also "leben und leben lassen" ernst nimmt wird sich aber automagisch die Frage danach einstellen wie es Andere schaffen mit der Software die man eben gerade als untauglich zur Nachfolge qualifiziert hat zu ansprechenden, Industriestandards entsprechenden Lösungen kommen... Vielleicht war die eigene Herangehensweise falsch? Gruß, Holm
Holm T. schrieb: > Aus meiner Sicht völlig nutzlos und mit der Miete überteuert. > Du hast keine Ahnungwas Freeware ist. Eagle in der Ausführung ist ne > kostenlose Demo, Werbematerial...aber kein Werkzeug. Ach Holm jetzt laß doch mal die Kirche im Dorf. Du machst - wie Du selbst schreibst - nur alle Nasen mal ein Layout, benutzt Eagle nicht und maßt Dir dann dieses Urteil an. Mal abgesehen davon das Du auch in dem zitierten Post schon wieder völlig die Contenance verlierst. Du glaubst doch nicht etwa das Du mit Deiner Art und Weise KiCAD ein Dienst erweist.
Zeno schrieb: > Holm T. schrieb: >> das ich es nicht geschafft habe ans Tel. zu gehen.. 0589 war der Beginn >> der Vorwahl. > > Ach so! Nö war ich nicht! Warum sollte ich hier bei irgend jemanden > anrufen. Ich wüßte noch nicht mal Deine Telefonnummer. ...weil Du oben schriebst ich solle dich mal schimpfen hören und antwortete das Du mich halt anrufen sollst. Meine Telno ist mir sehr wenig Mühe zu finden. Gruß, Holm
Holm T. schrieb: > Eagle ist Closed Source.. > interessiert mich nicht. Jetzt haben wir es doch. Da ist jede weitere Diskussion völlig überflüssig.
Lehrling schrieb: > Ich frage mich, was seit ihr nur für Vorbilder? Wahrscheinlich nicht die Deinigen. Stoße Dir erst mal Deine Hörner ab und dann beweise es mal den alten Säcken hier das Du es besser kannst. Aber das ist eben so, wenn man jung ist ist noch viel Begeisterung da, aber die Realität holt einen dann schon irgendwann ein und man findet (hoffentlich) auf den Boden der Tatsachen zurück. Hat jetzt nichts mit KiCAD vs. Eagle zu tun, ist einfach etwas was man im Laufe seines Lebens lernt. Wird bei Dir irgendwann nicht anders sein, wenn Du Dich mit Deinen Nachfolgegenerationen auseinandersetzen mußt.
Zeno schrieb: > Holm T. schrieb: >> Eagle ist Closed Source.. >> interessiert mich nicht. > > Jetzt haben wir es doch. Da ist jede weitere Diskussion völlig > überflüssig. Naja sicher. Weiß nicht wie oft ich es schrieb: Ich habe FreeBSD auf dem Rechner. Windows oder Linux müßte ich emulieren und auch wenn es oft ganz gut funktioniert..das will man nicht wirklich. Deswegen habe ich von Anfang an nie Eagle verwendet. Irgendwie hat sich aber die Diskussion hier mal herumgedreht, die Eagle Nutzer versuchen mir die Vorteile sogar einer Mietversion schmackhaft zu machen..was für ein Unfug, dafür gab es nie nur den Hauch einer Chance. Wir können schon weiter diskutieren, nur nicht darüber ob Eagle evtl. für mich besser geeignet ist, daran habe ich aber auch nie einen Zweifel gelassen. Gruß, Holm
Zeno schrieb: > Holm T. schrieb: >> Aus meiner Sicht völlig nutzlos und mit der Miete überteuert. >> Du hast keine Ahnungwas Freeware ist. Eagle in der Ausführung ist ne >> kostenlose Demo, Werbematerial...aber kein Werkzeug. > > Ach Holm jetzt laß doch mal die Kirche im Dorf. Du machst - wie Du > selbst schreibst - nur alle Nasen mal ein Layout, benutzt Eagle nicht > und maßt Dir dann dieses Urteil an. Moment, ich habe hier seit Anfang an Deinen "leben und leben lassen" Grundsatz verfolgt. Ich habe für mich definiert das Eagles Features völlig unbrauchbar sind, was interessanterweise Missionare auf den Plan rief. >Mal abgesehen davon das Du auch in > dem zitierten Post schon wieder völlig die Contenance verlierst. > Du glaubst doch nicht etwa das Du mit Deiner Art und Weise KiCAD ein > Dienst erweist. Es ist nicht immer so wie es scheint. Ja, ich bin ein Arschloch und ich schreibe deutlich was mir nicht paßt und auch nicht gezwungenermaßen politisch korrekt. Muß ich auch nicht, weder will ich gewählt werden noch bin ich unheimlich jung. Die Contenance verliere ich allerings niemals :-) Gruß, Holm
Zeno schrieb: > Holm T. schrieb: >> ..und wir auch sonst auf dich verzichten können.. > > Dur wirst schon wieder aggressiv. Wieso werde? :-) >Du solltest Dich besser kontrollieren. Das war schon im vorherigen Post eine Fehleinschätzung. Ich bin völlig ruhig und gefaßt. > Du schießt hier gegen jeden der nur etwas Positives zu Eagle sagt, er > muß da noch nicht einmal etwas gegen KiCAD sagen. Das ist einfach nicht wahr. Helmut hat einfach Nichts beigetragen. Er hat nur Postingstückchen gesammelt und aus seiner Sicht strategisch vorteilhaft plaziert. Das selbe Spiel wie mit der Nulpe vorher, wer Nichts zu sagen hat kann die Klappe halten. > Alleine die Tatsache > das derjenige positiv gegenüber Eagle eingestellt ist, reicht Dir schon > um teilweise beileidigend zu werden. Nein! Ich habe Nichts gegen Eagle, es ist aber simpel für mich nicht brauchbar aus mehreren Gründen. Das paßt aber den Eagle Jüngern nicht (..mieten vorteilhaft..etc pp.) > Du benutzt Eagle nicht weil es mit > Deinem OS nicht funktioniert aber machst es nieder Wo habe ich das getan? Ich schrieb das es aus Marketinggründen wohl vor dem Aus steht, nicht das es Scheiße ist oder schon immer war. ..Demoversion: zu klein ..Host OS nicht unterstützt. ..Lizenz für kleines Gewerbe zu teuer gemessen am Nutzen. .. Miete ..noch schlimmer. > obwohl Du es > vermutlich nicht beurteilen kannst. Es wird wohl nur sehr wenig PCB > Software geben die unter BSD direkt läuft und KiCAD ist da > offensichtlich die Ausnahme, weshalb Du darauf auch mehr oder weniger > angewiesen bist. Guck mal rückwärts im Thread seit wann ich das geschrieben habe... > > Und ja Du darfst BSD benutzen und Du darfst ebenso jede andere Software > nutzen von der Du meinst, daß sie Deinen Ansprüchen gerecht wird - es > wird hier eh niemanden interessieren. Niemand ist relativ. Ich bin hier in einem Fread über Eagle->KiCad Umsteiger, gelandet bin ich hier weil ich dachte evtl. helfen zu können. Gelesen habe ich dann Agit Prop für Eagle... > Aber unterlasse es bitte Leute zu beschimpfen die anderer Meinung sind > als Du. Gegen sachliche Kritik hat hier keiner etwas. Nein und nein. 1. haben hier viele was gegen sachliche Kritik und kommen mit unsachlichen Argumenten. 2. entscheide ich wem gegenüber ich wie aggressiv werden möchte. > Ach ja und das mit dem Telefon grenzt schon an leichte Paranoia. Das hast Du völlig mißverstanden, ich bin weder paranoid noch habe ich Angst vor klingelnden Telefonen. Ich hätte mich gerne mit Dir unterhalten, deswegen schlug ich das vor, mehr nicht. Das ist also keine Beschuldigung oder Sowas, ganz im Gegenteil. Gruß, Holm
Könnt ihr mal die Anfeindungen sein lassen und mal sachlich über das Thema diskutieren? Btw: Bis jetzt das Einzige, was genannt wurde, was KiCAD nicht kann, ist Forward-Backward-Annotation und über dessen Sinn wurde ja schon genug diskutiert.
Zeno schrieb: > dann beweise es mal den alten Säcken hier das Du es besser kannst. Was den Einsatz moderner produktiver SW -Tools anbetriff, allemal. KiCad gehört da auch dazu. Im Übrigen empfinde ich deine Beiträge als arrogant, anmaßend und aufdringlich
Robin schrieb: > Könnt ihr mal die Anfeindungen sein lassen und mal sachlich über das > Thema diskutieren? > Ich kann Dich beruhigen, aus meiner Richtung ist das in Richtung Zeno keineswegs irgend eine Anfeindung. Er ist einer Derjenigen hier der mehr für vernünftige Argumente grundsätzlich zugängig erscheint. Er begreift allerdings nicht das ich ihm gar nicht an die Wäsche will mit seinem Eagle.. > > Btw: Bis jetzt das Einzige, was genannt wurde, was KiCAD nicht kann, ist > Forward-Backward-Annotation und über dessen Sinn wurde ja schon genug > diskutiert. Ja..der 2. Kritikpunkt betrifft das Handlich von Schaltplansymbolen mit oder ohne Footprints und ist aus meiner Sicht völliger Nonsense, da man in den letzten Versionen die ich in der Hand hatte das Footprint in der Schaltung definieren kann. Das ist aber offensichtlich noch nicht früh genug, der Zeitpunkt muß vor Christus liegen oder so damit das rockt. ein 3.er Punkt ist das verschieben von Footprints und Schaltungsteilen mit angehängten Leitungen oder Leiterzügen die KiCads Philosophie, nicht in Netzlisten auftauchende Verbindungen gar nicht erst zuzulassen, entgegen steht. Mein Hinweis zu Forward/Backward Anno das KiCad noch ziemlich jung sei, wurde nicht akzeptiert ("wie lange soll denn das noch dauern.."). BTW: Ich kenne Leute die ohne jede Netzliste mit Sprintlayout prima 2seitige Platinen machen, über A4 groß..wäre mir zu fehleranfällig, muß aber offensichtlich funktionieren. Gruß, Holm
Oh je, hätte ich nur nichts geschrieben... Holm T. schrieb: > Du kannst das drehen wie Du willst. Auch die Philosophie von KiCad ist > berechtigt und mit Eagle ist es möglich Platinen zu erstellen. > Beide sind miteinander verglichen einfach "anders". [...] > Warum darf KiCad nicht anders sein und warum wird erwartet das es sich in > jeder Beziehung auf derselben Ebene zum Vergleich bewegen muß? [...] > W.S. hat nicht Recht. Die Art und Weise wie er seine Meinung vertritt > ist falsch und er vertritt sie an der falschen Stelle auf die falsche > Weise, genau deshalb ist sie falsch. Also: W.S. (und andere) suchen einen bestimmten Workflow, den sie bei Eagle kennen gelernt haben. Diesen Workflow kann KiCad nicht oder nur in Teilen abbilden. Aus diesem Grund ist KiCad für W.S. (und andere) KEINE ALTERNATIVE. Deswegen hat W.S. (und andere) hier recht. Punkt Aber: W.S. irrt, wenn er SEINE ANFORDERUNGEN verallgemeinert. Weil für viele andere IST KICAD EINE ALTERNATIVE, da KiCad sehr wohl einen vernünftigem, wenn auch in Teilen etwas anderen Workflow anbietet. Punkt. Übrigens ist auch für mich KiCad eine Alternative. Wird Zeit, dass ein Mod den Thread hier zumacht...
2⁵ schrieb: > Oh je, hätte ich nur nichts geschrieben... > ...ähh..Quatsch. > Holm T. schrieb: >> Du kannst das drehen wie Du willst. Auch die Philosophie von KiCad ist >> berechtigt und mit Eagle ist es möglich Platinen zu erstellen. >> Beide sind miteinander verglichen einfach "anders". > [...] >> Warum darf KiCad nicht anders sein und warum wird erwartet das es sich in >> jeder Beziehung auf derselben Ebene zum Vergleich bewegen muß? > [...] >> W.S. hat nicht Recht. Die Art und Weise wie er seine Meinung vertritt >> ist falsch und er vertritt sie an der falschen Stelle auf die falsche >> Weise, genau deshalb ist sie falsch. > > Also: > > W.S. (und andere) suchen einen bestimmten Workflow, den sie bei Eagle > kennen gelernt haben. Diesen Workflow kann KiCad nicht oder nur in > Teilen abbilden. Aus diesem Grund ist KiCad für W.S. (und andere) KEINE > ALTERNATIVE. Deswegen hat W.S. (und andere) hier recht. Punkt Das hat er einmal gehabt ja. Nun lese ich mir aber seinen Sermon mindestens im 6. Thread durch, immer Ein- und das Selbe. Deshalb sind wir jetzt an dem Punkt an dem er so nicht mehr Recht hat, sondern nur noch nervt. Er taucht in jedem Thread zu KiCad auf und läßt seinen Käse in identischer Form ab. DAS IST ES WAS ICH FÜR FALSCH HALTE. Dazu kommt das er hochnäsig und anmaßend urteilt. > > Aber: W.S. irrt, wenn er SEINE ANFORDERUNGEN verallgemeinert. Weil für > viele andere IST KICAD EINE ALTERNATIVE, da KiCad sehr wohl einen > vernünftigem, wenn auch in Teilen etwas anderen Workflow anbietet. > Punkt. > > Übrigens ist auch für mich KiCad eine Alternative. Wird Zeit, dass ein > Mod den Thread hier zumacht... ..wir sind eh am Ende. Mich zu bekehren hat nicht funktioniert, jetzt ist die Luft irnkwie raus. Eigentlich war ich hier um Fragen von eventuellen Umsteigern zu beantworten (in so weit mir Antworten bekannt sind). Der Diskurs ging aber ausschließlich um Eagle Vorteile ..bis zum Tanker. Gruß, Holm
Holm T. schrieb: > entscheide ich wem gegenüber ich wie aggressiv werden möchte. Mit überzeugenden Argumenten hättest Du das nicht nötig. Das meiste was Du hier hinsichtlich Eagle verbreitest sind doch ziemliche Luftnummern, was bei Zeno schrieb: > Holm T. schrieb: > Eagle ist Closed Source.. > interessiert mich nicht. > > Jetzt haben wir es doch. Da ist jede weitere Diskussion völlig > überflüssig. auch nicht wirklich verwundert! Holm hat Null Ahnung von Eagle, äußert sich aber hier unter dem Titel "Erfahrungen mit KiCAD von Eagle-Wechslern"!
Zeno schrieb: > Du schießt hier gegen jeden der nur etwas Positives zu Eagle sagt, Da ich weder KiCad- noch Eagle-Nutzer bin, möchte ich mich nicht in diese Streitereien einmischen, sondern das Ganze mal von außen betrachten. In einem Thread, in dem es seinem Titels zufolge um "Erfahrungen mit KICAD von Eagle-Wechlern" (sic!) geht, haben Lobeshymnen auf und/oder Werbung für Eagle meines Erachtens nichts zu suchen. Es sind "Eagle-Wechsler" gefragt, also Leute, die früher einmal Eagle benutzt haben und mittlerweile -- warum auch immer -- zu KiCad gewechselt sind. Denen nun erzählen zu wollen, wie toll Eagle oder wie doof KiCad sei, erscheint mir ziemlich deplatziert. Jene, die KiCad nur ein paar Stunden "angeschaut" oder "ausprobiert" haben, haben IMHO auch keine Erfahrungen gemacht, die sie zu dem Thema beitragen könnten. Sie sind auch keine "Eagle-Wechsler", sondern tatsächlich wieder zu Eagle zurückgekehrt -- alles gut, sollen sie doch glücklich damit sein -- und daher in diesem Thread gar nicht gefragt. Ebenso off-topic erscheinen mir die ganzen Beleidigungen, Pöbeleien und persönlichen Angriffe auf Eagle-Wechsler, KiCad-Benutzer und -Entwickler. Möglicherweise trügt er mich, aber mein Eindruck ist, daß es da in einigen Fällen nur darum geht, KiCad-bezogene Threads zu (zer)stören. Auch sonst ist dieser Thread, und eigentlich auch das Forum hier, nicht der richtige Ort, um Kritik an KiCad oder Verbesserungsvorschläge vorzubringen. Dazu bietet das KiCad-Team extra eigene Mailinglisten und IRC-Channels an, die genau dafür vorgesehen sind. Wer dort einen Verbesserungsvorschlag in halbwegs zivilisierter Form und Forumlierung einbringen kann, ist dort sicherlich herzlich willkommen. Herzlichen Dank für Eure Aufmerksamkeit, und ansonsten wünsche ich viel Spaß und Erfolg mit dem EDA-CAD Eurer Wahl.
Lehrling schrieb: > Im Übrigen empfinde ich deine Beiträge > als arrogant, anmaßend und aufdringlich Dann solltest Du Deinen ersten Post noch einmal genau lesen. Hängt halt alles davon ab auf welcher Seite man steht.
Lehrling schrieb: > Was du hier an geistigen Extrakt zu bieten hast, ist wohl nicht zu > überbieten:-( Danke für das Kompliment auch wenn es wohl anders gemeint war. In jedem Fall zeigt es wessen "Geistes" Kind Du bist. Von einem Lehrling kann man wohl heutzutage nicht mehr erwarten :(
P. Manfelder schrieb: > Holm hat Null Ahnung von Eagle, äußert > sich aber hier unter dem Titel "Erfahrungen mit KiCAD von > Eagle-Wechslern"! Ja, wäre schön, wenn alle diejenigen die nicht zu den EAGLE->KiCad Wechslern zählen, wenigstens in diesem Thread mal schweigen könnten ;-)
:
Bearbeitet durch User
Holm T. schrieb: > 2⁵ schrieb: >> Deswegen hat W.S. (und andere) hier recht. Punkt > > Das hat er einmal gehabt ja. Nun lese ich mir aber seinen Sermon > mindestens im 6. Thread durch, immer Ein- und das Selbe. > Deshalb sind wir jetzt an dem Punkt an dem er so nicht mehr Recht hat, > sondern nur noch nervt. Er taucht in jedem Thread zu KiCad auf und läßt > seinen Käse in identischer Form ab. DAS IST ES WAS ICH FÜR FALSCH HALTE. > Dazu kommt das er hochnäsig und anmaßend urteilt. Und dann kommt noch hinzu, daß das gewünschte Feature Backward-Annotation zwar nicht in KiCad integriert ist, sich aber mit einfachen Skripten von KiCad-Benutzern wie diesem hier [1] abbilden lässt. Es geht also. Wenn das Feature also W.S. einziges Problem wäre, dann ist es längst gelöst. Abgesehen davon ist dieses Forum der flashce Ort für W.S. Kritik. Wenn er wirklich ein Interesse an KiCad hätte, wären die den Mailinglisten und die IRC-Channels des Projekts der richtige Ansprechpartner. Da würde er sich allerdings um ein Mindestmaß an zwischenmenschlichen Kommunikationsformen bemühen und eine sachlichere Begründung als "das bin ich halt so gewöhnt" finden müssen, um ernst genommen zu werden. [1] https://hasanyavuz.ozderya.net/?p=256
Was soll das rumgepoltere einiger hier? Wem Kicad zu komplex ist, der kann doch (weiter) ein anderes Programm nutzen. Zum Beispiel den einfach anzuwendenden grafischen Layout Editor. So wie Jemand dem Notepad reicht, nicht Word lernen muss und Jemand, dem Paint reicht, sich nicht in Catia einarbeiten muss. Für alle diese Leute sollte es doch keinen Grund geben über die leistungsfähigeren Programme zu motzen. Manches geht mit den einfachen Programmen einfacher, zumindest anders, manches geht nicht. Die Eaglezahler könnten Kicad dankbar sein, dass sie jetzt zumindest den Hindernishelfer bekommen haben. Oder glaubt irgendjemand hier den hätte es ohne P&S bei Kicad gegeben? Warum also das Gestänker? Niemand zwingt euch zu Kicad. Ist es für die Nichtmieter so schlimm mit einer alten Version ohne Zukunft zu arbeiten und zu sehen wie OS immer weiter fortzieht? Ist es die Panik der Mieter davor "euer" Programm abgeschaltet zu bekommen?
2⁵ schrieb: > W.S. (und andere) suchen einen bestimmten Workflow, den > sie bei Eagle kennen gelernt haben. Um das mal zu konkretisieren: Gemäß der Sprachkonvention von oben gibt es - "Symbole" (=Schaltplansymbole), - "Footprints" und - "Bauelemente" (die aus Symbol und Footprint bestehen). Für Schaltplaneditoren gibt es drei Möglichkeiten: 1. Der Schaltplan enthält immer komplette Bauteile . 2. Der Schaltplan enthält immer nur Symbole . 3. Der Nutzer kann von Fall zu Fall wählen, ob ein komplettes Bauteil oder nur ein Symbol eingefügt werden soll. Eagle hat in der Vergangenheit, soweit ich weiss, Variante 1 implementiert -- aber wie ich aus der Diskussion gelernt habe, ist das neuerdings in Richtung Varianten 3 erweitert worden. KiCAD gehört - wie übrigens auch gEDA - zu der Fraktion, die ursprünglich Variante 2 gewählt hat (was ich persönlich besser finde als Variante 1, aber dennoch nicht optimal). Wie ich aus der Diskussion gelernt habe, wurden die neuesten Versionen von KiCAD jedoch in Richtung Variante 3 erweitert. (Mein altes KiCAD von 2014 kann es noch nicht.) Der hier diskutierte Unterschied sollte als bald vollständig der Vergangenheit angehören. > Diesen Workflow kann KiCad nicht oder nur in Teilen abbilden. Ja - zumindest war das bisher so. > Aus diesem Grund ist KiCad für W.S. (und andere) KEINE > ALTERNATIVE. Deswegen hat W.S. (und andere) hier recht. > Punkt Richtig. (Zumindest hatte er bisher Recht.) > Aber: W.S. irrt, wenn er SEINE ANFORDERUNGEN verallgemeinert. > Weil für viele andere IST KICAD EINE ALTERNATIVE, da KiCad > sehr wohl einen vernünftigem, wenn auch in Teilen etwas > anderen Workflow anbietet. Punkt. Auch wenn ich das gelegentlich sehr oberlehrerhafte Auftreten von W.S. sehr... anstrengend finde, lege ich Wert auf folgende Feststellung: Wir befinden uns in einem Diskussionsforum. Es sollte jedermann gestattet sein, auch einen abweichenden (Minderheiten-)Standpunkt nachhaltig zu vertreten. Es ist unter keinen Umständen akzeptabel, dass jemand aufgrund seiner dauerhaft abweichenden Meinung persönlich diffamiert wird. Das geht gar nicht.
Sheeva P. schrieb: > Auch sonst ist dieser Thread, und eigentlich auch das Forum hier, nicht > der richtige Ort, um Kritik an KiCad oder Verbesserungsvorschläge > vorzubringen. Dem schließe ich mich nicht ganz an. Als "potentieller Eagle-zu-Kicad-Wechsler" finde ich es schon angemessen, das "Anders-sein" von Kicad (sehr) kritisch zu hinterfragen; die Reaktion (zB "braucht man nicht") lässt für mich gute Rückschlüsse zu. Wenn für mich noch nciht mal klar ist, ob ich wechseln will, hab ich auch ungefähr ziemlich genau null Interesse, mich an eine Kicad-Mailingliste zu wenden. Insofern war (und ist!) der Thread für mich sehr lehrreich, und er darf gerne weitergeführt werden. Das Niveau ist allerdings tlw wirklich unter jeder Handcreme, aber das sind nur ein paar Wenige, die muss man halt ausblenden. (W.S. gehört für mich aber nicht dazu) Also bitte entspannen und weitermachen ;-)
Hallo Sheeva Plug. Sheeva P. schrieb: > Und dann kommt noch hinzu, daß das gewünschte Feature > Backward-Annotation zwar nicht in KiCad integriert ist, sich aber mit > einfachen Skripten von KiCad-Benutzern wie diesem hier [1] abbilden > lässt. Es geht also. Wenn das Feature also W.S. einziges Problem wäre, > dann ist es längst gelöst. > > [1] https://hasanyavuz.ozderya.net/?p=256 Danke für den Link. Ich habe ihn mal eingepflegt. Siehe: https://www.mikrocontroller.net/articles/KiCad#Problem:_Fehlende_Backannotationsm.C3.B6glichkeit_in_KiCad > Abgesehen davon ist dieses Forum der flashce Ort für W.S. Kritik. Hier ist schon der richtige Ort um Probleme zu nennen. Aber halt von Leuten, die schon gut Erfahrung mit KiCad gesammelt haben, nachdem sie gewechselt sind. Und W.S. scheint nicht zu diesen zu gehören, weil er sich seit Jahren wie eine kaputte Schallplatte wiederholt, über Probleme, zu denen man ihm schon oft gesagt hat, wie sie anzugehen sind. ,O) > Wenn > er wirklich ein Interesse an KiCad hätte, wären die den Mailinglisten > und die IRC-Channels des Projekts der richtige Ansprechpartner. Eben. > Da würde > er sich allerdings um ein Mindestmaß an zwischenmenschlichen > Kommunikationsformen bemühen und eine sachlichere Begründung als "das > bin ich halt so gewöhnt" finden müssen, um ernst genommen zu werden. Ich denke schon, daß "das bin ich halt so gewöhnt" ein wichtiges Argument wird, wenn man älter wird. Geht mir ja auch so. Es fällt immer schwerer, neues in Form eines OODA-Loops zu erlernen, und das alte passt nicht mehr und bringt einen ins Stolpern (Was nebenbei gesagt eine grundsätzliche Kritik am OODA-Cycle selber ist). Allerdings, für Hobby hat es bei mir gereicht. Ich bin ja so anno 2009 auch privat von Eagle auf KiCad umgestiegen. Und wenn ich das kann, kann das jeder. Es ist also durchaus machbar. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Hallo Michael R. Michael R. schrieb: > Wenn für mich noch nciht mal klar ist, ob ich wechseln will, Ich denke, dass ist auch nur halb sinnvoll, lange darüber Nachzudenken. 1) Ab einem gewissen Alter wird es eben sehr schwer, sich umzustellen, und es dauert eine Ewigkeit, bis man sich so eingewöhnt hat, das alles glatt funktioniert. Ich kenne das, ich bin auch ein alter Mann. Aus dieser Position heraus ist es sinnvoll, den Wechsel möglichst lange hinaus zu zögern. 2) Gerade bei open source kostet aber die Installation des fraglichen Programmes nur etwas Zeit und Plattenplatz. Es spricht also nichts dagegen, trozdem das Programm einmal in echt auszuprobieren. D.h. Du kannst stressfrei damit üben, und wenn Du irgendwann einmal wechseln müsstest, aus welchen Gründen auch immer, musst du nicht in Panik verfallen. > hab ich > auch ungefähr ziemlich genau null Interesse, mich an eine > Kicad-Mailingliste zu wenden. Das ist auch erst sinnvoll, wenn Du mit dem Lesen der Tutorials und Manuals alleine nicht weiter kommst. Allerdings muss Du in den Mailinglisten nicht zwangsweise Fragen. Lesen und Suchfunktionen benutzen hilft Dir in 2/3 aller Fälle auch weiter, weil sehr wahrscheinlich ist, dass das Problem schon mal behandelt wurde. KiCad ist gut dokumentiert, auch auf deutsch: http://kicad-pcb.org/help/documentation/ Eine Seite, in der Diskussionspunkte über KiCad hier im Forum gesammelt und verlinkt sind, findet sich hier: https://www.mikrocontroller.net/articles/KiCad > Das Niveau ist allerdings tlw wirklich unter jeder Handcreme, Besser als wenn es zu hoch ist. Keep it simple, stupid. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Ich kenne das, ich bin auch ein alter Mann. Woraus schliesst du dass ich ein alter Mann bin? ;-)
Hallo P. Manfelder. P. Manfelder schrieb: > Nun sollte doch > auch Dir klar sein daß sich bei dieser Ausgangslage ein kleiner leichter > Kutter wie KiCad (meist mit ein paar Leichtmatrosen an Bord) nur schwer > mit einem großen Tanker wie Eagle vergleichen kann. Ein merkwürdiger Vergleich. Vor allem wenn man die Kritiker dagegen hält, die Behaupten, KiCad wäre viel zu komplex für Anfänger. ;O) Was Blödsinn ist, weil, und das gilt für jedes Layoutprogramm, auch Eagle, die Komplexität weniger in der Layoutsoftware als in der Schaltungstechnik, der Platinentechnik und ihren vielfältigen Möglichkeiten und Unmöglichkeiten liegt. > Das geht maximal > über den Preis- doch selbst Eagle dient sich ja immer noch bis zu einer > gewissen Boardgröße und 2 Lagen als vollwertige Freeware an. Ja. eine Grenze, die zu knapp für viele Hobbyprojekte ist. > Für KiCad ist also noch viel Luft nach oben und es dürfte schwer werden, gegenüber kostenpflichtiger Software nachhaltig aufzuholen. Hinsichtlich Funktionsumfang, vor allem aber im Handling und Bedienkomfort. Das letzte Eagle, das ich selber noch benutzt habe, war ein Eagle 6. Und einem alten Eagle 6 ist ein aktuelles KiCad weit voraus. Ich persönlich fand KiCad 2009 auf Anhieb handlicher und komfortabler als Eagle, und den Funktionsumfang konnte man sich selber durch geschicktes Ausnutzen der vorhandenen Möglichkeiten plus editieren der Dateien deutlich erweitern. Mittlerweile sind viele Funktionen dazugekommen. Es wurde das implementiert, was stark nachgefragt wurde und wofür Arbeitskraft da war, sprich es hat sich jemand hingesetzt und den Kram selber geschrieben, wenn es ihn pressierte und er die entsprechenden Fähigkeiten hat. Mittlerweile ist das durch die Skripting Möglichkeit erweitert. In Open source entsteht halt vieles dadurch, dass sich Leute über vorhandene, durchaus kommerzielle, Programme ärgern, und es versuchen, es selber besser zu machen. Eagle 6 war das letzte Eagle, das über das Debian nonfree Repository zu installieren war. Für aktuelle Debians gibt es leider kein Eagle mehr im Repository. Auch das ist letztlich ein strategisches Argument gegen Eagle. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Michael. Michael R. schrieb: >> Ich kenne das, ich bin auch ein alter Mann. > > Woraus schliesst du dass ich ein alter Mann bin? ;-) Das habe ich nicht behauptet. Ich behaupte lediglich, das es mit zunehmendem alter schwer wird sich Umzustellen und habe mich selber als Beispiel genommen. ;O) Übrigens.....als ich so richtig jung war, hätte ich mir so was nie lange Überlegt, sondern die Programme, wenn erhältlich, ausprobiert. ;O) Das Du aber solange Überlegst, ist so gesehen ein starkes Indiz für Alter. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
P. Manfelder schrieb: > Holm T. schrieb: >> entscheide ich wem gegenüber ich wie aggressiv werden möchte. > > Mit überzeugenden Argumenten hättest Du das nicht nötig. Das meiste was > Du hier hinsichtlich Eagle verbreitest sind doch ziemliche Luftnummern, > was bei ..Butter bei die Fische: Was habe ich zu Eagle geäußert? [..] > > auch nicht wirklich verwundert! Holm hat Null Ahnung von Eagle, äußert > sich aber hier unter dem Titel "Erfahrungen mit KiCAD von > Eagle-Wechslern"! Ich habe mehrmals geschrieben warum ich hier bin, schön das das nun auch Dir hellen Leuchte aufgeht. Gruß, Holm
Sheeva P. schrieb: > Holm T. schrieb: >> 2⁵ schrieb: >>> Deswegen hat W.S. (und andere) hier recht. Punkt >> >> Das hat er einmal gehabt ja. Nun lese ich mir aber seinen Sermon >> mindestens im 6. Thread durch, immer Ein- und das Selbe. >> Deshalb sind wir jetzt an dem Punkt an dem er so nicht mehr Recht hat, >> sondern nur noch nervt. Er taucht in jedem Thread zu KiCad auf und läßt >> seinen Käse in identischer Form ab. DAS IST ES WAS ICH FÜR FALSCH HALTE. >> Dazu kommt das er hochnäsig und anmaßend urteilt. > > Und dann kommt noch hinzu, daß das gewünschte Feature > Backward-Annotation zwar nicht in KiCad integriert ist, sich aber mit > einfachen Skripten von KiCad-Benutzern wie diesem hier [1] abbilden > lässt. Es geht also. Wenn das Feature also W.S. einziges Problem wäre, > dann ist es längst gelöst. > > Abgesehen davon ist dieses Forum der flashce Ort für W.S. Kritik. Wenn > er wirklich ein Interesse an KiCad hätte, wären die den Mailinglisten > und die IRC-Channels des Projekts der richtige Ansprechpartner. Da würde > er sich allerdings um ein Mindestmaß an zwischenmenschlichen > Kommunikationsformen bemühen und eine sachlichere Begründung als "das > bin ich halt so gewöhnt" finden müssen, um ernst genommen zu werden. > > [1] https://hasanyavuz.ozderya.net/?p=256 Danke! Gruß, Holm
Possetitjel schrieb: [..] > > Auch wenn ich das gelegentlich sehr oberlehrerhafte Auftreten > von W.S. sehr... anstrengend finde, lege ich Wert auf folgende > Feststellung: Wir befinden uns in einem Diskussionsforum. Es > sollte jedermann gestattet sein, auch einen abweichenden > (Minderheiten-)Standpunkt nachhaltig zu vertreten. Es ist > unter keinen Umständen akzeptabel, dass jemand aufgrund seiner > dauerhaft abweichenden Meinung persönlich diffamiert wird. > Das geht gar nicht. ..doch, das geht! Wenn Derjenige es nicht lassen kann imemr wieder mit den selben Argumenten jeden möglichen KiCad-Thread zu verpesten, dann geht das. Gruß, Holm
Bernd W. schrieb: > Ich bin immer noch der Meinung, dass das eine monolitische Darstellung > von Symbolen dicht am Footprint für sehr kleine Schaltungen, Bausätze, > Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung > ist. > Mit zunehmender Komplexität der Schaltung kippt das ganze natürlich, und > eine aufgelöste Darstellung von Symbolen wird dann sinnvoller. Und wenn du nun deinen Gedanken bis zum Ende denkst, dann mußt du eine Grenze einziehen zwischen einfachen Schaltungen und komplexen Schaltungen - und zwar mit unterschiedlichen Symbolen. Was soll das? Nun, du hast dafür weiter oben ja schon genug Haue gekriegt. Also eines ist klar: Schematics sollen den Sinn der real existierenden Schaltung auf logischer Ebene darstellen. Für die Darstellung der physischen Anordnung dienen die Betückungspläne. Mit anderen Worten: Was du dargelegt hast, ist wirklich ziemlich zurückstehend. Nenne Andere deswegen nicht arrogant, sie haben Recht. Possetitjel schrieb: > Ich kritisiere, dass man, um eine bestimmte Darstellung > eines Netzes zu aktivieren, ein bestimmtes "Bauteil" in > den "Schaltplan" (Bedeutung 3) einfügen muss! Ähem.. renne lieber keine offenen Scheunentore ein. Also im Klartext: vom Eagle aus muß man sowas garnicht. Um z.B. ein Netz im Schematic zu einem +5V zu machen, kann man: a) das Netz anklicken und ihm den Namen +5V geben. b) an das Netz so ein +5V Symbol anfügen. c) einen Schaltkreis einfügen, wo +5V als Versorgungsquelle herauskommt. Aber: damit ist zwar das, was für die LP-Entwicklung nötig ist, erledigt, nicht jedoch das, was wir Menschen brauchen. Wir wollen es sehen können und so brauchen wir etwas, das uns im Schematic zeigt, was wir wissen wollen. Und das auch auf schwarzweiß. Nun kann man es auf verschiedene Weise halten, wiederum: a) man plaziert an einem Stück des betreffenden Netzes ein Label. In der Größe, wie man das gern hätte. b) entspricht obigem b), denn das kann man ja bereits sehen. c) das kann man bereits an dem betreffenden Schaltkreis sehen. All diese Optionen stehen einem offen, man kann sich auswählen, welche man benutzt. Und da solche Rail-Machen-Bauteile ohne Footprint ja keinerlei Extrawurst brauchen, sondern so wie alles andere gehandhabt werden können, gilt das mit den Optionen prinzipiell für alle Netze. Man kann das gleiche Verfahren mit so einem footprintlosen BE mit allen Netzen machen - sofern man sowas überhaupt tun will. Nochwas: Ich hab's ja schon dem Bernd gesagt: Schematics sollen die Schaltung auf logischer Ebene darstellen. In der Praxis sollen Schematics nicht nur am PC im Fenster angeschaut werden, sondern ihr Daseinszweck außerhalb des EDA-Flusses besteht darin, gedruckt zu werden. Zum Hinlegen auf den Schreibtisch/Werktisch, zum Einheften in den Leitz-Ordner, zum Archivieren, eben zu allen Zwecken, wo bedrucktes Papier noch immer die sinnvollste Sache ist. Da kann man eine Leitung nicht eben mal anklicken. Stattdessen will man gut erkennbare Symbole haben, die einem sofort ins Auge fallen. Dem kommen solche footprintlosen Bauteile sehr entgegen. Man kann sie besser auf den 1. Blick erkennen, als ein Label-Text an einer gedruckten Linie. Aber - wie gesagt - deine Kritik trifft ins Leere, denn man MUSS! überhaupt nicht. Man kann - oder man macht es eben anders. Soviel Flexibilität hat man bei Eagle. Fragt sich nur, wieviel Flexibilität in solcher Sache man bei Kicad tatsächlich hat. Ich lese von dieser Seite viel zu oft "da schreibt man sich ein kleines Python-Skript..". Und es ist das ganze ein bissel wie mit orthogonalen Befehlssätzen bei Prozessor-Architekturen: Je weniger Extrawürste man braten muß, desto besser für alle Seiten: sowohl für den Architekten als auch für den Nutzer, denn dieser muß sich eine Extrawurst weniger merken. W.S.
Bernd W. schrieb: [..] > Allerdings, für Hobby hat es bei mir gereicht. Ich bin ja so anno 2009 > auch privat von Eagle auf KiCad umgestiegen. Und wenn ich das kann, kann > das jeder. Es ist also durchaus machbar. > > Mit freundlichem Gruß: Bernd Wiebus alias dl1eic > http://www.l02.de ...Ergänzung: man muß es wollen. Es ist sinnlos wenn man von vornherein weiß das Eagle viel besser ist KiCad anzufassen und danach zu sagen "ich habs doch gewußt." Ist bei fast Jedem Problem so (Atmel vs. PIC, Basic vs. Assembler, BMW vs. Mercedes..) Gruß, Holm
Bernd W. schrieb: [..] > > Besser als wenn es zu hoch ist. Keep it simple, stupid. > Hmm... das weiß ich besser: "Keep it Small and Simple" ..von stupid muß man a nicht reden. Gruß, Holm
Sheeva P. schrieb: > Und dann kommt noch hinzu, daß das gewünschte Feature > Backward-Annotation zwar nicht in KiCad integriert ist, > sich aber mit einfachen Skripten von KiCad-Benutzern > wie diesem hier [1] abbilden lässt. Naja, für mich stellt sich ernsthaft die Frage, ob alle Beteiligten unter dem "gewünschten Feature Backward- Annotation" dasselbe verstehen. Wenn ich W.S. richtig verstehe, dann sieht er es als spezifische Stärke von Eagle an, dass es dort EINE Daten- struktur gibt, die VERBINDLICHE Auskunft über BAUTEILE (=Zusammenfassung von Symbol, Footprint und ggf. weiteren Attributen) geben kann - das ist nämlich der Schaltplan. (Ich stimme mit W.S. in dem Punkt überein, dass eine zentrale Datenstruktur, die mit BAUTEILEN hantiert, eine gute Design-Entscheidung ist, vertrete aber die abweichende Meinung, dass das nicht der SCHALTPLAN, sondern die von mir so getaufte Super-Stückliste sein sollte.) Wenn man EINE zentrale Datenstruktur für BAUTEILE zugrunde legt, ergibt sich die Backward-Annotation fast selbsttätig, weil man dann halt "nur noch" im GUI verdrahten muss, dass die entsprechenden Attribute auch aus dem Layout-Fenster heraus geändert werden können. KiCAD verfolgt aber - ähnlich wie gEDA - den Grundansatz, dass Schaltplan und Layout zwei unabhängige Datenstrukturen sind, die jeweils eine andere Teilmenge von Informationen über die bearbeitete Baugruppe widerspiegeln. Dieser Ansatz hat sowohl für die Software-Entwickler als auch für die Benutzer den großen Vorteil, dass Schaltplan- editor und Layouteditor weitgehend unabhängig benutzt und weiterentwickelt werden können. Die Arbeit damit ist nicht ganz so komfortabel, aber das ist der Preis für die größere Unabhängigkeit der Softwarekomponenten. Ich halte es (bis jetzt immer noch) für einen faulen Kompromiss, zwar einerseits an getrennten Datenstrukturen festzuhalten, andererseits aber einen Mechanismus zu fordern, mit dem "die Daten konsistent gehalten" werden können. Es ist meiner Meinung nach völlig unsinnig, die DATEN- STRUKTUREN weiterhin getrennt zu halten, die PROGRAMME aber miteinander zu koppeln. Sinnvoll wäre meiner Meinung nach genau der entgegengesetze Weg: Die Datenstrukturen zu vereinigen (nämlich in einer Projektdatenbank, die die "Super-Stückliste" enthält), aber die Programme weiterhin zu trennen. Das hätte nämlich den Vorteil, dass es mehrere unterschied- liche Schaltplaneditoren und mehrere unterschiedliche Layout- editoren geben könnte, die alle in dem Sinn kompatibel sind, dass sie mit derselben Super-Stücklisten-Datenbank zusammen- arbeiten könnnen. > Abgesehen davon ist dieses Forum der flashce Ort für W.S. > Kritik. Überhaupt nicht. > [...] und eine sachlichere Begründung als "das bin ich > halt so gewöhnt" finden müssen, um ernst genommen zu > werden. Auch nicht.
W.S. schrieb: [..] > Soviel Flexibilität hat man bei Eagle. Fragt sich nur, wieviel > Flexibilität in solcher Sache man bei Kicad tatsächlich hat. Soso, fragt sich das? Du weißt es nicht? Du weißt doch sonst Alles besser? >Ich lese > von dieser Seite viel zu oft "da schreibt man sich ein kleines > Python-Skript..". Jojo, ULP ist da nicht sonderlich angesagt... > > Und es ist das ganze ein bissel wie mit orthogonalen Befehlssätzen bei > Prozessor-Architekturen: Je weniger Extrawürste man braten muß, desto > besser für alle Seiten: sowohl für den Architekten als auch für den > Nutzer, denn dieser muß sich eine Extrawurst weniger merken. > > W.S. Du gehst mir unendlich auf die Eier. Du weißt nicht im Ansatz was KiCad kann, aber Du weißt es besser! Gruß, Holm
W.S. schrieb: > Bernd W. schrieb: >> Ich bin immer noch der Meinung, dass das eine monolitische >> Darstellung von Symbolen dicht am Footprint für sehr kleine >> Schaltungen, Bausätze, Schnittstellen- und Anpassungskarten >> und dergleichen die bessere Lösung ist. >> Mit zunehmender Komplexität der Schaltung kippt das ganze >> natürlich, und eine aufgelöste Darstellung von Symbolen >> wird dann sinnvoller. > > Und wenn du nun deinen Gedanken bis zum Ende denkst, dann > mußt du eine Grenze einziehen zwischen einfachen Schaltungen > und komplexen Schaltungen - und zwar mit unterschiedlichen > Symbolen. > Was soll das? Gegenfrage: Was wäre daran schlimm? Das jeder die Grenze etwas anders zieht, spielt doch keine große Rolle. Jede vernünftige Software sollte doch unter- schiedliche Vorlieben und Arbeitsweisen unterstützen. > Schematics sollen den Sinn der real existierenden Schaltung > auf logischer Ebene darstellen. Sicher. Ich sehe das tendenziell auch so wie Du -- aber müssen wir daraus einen "antagonistischen Widerspruch" zu Bernds Meinung konstruieren? > Possetitjel schrieb: >> Ich kritisiere, dass man, um eine bestimmte Darstellung >> eines Netzes zu aktivieren, ein bestimmtes "Bauteil" in >> den "Schaltplan" (Bedeutung 3) einfügen muss! > > Ähem.. renne lieber keine offenen Scheunentore ein. Also > im Klartext: vom Eagle aus muß man sowas garnicht. Um so besser. Ich will und muss überhaupt nix schlechtreden, was Eagle kann. Ich will nur die Gemeinsamkeiten und Unterschiede zwischen Eagle und KiCAD möglichst genau verstehen. > Aber: damit ist zwar das, was für die LP-Entwicklung > nötig ist, erledigt, nicht jedoch das, was wir Menschen > brauchen. Wir wollen es sehen können und so brauchen wir > etwas, das uns im Schematic zeigt, was wir wissen wollen. > Und das auch auf schwarzweiß. Ja - das ist richtig, betrifft aber einen subtil anderen Punkt: Der "Schaltplan", den man im Schaltplaneditor bearbeitet, ist nicht absolut deckungsgleich mit dem "Schaltplan", den man auf Papier ausdrucken kann -- genau aus dem Grund, den Du selbst angibst: Man kann einen Strich auf dem Papier nicht anklicken. > Nochwas: Ich hab's ja schon dem Bernd gesagt: Schematics > sollen die Schaltung auf logischer Ebene darstellen. In > der Praxis sollen Schematics nicht nur am PC im Fenster > angeschaut werden, sondern ihr Daseinszweck außerhalb des > EDA-Flusses besteht darin, gedruckt zu werden. > > Zum Hinlegen auf den Schreibtisch/Werktisch, zum Einheften > in den Leitz-Ordner, zum Archivieren, eben zu allen Zwecken, > wo bedrucktes Papier noch immer die sinnvollste Sache ist. > Da kann man eine Leitung nicht eben mal anklicken. > Stattdessen will man gut erkennbare Symbole haben, die einem > sofort ins Auge fallen. > > Dem kommen solche footprintlosen Bauteile sehr entgegen. > Man kann sie besser auf den 1. Blick erkennen, als ein > Label-Text an einer gedruckten Linie. Mag sein -- hier zeigt sich aber, wie kompliziert die Lage ist: Der Schaltplan, den man im Fenster "Schematic Editor" erzeugt, hat (mindestens) eine Doppelfunktion: 1. er ist Datenquelle für Informationen, die anschließend im Computer maschinell weiterverarbeitet werden sollen, 2. er ist Grundlage für ein zu erzeugenden Papierdokument. Beide Zwecke sind verwandt, aber nicht identisch. > Soviel Flexibilität hat man bei Eagle. Fragt sich nur, > wieviel Flexibilität in solcher Sache man bei Kicad > tatsächlich hat. Ich lese von dieser Seite viel zu oft > "da schreibt man sich ein kleines Python-Skript..". Das ist auch Flexibilität, und zwar echte Flexibilität, die manche Nutzer haben möchten. Ich bin nur in sehr engen Grenzen ein Freund von WYSIWYG- Software. Zu groß ist mir die Gefahr, dass das ganze "...erst klicken Sie hier, dann klicken Sie da, dann müssen Sie dort klicken..." mir den Blick dafür vernebelt, was technisch wirklich passiert. Ich möchte daraus aber ganz ausdrücklich kein "entweder - oder" konstruieren, sondern ein "sowohl - als auch": Es ist mir sehr wichtig, dass jede Software-Komponente vernünftige Exportschnittstellen hat und sich ggf. per Script fernsteuern lässt, aber das steht NICHT im Widerspruch dazu, dass sich möglichst der gesamte Arbeitsablauf auch mit einem GUI bewältigen lassen muss. Da ist kein gegenseitiger Ausschluss, es ist beides notwendig! Es ist also kein ENTWURFSMANGEL, dass irgendwo script- gesteuerte Bearbeitung möglich ist -- es ist allenfalls ein Mangel im PROJEKTFORTSCHRITT, dass es dafür noch kein GUI gibt!
Hallo W.S. W.S. schrieb: >> Ich bin immer noch der Meinung, dass das eine monolitische Darstellung >> von Symbolen dicht am Footprint für sehr kleine Schaltungen, Bausätze, >> Schnittstellen- und Anpassungskarten und dergleichen die bessere Lösung >> ist. >> Mit zunehmender Komplexität der Schaltung kippt das ganze natürlich, und >> eine aufgelöste Darstellung von Symbolen wird dann sinnvoller. > > Und wenn du nun deinen Gedanken bis zum Ende denkst, dann mußt du eine > Grenze einziehen zwischen einfachen Schaltungen und komplexen > Schaltungen - und zwar mit unterschiedlichen Symbolen. > Was soll das? Achselzuck Ich sehe da jetzt irgendwie kein Problem. Im Anhang ist als TL084_Monolitisch.png, TL084_Aufgeloest.png und TL084_Monolitisch_RevB.png jeweils ein Beispiel für ein und denselben TL084. Wenn der Schaltplan locker auf DIN A4 oder Din A5 passt (also ohne dass das Blatt voll ist), würde ich die monolitische Darstellung wählen. Für alles, was größer ist, oder die Verwendung des TL084 über mehrere hierarchische Seiten streut, die aufgelöste Darstellung. > Nun, du hast dafür weiter oben ja schon genug Haue gekriegt. Hab ich nix von gemerkt. ;O) > Also eines ist klar: Schematics sollen den Sinn der real existierenden > Schaltung auf logischer Ebene darstellen. Für die Darstellung der > physischen Anordnung dienen die Betückungspläne. Soviel zur Theorie. Aber praktisch ist es halt doch, wenn man gelegentlich beides mischen kann. Sei mal ein wenig pragmatischer. ;O) > Mit anderen Worten: Was > du dargelegt hast, ist wirklich ziemlich zurückstehend. Aber eben praktisch. > Nenne Andere deswegen nicht arrogant, sie haben Recht. Doch. Weil sie ignorieren, dass es nicht immer und überall angebracht ist, der Theorie wie einer Ideologie zu folgen. ;O) So etwas könnte man auch "Verhältnissmäßigkeit der Mittel" nennen, wen Du es theoretisch magst. Viele Hersteller kleinerer Boards oder auch von Bausätzen haben kein Problem damit, mal das eine und mal das andere zu wählen, je nachdem wie es passt. > Nochwas: Ich hab's ja schon dem Bernd gesagt: Schematics sollen die > Schaltung auf logischer Ebene darstellen. In der Praxis sollen > Schematics nicht nur am PC im Fenster angeschaut werden, sondern ihr > Daseinszweck außerhalb des EDA-Flusses besteht darin, gedruckt zu > werden. > > Zum Hinlegen auf den Schreibtisch/Werktisch, zum Einheften in den > Leitz-Ordner, zum Archivieren, eben zu allen Zwecken, wo bedrucktes > Papier noch immer die sinnvollste Sache ist. Da kann man eine Leitung > nicht eben mal anklicken. Stattdessen will man gut erkennbare Symbole > haben, die einem sofort ins Auge fallen. Oder wenn man auf einer Leiter steht, möchte man das Schaltplanblatt am liebsten mit einer Reiszwecke an die Wand heften oder mit einem Klebestreifen an die Konstruktion. Mit einem Netbook möchte ich da nicht auch noch hantieren müssen. Und ich will auf Anhieb wissen, wo ich messen muss. Auch wenn ich das Symbol nur so eben aus den Augenwinkeln sehen kann. Über die funktion habe ich mir vorher unten neben der Leiter schon Gedanken gemacht (und muss das eventuell wiederholen) > > Dem kommen solche footprintlosen Bauteile sehr entgegen. Man kann sie > besser auf den 1. Blick erkennen, als ein Label-Text an einer gedruckten > Linie. Aber - wie gesagt - deine Kritik trifft ins Leere, denn man MUSS! > überhaupt nicht. Man kann - oder man macht es eben anders. > Soviel Flexibilität hat man bei Eagle. Was auch ein allgemeines Problem ist, dass nicht eine bestimmte Software alleine betrifft. Alle Schaltplan- und Layout Programme die ich direkt kennengelernt habe, liessen dieses zu. Das ist also weder ein Alleinstellungsmerkmal von Eagle noch von KiCad. Keine Automarke würde für sich beanspruchen, dass sie runde Räder als Alleinstellungsmerkmal hätten. ;O) > Fragt sich nur, wieviel > Flexibilität in solcher Sache man bei Kicad tatsächlich hat. Ich lese > von dieser Seite viel zu oft "da schreibt man sich ein kleines > Python-Skript..". Nun, Eagle kennt ja auch Skripte und ULPs. ;O) Deine oben angeführtes Beispiel geht aber ganz ohne Skript in KiCad. Einfach indem man sich die Symbole und Footprints passend kombiniert und anpasst, und sich auch was neues macht, wenn man meint, es besser passend machen zu müssen. Dein Einwurf zeigt auch hier, dass Du dich noch nie ernsthaft damit auseinandergesetzt hast. Klar, willst du nicht, Du kriegst ja schon beim Gedanken daran eine Krise. Aber dann erzähle doch bitte nicht so einen Mist herum. > Und es ist das ganze ein bissel wie mit orthogonalen Befehlssätzen bei > Prozessor-Architekturen: Je weniger Extrawürste man braten muß, desto > besser für alle Seiten: sowohl für den Architekten als auch für den > Nutzer, denn dieser muß sich eine Extrawurst weniger merken. Solange sich nicht das Problem der Extrawurst aus den externen Anforderungen stellt. Dann hat man besser eine Lösung, in der Extrawürste unkompliziert zu behandeln sind. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Michael R. schrieb: > Sheeva P. schrieb: >> Auch sonst ist dieser Thread, und eigentlich auch das Forum hier, nicht >> der richtige Ort, um Kritik an KiCad oder Verbesserungsvorschläge >> vorzubringen. > > Dem schließe ich mich nicht ganz an. Als "potentieller > Eagle-zu-Kicad-Wechsler" finde ich es schon angemessen, das > "Anders-sein" von Kicad (sehr) kritisch zu hinterfragen; Das kann gerne gemacht werden, aber nicht in einem Thread mit dem Thema, welches der TO vorgegeben hat. Und schon gar nicht, wenn das Geäußerte sowie die Aggressivität und Penetranz, mit dem es geäußert wird, an einem bloßen "Hinterfragen" dann doch meilenweit vorbeigeht. > die Reaktion (zB "braucht man nicht") lässt für mich gute Rückschlüsse > zu. Tatsächlich? Wenn Du die etwas unbeherrschte Reaktion eines zuvor mehrfach provozierten Teilnehmers in diesem Thread heranziehst, um Rückschlüsse auf die in Rede stehende Software daraus zu ziehen, dann, entschuldige bitte, ist OpenSource-Software vermutlich nicht das Richtige für Dich -- YMMV. > Wenn für mich noch nciht mal klar ist, ob ich wechseln will, hab ich > auch ungefähr ziemlich genau null Interesse, mich an eine > Kicad-Mailingliste zu wenden. Dieser Hinweis war ja auch an jene gerichtet, die ihre "Kritik" nicht in den Kommunikationskanälen des Projekts, sondern nur hier vortragen -- und das, wie gesagt, mit einer Aggressivität, Penetranz und Arroganz, die über jede sachliche Kritik deutlich hinaus geht. Und auch für Dich wäre dieser Thread sicherlich bedeutend informativer und hilfreicher gewesen, wenn es darin keine Pöbeleien und persönlichen Angriffe gegeben hätte, sondern nur über das vom TO gewählte Thema diskutiert worden wäre. Es sei denn, Du meintest Deine Aussage mit den "Rückschlüssen" tatsächlich ernst. ;-)
Nachtrag: Bernd W. schrieb: > Ich sehe da jetzt irgendwie kein Problem. > Im Anhang ist als TL084_Monolitisch.png, TL084_Aufgeloest.png und > TL084_Monolitisch_RevB.png jeweils ein Beispiel für ein und denselben > TL084. Und nun der vergessene Anhang. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
2⁵ schrieb: > Robin schrieb: >> Ich verstehe nicht, was das Problem von W.S. ist? >> Alles was er da anspricht können doch Eagle und KiCad, oder etwa nicht? > > Nein, W.S. hat Recht. KiCad kann halt einfach nicht alles, was Eagle > kann. Punkt. Das Problem ist nur, dass man trotzdem (mit ein wenig > Flexibilität im Hirn) mit KiCad brauchbar Platinen entwickeln kann. > Punkt. Ähem... nein, ich selber habe damit gar keine Probleme. Ich hab mir lediglich die Zeit genommen, um Possetitjel die Sache mit den Bauteilen, den Footprints und den Symbolen im Detail zu erklären. Das ist alles. Und es ist eher KEIN Problem, sondern eine Erleichterung, daß man mit Kicad inzwischen brauchbare Platinen entwickeln kann. Insbesondere für Bastler, die an die mechanischen oder logischen Grenzen der jeweiligen Demoversionen anstoßen. Bei Kommerziellen habe ich jedoch etwas weniger Verständnis für das Bejammern von Demoversionen. Für den Broterwerb sollte man sich eine EDA in Vollversion leisten können. Da sollte auch das Geld für den Zweit- oder Dritt-PC nicht zu knapp sein, sonst steht es mit der Firma rundweg nicht wirklich gut. Das Problem oder besser gesagt, das große Ärgernis ist, daß man beim Entwickeln von Kicad es verabsäumt hat, sich zuvor aktuelle Systeme genauer anzusehen, um dort zu begreifen, was für ausgereifte Funktionalität dahinter steckt. Das Begreifen dessen, was man an Grund-Entwurf für eine ausbaufähige Funktionalität benötigt, ist das Wesentliche. Man hätte in Kenntnis und mit Berücksichtigung benutzerfreundlicher Funktionalitäten die Basis für Kicad weitaus besser legen können, als es getan wurde. Immerhin hätte Kicad ja frei sein können von Uralt-Modalitäten, wie sie einige heutige EDA-Systeme aus ihren lange Zeit zurückliegenden Wurzeln noch immer mit sich herumschleppen. Das jetzige Problem ist, daß schon zuviel Zeit vergangen ist. Damit werden Änderungen in die richtige Richtung immer schwieriger. Fehler im Anfang werden mit der Zeit zu einem immer größeren Hemmschuh. Ich hab sowas schon so oft erlebt: Fans von OS/2, die erst verschwanden, als die Menschen mit den Füßen und W95 abgestimmt hatten, Linux-Gurus die "Klickibunti" riefen und grafische Oberflächen als Dummzeug verdammten - bis auch sie zähneknirschend das Gegenteil zur Kenntnis nehmen mußten, Kicad-Fans die V/R-Annotation als überflüssig oder gar gefährlich ansahen, Kicad-Fans die noch immer nicht die richtige Beziehung zwischen Bauteilen, Footprints und Symbolen akzeptieren wollen. Ebenso die Trennung der Programme für SCH und BRD. Das alles wird sich mit der Zeit ändern. Aber wenn zuviel Zeit vergeigt wird, dann ist eine richtige Lösung des jeweiligen Problems eben nicht mehr möglich, ohne daß man die Machete gar zu tief in's Gebüsch hauen müßte - und so geht es ab einem Point of no Return nur noch mit Workarounds weiter. Das war schon immer so und es wird auch so mit Kicad gehen. Deswegen ist es bitter nötig, so früh wie möglich und so heftig wie möglich all diese Unzulänglichkeiten und Designfehler zu verbalisieren. Ich stoße den Finger ja nicht aus Häme immer wieder in die Wunde. Begreift das mal! W.S.
Holm T. schrieb: >> Es ist unter keinen Umständen akzeptabel, dass >> jemand aufgrund seiner dauerhaft abweichenden >> Meinung persönlich diffamiert wird. Das geht gar >> nicht. > > ..doch, das geht! > Wenn Derjenige es nicht lassen kann imemr wieder mit > den selben Argumenten jeden möglichen KiCad-Thread > zu verpesten, dann geht das. Holm, kannst Du das nicht BITTE ! einfach unterlassen? Ich möchte wissen und VERSTEHEN , was W.S. an KiCAD zu kritisieren hat. Ich mag ja letztlich zu einem anderen Urteil kommen als er, weil ich bestimmte Dinge anders wichte, aber ich ziehe dennoch doppelten Nutzen aus der laufenden Diskussion: 1. Ich erfahre etwas darüber, wie Eagle funktioniert. Mein eigener Kontakt mit Eagle liegt schon Jahre zurück und war (gottseidank) auch nicht besonders intensiv. Dennoch interessiert es mich, was Eagle kann, und wie das dort implementiert ist. 2. Ich erfahre etwas über KiCAD. Ich bin - wie sich inzwischen herumgesprochen haben sollte - der Meinung, dass sowohl Eagle als auch KiCAD gewisse Fehler im Grundkonzept haben (was mir das zweifelhafte Vergnüngen verschafft, BEIDE Lager als Gegner zu haben). Was mir aber massiv auf den Zünder geht, das sind diese ständigen persönlichen Beleidigungen und Diffamierungen, die einige hier abkippen! ES NERVT !
Possetitjel schrieb: > Wenn ich W.S. richtig verstehe, dann sieht er es als > spezifische Stärke von Eagle an, dass es dort EINE Daten- > struktur gibt, die VERBINDLICHE Auskunft über BAUTEILE > (=Zusammenfassung von Symbol, Footprint und ggf. weiteren > Attributen) geben kann - das ist nämlich der Schaltplan. Ähem.. nein. Wir alle kennen weder den Quellcode von Eagle, noch den von irgend einem anderen EDA-System. Aber: So wie es aussieht, ist unter'm Blech dort eine Datenbank am werkeln, die alles beinhaltet und somit zusammenhält. Da ist der Schematics-Editor nur ein Kopf dieses Drachens, der Layout-Editor ein anderer Kopf, die Bibliotheksverwaltung ein weiterer Kopf, ebenso die Projektverwaltung und weitere User-Interfaces sind eben weitere Köpfe. Damit ist die zentrale Instanz eben die Datenbank und der Schaltplan ist quasi nur eine von vielen Projektionen derselben. Im allerweitesten Sinne könntest du deine Bauteile-Liste oder so eben mit dieser Datenbank identifizieren. Ich nehme mal an, daß dieses Prinzip der alles zusammenhaltenden Datenbank keine Spezialität von Eagle ist, sondern mittlerweile mehr oder weniger gut von vermutlich allen aktuellen Systemen so gehandhabt wird. W.S.
Sheeva P. schrieb: > Michael R. schrieb: >> Sheeva P. schrieb: >>> Auch sonst ist dieser Thread, und eigentlich auch das >>> Forum hier, nicht der richtige Ort, um Kritik an KiCad >>> oder Verbesserungsvorschläge vorzubringen. >> >> Dem schließe ich mich nicht ganz an. Als "potentieller >> Eagle-zu-Kicad-Wechsler" finde ich es schon angemessen, das >> "Anders-sein" von Kicad (sehr) kritisch zu hinterfragen; > > Das kann gerne gemacht werden, aber nicht in einem Thread > mit dem Thema, welches der TO vorgegeben hat. ??? Welcher Thread waere denn geeigneter, Eagle und KiCAD vernünftig miteinander zu vergleichen, als einer, in dem nach Erfahrungen von Umsteigern gefragt wird? Das ist doch die beste Informationsquelle überhaupt -- man muss nur bereit sein, zuzuhören. > Und schon gar nicht, wenn das Geäußerte sowie die > Aggressivität und Penetranz, mit dem es geäußert wird, > an einem bloßen "Hinterfragen" dann doch meilenweit > vorbeigeht. ??? Penetranz mag unangenehm sein, aber sie ist ein Menschenrecht. Und als aggressiv würde ich W.S. nun nicht bezeichnen... den Part übernehmen andere hier. > Dieser Hinweis war ja auch an jene gerichtet, die ihre > "Kritik" nicht in den Kommunikationskanälen des Projekts, > sondern nur hier vortragen [...] Wir hatten diesen Punkt schonmal in einem anderen Kontext: Interoperabilität ZWISCHEN verschiedenen Projekten MUSS auch außerhalb der jeweiligen Projekte diskutiert werden! Und wenn unterschiedliche Projekte ähnliche Ziele verfolgen, dann müssen die Ergebnisse auch AUSSERHALB dieser Projekte verglichen werden.
Sheeva P. schrieb: >> die Reaktion (zB "braucht man nicht") lässt für mich gute Rückschlüsse >> zu. > > Tatsächlich? Wenn Du die etwas unbeherrschte Reaktion eines zuvor > mehrfach provozierten Teilnehmers in diesem Thread heranziehst, um > Rückschlüsse auf die in Rede stehende Software daraus zu ziehen, dann, > entschuldige bitte, ist OpenSource-Software vermutlich nicht das > Richtige für Dich -- YMMV. Entschuldige bitte, ich hab seit 15 Jahren einen MS-freien Haushalt, der fast ausschließlich auf Open Source fusst. ich bin alt und erfahren genug, meine eigenen Rückschlüsse zu ziehen. Danke.
W.S. schrieb: > Ähem.. nein. > Wir alle kennen weder den Quellcode von Eagle, noch den > von irgend einem anderen EDA-System. > > Aber: > > So wie es aussieht, ist unter'm Blech dort eine Datenbank > am werkeln, die alles beinhaltet und somit zusammenhält. Logisch... in diesem Sinne war das gemeint. > Da ist der Schematics-Editor nur ein Kopf dieses Drachens, > der Layout-Editor ein anderer Kopf, die Bibliotheksverwaltung > ein weiterer Kopf, ebenso die Projektverwaltung und weitere > User-Interfaces sind eben weitere Köpfe. Damit ist die zentrale > Instanz eben die Datenbank und der Schaltplan ist quasi nur > eine von vielen Projektionen derselben. > > Im allerweitesten Sinne könntest du deine Bauteile-Liste oder > so eben mit dieser Datenbank identifizieren. Ja... genau das ist der Gedanke. > Ich nehme mal an, daß dieses Prinzip der alles zusammenhaltenden > Datenbank keine Spezialität von Eagle ist, sondern mittlerweile > mehr oder weniger gut von vermutlich allen aktuellen Systemen > so gehandhabt wird. Das hängt wohl von der Definition von "aktuell" ab :) Von Target3001 weiss ich es natürlich nicht sicher, aber es fühlt sich wenigstens so an, als ob es diese Datenbank im Inneren gäbe. (Target macht meiner Meinung nach ziemlich viel richtig; es ist merkwürdig, dass es so wenig bekannt ist.) Das klassische gEDA kennt diese Datenbank nicht. Wohin die Reise bei gEDA-rnd geht, kann ich noch nicht sagen. gEDA hat allerdings aus meiner Sicht den Vorzug, dass es modular genug ist, um ohne Probleme um eine solche Datenbank ergänzt werden zu können. Da sehe ich keinen Hinderungsgrund. Das klassische KiCAD scheint die Datenbank ja auch nicht zu kennen; bleibt abzuwarten, in welche Richtung sich das Projekt weiterentwickelt. Danke jedenfalls für Deine Auskünfte.
Hallo Possetitjel. Possetitjel schrieb: > Ich mag ja letztlich zu einem anderen Urteil kommen als > er, weil ich bestimmte Dinge anders wichte, aber ich ziehe > dennoch doppelten Nutzen aus der laufenden Diskussion: > > 1. Ich erfahre etwas darüber, wie Eagle funktioniert. > Mein eigener Kontakt mit Eagle liegt schon Jahre zurück > und war (gottseidank) auch nicht besonders intensiv. > Dennoch interessiert es mich, was Eagle kann, und wie > das dort implementiert ist. Das ist gut möglich, weil sich W.S. relativ gut mit Eagle auskennt und Erfahrung darin hat. > 2. Ich erfahre etwas über KiCAD. Das ist leider weniger warscheinlich, weil W.S. selber KiCad nur in einer Uraltversion oder vom Hörensagen kennt, seinen Ausführungen nach zu urteilen. > Ich bin - wie sich inzwischen herumgesprochen haben sollte - > der Meinung, dass sowohl Eagle als auch KiCAD gewisse Fehler > im Grundkonzept haben (was mir das zweifelhafte Vergnüngen > verschafft, BEIDE Lager als Gegner zu haben). Nix ist perfekt. Das nächste Problem ist, dass Du selber anscheinend keinerlei praktische Erfahrung mit diesen Programmen hast und Dich darum auf theoretische Überlegungen beschränkst. Das ist erst einmal formal ok, aber Du läufst dabei eben auch Gefahr, dass Du die praktischen Auswirkungen von theoretischen Vor- und Nachteilen nicht richtig Einschätzt. Das ist, als wenn Du versuchst, die Vor- und Nachteile eines bestimmten Automodelles gegenüber einem anderen an z.b. der Gleitzahl festzumachen. Ein Auto mag eine bessere Gleitzahl als ein anderes haben, aber ich hoffe mal, dass Du keinen Fahrstil hast, bei dem die Gleitzahl Deines Autos Bedeutung hat. Formalismus ist eben nicht alles, wie auch schon Feynman in seiner Bemerkung über Cargo-Cult-Wissenschaft feststellt. https://de.wikipedia.org/wiki/Cargo-Kult-Wissenschaft Von Eagle (und einigen anderen Programmen) gibt es Demoversionen. KiCad ist open Source. Du solltest halt irgendwann den Schritt machen, und das ganze praktisch austesten. Du liesst hier die Diskussionen seit Monaten mit. Irgendwie wiederholt sich das ganze, und spätestens wenn Du das merkst, ist eigentlich der Punkt gekommen, in die Praxis zu gehen. Theoretische Überlegungen sind schön und gut, aber sie lassen wenig Rückschlüsse auf Deine persönlichen Präferenzen zu, die ebenfalls in die praktische Anwendung von Layoutprogrammen einfliessen. Vieleicht ist für Dich persönlich ja eine Eigenschaft wichtig, die hier noch nie diskutiert wurde. Das würdest Du aber nur durch Ausprobieren herausbekommen. > Was mir aber massiv auf den Zünder geht, das sind diese > ständigen persönlichen Beleidigungen und Diffamierungen, > die einige hier abkippen! ES NERVT ! Wer in Foren diskutiert, muss halt ein dickes Fell haben. Das Problem liegt aber vor allem auch darin, dass ich bei einigen Diskussionsteilnehmern meine wahrzunehmen, dass sie aus welchen Gründen auch immer ein falsches Bild der Situation vermitteln, und das sehr Bewusst und aggressiv. auf andere zeig Ansonsten beschränke ich mich lieber darauf, Tipps zu geben. Jeder muss für sich selber das Programm finden, mit dem er am besten klarkommt, oder halt selber eins schreiben. Siehe Horizon. Das kommt Deiner Datenbankidee (die ich persönlich auch interessant finde) wohl schon sehr nahe. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Possetitjel schrieb: > Sheeva P. schrieb: > >> Michael R. schrieb: >>> Sheeva P. schrieb: >> Das kann gerne gemacht werden, aber nicht in einem Thread >> mit dem Thema, welches der TO vorgegeben hat. > > Welcher Thread waere denn geeigneter, Eagle und KiCAD > vernünftig miteinander zu vergleichen, als einer, in dem > nach Erfahrungen von Umsteigern gefragt wird? Gegen Vergleiche habe ich nichts. Aber "ich hab' mir das mal zwei Stunden angeschaut und will keine Tutorials durcharbeiten" befähigt niemanden zu einem vernünftigen Vergleich -- und ebensowenig das Insistieren von W.S., daß ihm für seinen Workflow eine bestimmte Funktion fehlt. Das kann man einmal vorbringen -- und zwar idealerweise, ohne dann das ganze Projekt gleich als "schlecht konstruiert" abzuqualifizieren, ohne den Entwicklern eine "eingeschränkte Sicht" zu unterstellen, und oder die Software, die man nach eigener Aussage nur 10 Minuten ausprobiert hat, als "Mist" abzutun. Da wird aus dem nützlichen "Vergleich" nämlich eine nutzlose Schmähkritik und gleichzeitig nicht weniger nutzlose Provokation. >> Dieser Hinweis war ja auch an jene gerichtet, die ihre >> "Kritik" nicht in den Kommunikationskanälen des Projekts, >> sondern nur hier vortragen [...] > > Wir hatten diesen Punkt schonmal in einem anderen Kontext: > Interoperabilität ZWISCHEN verschiedenen Projekten *MUSS* > auch außerhalb der jeweiligen Projekte diskutiert werden! Bei der vielzitierten Backward-Annotation geht es um die Interoperabilität innerhalb zweier Komponenten desselben Projekts, nämlich dem Schaltplan- und dem Layout-Editor des KiCad-Projekts. Und deswegen ist genau dieses Thema auch nur und ausschließlich beim KiCad-Projekt richtig aufgehoben, würde ich sagen. Wenn ich eine Excel-Tabelle nicht in ein Word-Dokument übernommen bekomme, frag' ich ja auch nicht in einem Oracle-Forum. ;-)
Possetitjel schrieb: > Ich möchte wissen und VERSTEHEN , was W.S. an KiCAD > zu kritisieren hat. OK, ich formuliere es nochmal: Vor geraumer Zeit, als es mir mit Eagle und Farnell's Ansichten darüber so langsam brenzlig zu werden schien, war die Zeit, wo einige Fans das Diptrace als würdigen Ersatz für Eagle handeln wollten. Mir war klar, daß das nicht funktioniert, denn da waren Welten dazwischen. Bei Kicad sah das anders aus, da sah ich eine Perspektive dahingehend, daß Kicad tatsächlich einmal etwa als eine gute Alternative zu kommerziellen Systemen dastehen kann. Aber bei alldem, was ich schon damals sah, war (und ist) noch eine Menge am prinzipiellen Grundentwurf zu tun. Perspektiven können vergeigt werden. Da ist die weiter oben geschriebene Sache mit der zentralen Datenbank, wo V/R-Anno, das Nichtabreißen von Netzen im Schematics, die Bibliotheksprobleme und so weiter schlichtweg gelöst wären, hätte man es so angefangen oder zumindest rechtzeitig in diese Richtung gebracht. Der Lukas mit seinem Horizon hat das bislang eigentlich viel deutlicher gesehen, als das von den Kicad-Leuten hier akzeptiert wird. Allerdings ist er momentan noch immer ein ziemlicher Feuerkopf mit gefühlten 1000 Ideen pro Minute - und er ist mit seinem Projekt noch immer recht allein. Auch Kicad sollte zu einer Ein-Programm Lösung mutieren, wo Schematics und Board zugleich und ineinander verzahnt durch eine gemeinsame Datenbankmaschine als zwei von deren UI-Frontends fungieren, wo V/R-Anno von selbst geht, weil es eben dieselbe DB ist, wo das unselige Bibliotheksgewimmer abgelöst ist durch Bauteile, die eben Symbole und Footprints und in Zukunft auch noch Logik in Form von VHDL sowie mechanische 3D-Modelle und elektrische 3D-Modelle für EMV-Modellierungen und in weiterer Zukunft auch Modelle für distributed elements und dergleichen beinhalten. Also Aussicht in Richtung Spice UND in Richtung Sonnet oder Ansoft oder dergleichen. Mit einem auf bloßen Symbol-->Footprint System ist das aussichtslos. Für all sowas muß die Grundlage beizeiten gelegt werden, das ist nicht das Draufsetzen eines weiteren Features. Um das bildlich zu sagen: die Fundamente müssen geradegerückt werden und nicht an ein weiteres Türmchen auf dem Dach angepeilt werden. Und hier, bei der Diskussion über Kicad muß ich feststellen, daß ein Großteil der Diskutierer sich mit der Mühe abplagt, zwischen aufgelösten und unaufgelösten Symbolen abzuwägen, mit Schmutz um sich zu werfen, Eagle überhaupt nicht zu kennen weil man ja BSD hat, aber Eagle's Bauteilverwaltung miserabel zu finden und weitere völlig unsachliche Beiträge zu posten. Nein, wenn all die Kicad-Leute jedes Nicht-Lobeswort auf Kicad als persönlichen Affront ansehen, dann kommt hier garnix zuwege. W.S.
Michael R. schrieb: > Entschuldige bitte, ich hab seit 15 Jahren einen MS-freien Haushalt, der > fast ausschließlich auf Open Source fusst. Meinen Glückwunsch, das freut mich für Dich. > ich bin alt und erfahren genug, meine eigenen Rückschlüsse zu ziehen. Aus den unbedachten Aussagen eines einzelnen Forennutzers, der nicht für das Projekt spricht und zudem vorher provoziert wurde? Dann bin ich wohl zu jung und zu unerfahren, denn auf die Idee würde ich nie kommen. ;-)
Hallo W.S. W.S. schrieb: > Und hier, bei der Diskussion über Kicad muß ich feststellen, daß ein > Großteil der Diskutierer sich mit der Mühe abplagt, zwischen aufgelösten > und unaufgelösten Symbolen abzuwägen, Weil Deine Behauptungen dazu mit zu Deiner allgemeinen Desinformation über das Thema beitragen. ;O) Sinnvolle Kritik sieht anders aus. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Sheeva P. schrieb: >> ich bin alt und erfahren genug, meine eigenen Rückschlüsse zu ziehen. > > Aus den unbedachten Aussagen eines einzelnen Forennutzers, der nicht für > das Projekt spricht und zudem vorher provoziert wurde? Dann bin ich wohl > zu jung und zu unerfahren, denn auf die Idee würde ich nie kommen. ;-) Du, es mag dich überraschen, aber ich lese nicht nur die Beiträge "eines einzelnen Forennutzers" (ich weiss nicht mal auf wen du anspielst) Jedenfalls war und ist mein Erkenntnisgewinn in diesem Thread durchaus hoch
Bernd W. schrieb: > Sinnvolle Kritik sieht anders aus. Sehe ich grad nicht so. W.S. bringt es schon ganz gut auf den Punkt...
W.S. schrieb: > OK, ich formuliere es nochmal: Na prima, geht doch. ;-) > Vor geraumer Zeit, als es mir mit Eagle und Farnell's Ansichten darüber > so langsam brenzlig zu werden schien, war die Zeit, wo einige Fans das > Diptrace als würdigen Ersatz für Eagle handeln wollten. Mir war klar, > daß das nicht funktioniert, denn da waren Welten dazwischen. > > Bei Kicad sah das anders aus, da sah ich eine Perspektive dahingehend, > daß Kicad tatsächlich einmal etwa als eine gute Alternative zu > kommerziellen Systemen dastehen kann. > > Aber bei alldem, was ich schon damals sah, war (und ist) noch eine Menge > am prinzipiellen Grundentwurf zu tun. Mag sein, daß die Entwickler einige Entscheidungen getroffen haben, die Dir nicht gefallen. Aber statt dann hier im Forum zu mosern, wäre es doch viel sinnvoller, wenn Du Deine Erfahrungen, Dein Fachwissen, Deine Vorstellungen und Deine Wünsche dort einbringen würdest. Nur dann hast Du nämlich eine Chance, daß das Projekt in eine Richtung weiterentwickelt wird, die Dir gefallen und die Software auch für Dich interessant machen würde.
Michael R. schrieb: > Du, es mag dich überraschen, aber ich lese nicht nur die Beiträge "eines > einzelnen Forennutzers" (ich weiss nicht mal auf wen du anspielst) Ich spiele auf Deine Aussage 'die Reaktion (zB "braucht man nicht") lässt für mich gute Rückschlüsse zu' an. Ausgerechnet das wäre so ziemlich die letzte Aussage, aus der ich irgendwelche Rückschlüsse ziehen würde. ;-)
Hallo Michael r. Michael R. schrieb: > > Du, es mag dich überraschen, aber ich lese nicht nur die Beiträge "eines > einzelnen Forennutzers" (ich weiss nicht mal auf wen du anspielst) Der mit "Backannotation braucht man nicht" war ich. ;O) Und das meine ich auch so. Es mag andere Arbeitsstile geben, wo sowas wichtig ist, aber halt bei meinem nicht. Und ich würde auch sagen, dass die, die eine Backannotation verwenden, eher selten sind. Das ist wohl auch einer der Gründe für die bisher fehlende Implementation in KiCad. Es wird halt das zuerst bearbeitet, was man für besonders wichtig hält, entweder aus persönlicher Erfahrung, oder weil es nachgefragt wird. Aber Sheeva Plug hat ja auf ein Skript verwiesen, mit dem man eine Backannotation durchführen kann, und ich habe dann auch einen Verweis darauf in https://www.mikrocontroller.net/articles/KiCad eingetragen. Getestet habe ich es aber noch nicht. Ich besitze übrigens auch keinen Staubsauger, nur einen Besen und einen Wischmop. Auch einen Staubsauger "braucht man nicht". Und ich vermisse ihn auch nicht. > Jedenfalls war und ist mein Erkenntnisgewinn in diesem Thread durchaus > hoch Viel Erfolg. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
W.S. schrieb: [..] > Ich stoße den Finger ja nicht aus Häme immer wieder in die Wunde. > Begreift das mal! > > W.S. ..nein, aus unbeschreiblicher Dummheit, Ignoranz und Arroganz..wohl wissend das Du Deine Kritiken penetrant an der falschen Stelle anbringst terrorisierst Du hier die Leute. Wenn Du Dich mal ansatzweise damit beschäftigt hättest wie KiCad entstanden ist (es wurde ein Schaltungseditor zu einem bereits existierenden Layoutproramm hinzu gefügt) könntest Du jetzt nicht Dein Gift über vorher vergessene Designstudien bei anderen Systemen anbringen. Es ist nicht der Zweck Deines Gelabers beizutragen irgend etwas besser zu machen, das genau Gegenteil ist der Fall. Du bist ein kranker Mann. Gruß, Holm
Possetitjel schrieb: > Holm T. schrieb: > >>> Es ist unter keinen Umständen akzeptabel, dass >>> jemand aufgrund seiner dauerhaft abweichenden >>> Meinung persönlich diffamiert wird. Das geht gar >>> nicht. >> >> ..doch, das geht! >> Wenn Derjenige es nicht lassen kann imemr wieder mit >> den selben Argumenten jeden möglichen KiCad-Thread >> zu verpesten, dann geht das. > > Holm, kannst Du das nicht BITTE ! einfach unterlassen? Nein. > > Ich möchte wissen und VERSTEHEN , was W.S. an KiCAD > zu kritisieren hat. Dann ruf ihn an! W.S: ist nicht zu verstehen, weil seine Ziele ein moving Target sind. Als Kritik kam jetzt die Verwendung von Python Scripten um irgendwas zu erreichen. Eagles Scripte und ULPs hat er da versehentlich vergessen. Du kannst jetzt langsam aufhören zu hinterfragen was er will, das solltest Du mit der Anzahl seiner Postings mittlerweile gerafft haben! Höre auf damit anderen auf die Ketten zu gehen. BTW: es ist völlig Wurscht ob eine Datenbank von Objekten die Bauteile in Schaltung und Layout beschreiben Netzliste, Objektdatenbank, Superbautleliste oder sonst wie heißt. > > Ich mag ja letztlich zu einem anderen Urteil kommen als > er, weil ich bestimmte Dinge anders wichte, aber ich ziehe > dennoch doppelten Nutzen aus der laufenden Diskussion: > > 1. Ich erfahre etwas darüber, wie Eagle funktioniert. > Mein eigener Kontakt mit Eagle liegt schon Jahre zurück > und war (gottseidank) auch nicht besonders intensiv. > Dennoch interessiert es mich, was Eagle kann, und wie > das dort implementiert ist. > 2. Ich erfahre etwas über KiCAD. Du gedenkst etwas über KiCad zu erfahren von Einem der sich das das letzte Mal vor 2 Jahren angesehen hat? Warum fragst Du nicht Deine Mutti? > > Ich bin - wie sich inzwischen herumgesprochen haben sollte - > der Meinung, dass sowohl Eagle als auch KiCAD gewisse Fehler > im Grundkonzept haben (was mir das zweifelhafte Vergnüngen > verschafft, BEIDE Lager als Gegner zu haben). > > Was mir aber massiv auf den Zünder geht, das sind diese > ständigen persönlichen Beleidigungen und Diffamierungen, > die einige hier abkippen! ES NERVT ! Loriot: Achwas! Mach Du mit Deinem Fragen an Ihn weiter und ich erweitere dann meinen Aktionsradius! Gruß, Holm
W.S. schrieb: > Possetitjel schrieb: >> Wenn ich W.S. richtig verstehe, dann sieht er es als >> spezifische Stärke von Eagle an, dass es dort EINE Daten- >> struktur gibt, die VERBINDLICHE Auskunft über BAUTEILE >> (=Zusammenfassung von Symbol, Footprint und ggf. weiteren >> Attributen) geben kann - das ist nämlich der Schaltplan. > > Ähem.. nein. > Wir alle kennen weder den Quellcode von Eagle, noch den von irgend einem > anderen EDA-System. > > Aber: > > So wie es aussieht, ist unter'm Blech dort eine Datenbank am werkeln, > die alles beinhaltet und somit zusammenhält. Da ist der > Schematics-Editor nur ein Kopf dieses Drachens, der Layout-Editor ein > anderer Kopf, die Bibliotheksverwaltung ein weiterer Kopf, ebenso die > Projektverwaltung und weitere User-Interfaces sind eben weitere Köpfe. > Damit ist die zentrale Instanz eben die Datenbank und der Schaltplan ist > quasi nur eine von vielen Projektionen derselben. > > Im allerweitesten Sinne könntest du deine Bauteile-Liste oder so eben > mit dieser Datenbank identifizieren. > > Ich nehme mal an, daß dieses Prinzip der alles zusammenhaltenden > Datenbank keine Spezialität von Eagle ist, sondern mittlerweile mehr > oder weniger gut von vermutlich allen aktuellen Systemen so gehandhabt > wird. > > W.S. Wie haste denn das nur raus gekriegt? Mit Fleckenwasser? Woher kommt die brilliante Erkenntnis das da eine gemeinsame Datenbasis aka Datenbank dahinter stecken müsse? Die haben übrigens gerade in den Nachrichten gebracht das es morgens hell und abends dunkel werden wird.... Gruß, Holm
W.S. schrieb: > Possetitjel schrieb: >> Ich möchte wissen und VERSTEHEN , was W.S. an KiCAD >> zu kritisieren hat. > > OK, ich formuliere es nochmal: > > Vor geraumer Zeit, als es mir mit Eagle und Farnell's Ansichten darüber > so langsam brenzlig zu werden schien, war die Zeit, wo einige Fans das > Diptrace als würdigen Ersatz für Eagle handeln wollten. Mir war klar, > daß das nicht funktioniert, denn da waren Welten dazwischen. > > Bei Kicad sah das anders aus, da sah ich eine Perspektive dahingehend, > daß Kicad tatsächlich einmal etwa als eine gute Alternative zu > kommerziellen Systemen dastehen kann. > > Aber bei alldem, was ich schon damals sah, war (und ist) noch eine Menge > am prinzipiellen Grundentwurf zu tun. Perspektiven können vergeigt > werden. > > Da ist die weiter oben geschriebene Sache mit der zentralen Datenbank, > wo V/R-Anno, das Nichtabreißen von Netzen im Schematics, die > Bibliotheksprobleme und so weiter schlichtweg gelöst wären, hätte man es > so angefangen oder zumindest rechtzeitig in diese Richtung gebracht. Hallo W.S.! ..er hat es geschafft. Sein Gelaber ist nun nicht mehr von Deinem zu unterscheiden. > > Der Lukas mit seinem Horizon hat das bislang eigentlich viel deutlicher > gesehen, als das von den Kicad-Leuten hier akzeptiert wird. Allerdings > ist er momentan noch immer ein ziemlicher Feuerkopf mit gefühlten 1000 > Ideen pro Minute - und er ist mit seinem Projekt noch immer recht > allein. Ich drücke ihm auch alle verfügbaren Daumen für sein Projekt, genauso wie ich das für KiCad tue. > > Auch Kicad sollte zu einer Ein-Programm Lösung mutieren, wo Schematics > und Board zugleich und ineinander verzahnt durch eine gemeinsame > Datenbankmaschine als zwei von deren UI-Frontends fungieren, wo V/R-Anno > von selbst geht, weil es eben dieselbe DB ist, wo das unselige > Bibliotheksgewimmer a... Ist gut nun. Auch auch Du solltest Dich in eine Richtung entwickeln in der Du Dich mal mit Tatsachen auseinandersetzt und nicht nur mit dummem Geschwätz. Du erfindest hier gerade ein eierlegendes Wollmilchwindows das Niemand haben will. [..] >Und hier, bei der Diskussion über Kicad muß ich feststellen, daß ein >Großteil der Diskutierer sich mit der Mühe abplagt, zwischen aufgelösten >und unaufgelösten Symbolen abzuwägen, Ach. >mit Schmutz um sich zu werfen, >Eagle überhaupt nicht zu kennen weil man ja BSD hat, Sag mal...kannst Du mal bitte konkretisieren was ich an Eagle schlecht gemacht habe? Falls Du das etwa nicht können solltest bitte ich Dich darum diese Anschuldigung hier zurück zu nehmen, wahrscheinlich fehlen Dir dazu aber die Eier in der Hose. > aber Eagle's >Bauteilverwaltung miserabel zu finden und weitere völlig unsachliche >Beiträge zu posten. Du bist keinen, keinen noch so kleinen Scheißdreck besser. Statt Dir die Software mal anzusehen laberst Du herum was das Zeug hält..identisch zu W.S. Du hast in meinen Augen eine völlig neue Qualifikationsstufe erreicht, die liegt aber leider nicht höher als die Vorhergehende. Ist das schon präsenile Demenz? Ich weiß es nicht... Gruß, Holm
Wäre diese Diskussion nicht ertragreicher bei einem gemütlichen Zusammensein im Bräukämmerlein bei einem (oder mehreren) Glas Bier? Wenn das so weiter geht bekommt diese Erörterung hier das Gesicht einer toten Maus...
Bernd W. schrieb: > Und ich würde auch sagen, dass die, die eine Backannotation verwenden, > eher selten sind. Das ist wohl auch einer der Gründe für die bisher > fehlende Implementation in KiCad. Die KiCad-Entwickler sagen dazu in ihrem "Getting Started": "Rückwärts Annotation ist der Prozess eine PCB Layout Veränderung zurück zum entsprechenden Schaltplan zu schicken. Einige betrachten diese spezielle Funktion aber als nicht besonders nützlich." [1] [1] http://docs.kicad-pcb.org/4.0.7/de/getting_started_in_kicad.html#forward-and-backward-annotation
Hallo Gerhard, Gerhard O. schrieb: > Wäre diese Diskussion nicht ertragreicher bei einem gemütlichen > Zusammensein im Bräukämmerlein bei einem (oder mehreren) Glas Bier? Dein versöhnlicher Ansatz in Ehren, aber es geht W.S. nicht um eine sachbezogene Diskussion. Mit kruden Ideen teilt er wirr gegen alles was seine einstige Investition in Frage stellen könnte aus, deshalb kann und darf OSS für ihn nicht besser sein, als das wofür er bezahlt hat: Footprints flexibel einem Symbol zuordnen zu können ist böse, weil dann könnte man ja auch generische Symbole für Schaltpläne ohne folgende PCBs nutzen. Das stellt sein Konzept aber in Frage, deshalb braucht das Niemand und darf das auch Niemand machen. Flexibel die Footprints zu einigen Bauteilen erst dann festzulegen, wenn der Schaltplan fertig ist kann er nicht, deshalb ist das böse und wer das doch macht handelt planlos. Dafür braucht er dann Backannotation, weil er mit seiner frühzeitigen Festlegung doch regelmäßig falsch liegt. Das muss so sein und hat nichts mit planlos zu tun. Wer eine solche nachträgliche Änderung über den Schaltplan macht handelt böse, weil das bestimmt inkonsistent ist. Wer Symbole je nach Zweck des Schaltplans anwenderorientiert mit unterschiedlich tiefer Abstraktion (footprintorientiert oder funktionsorientiert) verwendet ist dumm, weil das kann er nicht. Wenn ein Programm mit Pythonscripten unterstützt werden kann ist das böse, weil das kann er nicht. Er verschwendet seine Lebensenergie darauf sich zu belegen warum alles was er und sein Programm nicht können dumm und falsch sein muss. Konstruktiv heranzugehen lohnt sich nicht, da das andere Programm leicht anders ist als seins, müssen die Fehler zu grundlegend sein, als das es sich lohnen würde das zu optimieren. Es wäre durchaus sinnvoll sich zusammen zu setzen und Stellen für Verbesserungen (da gibt es durchaus Einige) zu identifizieren und potenzielle Lösungswege zu diskutieren. Aber nur mit Leuten, die an der Sache interessiert sind, nicht mit destruktiven Stänkerern. Es ist auch gar nicht nötig ihn dabei zu haben, er hat ja schon ein Programm welches genau das kann was er braucht und das genau richtig macht. Ein anderes Programm müsste für ihn genauso sein, sonst kann es nur schlechter sein.
Jetzt habe ich mich aber wirklich in die Nesseln gesetzt:-) Ich kann bei diesem Thema momentan nicht wirklich mitreden weil mir nur die flache Weltscheibe von Altium/Protel und von früher noch Orcad, Tango geläufig ist. Ich glaube übrigens, daß ein Gespräch oder Zusammensitzen am PC zum Erforschen der Eigenschaften besser funktionieren würde wie antwortende Monologe im Forum hier. Bei persönlicher Zusammenarbeit gibt es oft gegenseitige Aha Momente. Das fehlt bei dieser Art von Kommunikation. Irgendwie enstehen so oft viele Mißverständnisse aller Art und lassen sich schwer aus der Welt bringen die ein persönliches Zusammenarbeiten gar nicht enstehen lassen würde. Jedenfalls ist das meine Seite dieser Story... Ich habe mir vor kurzem Kicad und Eagle installiert um mir selber ein Bild machen zu können. Bei ersten Versuchen wurde mir gleich klar, daß eine objektive Beurteilung nicht ohne eine gewisse Einarbeitung möglich ist und werde mir zuerst einmal einige der vielen Tutorials im Internet zu Gemüte führen. Da ich aktiv in der Open Source Bewegung beitragen möchte, habe ich ein Interesse mit Eagle CAD Designs arbeiten zu können weil nicht jeder Zugang zum Altium Format hat. Von meiner Perspektive aus, finde ich alle Kommentare hier nützlich und persönlich sehe die Argumente von W.S. nicht wirklich so negativ. Das Thema F/B ist schon wichtig. Bei PR99 verwende ich das oft um von der PCB Seite Footprints ändern zu können und den Schaltplan von dort zu aktualisieren. Es ist zumindest angenehm diese Möglichkeit zu haben. Ich habe mir ein paar Kicad Tutorials angesehen und finde es nicht zu schwierig sobald man sich an die pertinenten Unterschiede angepasst hat. Was mir am PCB Editor wichtig ist, daß man das Design gut nachbearbeiten kann ohne daß das Programm immer sagt "Das geht nicht und dies darfst Du nicht, und so". Bei PR funktioniert dieser Aspekt außerordentlich gut und das Programm redet mir nicht andauernd drein. Ich finde die Einarbeitung in ein anderes CAD Ökusystem schwierig weil Vieles noch so vielen Jahren in Fleisch und Blut übergegangen ist. Beim Rumspielen mit der frisch installierten Kicad fand ich mich sofort im "Kampf" mit dem Programm das nicht so reagierte wie ich es gewöhnt bin. Deshalb ist methodisches Einarbeiten absolut erforderlich. Bloßes Rumspielen führt nur zu Enttäuschungen. Schönen Sonntag noch, Gerhard
:
Bearbeitet durch User
Hai Bernd. Bernd W. schrieb: > Possetitjel schrieb: > >> 2. Ich erfahre etwas über KiCAD. > > Das ist leider weniger warscheinlich, weil W.S. selber > KiCad nur in einer Uraltversion oder vom Hörensagen > kennt, seinen Ausführungen nach zu urteilen. Sag' mal... was ist denn in euch gefahren? Können wir mal bitte von dieser Personaldebatte wegkommen? W.S. ist doch nicht der einzige Diskussionsteilnehmer hier! Es genügt doch, wenn er über Eagle fundiert Auskunft geben kann -- zu KiCAD können genügend andere Leute etwas sagen. > [...] > Das nächste Problem ist, dass Du selber anscheinend > keinerlei praktische Erfahrung mit diesen Programmen > hast [...] Das stimmt so nicht ganz. Ich habe beruflich OrCAD (wenige Wochen) und Target3001 (halbes Jahr intensiv) verwendet. Ich habe privat Eagle punktuell angetestet, bin aber nie damit warmgeworden. gEDA ist seit längerem auf meiner privaten Kiste installiert, KiCAD seit ein paar Monaten -- Hauptzweck war bisher, auf die Schnelle mal einzelne Teilfunktionen ausprobieren zu können. Komplette Projekte habe ich damit noch nicht abgewickelt, das stimmt. > und Dich darum auf theoretische Überlegungen beschränkst. Das stimmt auch nicht. Ich gehe ungern mit ungelegten Eiern hausieren, aber sei's drum...: - Ich habe mir eine Mini-Suchmaschine für Datenbläter programmiert (extrem rudimentär, aber ziemlich praktisch). - Ich habe mich kurz mit Datenbanken, Normalformen und SQL befasst. - Ich habe mich mit gschem beschäftigt, mich dabei über die krude Bedienung geärgert und überlegt, wie man das besser machen kann. - Ich habe HobbyCi (Schaltplaneditor; Java, Thomas Olzen) ausprobiert (enthält clevere Ideen, ist aber in der Praxis nicht benutzbar, da nicht weiter gepflegt). - Ich habe (ergebnislos) versucht, Peted (Schaltplaneditor von Dr. Stefan Salewski, Ruby) zum Laufen zu bringen. - Ich habe mich mit einigen Ungereimtheiten im gschem befasst und mich dabei etwas in die Symbolbibliothek von gschem vertieft. - Ich habe m.o.w. aus Quatsch angefangen, ein paar Grund- funktionen für einen Schaltplaneditor zu implementieren (Tcl/Tk; nutzt die Symbole von gEDA; liegt auf Eis). - Ich hatte kurzen Kontakt zu Tibor Palinkas (Chef des gEDA- Forks gEDA-rnd), um etwas zu den Hintergründen des Forks und zu seinen Vorstellungen für die Zukunft zu erfahren. (Klang SEHR ermutigend, da ausdrücklich auf Datenkompa- tibilität mit anderen freien Projekten orientiert.) - Mir ist aufgefallen, dass meine Datenblatt-Suchmaschine, meine berufliche Beschäftigung mit Stücklisten und die Struktur der gEDA-Library etwas miteinander zu tun haben -- die Idee der Super-Stückliste war geboren. Die laufende Diskussion war für mich weder nutzlos noch eine Wiederholung früherer Diskussionen: - Nutzlos war die Diskussion schon deshalb nicht, weil ich erstmals den Kritikpunkt von W.S. verstanden (und darüber hinaus als zutreffend erkannt) habe. - Eine Wiederholung früherer Diskussionen war es deshalb nicht, weil ich die Idee der Super-Stückliste vorher noch nie öffentlich vorgestellt hatte (jedenfalls erinnere ich mich nicht daran ;-). (Ach so, und nur für's Protokoll: Die Idee der "Super- Stückliste" ist ganz offensichtlich weder trivial noch selbstverständlich, denn gEDA hat keine und KiCAD - soweit ich weiss - auch nicht .) > Das ist erst einmal formal ok, aber Du läufst dabei > eben auch Gefahr, dass Du die praktischen Auswirkungen > von theoretischen Vor- und Nachteilen nicht richtig > Einschätzt. Naja, die wichtigsten Nachteile sind: 1. Die Ergonomie ist furchtbar (--> weiss ich aus Erfahrung). 2. Die Datenformate sind nicht kompatibel. Bilanz: Vernichtend. >> Was mir aber massiv auf den Zünder geht, das sind diese >> ständigen persönlichen Beleidigungen und Diffamierungen, >> die einige hier abkippen! ES NERVT ! > > Wer in Foren diskutiert, muss halt ein dickes Fell haben. Das ist zwar richtig -- aber entschuldige: Das ist kein Freibrief für persönliche Diffamierung und Pöbelei. > Das Problem liegt aber vor allem auch darin, dass ich bei > einigen Diskussionsteilnehmern meine wahrzunehmen, dass > sie aus welchen Gründen auch immer ein falsches Bild der > Situation vermitteln, und das sehr Bewusst und aggressiv. Tja gut... W.S. kannst Du damit ja schwerlich meinen, denn soweit mir bekannt ist, hat KiCAD ja tatsächlich keine zentrale Datenstruktur für alle Baugruppendaten ("Super- Stückliste") -- zumindest ist das mein Wissensstand. (gEDA übrigens auch nicht...) Seine Aussage über KiCAD ist also sachlich richtig, oder? Nimm mir's nicht übel, aber es ist schon ZIEMLICH lange her, dass ich eine vergleichbar abstruse Situation erlebt habe wie hier: Diejenigen, die sachbezogen über eine Thema diskutieren, das sowohl in das Unterforum wie auch in den Diskussionsfaden passt, werden MASSIV von denjenigen attackiert, die überwiegend Beleidigungen, Pöbeleien und Spekulationen über schlechte Absichten von sich geben. Entschuldige, aber das ist völlig schizophren. > Ansonsten beschränke ich mich lieber darauf, Tipps zu > geben. Das ist mir seit langem wohltuend aufgefallen, ja. > Jeder muss für sich selber das Programm finden, mit dem > er am besten klarkommt, oder halt selber eins schreiben. > Siehe Horizon. Das kommt Deiner Datenbankidee (die ich > persönlich auch interessant finde) wohl schon sehr nahe. Kann sein, ja. Die Komplikation für mich liegt darin, dass jetzt neben gEDA und KiCAD noch ein dritter Spieler im Feld ist... :)
Possetitjel schrieb: > Wir befinden uns in einem Diskussionsforum. Es > sollte jedermann gestattet sein, auch einen abweichenden > (Minderheiten-)Standpunkt nachhaltig zu vertreten. Volle Zustimmung zu diesem Satz.
ZF schrieb: > Dein versöhnlicher Ansatz in Ehren, aber es geht W.S. nicht um eine > sachbezogene Diskussion. Entschuldige bitte (und Du, Holm, bitte auch), aber W.S. hat sich in seinem letzten Beitrag IMHO durchaus um Sachlichkeit und eine gewisse Deeskalation bemüht. Könnten wir jetzt bitte aufhören, auf ihm herum zu hacken, und uns wieder der Sachdiskussion zuwenden? Eure Unterstellungen und Beschimpfungen sind dabei ebenso kontraproduktiv wie seine. Also bitte, zurück zur Sache. Besten Dank.
Gerhard O. schrieb: > Da ich aktiv in der Open Source Bewegung beitragen > möchte, habe ich ein Interesse mit Eagle CAD Designs arbeiten zu können > weil nicht jeder Zugang zum Altium Format hat. Äh, das OpenSource-Programm ist KiCad, nicht Eagle. ;-) > Das Thema F/B ist schon wichtig. Bei PR99 verwende ich das oft um von > der PCB Seite Footprints ändern zu können und den Schaltplan von dort zu > aktualisieren. Es ist zumindest angenehm diese Möglichkeit zu haben. Aber letztlich ist es doch nur eine Komfortfunktion, oder? > Deshalb ist methodisches Einarbeiten absolut erforderlich. Bloßes > Rumspielen führt nur zu Enttäuschungen. Unbedingt absolut korrekt!
Sheeva P. schrieb: > Gerhard O. schrieb: >> Da ich aktiv in der Open Source Bewegung beitragen >> möchte, habe ich ein Interesse mit Eagle CAD Designs arbeiten zu können >> weil nicht jeder Zugang zum Altium Format hat. > > Äh, das OpenSource-Programm ist KiCad, nicht Eagle. ;-) Warum müssen aber auch beide Programme mit ähnlichen Farben arbeiten, so daß man nur als erfahrener Benutzer den Unterschied erkennt? :-) Die Arduino Faktion scheint aber hauptsächlich Eagle zu verwenden. Macht nichts, hab ja jetzt beide CAD Werkzeuge. > >> Das Thema F/B ist schon wichtig. Bei PR99 verwende ich das oft um von >> der PCB Seite Footprints ändern zu können und den Schaltplan von dort zu >> aktualisieren. Es ist zumindest angenehm diese Möglichkeit zu haben. > > Aber letztlich ist es doch nur eine Komfortfunktion, oder? Absolut. Oft mache ich Änderungen nur von der Schaltbildseite her. Für mich ist diese Funktion also nicht sehr maßgebend. > >> Deshalb ist methodisches Einarbeiten absolut erforderlich. Bloßes >> Rumspielen führt nur zu Enttäuschungen. > > Unbedingt absolut korrekt!
Sheeva P. schrieb: > Aber "ich hab' mir das mal zwei Stunden angeschaut und > will keine Tutorials durcharbeiten" befähigt niemanden > zu einem vernünftigen Vergleich -- und ebensowenig das > Insistieren von W.S., daß ihm für seinen Workflow eine > bestimmte Funktion fehlt. Das ist beides zu kurz gegriffen. Ich finde den Wunsch, dass man nach zwei Stunden mit Software B einigermaßen klarkommt, wenn man Software A (die demselben Zweck dient) solide kennt, im Kern legitim. Wenn ich Excel kenne, komme ich mit LibreOffice Calc einigermaßen klar. Mir fallen die Unterschiede auf, aber ich kann sinnvoll damit arbeiten. Und "das Fehlen einer bestimmten Funktion" ist nach meinem Verständnis nicht nur das Fehlen dieser Funktion, sondern Ausdruck eines konzeptionellen Unterschiedes. Das ist keine Katastrophe, aber man sollte anerkennen, dass dieser Unterschied tatsächlich vorhanden ist, und das nicht leugnen. > Das kann man einmal vorbringen -- und zwar idealerweise, > ohne dann das ganze Projekt gleich als "schlecht konstruiert" > abzuqualifizieren, ohne den Entwicklern eine "eingeschränkte > Sicht" zu unterstellen, [...] Ich stimme Dir darin zu, dass W.S. seine Argumente dadurch entwertet, dass sie übertrieben überspitzt formuliert sind. Ich möchte dennoch dafür werben, sich primär auf den korrekten sachlichen Gehalt zu fokussieren und nicht auf die wenig zweckdienliche Form. (Das mag wohl auch damit zusammenhängen, dass ich zuweilen auch zur Überspitzung neige...:) >>> Dieser Hinweis war ja auch an jene gerichtet, die ihre >>> "Kritik" nicht in den Kommunikationskanälen des Projekts, >>> sondern nur hier vortragen [...] >> >> Wir hatten diesen Punkt schonmal in einem anderen Kontext: >> Interoperabilität ZWISCHEN verschiedenen Projekten *MUSS* >> auch außerhalb der jeweiligen Projekte diskutiert werden! > > Bei der vielzitierten Backward-Annotation geht es um die > Interoperabilität innerhalb zweier Komponenten desselben > Projekts, [...] Jein... Missverständnis. Was unter Backward-Annotation verstanden wird, ist gar nicht so eindeutig: Wenn es eine projektweite zentrale Datenbank gibt, dann ist die Backward-Annotation lediglich ein Zugriff auf diese Datenbank von einer ungewöhnlichen Stelle aus. Das ist ein reines GUI-Thema; wenn User das haben wollen, soll(t)en sie das bekommen. Wenn Schaltplan und Layout aber getrennte Datenstrukturen sind, sieht die Sache anders aus. Es ist meiner Meinung nach nicht zweckmäßig, Abhängigkeiten im Code zu schaffen, die Datenstrukturen aber getrennt zu lassen; das ist der falsche Weg. > Und deswegen ist genau dieses Thema auch nur und > ausschließlich beim KiCad-Projekt richtig aufgehoben, > würde ich sagen. Ich bin nicht sicher. Im Gegensatz zu W.S. bin ich nicht der Meinung, dass der Verzicht auf eine zentrale Datenbank von vornherein ein Fehler ist, der auf mangelnde Überlegung der Entwickler zurückzuführen ist. Im Gegenteil, es gibt gute Gründe dafür -- auch wenn es mit einem Komfortverlust für den Anwender verbunden ist. Insofern... man sollte seine Wünsche als Anwender schon in sinnvolle Relation zu den Zielen und Möglichkeiten des Projektes setzen, und nix fordern, was offensichtlich zu einer beschissenen Architektur führt...
W.S. schrieb: > Ich hab sowas schon so oft erlebt: Fans von OS/2, die erst verschwanden, > als die Menschen mit den Füßen und W95 abgestimmt hatten Hallo W.S. da irrst Du etwas. OS/2 gab es schon lange vor Windows 95 und es hatte einige Vorteile gegenüber dem damals vorherrschenden Windows 3.1. welches ja auch nur ein Aufsatz auf DOS war. Aber das brauche ich Dir ja niht zu sagen. OS/2 hatte zur damaligen Zeit einen entscheidenten Nachteil der letztendlich dazu geführt hat das es sich nicht wirklich etabliert hat. Das System stellte hohe Hardwareanforderungen (z.B. mindestens 8MB RAM) die zum damaligen Zeitpunkt einfach zu kostenintensiv waren. OS/2 war einfah etwas zu zeitig. Im übrigen gibt es einen Maschinenhersteller der auf seinen Maschinen bis weit über das Jahr 2000 hinaus OS/2 als Betriebssystem sehr erfolgreich eingesetzt hat. Ein tolles Feature von OS/2 war das es sowohl DOS Programme als auch Windowsprogramme ausführen konnte.
Bernd W. schrieb: > Der mit "Backannotation braucht man nicht" war ich. ;O) > > Und das meine ich auch so. Es mag andere Arbeitsstile geben, wo sowas > wichtig ist, aber halt bei meinem nicht. Bernd Du sagst es - für Dich ist FB nicht wichtig. Andere, auch ich, sehen das eben anders. Du kommt sicher auch noch aus einer Zeit, als wir die LP's mit Bleistift und Millimeterpapier gelayoutet haben. Ich muß Dir jetzt nicht erzählen wie oft da Fehler unterlaufen sind und man dann bei der fertigen Platte festgestellt hat, das trotz aller Sorgfalt doch ein Leiterzug vergessen oder falsch verlegt wurde. Genau für die Vermeidung von derartigen Fehlern ist FB ein Segen und ich persönlich möchte darauf nicht mehr verzichten. Genau diese fehlende FB ist derzeit für mich ein Hauptargument KiCAD ebennicht zu benutzen.
Possetitjel schrieb: > Bernd W. schrieb: >> Das ist leider weniger warscheinlich, weil W.S. selber >> KiCad nur in einer Uraltversion oder vom Hörensagen >> kennt, seinen Ausführungen nach zu urteilen. > > Sag' mal... was ist denn in euch gefahren? Können wir > mal bitte von dieser Personaldebatte wegkommen? W.S. > ist doch nicht der einzige Diskussionsteilnehmer hier! Dieser Bitte möchte ich mich vor allem deswegen anschließen, weil W.S. sich in seinen letzten Beiträgen offensichtlich um Deeskalation und Sachlichkeit bemüht hat -- für seine Verhältnisse jedenfalls. ;-) > Es genügt doch, wenn er über Eagle fundiert Auskunft > geben kann -- zu KiCAD können genügend andere Leute > etwas sagen. Kein Problem, dann mag er sich bitte zu Eagle äußern -- und bitte auch zu seinem speziellen Wörkfloh, den er mit KiCad nicht oder nur unter enormen Verrenkungen abbilden kann. Ehrlich gesagt, würde ich nähere Ausführungen zu seinem Workflow und seinen Bedürfnissen viel interessanter finden, als abqualifizierende oder gar diffamierende Aussagen über das KiCad-Projekt, seine Entwickler und seine Benutzer. > gEDA ist seit längerem auf meiner privaten Kiste > installiert, KiCAD seit ein paar Monaten -- Hauptzweck > war bisher, auf die Schnelle mal einzelne Teilfunktionen > ausprobieren zu können. Komplette Projekte habe ich damit > noch nicht abgewickelt, das stimmt. Same with me. gEDA ist aber auch nicht der wahre Jakob und verwendet, wenn ich das richtig verstanden habe, einen ähnlichen Workflow wie KiCad. > - Ich habe mir eine Mini-Suchmaschine für Datenbläter > programmiert (extrem rudimentär, aber ziemlich praktisch). Lustig, hab' ich auch. Sind wir schizophren, ohne es zu wissen, und Du wärst meine Zweitpersönlichkeit? ... > - Ich habe mich kurz mit Datenbanken, Normalformen und SQL > befasst. Puh, zum Glück nicht. Ich habe mich nämlich im Laufe vieler Jahre meines privaten und beruflichen Lebens sehr, sehr intensiv mit Datenbanken, SQL, Modellierung, Normalformen und Performanceoptimierung befaßt. Nebenbei bemerkt würde ich für Datenblätter keine SQL-Datenbank, sondern eine moderne, strukturierte und clusterfähige Volltext-Suchmaschine wie Apache Solr oder Elasticsearch benutzen. Beides habe ich aufgesetzt und benutzt, mit ES aber wesentlich mehr Erfahrung gesammelt. Wenn Du interessiert bist, können wir uns diesbezüglich gerne austauschen. Weiter oben habe ich ein (stark vereinfachtes) UML-Schema für derartige Datenbanken gepostet, vielleicht können wir das als Gesprächsgrundlage zum Einstieg verwenden. Leider hat da niemand was zu gesagt, was verschiedene Vermutungen zuläßt: a) es hat keiner verstanden, b) es ist so gut, daß man es nicht kritisieren kann, oder c), es war den Leuten in dieser Phase der Diskussion egal. Wie auch immer: wenn Du Lust hast, plz send a PM. > (Ach so, und nur für's Protokoll: Die Idee der "Super- > Stückliste" ist ganz offensichtlich weder trivial noch > selbstverständlich, denn gEDA hat keine und KiCAD - > soweit ich weiss - auch nicht .) Wenn ich Dein Konzept richtig verstanden habe, ist die "Superstückliste" eine Datenstruktur, die oberhalb der Schaltpläne und Layouts angesiedelt werden müßte und von diesen referenziert würde, korrekt? >> Jeder muss für sich selber das Programm finden, mit dem >> er am besten klarkommt, oder halt selber eins schreiben. >> Siehe Horizon. Das kommt Deiner Datenbankidee (die ich >> persönlich auch interessant finde) wohl schon sehr nahe. > > Kann sein, ja. Vielleicht sind Leute, die EDA-Software schreiben, ja auch einfach keine eingefleischten Datenbänker und -Modellierer. Aus meiner Informatiksicht sind Bauteil-Libraries im Wesentlichen Datenbanken mit Relationen (dabei aber nicht notwendigerweise klassische RDBMS), während Schaltpläne sowie Layouts im Prinzip zunächst eine Sonderform von ungerichteten, und zudem häufig zyklischen Graphen mit gruppierten Nodes (Pins) sind. Die Edges des Graphen sind dann die Verbindungen zwischen den Nodes einer Node-Gruppe, oder, elektronisch: die Verbindungen im Schaltplan oder die Leiterbahnen eines konkreten Layouts.
Gerhard O. schrieb: > Sheeva P. schrieb: >> Äh, das OpenSource-Programm ist KiCad, nicht Eagle. ;-) > Warum müssen aber auch beide Programme mit ähnlichen Farben arbeiten, so > daß man nur als erfahrener Benutzer den Unterschied erkennt? :-) Das ist eine Frage, die die Entwickler der betreffenden Software sicher besser beantworten können als ich. Meine Vermutung wäre, daß sich diese Farbgebung als eine Art Pseudostandard etabliert hat. > Die Arduino Faktion scheint aber hauptsächlich Eagle zu verwenden. Macht > nichts, hab ja jetzt beide CAD Werkzeuge. Naja, wenn ich das richtig sehe, erfreut sich bei der Arduino-Fraktion vor allem Fritzing einer besonders großen Beliebtheit. ;-)
Sheeva P. schrieb: > Gerhard O. schrieb: >> Sheeva P. schrieb: >>> Äh, das OpenSource-Programm ist KiCad, nicht Eagle. ;-) >> Warum müssen aber auch beide Programme mit ähnlichen Farben arbeiten, so >> daß man nur als erfahrener Benutzer den Unterschied erkennt? :-) > > Das ist eine Frage, die die Entwickler der betreffenden Software sicher > besser beantworten können als ich. Meine Vermutung wäre, daß sich diese > Farbgebung als eine Art Pseudostandard etabliert hat. > >> Die Arduino Faktion scheint aber hauptsächlich Eagle zu verwenden. Macht >> nichts, hab ja jetzt beide CAD Werkzeuge. > > Naja, wenn ich das richtig sehe, erfreut sich bei der Arduino-Fraktion > vor allem Fritzing einer besonders großen Beliebtheit. ;-) Eigentlich bezog ich mich auf publizierte Arduino Bord Designs im Internet. Fritzing sollte man definitiv nicht vewenden. Da ist sogar ein Photo eines sauber von Hand hingeskizzten Schaltplans besser presentierbar.
Possetitjel schrieb: > Ich finde den Wunsch, dass man nach zwei Stunden mit > Software B einigermaßen klarkommt, wenn man Software A > (die demselben Zweck dient) solide kennt, im Kern legitim. > > Wenn ich Excel kenne, komme ich mit LibreOffice Calc > einigermaßen klar. Mir fallen die Unterschiede auf, aber > ich kann sinnvoll damit arbeiten. Hm... nein, tut mir leid, aber da muß ich widersprechen. Bei einander sehr ähnlichen Programmen mit sehr ähnlichen Bedienkonzepten wie Excel und Libre Office Calc hast Du natürlich völlig Recht. Aber wenn ich da beispielsweise an handelsübliche UNIX-Editoren denke, wie meinen geliebten GNU Emacs und den nicht weniger leistungsfähigen vi(m): kein Emacs-User wird sich in zwei Stunden (oder auch nur in zwei Tagen!) einen vi(m) aneignen oder umgekehrt. Das ist aber in beiden Fällen keine Designschwäche, sondern einfach nur den völlig unterschiedlichen Bedienkonzepten geschuldet. > Das ist keine Katastrophe, aber man sollte anerkennen, > dass dieser Unterschied tatsächlich vorhanden ist, und > das nicht leugnen. Der Unterschied erscheint zwar vorhanden, ist es aber andererseits durch die benutzer-gelieferten Skripte dann auch wieder nicht. >> Das kann man einmal vorbringen -- und zwar idealerweise, >> ohne dann das ganze Projekt gleich als "schlecht konstruiert" >> abzuqualifizieren, ohne den Entwicklern eine "eingeschränkte >> Sicht" zu unterstellen, [...] > > Ich stimme Dir darin zu, dass W.S. seine Argumente dadurch > entwertet, dass sie übertrieben überspitzt formuliert sind. ...und auf die Gefahr hin, mich zu wiederholen, an der falschen Stelle. > Ich möchte dennoch dafür werben, sich primär auf den > korrekten sachlichen Gehalt zu fokussieren und nicht auf > die wenig zweckdienliche Form. Form follows function. ;-) > Jein... Missverständnis. Was unter Backward-Annotation > verstanden wird, ist gar nicht so eindeutig: > > Wenn es eine projektweite zentrale Datenbank gibt, dann ist > die Backward-Annotation lediglich ein Zugriff auf diese > Datenbank von einer ungewöhnlichen Stelle aus. Das ist ein > reines GUI-Thema; wenn User das haben wollen, soll(t)en > sie das bekommen. Ok, Du siehst diesen Aspekt wieder aus Deiner Perspektive mit einer zentralen Datenbank. Aber dann laß' uns doch eine modellieren! > Wenn Schaltplan und Layout aber getrennte Datenstrukturen > sind, sieht die Sache anders aus. Das wirft wieder ganz andere Probleme auf: die Synchronisation unter im Zweifelsfall parallelen Modifikationen an verschiedenen Stellen. Wie oben schon erwähnt: da sich solche Probleme nicht einmal dann vermeiden lassen, wenn der Datenspeicher auf nur einem einzelnen Host läuft, betreiben die Datenbänker einen enormen Aufwand für die Normalisierung. Ohne einen Mechanismus zur Synchronisation und Konfliktauflösung kannst Du nicht mehrere voneinander abhängige, duplizierte Datensätze konsistent halten. Deswegen braucht es in einem konsistenten Entwicklungsprozeß einerseits eine Deduplikation der Daten. In dem -- davon nur teilweise abhängigen -- Archivierungsprozeß hingegen ist hingegen eine Duplikation notwendig! > Ich bin nicht sicher. Im Gegensatz zu W.S. bin ich nicht > der Meinung, dass der Verzicht auf eine zentrale Datenbank > von vornherein ein Fehler ist, der auf mangelnde Überlegung > der Entwickler zurückzuführen ist. Im Gegenteil, es gibt > gute Gründe dafür -- auch wenn es mit einem Komfortverlust > für den Anwender verbunden ist. Das Problem scheint mir weniger das Vorhandensein oder die Absenz einer zentralen Datenbank zu sein, sondern vielmehr a) deren Design sowie b) deren Verwendung. Eigentlich bräuchte man nämlich zwei Datenbanken, eine für die konkrete Auswahl beim Erstellen von Schaltplänen und PCB-Layouts, und eine zweite für jedes konkrete Projekt. Die Projekt-Datenbank müßte dann die zum konkreten Zeitpunkt des Schaltplan- oder Platinenentwurfes genutzten Elemente enthalten. Das ist so ein bisschen wie die Rechnungslegung in einem Handelsgeschäft: die Angebote dürfen temporär referenzieren, Rechnungen dagegen müssen den zum Zeitpunkt der Rechnungslegung vorhandenen Datenstand behalten -- und müssen ihn daher beinhalten statt referenzieren. > Insofern... man sollte seine Wünsche als Anwender schon > in sinnvolle Relation zu den Zielen und Möglichkeiten > des Projektes setzen, und nix fordern, was offensichtlich > zu einer beschissenen Architektur führt... Dann, wie gesagt, laß' uns doch einfach etwas bauen.
Zeno schrieb: > Bernd Du sagst es - für Dich ist FB nicht wichtig. FratzenBuch? Du kommt sicher auch noch aus einer Zeit, als wir > die LP's mit Bleistift und Millimeterpapier gelayoutet haben. Ich muß > Dir jetzt nicht erzählen wie oft da Fehler unterlaufen sind und man dann > bei der fertigen Platte festgestellt hat, das trotz aller Sorgfalt doch > ein Leiterzug vergessen oder falsch verlegt wurde. Genau für die > Vermeidung von derartigen Fehlern ist FB ein Segen und ich persönlich > möchte darauf nicht mehr verzichten. Genau diese fehlende FB ist derzeit > für mich ein Hauptargument KiCAD ebennicht zu benutzen. Entschuldige, bitte laß' mich genauer verstehen, was "FB" ist. Du meinst damit, daß Du Eigenschaften (zB. Footprint) ein Bauelements im PCB-Layout änderst, und diese Änderung dann mehr oder weniger automagisch auch in den Schaltplan übernommen wird? Der konkrete Anwendungsfall ist also beispielsweise: Du hast im Schaltplan einen 1206 eingebaut, stellst aber beim Layout Deiner Platine fest, daß der verfügbare Platz nur für einen 0805 ausreicht. Also änderst Du den Footprint im Layout und erwartest, daß diese Änderung dann auch automatisch in Deinen Schaltplan übernommen wird. Korrekt?
Gerhard O. schrieb: > Sheeva P. schrieb: >> Naja, wenn ich das richtig sehe, erfreut sich bei der Arduino-Fraktion >> vor allem Fritzing einer besonders großen Beliebtheit. ;-) > > Eigentlich bezog ich mich auf publizierte Arduino Bord Designs im > Internet. Fritzing sollte man definitiv nicht vewenden. Da ist sogar ein > Photo eines sauber von Hand hingeskizzten Schaltplans besser > presentierbar. Ach, weißt Du, ich bin da völlig agnostisch. Fritzing hab' ich installiert und bisher für zwei oder drei Breadbord-"Layouts" benutzt und halte es für die Zielgruppe von Arduino sogar für sehr brauchbar. Für Profis (ich bin keiner) und ernsthafte Laien (vermutlich bin ich nicht einmal das) ist Fritzing aber sicher ungeeignet. Andere Zielgruppe und so. Edit: Wortwahl.
:
Bearbeitet durch User
Stefan schrieb: > Reicht es nicht aus in einem ECAD Programm etwas > herumzuklicken um sich eine Meinung dazu zu bilden. Dazu sind diese > Systeme zu komplex. Dem möchte ich ganz entschieden wiedersprechen. Nein, nicht der Tatsache daß viele dieser Systeme zu komplex seien. Aber, es ist eben kein Naturgesetz daß sie so komplex sein müssen. Und zweitens, gerade der Einstieg ist ein empfindlicher Lackmus-Test für vorhandene Software-Ergonomie, Komfort, die Anpassung an menschliche Intuition. Das zu beurteilen, dafür zählt gerade und ganz besonders die erste Meinung! Wir gehen im folgenden selbstverständlich davon aus, daß der Erstbenutzer einer ECad-Software genügend von Elektronik versteht und auch schon Leiterplatten in der Hand hatte. Was hier von Technokraten und Programmierern, die sehr gern nur die Details der Implementierung im Vordergrund sehen wirklich sehr sehr gern getan wird ist, die bei allen Unterschieden der Menschen eben doch vorhandene ähnliche Intuition bei der Bedienung von grafischer Programmen zu bestreiten, zu ignorieren, wegzudiskutieren. Gäbe es diese gemeinsame Intuitionsbasis nicht, die ja im wesentlichen auf gleichen Sinnen und zwei Händen beruht, wäre beispielsweise ein Apple mit seinen Geräten nicht so erfolgreich. Auf diese gemeinsame Intuition muß man eingehen. Das machen die einen besser, die anderen schlechter- und eben gerade nicht wie hier oft unterstellt nur unterschiedlich. Das bedeutet zweitens einen oft erheblichen programmtechnischen Aufwand, den die einen mehr, die anderen weniger betreiben. Ich möchte nicht verhehlen, daß ich die damit anzustrebende Simplizität der Bedienung bei Eagle weitaus eher und ausgereifter sehe als bei KiCad. Das im Groben zu beurteilen reicht definitiv bereits eine halbe Stunde Rumspielen mit dem Programm. Der Programmierer ist klug beraten, an diesem Punkt eine ganze Menge Knowhow zu investieren, schon um den potentiell Interessierten bei der Stange zu halten. Denn nicht jeder der Interessenten vermag diese Programmdefizite in gleicher Weise durch Mitdenken und Anpassungsfähigkeit auszugleichen- insofern sind die Menschen nun wieder sehr unterschiedlich. Simplizität heißt auch nicht Funktionsarmut. Es heißt sinnvolles Verstecken gerade nicht benötigter Features, natürliches Hinführen zu gebrauchten Arbeitsabläufen, mächtige Funktionalitäten die die Anzahl und den Umfang von Menüs und Optionseinstellungen eindämmmen und damit schlicht intelligenter sind. Das Ergebnis ist dann auch ein kürzeres Handbuch, weniger Tutorials, weniger Forenanfragen und Supportkontakte. Empfindliche Indikatoren für ein gutes Programm! Im Grunde muß das gewünschte Ergebnis (die Leiterplatte) im Vordergrund stehen und wie man schnellstmöglich dorthin gelangt. Vom Ende her denken ist da die Devise. Durch den starren Workflow ist der Anwender bei KiCad hier leider derzeit wesentlich festgelegter und gebundener, was ich persönlich als großen Nachteil empfinde. Der Einstieg in Eagle (damals noch in einer DOS-Version) war hingegen für mich schon eine echte Offenbarung- das Programm tat nämlich einfach genau das was man wollte :)
Simon H. schrieb: > 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. Dafür habe ich folgende Lösung: statt das Package gleich zu erstellen, nehme man einen beliebigen, ausreichend großen Footprint und wähle den Varianten-Namen "UNDEFINED". Dann clicke man die Pin-Pad-Verbindungen durch so dass alles irgendwie angeschlossen ist (ist ja harmlos, da man überhaupt noch kein Layout hat bzw. haben will). Dauert ca. 1 Minute. Dann kann man das Symbol in den Schaltplan übernehmen so als ob es überhaupt kein Board-File gäbe. Bzw. das ignoriert man. Und schon benutzt man EAGLE im KiCAD-Mode wo man erst den Schaltplan erstellt und später Footprints zuweisen muß... Die ganze Diskussion scheint sich drum zu drehen ob man einfach erst mal einen x-beliebigen (falschen) Footprint wählen muß (EAGLE) den man später korrigiert oder gar keinen (KiCAD) den man später erst setzt. Außerdem wird meist vergessen: Schaltplan erstellen ist nach meiner Erfahrung nur ein kleinerer Teil der Entwicklungsarbeit, bis ein Projekt in der Serienfertigung ist. Änderungen an einem fast fertigen Projekt ist das Aufwändigste. Also hier noch einen Chip durch ein anderes Gehäuse ersetzen, weil es doch billiger ist, einen weiteren Pin des µC auf einen Testpunkt ziehen usw. D.h. da sind Schaltplan und Layout "eigentlich" schon fertig und man muß den sauberen Wasserfall von "erst Schaltplan, dann Layout" verlassen. Gerade dann muß das CAD-Tool helfen und für Konsistenz sorgen und braucht völlig andere Funktionen als wenn man erstmalig mit einem Schaltplan anfängt.
:
Bearbeitet durch User
Helmut schrieb: > Dem möchte ich ganz entschieden wiedersprechen. > Nein, nicht der Tatsache daß viele dieser Systeme zu komplex seien. > Aber, es ist eben kein Naturgesetz daß sie so komplex sein müssen. Paint ist weniger komplex als Catia. Mit beiden kann man zeichnen, und Paint zeigt, dass es kein Naturgesetz ist, dass Programme komplex sein müssen. Trotzdem gibt es gute Gründe dafür, dass Catia komplexer ist als Paint. > Durch den starren Workflow ist der Anwender bei KiCad hier leider > derzeit wesentlich festgelegter und gebundener, was ich persönlich als > großen Nachteil empfinde. Meine Eaglezeit liegt lange zurück, deshalb bin ich für Angaben zur Funktionalität der letzten kaufbaren und der aktuellen Sektenversion auf die Beschreibungen der Anhänger angewiesen. Demnach scheint es mir, dass der Eagle Workflow starrer ist und Kicad mehr Flexibilität bietet. Letztlich ist es so: Irgendwann und irgendwie müssen bestimmte Dinge im Designprozess gemacht werden. Dafür gibt es verschiedene Ansätze. Was dem einzelnen Nutzer gefällt scheint nach den Diskussionen hier sehr unterschiedlich zu sein, erst recht, wenn man sich an einen Ablauf gewöhnt hat und nun umgewöhnen muss - und nicht will. Ist aber egal, solange jeder ein Programm hat mit dem er im Wesentlichen zufrieden ist. > Der Einstieg in Eagle (damals noch in einer > DOS-Version) war hingegen für mich schon eine echte Offenbarung- das > Programm tat nämlich einfach genau das was man wollte :) Fand ich auch toll für die damalige Zeit. Aber ganz intuitiv war es auch nicht, ein wichtiges Tastaturkommando fehlte in der Liste auf dem Schirm, ich weiß nicht mehr welches, aber ohne Handbuch wäre man nicht weiter gekommen. Heute würde ich mit dem DOS-Programm aber nicht mehr arbeiten wollen, nicht wegen DOS, sondern weil für heutige Ansprüche wichtige Funktionen fehlen. Es war halt ein Programm für Platinen mit übersichtlicher Komplexität. Gegängelt wurde man damals auch schon: Durch den Dongle, ich musste den Rechner weiter von der Wand wegziehen als auf dem damaligen Tisch angenehm war.
Nikolaus S. schrieb: > Gerade dann muß das CAD-Tool helfen und für Konsistenz sorgen und > braucht völlig andere Funktionen als wenn man erstmalig mit einem > Schaltplan anfängt. Kleine Off-Toppic" Frage dazu: Ist es bei Eagle 8+ immer noch so, dass Schaltplan und Layout unbedingt beide geöffnet sein müssen, wenn man Verbindungen, Packages ... ändert? (Ich bin bei Eagle 7 stehen geblieben und das ist hier für mich einer der größten Schwachpunkte, dass die Synchronität futsch ist und nicht automatisch wieder hergestellt werden kann. Bereitet trotz der irgendwann eingeführten gelb-schwarzen Warnbanderole unseren blauäugige Studierenden immer Mal wieder einige Extraarbeit ;-) Von der Software, die ich vor Eagle benutzt habe, war ich es gewohnt, dass ich jederzeit (auch nachträglich) Änderungen in beide Richtungen übernehmen konnte. Zukünftig will ich auch auf KiCad umsteigen. Ich finde es nicht ganz so dramatisch, wenn Änderungen nur im Schaltplan durchgeführt werden können. Auf jeden Fall viel akzeptabler, als wenn die Synchronität verloren gehen und nicht automatisch wieder hergestellt werden kann.
Gerhard O. schrieb: > Jetzt habe ich mich aber wirklich in die Nesseln gesetzt:-) Ist schon gut. :-) > Ich habe mir vor kurzem Kicad und Eagle installiert um mir selber ein > Bild machen zu können. Bei ersten Versuchen wurde mir gleich klar, daß > eine objektive Beurteilung nicht ohne eine gewisse Einarbeitung möglich > ist und werde mir zuerst einmal einige der vielen Tutorials im Internet > zu Gemüte führen. Ja guck sie Dir mal an und berichte von Deinen Eindrücken. Arbeiten kann man mit beiden Programmen, wer von Eagle zu Kicad wechseln will (darum geht es ja in diesem Thread), der schafft das. Und wer Gründe suchen will warum er das nicht kann, der wird ebenfalls fündig werden. > Da ich aktiv in der Open Source Bewegung beitragen > möchte, habe ich ein Interesse mit Eagle CAD Designs arbeiten zu können > weil nicht jeder Zugang zum Altium Format hat. Kicad ist das OS-Programm, und die offenen Dateistrukturen sind schön. Man kann auch Dinge im Texteditor richten, wenn man will. > Ich finde die Einarbeitung in ein anderes CAD Ökusystem schwierig weil > Vieles noch so vielen Jahren in Fleisch und Blut übergegangen ist. Beim > Rumspielen mit der frisch installierten Kicad fand ich mich sofort im > "Kampf" mit dem Programm das nicht so reagierte wie ich es gewöhnt bin. > Deshalb ist methodisches Einarbeiten absolut erforderlich. Bloßes > Rumspielen führt nur zu Enttäuschungen. Absolut! Auch wenn Kicad wie Eagle "Einsteigerklasse" sind (Xpedition kann viel mehr), so kommt man um eine methodische Einarbeitung nicht umhin. Doch wenn man neugierig auf das Programm ist macht das Spaß. > Schönen Sonntag noch, Ebenso!
Hallo Zeno. Zeno schrieb: > Du kommt sicher auch noch aus einer Zeit, als wir > die LP's mit Bleistift und Millimeterpapier gelayoutet haben. Jain. Ich habe alles auf Lochraster aufgebaut, und davon Handskitzzen angefertig. Meine erste Platine habe ich angefertigt, als ich auf dem Atari ST PCB (jetzt Bestandteil des gEDA Projektes) laufen lassen konnte. Die Netzliste dafür musste ich aber noch manuell erstellen. ;O) Platinen mit Tusche oder Aufreibesymbolen habe ich nie gemacht. > Ich muß > Dir jetzt nicht erzählen wie oft da Fehler unterlaufen sind und man dann > bei der fertigen Platte festgestellt hat, das trotz aller Sorgfalt doch > ein Leiterzug vergessen oder falsch verlegt wurde. Genau für die > Vermeidung von derartigen Fehlern ist FB ein Segen und ich persönlich > möchte darauf nicht mehr verzichten. Ich habe mich zur Minimierung solcher Fehler schon zu Lochrasterzeiten zu der Selbstdisziplin gezwungen, Änderungen zuerst im Schaltplan (auf einer Xerox Kopie des handezeichneten Schaltplanes) durchzuführen, bevor ich sie in Lochraster umgesetzt habe. Diese Vorgehensweise habe ich dann einfach später beibehalten. Bei PCB musste man das sowieso (wegen manuell erstellten der Netzliste, heute bietet das gEDA Projekt Tools dafür), und in frühen DOS Eagle Versionen auch. Ich weiss, dass die Backannotation irgendwann dann bei Eagle eingeführt wurde, und groß gefeiert wurde. Aber ich bin damit halt nur auf die Nase gefallen. Später bei Orcad und moderneren Eagle Versionen habe ich meinen "Workflow" einfach beibehalten. Funktionierte. Ich kann mich z.B. nicht erinnern, ob Orcad eine Backwardannotation überhaupt unterstützte. Ich habe sie einfach gewohnheitsmäßig nicht verwendet, und meine Arbeitskollegen auch nicht. Es gibt kaum einen Grund, Änderungen im Board zu machen, ohne sie vorher im Schaltplan durchgeführt zu haben. ich würde das eher als "chaotischen Arbeitsstil" interpretieren. ;O) Ok, es gibt möglicherweise Fälle, wo eine Annotation auf dem Board von z.B. links nach rechts und von oben nach unten sinnvoll ist. Aber wenn so etwas durchgeführt wird, ist dafür dann halt die Annotation im Schaltplan Kraut und Rüben. Es geht halt nicht, beides zugleich geordnet zu halten und dabei konsistent zu bleiben. Wenn ich die Wahl habe, und viel mit hierarchischen Schaltplänen mache, ist eine Annotation nach den hierarchischen Schaltplänen sehr sinnvoll, und das wird wiederum von KiCad gut unterstützt. > Genau diese fehlende FB ist derzeit > für mich ein Hauptargument KiCAD ebennicht zu benutzen. Dann bist Du ja eigentlich prädestiniert dazu, das von Sheva Plug oben erwähnte Backannotationsskript auf Anwendbarkeit zu Testen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Volker. Volker S. schrieb: > Ich finde es nicht ganz so > dramatisch, wenn Änderungen nur im Schaltplan durchgeführt werden > können. Richtig. Übrigens: KiCad hindert Dich nicht wirklich, wild im Board Footprints zu plazieren und wüst mit Leiterbahnen herumzumalen. > Auf jeden Fall viel akzeptabler, als wenn die Synchronität > verloren gehen und nicht automatisch wieder hergestellt werden kann. Aber wenn Du wie oben genannt vorgehst, must Du bei KiCad halt die Konsistenz zwischen Schaltplan und Board manuell herstellen. Genauso wie bei Eagle, wenn die Konsistenz einmal futsch ist. Ich habe mir das von Sheva Plug erwähnte Skript mal angesehen. Beim ersten Überfliegen sieht es so aus, als ob es nur die Annotation (also die Referenzbezeichner) im Board macht und auf den Schaltplan überträgt. Das bedeutet, im Board nachträglich gezogene Leiterbahnen werden nicht in den Schaltplan übertragen. Das wäre auch deutlich aufwändiger. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Aber wenn Du wie oben genannt vorgehst, must Du bei KiCad halt die > Konsistenz zwischen Schaltplan und Board manuell herstellen. Genauso wie > bei Eagle, wenn die Konsistenz einmal futsch ist. Ich bin jetzt, mit meinem KiCad Einstieg, noch nicht besonders weit gekommen. Deshalb kann es durchaus sein, dass ich es auch noch nicht richtig verstanden habe. Muss ich nicht einfach im KiCad Schaltplan die Netzliste auf den neuen Stand bringen und danach wieder im Layout einlesen? Bei Eagle (bis V7) hätte ich einfach verkackt?
:
Bearbeitet durch User
Hallo Volker. Volker S. schrieb: > Muss ich nicht einfach im KiCad Schaltplan die Netzliste auf den neuen > Stand bringen und danach wieder im Layout einlesen? Ja, das ist eine Möglichkeit, die in KiCad Konsistenz mit der Brechstange wieder herzustellen. ABER dann würden halt auch die Differenzen gelöscht, und Deine Änderungen im Board wären weg. Es sei, Du wählst explizit in dem Auswahlfenster an den entsprechenden Stellen "behalten" an. Dann werden die Änderungen im Board auch behalten, aber Du bist dann durch Einlesen der Netzliste halt auch nicht wieder konsistent geworden. Beides gleichzeitig geht halt nicht so einfach. > Bei Eagle (bis V7) hätte ich einfach verkackt? Bei Eagle 3 oder 4 war das so. Da ich mich anschliessend davor gehütet habe, änderungen im Board ohne vorherige Änderungen im Schaltplan zu machen, ist mir das halt später nie mehr passiert. Darum kann ich zu den späteren Eagle Versionen nichts sagen. Es sind aber mit Sicherheit Kompetentere in der Runde, die Dir Tipps geben können, wie Du das hinbiegst. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Übrigens: KiCad hindert Dich nicht wirklich, wild im Board Footprints zu > plazieren und wüst mit Leiterbahnen herumzumalen. Das finde ich furchtbar! Natürlich nicht nur bei KiCad, sondern überall. Alle halbwegs professionellen Tools sollten das nicht erlauben. Zuerst wird ein vernünftiger Schaltplan gezeichnet. Auf dessen Basis wird dann das Layout erstellt. Wenn das Layout-Modul die Möglichkeit bietet, Packages zu ändern, oder Gates zu Switchen (im 4fach OP, 74...) und diese Änderungen automatisch im Schaltplan übernommen werden, dann ist das super. Alles andere, außer den Änderungen von Gehäusebauformen oder das Tauschen von Gates ist meiner Meinung nach nicht sinnvoll. (Bestimmt habe ich aber noch eine Anwendung vergessen) Wenn ich mir gelegentlich Dokumentationen von Studierendenprojekten anschauen muss, die nur ein Layout ohne Schaltplan enthalten und die offensichtlich in einem Layouteditor zusammengeschustert wurden, weil z.B. in der Bibliothek keine passenden Bauteile (Symbole) vorhanden waren, könnte ich ausrasten ;-)
Sheeva P. schrieb: > Der konkrete Anwendungsfall ist also beispielsweise: Du hast im > Schaltplan einen 1206 eingebaut, stellst aber beim Layout Deiner Platine > fest, daß der verfügbare Platz nur für einen 0805 ausreicht. Also > änderst Du den Footprint im Layout und erwartest, daß diese Änderung > dann auch automatisch in Deinen Schaltplan übernommen wird. Korrekt? Ja das ist korrekt so, d.h. im Schematic wird das Symbol, welches sich natürlich nicht ändert, denn ein Kondensator bleibt ein Kondensator, mit einem neuen Footprint verknüpft. Man kann dies auch schnell nachprüfen, wenn sich im Schematik das mit dem Symbol verknüpfte Device (das ist in Eagle das Bauelement) anzeigen läßt. FB geht aber noch weiter, z.B. beim Pinswap oder Gateswap. Mal ein einfaches Beispiel: Du hast einen 7400 in Deiner Schaltung verbaut. Beim Layouten stellst Du fest das es günstiger ist beim 2. NAND die Eingänge zu vertauschen, weil sich so der Leiterzug besser verlegen läßt. Technisch ist dies ja kein Problem, da beide Eingänge funktionell identisch sind. Also tauschst Du einfach die beiden Eingänge mit einander. An der Logik der Schaltung hast Du damit aber nichts geändert. Aber die Konsistenz zwischen Layout und Schematic ist nicht mehr gegeben, da der Schaltplan ohne FB immer noch die alte Zuordnung der Pins enthält. Da wird es dann aber Bern "von der Leiter hauen" wenn er Signal A sucht welches lt. Schematic auf Pin 4 sein sollte, aber real auf Pin 5 ist weil der Layouter es geändert hat. Mit FB passiert genau das nicht, da wird der Schaltplan gleich mit geändert so das es passt. Gleiches passiert beim Gateswap, also wenn ich die Gatter des 7400 gegeneinander tausche. Oder ich stelle fest, das ich mich im Schematic vertan habe und an Stelle eines Widerstandes eigentlich einen Kondensator brauche. Dann ändere ich das im Schematic und wenn es die gleiche Bauform wie der Widerstand ist, dann ist es damit auch erledigt. Im Layout wird dann halt nur der Bestückungsdruck geändert, da sich am Footprint ja nichts geändert hat. Also genau deswegen empfinde ich FB als Segen, weil dadurch die Konsistenz von Schematic und Layout gewährleistet ist und ich oder Bernd eben nicht von der Leiter fallen, da real also auf der LP alles so ist wie im Schematic dargestellt.
Bernd W. schrieb: > Ja, das ist eine Möglichkeit, die in KiCad Konsistenz mit der > Brechstange wieder herzustellen. Ok, wenn du das als mit der Brechstange bezeichnest, dann habe ich es vermutllich wirklich noch nicht verstanden und es gibt einen eleganteren Weg. > ABER dann würden halt auch die Differenzen gelöscht, und Deine > Änderungen im Board wären weg. Es sei, Du wählst explizit in dem > Auswahlfenster an den entsprechenden Stellen "behalten" an. Dann werden > die Änderungen im Board auch behalten, aber Du bist dann durch Einlesen > der Netzliste halt auch nicht wieder konsistent geworden. Was für Änderungen im Board betreffen die Netzliste?
Zeno schrieb: > Beim > Layouten stellst Du fest das es günstiger ist beim 2. NAND die Eingänge > zu vertauschen, weil sich so der Leiterzug besser verlegen läßt. > Technisch ist dies ja kein Problem, da beide Eingänge funktionell > identisch sind. Also tauschst Du einfach die beiden Eingänge mit > einander. Das ist schon "cool", wenn man das im Layout machen kann und es wird in den Schaltplan übernommen. FAST genauso gut kann man es aber auch im Schaltplan machen und ins Layout übernehmen. Schön ist es natürlich, wenn es eine Funktion dafür gibt, die du auswählst, und dann einfach die zu tauschenden Pins oder Gates anklickst. Geht aber auch "manuell". Ist ja nicht so, dass man das 1000x am Tag braucht.
Nikolaus S. schrieb: > Dann kann man das Symbol in den Schaltplan übernehmen so als ob es > überhaupt kein Board-File gäbe. Du nimmst mir die Worte fast aus dem Munde. Man kann in Eagle Schaltpläne zeichnen und die Footprints erst mal völlig ignorieren. Dan hat man halt erst mal einen Schaltplan. Für kleinere Projekte die dann vielleicht noch auf Universalleiterplatte realisiert werden, mache ich das genau so. Die Footprints kommen ja erst ins Spiel, wenn ich das Board erzeuge und wenn es dann nicht passt kann ich es jederzeit ändern.
Volker S. schrieb: > Von der Software, die ich vor Eagle benutzt habe, war ich es gewohnt, > dass ich jederzeit (auch nachträglich) Änderungen in beide Richtungen > übernehmen konnte. Bernd W. schrieb: > Beides gleichzeitig geht halt nicht so einfach. Bei meiner obigen Aussage gilt natürlich, dass entweder nur Schaltplan oder Layout geändert ist. War man so blöd, Änderungen in beiden vorgenommen zu haben, dann musste man sich eben entscheiden welche einem wichtiger sind. Auf jeden Fall konnte man das aber auf Kommando wieder synchronisieren.
Zeno schrieb: > FB geht aber noch weiter, z.B. beim Pinswap oder Gateswap. Mal ein > einfaches Beispiel: Du hast einen 7400 in Deiner Schaltung verbaut. Beim > Layouten stellst Du fest das es günstiger ist beim 2. NAND die Eingänge > zu vertauschen, weil sich so der Leiterzug besser verlegen läßt. (...) > Gleiches passiert beim Gateswap, also wenn ich die Gatter des 7400 > gegeneinander tausche. Das wären wirklich Zeit sparende Funktionen. Eagle (Version 4.09 bis 7.7) kann das so gut wie nicht. Gateswap geht garnicht, beim Pinswap werden nicht die Pinnummern getauscht, sondern die Leitungen sind anschließend gekreuzt, müssen also manuell im Schaltbild repariert werden. Änderungen an der Netzliste sind vom Board aus nicht möglich. Praktisch mache ich bei Eagle also alle Änderungen erst im Schaltbild! Das einzig wirklich brauchbare ist die Sortierung der Bauteilbezeichnungen im Board, das wird mir bei KiCad fehlen. > Also genau deswegen empfinde ich FB als Segen, weil dadurch die > Konsistenz von Schematic und Layout gewährleistet ist und ich oder Bernd > eben nicht von der Leiter fallen, da real also auf der LP alles so ist > wie im Schematic dargestellt. Diese Konsistenz könnte man ohne Backannotation genauso gut und einfacher sicherstellen :)
:
Bearbeitet durch User
Hallo Volker. Volker S. schrieb: >> Übrigens: KiCad hindert Dich nicht wirklich, wild im Board Footprints zu >> plazieren und wüst mit Leiterbahnen herumzumalen. > > Das finde ich furchtbar! Natürlich nicht nur bei KiCad, sondern überall. > Alle halbwegs professionellen Tools sollten das nicht erlauben. Erlauben sollten sie das schon. Ich verwende Layoutprogramme halt auch gerne, um z.B. Etiketten oder Schilder zu machen. Dann existiert nur ein "Layout" ohne "Schaltplan" (Was sollte auch ein Schaltplan bei Etiketten für Eingemachtes). Andere machen mit Layoutprogrammen Frontplatten, Zifferblätter oder dergleichen. Und zwar durchaus auch Firmen. Ich sehe keinen Grund, diesen "Dual Use" zu unterbinden. > Zuerst wird ein vernünftiger Schaltplan gezeichnet. Auf dessen Basis > wird dann das Layout erstellt. Leute, die professionell Arbeiten, haben irgendwann gelernt, solche Kinken im Arbeitsfluss zu vermeiden. Denen muss man das nicht extra verbieten, allenfalls davor warnen, damit es nicht versehentlich passiert. Wenn sie es aber machen wollen, existiert vermutlich ein Grund dafür. > > Wenn das Layout-Modul die Möglichkeit bietet, Packages zu ändern, oder > Gates zu Switchen (im 4fach OP, 74...) und diese Änderungen automatisch > im Schaltplan übernommen werden, dann ist das super. Footprints zu ändern ist in KiCad kein Problem (solange Pin-Pad Nummerierung passt). Ansonsten gibt es bei Fehlern, sofern sie überhaupt vom Programm bemerkt werden können, Warnungen und Fehlermeldungen. Der Software Aufwand, die gates automatisch im Schaltplan zu tauschen, scheint recht hoch zu sein, wenn ich sehe, wie krampfhaft das bei Eagle abläuft. Dann vieleicht doch besser manuell. Oder per externem Skript, da lassen sich auch einige Fehlerquellen ausschliessen. > Alles andere, außer den Änderungen von Gehäusebauformen oder das > Tauschen von Gates ist meiner Meinung nach nicht sinnvoll. (Bestimmt > habe ich aber noch eine Anwendung vergessen) Nun, ich habe Leute kennengelernt, die zuerst ein Board/Lochraster machen und dann erst den Schaltplan. So genial bin ich aber nicht. Das würde bei mir katastrophal enden. > Wenn ich mir gelegentlich Dokumentationen von Studierendenprojekten > anschauen muss, die nur ein Layout ohne Schaltplan enthalten und die > offensichtlich in einem Layouteditor zusammengeschustert wurden, weil > z.B. in der Bibliothek keine passenden Bauteile (Symbole) vorhanden > waren, könnte ich ausrasten ;-) Nun, Studenten lernen ja auch noch, da erwarte ich keine Perfektion. ;O) Aber wenn die sich halt selber in solche Vorgängerprojekte hineinwühlen wollen, sehen sie selber, wie mistig fehlende Doku ist. Das kann lehrreich sein. Der Ärger fängt übrigens schon damit an, dass kein vernünftiges Datum in die Doku geschrieben wird. Das finde ich wichtiger als Rechtschreibung.....ok, ich gebe zu, ich habe diesbezüglich Zwangsvorstellungen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Volker S. schrieb: > Kleine Off-Toppic" Frage dazu: Ist es bei Eagle 8+ immer noch so, dass > Schaltplan und Layout unbedingt beide geöffnet sein müssen, wenn man > Verbindungen, Packages ... ändert? Nein die müssen nicht beide geöffnet sein. Man kann diese auch unabhängig voneinander öffnen, aber dann gibt es naturgemäß keine FB mehr und ich bin mit meinen Aktionen völlig frei. Das unabhängige Öffnen geht schon mindestens seit Version 4, man muß halt nur die Frage ob das zugehörige Bord/Schematic geöffnet werden soll mit Nein beantworten. Ohne FB habe ich dann wirklich alle Freiheiten. Da kann ich dann z.B. im Layout Leiterverbindungen richtig löschen, was er bei aktiver FB nicht erlaubt. Bei aktiver FB müssen Änderungen an den Netzen = grundlegende Änderung des Schaltplanes zwingend im Schematic durchgeführt werden. Bei aktiver FB gibt eine eigene Funktion im Layouteditor zum Entfernen von Leiterbahnen, welche nur die Leiterbahn im Layout entfernt bzw. selbige durch ungeroutete Verbindungen (in KiCAD sind das glaube ich die "Gummibänder")ersetzt. Das ist z.B. eine Funktion die sich mir nicht sofort (intuitiv) erschlossen hat. Enn man es dann geschnallt hat ist es kein Problem mehr.
Bernd W. schrieb: > Ich habe mich zur Minimierung solcher Fehler schon zu Lochrasterzeiten > zu der Selbstdisziplin gezwungen, Änderungen zuerst im Schaltplan (auf > einer Xerox Kopie des handezeichneten Schaltplanes) durchzuführen, bevor > ich sie in Lochraster umgesetzt habe. Ja Bernd, das habe ich auch immer so (versucht) zu machen. Aber Selbstdisziplin hin oder her, wir sind halt Menschen und machen Fehler. Man wird mal in seiner Arbeit unterbrochen und dann vergisst man einfach, das man noch dies und jenes ändern wollte. Ganz zu schweigen davon, das bei größeren Projekten die Übersicht verloren geht und man dann im Liniengewirr auf dem Papier eben doch etwas übersieht.
Hallo volker. Volker S. schrieb: >> Ja, das ist eine Möglichkeit, die in KiCad Konsistenz mit der >> Brechstange wieder herzustellen. > > Ok, wenn du das als mit der Brechstange bezeichnest, dann habe ich es > vermutllich wirklich noch nicht verstanden und es gibt einen eleganteren > Weg. Eleganter? Die Alternative wäre, das ganze manuell zu machen. Per Neueinlesen der Netzliste drüberbügeln geht halt schneller, aber die Änderungen, so Du sie dann willst, müsten dann halt schon im Schaltplan existieren. D.h. du kommst eigentlich um eine Schaltplananpassung nicht herum. Wenn das aber gemacht ist, stellt das Einlesen der Netzliste (ohne "behalten") sicher, dass das Board dem Schaltplan entspricht. >> ABER dann würden halt auch die Differenzen gelöscht, und Deine >> Änderungen im Board wären weg. Es sei, Du wählst explizit in dem >> Auswahlfenster an den entsprechenden Stellen "behalten" an. Dann werden >> die Änderungen im Board auch behalten, aber Du bist dann durch Einlesen >> der Netzliste halt auch nicht wieder konsistent geworden. > > Was für Änderungen im Board betreffen die Netzliste? Geänderte Footprints, zusätzliche Footprints und abweichende Verbindungen. Zusätzliche Footprints sind nicht so abwegig wie du denkst, weil es durchaus sinnvoll ist, z.B. ein Logo (Firma, Warninweis Hochspannung oder ESD ec.) als Footprint einzubinden. Ich selber vertrete den Standpunkt, dann dazu auch ein entsprechendes Symbol in den Schaltplan zu stellen (hätte auch den Vorteil, dass es nicht so leicht vergessen wird) und ein Einlesen der Netzliste dann auch ein vieleicht versehentlich gelöschtes Logo wieder herbeibringt. Aber das sehen nicht alle so. Die stellen lieber aus dem Bauch heraus das Logo auf die Platine und sind dann formal schon wieder inkonsistent. Was ich z.B. auch gerne mache, ist einen Platinenumriss als Footprint anzulegen, und dann dafür ein extra Symbol formal in den schaltplan zu machen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Zeno schrieb: > Nein die müssen nicht beide geöffnet sein. Man kann diese auch > unabhängig voneinander öffnen, aber dann gibt es naturgemäß keine FB > mehr und ich bin mit meinen Aktionen völlig frei. Ja klar. Mein Problem ist doch, was dann mit der Annotation passiert. Unwiderruflich im Ar... oder eben nicht. Ist das in V8 besser geworden? (Nicht das ich V8 noch in Erwägung ziehen würde)
:
Bearbeitet durch User
Volker S. schrieb: > Das ist schon "cool", wenn man das im Layout machen kann und es wird in > den Schaltplan übernommen. FAST genauso gut kann man es aber auch im > Schaltplan machen und ins Layout übernehmen. Genau das macht Eagle wegen FB automatisch, d.h. Du kannst auch im Schaltplan ändern und das Ganze wird ins Layout übertragen.
Hallo Zeno. Zeno schrieb: >> Ich habe mich zur Minimierung solcher Fehler schon zu Lochrasterzeiten >> zu der Selbstdisziplin gezwungen, Änderungen zuerst im Schaltplan (auf >> einer Xerox Kopie des handezeichneten Schaltplanes) durchzuführen, bevor >> ich sie in Lochraster umgesetzt habe. > > Ja Bernd, das habe ich auch immer so (versucht) zu machen. Aber > Selbstdisziplin hin oder her, wir sind halt Menschen und machen Fehler. Oh ja. > Ganz zu schweigen davon, das bei größeren Projekten die Übersicht > verloren geht und man dann im Liniengewirr auf dem Papier eben doch > etwas übersieht. Für diese Fälle gibt es ja nun bei Platinenlayoutprogrammen die Vorwärts -Annotation, deren Segen ich nie bestritten habe. ;O) Aber die Diskussion ging eben um die "Backannotation". Wenn sie jemand unbedingt haben will, ok, aber als überragend wichtig schätze ich sie halt persönlich nicht ein. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Volker S. schrieb: > Zeno schrieb: >> Nein die müssen nicht beide geöffnet sein. Man kann diese auch >> unabhängig voneinander öffnen, aber dann gibt es naturgemäß keine FB >> mehr und ich bin mit meinen Aktionen völlig frei. > > Ja klar. Mein Problem ist doch, was dann mit der Annotation passiert. > Unwiderruflich im Ar... oder eben nicht. Ist das in V8 besser geworden? > > (Nicht das ich V8 noch in Erwägung ziehen würde) In V7 ist erstmal alles im A... Aber man bekommt eine Liste mit den einzelnen Unterschieden und kann die Konsistenz manuell wieder herstellen. Die Liste gibt's im Schaltplan-Fenster, aber man kann auch im Board ändern.
Bauform B. schrieb: > Das wären wirklich Zeit sparende Funktionen. Eagle (Version 4.09 bis > 7.7) kann das so gut wie nicht. Gateswap geht garnicht, beim Pinswap > werden nicht die Pinnummern getauscht, sondern die Leitungen sind > anschließend gekreuzt, müssen also manuell im Schaltbild repariert > werden. Also ab der 6.5 geht das definitiv. Das die sich danach erstmal kreuzen ist doch logisch, weil du änderst ja die Anordnung und ja man muß es hinterher gerade ziehen. Es ist schon ein Unterschied ob ein Leiterzug an Pin 1 oder 2 geht. Wenn ich's beim Layouten machen dann muß ich es halt im Schaltplan noch anpassen, weil's Schei.. aussieht. Meckern würde er da nicht weil die Schaltung ja trotzdem korrekt ist. Umgekehrt würde er im Layout sehr wohl meckern, wenn sich durch Swaping im Schematic Leiterzüge überkreuzen. Du kannst das natürlich ignorieren aber Deine Leiterplatte wird dann einfach nur Schrott. Ohne FB wären jetzt Schaltung und Bord inkonsistent, was an der Funktion ja nicht unbedingt was ändern muß, aber den "armen" Bernd wird es von der Leiter hauen, wenn er seine Signale nicht dort findet wo sie lt. Schematic sein sollten. Natürlich kann man auch auf FB verzichten aber dann muß man sehr sehr diszipliniert arbeiten, so wie das Bernd beschrieben hat und vorgibt zu tun. Allerdings kann ich mir nur sehr schwer vorstellen, das manda bei größeren Projekten den Überblick behält - ich würde das von mir nicht behaupten wollen. Und ja es wird in KiCad funktionieren, wenn man alle Änderungen im Schaltplan macht, danach die Netzliste erzeugt/exportiert und selbige dann im Board wieder einliest. Ich persönlich halte das für keine glückliche Lösung und finde an dieser Stelle FB einfach zuverlässiger, aber wenn man diszipliniert arbeitet führt sicher auch der andere Weg zum Ziel. Also jeder so wie er mag.
Bauform B. schrieb: > Änderungen an der Netzliste sind vom Board aus nicht möglich. Praktisch > mache ich bei Eagle also alle Änderungen erst im Schaltbild! Das einzig > wirklich brauchbare ist die Sortierung der Bauteilbezeichnungen im > Board, das wird mir bei KiCad fehlen. Na den Namen kannst Du ändern. Aber generelle Änderungen an Netzliste, sprich neue elektrische Verbindungen im Layout machen, ist schon Harikiri. Das ist aus gutem Grund verboten. Bei einem ganz Projekt mag das vielleicht möglich sein aber das will man nicht wirklich.
Bauform B. schrieb: > Diese Konsistenz könnte man ohne Backannotation genauso gut und > einfacher sicherstellen :) Wie denn bitte?
Hallo Helmut, > Was hier von Technokraten und Programmierern, > ... > Im Grunde muß das gewünschte Ergebnis (die Leiterplatte) im Vordergrund > stehen und wie man schnellstmöglich dorthin gelangt. Vom Ende her denken > ist da die Devise. Der für mich mit Abstand beste Beitrag in dieser Diskussion. Helmut, du hast das Problem genau auf den Punkt gebracht. rhf
Volker S. schrieb: > Ja klar. Mein Problem ist doch, was dann mit der Annotation passiert. > Unwiderruflich im Ar... oder eben nicht. Ist das in V8 besser geworden? Wenn Du im Layout ein Bauelement löschst, was nur bei inaktiver FB geht, dann sind beine inkonsistent und das läßt sich wie es scheint auch nicht so einfach beheben. Wenn ich beim Öffnen bewußt FB umgehe und dann gravierende Änderungen vornehme habe ich offensichtlich im wahrsten Sinne des Wortes verkackt. Aber das Thema interessiert mich selber und ich werde da noch mal intensiv nachforschen. Könnte mir vorstellen, das es da ein Script oder ULP gibt um das zu reparieren.
Bauform B. schrieb: > In V7 ist erstmal alles im A... Aber man bekommt eine Liste mit den > einzelnen Unterschieden und kann die Konsistenz manuell wieder > herstellen. Die Liste gibt's im Schaltplan-Fenster, aber man kann auch > im Board ändern. Das ist mir alles sonnenklar. Die Frage ist, tut sich da was? Also die Synchronisation auf Knopfdruck, bei der die Software alle Unterschied bereinigt! (War eben "Damals" eine herbe Enttäuschung, dass das mit Eagle nicht geht) <edit> Zeno schrieb: > Könnte mir vorstellen, das es da ein Script oder > ULP gibt um das zu reparieren. Hmmm, könnte sein ;-) BTW: wofür steht bei dir FB? Forward-Backward-(Annotation)?
:
Bearbeitet durch User
Zeno schrieb: > Bauform B. schrieb: >> Diese Konsistenz könnte man ohne Backannotation genauso gut und >> einfacher sicherstellen :) > > Wie denn bitte? Mit Forward-Annotation? Wenn man beides hat, ist das eben ein bisschen "luxuriöser" ;-)
W.S. schrieb: > Nein, wenn all die Kicad-Leute jedes Nicht-Lobeswort auf Kicad als > persönlichen Affront ansehen, dann kommt hier garnix zuwege. Das erinnert mich sehr stark an diverse Linux-Threads. Wenn man da mal sagt: Aber das und das an Linux ist Mist, ist "dann bleib doch bei Deinem Windows" noch das harmloseste, die Leute schaffen es nicht, Kritik an einem technischen System von Kritik an sich selbst zu trennen. Zeno schrieb: > Wenn Du im Layout ein Bauelement löschst, was nur bei inaktiver FB geht, > dann sind beine inkonsistent und das läßt sich wie es scheint auch nicht > so einfach beheben. Wenn ich beim Öffnen bewußt FB umgehe und dann > gravierende Änderungen vornehme habe ich offensichtlich im wahrsten > Sinne des Wortes verkackt. Ja, aber Eagle warnt seit mindestens V6 ganz groß und breit davor. Es geht auch gr nicht anders, wenn das BE im Layout weg ist, sind Schaltung und Layout nunmal nicht mehr konsistent. Beheben kann man das je nach Aufwand: Ein fehlendes BE im Layout kann man im Layout - bei geschlossenem Schematic - wieder einfügen und gibt ihm dann exakt die gleiche Bezeichnung wie im Schematic. Es muss natürlich aus der gleichen Lib stammen. Dann Schematic öffnen und prüfen: Geht. Ich hab schon Layouts mit mehreren hundert derartigen Fehlern repariert, weil jemand ein Bauteil nur im Schematic geändert hatte. War immer noch schneller als das Layout neu zu machen.
Zeno schrieb: > Wenn Du im Layout ein Bauelement löschst, was nur bei inaktiver FB geht, > dann sind beine inkonsistent und das läßt sich wie es scheint auch nicht > so einfach beheben. Doch, du musst es nur im Schaltbild auch löschen. > Wenn ich beim Öffnen bewußt FB umgehe und dann > gravierende Änderungen vornehme habe ich offensichtlich im wahrsten > Sinne des Wortes verkackt. Wenn es sehr viele Änderungen sind, geht es wahrscheinlich schneller, von vorne anzufangen. Aber es lässt sich durchaus reparieren, alles nur eine Frage der Geduld. > Könnte mir vorstellen, das es da ein Script oder > ULP gibt um das zu reparieren. Das kann ich mir garnicht vorstellen. Woher soll das Programm wissen, bei welcher Änderung der Schaltplan und wann das Layout aktuell ist? Zeno schrieb: > Bauform B. schrieb: >> Das wären wirklich Zeit sparende Funktionen. Eagle (Version 4.09 bis >> 7.7) kann das so gut wie nicht. Gateswap geht garnicht, beim Pinswap >> werden nicht die Pinnummern getauscht, sondern die Leitungen sind >> anschließend gekreuzt, müssen also manuell im Schaltbild repariert >> werden. > > Also ab der 6.5 geht das definitiv. Das die sich danach erstmal kreuzen > ist doch logisch, weil du änderst ja die Anordnung und ja man muß es > hinterher gerade ziehen. Es ist schon ein Unterschied ob ein Leiterzug > an Pin 1 oder 2 geht. Wie geht ein Gateswap im Board? Das suche ich seit Jahren. Dass sich die Leitungen kreuzen ist überhaupt nicht logisch. Eagle könnte einfach die Pinnummern tauschen, dann ist eben Pin 2 oben und nicht mehr Pin 3.
Volker S. schrieb: > Also die Synchronisation auf Knopfdruck, bei der die Software alle > Unterschied bereinigt! Ähm ja, Entschuldigung: Woher soll die Software wissen, ob das noch vorhandene Bauteil im Layout oder das fehlende Bauteil im Schematic jetzt richtig sind? Oder ob die im Layout verwendete Lib oder die im Schematic jetzt die bessere ist? Dieses Problem ließe sich sofort umgehen, wenn man Schematic und Layout in einer Datei speichert. Aber das will man offenbar auch bei Kicad aus anderen Gründen nicht.
Karl schrieb: > Ähm ja, Entschuldigung: Woher soll die Software wissen, ob das noch > vorhandene Bauteil im Layout oder das fehlende Bauteil im Schematic > jetzt richtig sind? Man kommt auf solche Ideen, wenn man mal eine Software benutzt hat, die das eben konnte. Hier war es einfach so, dass es darauf ankam in welchem Modul man auf synchronisieren gelickt hat. Ob das dann der Chef war, oder of die Datem in diesem auf das andere Synchronisiert wurden, weiß ich gar nicht mehr. Stand aber als Hinweis auf der entsprechenden Schaltfläche...
Bernd W. schrieb: > Aber die Diskussion ging eben um die "Backannotation". Wenn sie jemand > unbedingt haben will, ok, aber als überragend wichtig schätze ich sie > halt persönlich nicht ein. Kannst Du auch nicht, weil Du Deinen eigenen Aussagen nach nie damit gearbeitet hast. Ich mein, was soll das?
Also mal Butter bei die Fische? Wie nehme ich in Kicad ein einzelnes Symbol auf? Erstmal einen Rahmen drumziehen kann es wohl nicht sein. Wenn ich in Kicad eine Baugruppe markiere und verschieben will, habe ich eine Kopie in schlechter Strichzeichnung. Das Original bleibt auf dem Blatt. Verschiebe oder zoome ich das Blatt, ist das Original plötzlich weg. Häh? Setze ich die verschobene Baugruppe ab, sind alle vorherigen Leiterverbindungen abgerissen. Wie verschiebe ich eine Baugruppe oder ein Bauteil, ohne dass ich es danach erneut verbinden muss? Wie verbessere ich die verpixelten Schriften im Schematic?
Karl schrieb: > Bernd W. schrieb: >> Aber die Diskussion ging eben um die "Backannotation". Wenn sie jemand >> unbedingt haben will, ok, aber als überragend wichtig schätze ich sie >> halt persönlich nicht ein. > > Kannst Du auch nicht, weil Du Deinen eigenen Aussagen nach nie damit > gearbeitet hast. > > Ich mein, was soll das? Es sind ja durchaus auch noch andere da, die das auch nicht als oberste Priorität sehen. Ob jetzt forward- oder back- Annotation, was macht das schon groß für einen Unterschied? Bauform B. schrieb: > Wie geht ein Gateswap im Board? Das suche ich seit Jahren. Geht das etwa nicht? (Ok, habe ich offensichtlich in EAGLE auch noch nie danach gesucht, aber in einer anderen Software durchaus schon mal benutzt...)
:
Bearbeitet durch User
Karl schrieb: > Also mal Butter bei die Fische? > > Wie nehme ich in Kicad ein einzelnes Symbol auf? Erstmal einen Rahmen > drumziehen kann es wohl nicht sein. Also ich würde mich persönlich noch als blutigen Anfänger bezeichnen, aber das habe ich schon raus bekommen ;-) Maus drüber und [m] oder [g]. Man kann natürlich auch umständlich über Pop-Up Menü... > Wenn ich in Kicad eine Baugruppe markiere und verschieben will, habe ich > eine Kopie in schlechter Strichzeichnung. Das Original bleibt auf dem > Blatt. Verschiebe oder zoome ich das Blatt, ist das Original plötzlich > weg. Häh? Also bei mir verhält es sich anders. Das Original bleibt bis zum Ablegen sichtbar. Das mit der schlechte Strichzeichnungen kann ich auch nicht nachvollziehen. > Setze ich die verschobene Baugruppe ab, sind alle vorherigen > Leiterverbindungen abgerissen. Wie verschiebe ich eine Baugruppe oder > ein Bauteil, ohne dass ich es danach erneut verbinden muss? Wenigstens im Schaltplan könnten die Signale verbunden bleiben. (nicht die Linien) ((Vieleicht mache ich aber was falsch)) Im Layout macht es vermutlich nicht oft Sinn den für die Realisierung dieses Features notwendigen Aufwand zu treiben, solange es noch andere Baustellen gibt ;-) > Wie verbessere ich die verpixelten Schriften im Schematic? Verpixelt? Bei mir sieht das verglichen mit anderen Saystemen nicht ungewöhnlich aus. <edit> Die Version, mit der ich spiele, verrate ich natürlich nicht ;-)
:
Bearbeitet durch User
Wenn das auch etwas abseits vom augenblicklichen Thema liegt würden mich Eure Erfahrungen mit mechanischen Möglichkeiten und Notwendigkeiten im Zusammenhang mit Kicad und Eagle interessieren da es für mich sehr wichtig ist. Zu oft werden nur rein PCB technische Belange diskutiert. Ich baute mir Mitte der 90er Jahre eine CNC Gravier Maschine zur Leiterplattenherstellung welche die Leiter Isolation fräst, Löcher bohrt und die LP herausfräst. Dazu verwendete ich früher Tango PCB und dann Pr99se. Die Maschine verwendet software von den Vorgängern der LPKF Geräte die noch von Jürgen Sebach (IBC-Boardmaker 912) entwickelt wurde. Das System verwendet Gerber Daten zur Erstellung der CAM Daten die dann zur Maschinensteuerung im HP-GL Format ausgegeben werden. Es hat sich herausgestellt, daß sich Pr sehr gut für mechanische Design Arbeiten eignet weil manuelles Arbeiten ohne Nets und Schaltbild nicht behindert wird. Mit DXF Import kann ich auch andere mechanische CAD Inputs verwenden. Bitte nicht vergessen, daß die üblichen mechanisches CAD Werkzeuge ja keine Gerber Daten erzeugen. Dieser mechanische Aspekt ist sehr wichtig. Da da noch andere Gesichtspunkte ins Spiel kommen. Zum Beispiel erstellte ich die Frontplatte vom LNG30 NT mit Frontdesigner im Gravor Modus. Die erzeugten DXF Daten importierte ich in Pr. Dort erzeugte ich ein Komposit Design von Frontplattengravur und allen Loch Aussparungen. Diese ganzen Layers wurden dann wie bei PCB Design in Gerber Daten ausgegeben und als Eingabe für das CAM Program benuzt. Dieses CAM Programm stellt auch sicher dass alle Segmente für richtiges Arbeiten der Maschine in der richtigen Reihenfolge ablaufen und auch Werkzeug Durchmesser korrekt kompensiert werden. Mit diesen CAM Program stellte ich dann einzelne Maschinen Steuerungsdateien her für Schriftgravur, alle Lochausparungen der Frontplatte, das Herausfräsen der eigentlichen Gravurfrontplatte mit der Beschriftung sowie die unterliegende mechanische Frontplatte. Damit wurde sicher gestellt, das alle Teile perfekt zusammenpassten. Deshalb ist das PCB Program als Zentral Koordinations Werkzeug so wichtig weil so Skalierungs und Positionsfehler vollkommen ausgeschlossen werden können. Für alle diese Arbeiten ist also das PCB CAD Programm ein wichtiger, unersetzlicher Bestandteil meines Arbeitsprozesses. Das PCB CAD verwende ich auch oft zur Herstellung mechanischer 2D Teile einschließlich Herstellung von Zahnrädern mit Gearotic als Frontend zum Design von involuten Zähnen. (In meiner PCB Library habe ich sogar fertige Zahnräder zur Erstellung von Getrieben) Auch Rotationssymmetrische Strukturen kann man so leicht anfertigen. (die So gefertigten Zahnräder laufen absolut präzise und ruhig) Bei solchen Arbeiten ist es unbedingt notwendig, daß das CAD sich keine Eigenmächtigkeiten erlaubt und sich vollkommen passiv verhält und nur meine Anweisungen ohne Interpretation und ohne Zwischenfragen ausführt. Auch kommt es oft vor, daß man DXF Hersteller Zeichnungen von Gehäuseteilen importieren möchte um zum Beispiel eine LP präzise für ein bestimmtes Gehäuse anzupassen. Das stellt sicher, dass Befestigungslöcher durch Koordination Kopieren genau plaziert werden können und LCD Displays genau auf schon vorhandene Gehäuseausparungen geschoben werden können. Ich finde es angenehm, daß ich mit Hilfe vom PCB CAD Programm sowohl Mechanik und PCB mechanisch präzise integrieren kann ohne Skalierungs oder Koordinatenfehler befürchten zu müssen und ich den gesammten Prozess auf meine Werkzeuge abgestimmt zu haben. Ich bitte übrigens zu berücksichtigen, daß sich trotz des hohen Alters mit der durchdachten Original Maschinen Software sehr gut arbeiten läßt. Die alte MSDOS Maschinensteuerungssoftware ist in meinen Augen ein Meisterstück von J. Sebach. Deshalb verwende ich nicht MACH3 und Co. weil eine Gesamt Prozess Modernisierung einfach für mich zu aufwendig und zeitfressend ist. Wenn auch die angeführten Punkte nicht oft berücksichtigt werden, sind sie für mich persönlich emminent wichtig. Deshalb interessiert mich diesbezüglich die Flexibiltät von Eagle und Kicad im Zusammenarbeiten mit externen mechanischen Werkzeugen. Aber da muß ich erst mal die Grundlagen beider Programme erlernen um mir davon ein Bild machen zu können. Sorry, wenn ich vom Haupt Thema momentan abwich. Aber wie gesagt, mechanische Flexibilität der PCB Software ist für mich von ganz besonderer Bedeutung. Ich hoffe zumindest meine Geschichte hier war nicht ganz uninteressant.
Bauform B. schrieb: > Wie geht ein Gateswap im Board? Das suche ich seit Jahren. Genauso wie im Schematic.
Bauform B. schrieb: > Dass sich die Leitungen kreuzen ist überhaupt nicht logisch. Eagle > könnte einfach die Pinnummern tauschen, dann ist eben Pin 2 oben und > nicht mehr Pin 3. Macht er ja auch, aber er ändert deswegen die Zeichnung nicht.
Volker S. schrieb: > Ob jetzt forward- oder back- Annotation, was macht das > schon groß für einen Unterschied? Nicht oder. Und. Wenn man nie damit gearbeitet hat, wird man sicher nicht verstehen, was es ausmacht. Aber warum zum Henker versucht man dann anderen Leute, die seit Jahren damit arbeiten zu erklären, dass sie das nicht brauchen? Das ist wie... A: Ich hab hier ein tolles Schreibprogramm. B: Hat es eine Druckfunktion? A: Du musst nicht drucken, Du kannst die Seite als PS exportieren und das PS kannst Du dann drucken. C: Du bekommst ein kostenloses Schreibprogramm, was willst Du denn noch? B: Ich will drucken, so wie ich es von meinem bisherigen Schreibprogramm kenne. D: Ich hab noch nie was drucken müssen. E: Druckfunktion ist völlig überwertet. ... to be continued.
Karl schrieb: > Wenn man nie damit gearbeitet hat, wird man sicher nicht verstehen, was > es ausmacht. Aber warum zum Henker versucht man dann anderen Leute, die > seit Jahren damit arbeiten zu erklären, dass sie das nicht brauchen? Ich habe damit gearbeitet und tue es immer noch. Ich will auch niemand davon überzeugen, dass er es nicht braucht. Wenn die Möglichkeit da ist benutze ich sie. Es ist lediglich kein Ausschlusskriterium für mich, wenn ich die Änderung nur im Schaltplan machen kann. Juckt mich persönlich eben so gut wie gar nicht. Falls das irgendwo so rüber kam, dass ich irgendwen von irgendwas überzeugen möchte, dann habe ich mich missverständlich ausgedrückt...
:
Bearbeitet durch User
Hallo Karl. Karl schrieb: > Das ist wie... > A: Ich hab hier ein tolles Schreibprogramm. > B: Hat es eine Druckfunktion? > A: Du musst nicht drucken, Du kannst die Seite als PS exportieren und > das PS kannst Du dann drucken. > C: Du bekommst ein kostenloses Schreibprogramm, was willst Du denn noch? > B: Ich will drucken, so wie ich es von meinem bisherigen Schreibprogramm > kenne. Was regst Du dich auf? Vorausgesetzt, dass Programm ist sonst gut.... Ich lege von allem, was ich schreibe onehin eine Kopie in PDF *)hin. Warum sollte ich die nicht auch zum Ausdrucken nehmen? > D: Ich hab noch nie was drucken müssen. > E: Druckfunktion ist völlig überwertet. Richtig. Druckfunktion wird überbewertet. ;O) Ich besitze seit irgendwann um 2000 mein alter Star 9 Nadler aus den 80ern den Geist aufgegeben hat, keinen Drucker mehr. Tintenstrahlpatronen würden bei mir entweder austrocknen oder vom wöchentlichen Testausdruck um Düsen frei zu halten leergedruckt. Laserdrucker stauben ein und machen dann ein komisches Druckbild. Immer aus- und wieder einpacken kostet Zeit. Für das dutzend Ausdrucke im Jahr kann ich besser in einen Laden gehen und ausdrucken lassen. Wenn es mal am WE sein müsste, lasse ich gegen eine Tasse Kaffe auch bei Freunden mal ausdrucken. Irgendwer ist immer Bilderfetischist und hat beste Druckausrüstung. Und selbstverständlich lege ich dafür eine PDF Datei an. PS war mal, Du soltest Dein Flamewar Handbuch mal aktualisieren. Das muss noch von vor der Jahrtausendwende sein. ;O) *) und zwar als PDF/A-1a für Archivierungszwecke. Dann kann man darin auch problemlos markieren und kopieren. Und das kann nicht nur Libre Office, sondern auch Microsoft Office. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Und das kann nicht nur Libre > Office, sondern auch Microsoft Office. Da fällt mir wieder einer der Gründe ein mich von Microsoft Office zu verabschieden. Das aht ne Weile immer so komisch Sachen mit den Seitenzahlen beim Drucken veranstaltet. 1/1, 2/2, 3/3.... Beim Exportieren als PDF hat es seltsamer Weise gepasst. MS-Office hatte aber im Gegensatz zu OO zu der Zeit noch keinen PDF Export integriert... <edit> der Hauptgrund für den Wechsel, war natürlich eher Software zu verwenden,die auf allen gängigen OS läuft. Wenn möglich auch Open source. Eagle war bisher auch ganz OK. Kein Problem damit, dass durch die Benutzung in unseren Laboren quasi kostenlose Werbung bei den Studierenden dafür gemacht wurde. Das neue Lizenzmodell gibt aber den letzten Schubs es mit dem Wechsel zu probieren.
:
Bearbeitet durch User
Hallo Gerhard . Gerhard O. schrieb: > Wenn auch die angeführten Punkte nicht oft berücksichtigt werden, sind > sie für mich persönlich emminent wichtig. Klar. > Deshalb interessiert mich > diesbezüglich die Flexibiltät von Eagle und Kicad im Zusammenarbeiten > mit externen mechanischen Werkzeugen. Aber da muß ich erst mal die > Grundlagen beider Programme erlernen um mir davon ein Bild machen zu > können. Nun, ich kann an dem Punkte nur über KiCad berichten. Aktuelle KiCad Versionen können wrl und Step Daten einlesen und dann mit der Leiterplatte verarbeiten und als wrl oder IDF format exportieren. Step Export in der Version 4 funktioniert noch nicht. Vieleicht kann aber jemand, der Version 5 hat näheres dazu berichten. wrl ist zum Rendern und Darstellen in einer Präsentation ideal und gibt die besseren Oberflächen zum anschauen, ist aber wegen der Dreiecksflächen ungenau und als Datei dann aufgeblasen. Das Format kommt ursprünglich aus der Videospiel Ecke. Darum kann man auf der eben fertiggerouteten Platine zur Entspannung auch eine Runde Counterstrike spielen. ;O) IDF ist ein Spezialformat um die mechanischen Abmessungen einer Leiterplatte weiterzugeben. Habe ich aber noch nie verwendet. STEP bildet "solids" ab, und ist demzufolge kompakt und sehr genau, ideal für die mechanische Fertigung. Wenn man etwas zur CNC Bearbeitung oder zum 3D Druck gibt, kenne ich es als übliches Format. Ebenso für FEM-Simulationen. > Sorry, wenn ich vom Haupt Thema momentan abwich. Aber wie gesagt, > mechanische Flexibilität der PCB Software ist für mich von ganz > besonderer Bedeutung. Ich hoffe zumindest meine Geschichte hier war > nicht ganz uninteressant. Als das mit dem 3D in KiCad eingeführt wurde, habe ich mir auch gedacht "ganz nett, aber was soll das?" Dann habe ich aber auch gesehen, das ich meinen Chef leichter von etwas überzeugen kann, wenn ich ihm ein Video zeige, wo sich die fertiggeroutete Platine als 3D Modell aufreizend dreht. Und aktuell macht die Entwicklung (mit Altium) nichts, ohne ein STEP Modell zu erzeugen mit dem man testen kann, ob sich auch alles gut zusammenbauen lässt. Mittlerweile schicken Kunden komplette STEP Modelle von Schaltschränken, die man virtuell zerlegen kann. Die Thematik wird also nicht nur bei Dir immer wichtiger. Eagle kann das grundsätzlich auch irgendwie. Aber das soll Dir jemand erzählen, der sich mit einem aktuellen Eagle auskennt. Es wäre unfair, wenn ich meine uralt Eagle Kenntnisse als aktuellen Stand ausgeben würde. Privat verwende ich für 3D Cad Wings3D (schön einfach, quasi das 3D Paint) und wenn es etwas mehr sein muss, FreeCAD oder BRL Cad. BRL Cad ist aber eine Sache für sich. Ich nehme es meistens nur zum konvertieren von Formaten, die FreeCad noch nicht kennt. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Wenn es mal am WE sein müsste, lasse ich gegen eine Tasse Kaffe auch bei > Freunden mal ausdrucken. Ja, das kenne ich auch: Kein Auto und jedem erzählen wie gut man damit klar kommt, braucht man alles nicht. Und dann angedackelt kommt... "Kann ich mal Dein Auto haben." Wenn ich nicht wüsste, wie lange Du schon im Forum unterwegs bist, würde ich sagen, Du denkst Dir diese Geschichten extra aus. Obwohl, das eine schließt ja das andere nicht aus.
Karl, so langsam kommen mir deine Beiträge auch seltsam vor ;-)
Karl schrieb: > Wenn ich nicht wüsste, wie lange Du schon im Forum unterwegs bist, würde > ich sagen, Du denkst Dir diese Geschichten extra aus. Obwohl, das eine > schließt ja das andere nicht aus. Richtig. das eine schliesst das andere nicht aus. Darum muss sich halt jeder selber ein Bild machen, was stimmt oder nicht. Am besten durch praktische Versuche, denn der Augenschein oder das Bauchgefühl sind leicht zu manipulieren, wie man gerade in diesem Thread beobachten kann. grinz Ansonsten liebe ich es tatsächlich Geschichten zu schreiben: https://www.mikrocontroller.net/attachment/244314/Traum_Nummerngirls_November2007.pdf Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Volker S. schrieb: > so langsam kommen mir deine Beiträge auch seltsam vor Ja angefangen hat das damit, dass ich weiter oben irgendwann mal gefragt habe, ob Kicad inzwischen FB-Anno kann. Ich wollte das einfach nur wissen, weil es vor ein paar Jahre noch abgelehnt wurde. Seitdem versuchen mir Leute mehr oder weniger aussschweifend zu erklären, dass ich das nicht brauche und warum ich das nicht brauche. Das ist schon irgendwie witzig - aber nicht sehr zielführend.
Karl schrieb: > Volker S. schrieb: >> Ob jetzt forward- oder back- Annotation, was macht das >> schon groß für einen Unterschied? > > Nicht oder. Und. > > Wenn man nie damit gearbeitet hat, wird man sicher nicht verstehen, was > es ausmacht. Aber warum zum Henker versucht man dann anderen Leute, die > seit Jahren damit arbeiten zu erklären, dass sie das nicht brauchen? > > Das ist wie... > A: Ich hab hier ein tolles Schreibprogramm. > B: Hat es eine Druckfunktion? > A: Du musst nicht drucken, Du kannst die Seite als PS exportieren und > das PS kannst Du dann drucken. > C: Du bekommst ein kostenloses Schreibprogramm, was willst Du denn noch? > B: Ich will drucken, so wie ich es von meinem bisherigen Schreibprogramm > kenne. > D: Ich hab noch nie was drucken müssen. > E: Druckfunktion ist völlig überwertet. > ... to be continued. Karl ja länger Du erzählst was Dein KiCad so macht, desto mehr vermute ich das wir bei Backward-Annotation unterschiedliche Meinungen haben was das eigentlich ist bzw. sein sollte. Die Forward-Annotation ist ein im KiCad ein eigentlich nicht zu umgehender Arbeitsschritt. Danach erfolgt das erstellen der Netzlistendatei für PCB. Liest man in PCB diese Datei ein, bringt die Kiste alle Footprints angewürgt, es sei denn es findet einen nicht. Die müssen dann platziert werden und man kann routen, so weit so gut. Wenn ich jetzt ein Footprint ändern möchte, lösche ich auf der Platine den aktuellen Footprint, gehe in den Schaltplaneditor, editiere das Bauelement..verpasse ihm ein anderes Footprint, mache eine neue Annotation (vorhandenes Bezeichner behalten) und lese die danach erstellte Netzliste wieder mit PCB ein. Das führt dazu das PCB nun nur einen einzelnen Footprint zum platzieren anbietet und man da weiterarbeiten kann. Du kannst beliebig viele Footprints und Leiterbahnen löschen, das einlesen der Netzliste bringt die wieder. Auf diese Weise könnte evtl. für Euch nachvollziehbar sein warum nicht nur Bernd behauptet die Backward-Annotoation braucht man nicht. Das soll nicht bedeuten das wir alle Eagle User für blöde halten, sondern das sich auf die Art erreichen läßt was man eigentlich möchte. Den Kram mit Deiner schlechten Strichzeichnung kann ich auch nicht nachvollziehen. BTW: Kennst Du die Unterschiede zwischen Legacy-, OpenGL- und Cairo (F9,F11,F12) Canvas (view heißt das in der Version 5.x)? Die sind nicht nur unterschiedlich in der Bedienung, sondern auch deutlich unterschiedlich in den Features.. Ehe hier Kritik kommt: der Legacy-Modus ist aus Kompatibilitätsgründen noch enthalten, weiterentwickelt werden nur OpenGL- und Cairo Modus und so lange nocht nicht alle Features des Legacy Mode funktionieren, bleibt der noch da. OpenGL arbeitet mit Hardwarebeschleunigung der Bildschirmtreiber, Cairo ist OpenGL ohne Beschleunigung. ..unter einer funktionierenden Backward Annotation verstehe ich eigentlich das was hier schon angesprochen wurde.. Pin oder Gate Swap im PCB Editor. wenn das in Eagle verboten ist....??? was fehlt dann eigentlich? In den neueren KiCAD PCB Versionen gibt es einen Knopf "Update PCB from Schematic" der den ganzen Kram automatisiert... Ich habe meistens beide Fenster (Schaltung und PCB) gleichzeitig offen. Es ist so kein Mehraufwand einen Footprint im Schaltplan statt im Layout zu ändern. Gruß, Holm
Hallo Holm. Holm T. schrieb: > Den Kram mit Deiner schlechten Strichzeichnung kann ich auch nicht > nachvollziehen. Ich erinnere mich dumpf, dass in der KiCad Usergroup anno 2010 rum solche Probleme diskutiert wurden. auch die kaputten verzerrten Schriften, die er erwähnt und auch Druckprobleme. Das waren tatsächlich mal echte Fehler. Was ich aber jetzt nicht verstehe, warum er fast ein Jahrzehnt später immer noch Probleme von damals hat, obwohl die für alle anderen längst gelöst sind. Zeitschleife? Uralt Rechner noch mit XP von damals? Langsame Reaktionen? Wer weiss..... grinz Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
@Karl Wenn man sich deine Beiträge so durchliest, kommt man zu dem Schluss, dass du zu einer kleinen, versprengter, orientierungslosen Eagle Usergruppe gehörst die irgendwie Ersatz suchen aber nicht bereit sind sich anzupassen. Nach dem Motto: Bitte ich möchte gern die neue Wurst aber die sollte ganz genau so schmecken wie die Alte - das wird nicht funktionieren. Wenn du nicht bereit bist dich anzupassen wird dich die "..Cad - Evolution" gnadenlos aussortieren. Mehr wie die Hälfte schafft das (sihe Thread-Verlauf), die anderen verkümmern zur Bedeutungslosigkeit. Ein gutes Beispiel für eine gelungene Anpassung an die neuen CAD Zeiten ist übrigens Bernd.W. der Geschichtenschreiber ;-) Der hat den Wechsel schon 2009 geschafft, in einer Zeit wo du bestimmt noch mit Fotoapparaten von Fred Feuerstein gespielt hast :-)
Holm T. schrieb: > Wenn ich jetzt ein Footprint ändern möchte, lösche ich auf der Platine > den aktuellen Footprint, gehe in den Schaltplaneditor, editiere das > Bauelement..verpasse ihm ein anderes Footprint, mache eine neue > Annotation (vorhandenes Bezeichner behalten) und lese die danach > erstellte Netzliste wieder mit PCB ein. Das führt dazu das PCB nun nur > einen einzelnen Footprint zum platzieren anbietet und man da > weiterarbeiten kann. Und wenn Du einmal mit FB-Anno von Eagle gearbeitet hättest, würde Dir das unglaublich umständlich vorkommen. Ganz abgesehen davon - steht das neue Footprint dann an der gleichen Stelle wie das alte, oder muss ich es neu platzieren? Sprich, wenn ich 20 Widerstände von 1206 auf 0805 ändern will, muss ich die dann alle wieder neu platzieren? Holm T. schrieb: > Den Kram mit Deiner schlechten Strichzeichnung kann ich auch nicht > nachvollziehen. Ich mein das wie im Bild. > BTW: Kennst Du die Unterschiede zwischen Legacy-, OpenGL- und Cairo > (F9,F11,F12) Canvas (view heißt das in der Version 5.x)? Das ist aber Layout, ich rede vom Schematic. Bei mir läßt sich OpenGL ("Moderner Grafikmodus") nur für Layout einstellen.
Ich habe mal eine ganz andere Frage zum Lizenzmodell von Eagle: Bei einem anderen Kind von Autodesk (ob nun ebenfalls adoptiert oder nicht, weiss ich nicht), nämlich Fusion360, haben die eine sehr interessante Art, ihre Lizenzen zu vergeben. Man kann sie ebenfalls mieten, nicht kaufen. Soweit so gleich. Ebenfalls gibt es eine kostenlose Demoversion. Die kann aber alles, was die "grosse" kann. Läuft aber nach einiger Zeit ab. Soweit so unspektakulär. Dann gibt es noch die Möglichkeit, die Software dauerhaft umsonst zu nutzen. Nämlich, wenn man a) Student ist (ebenfalls unspektakulär), oder, und jetzt kommt das Interessante, wenn man Hobbyist ODER Kleinunternehmer mit weniger als 100'000$ Jahresumsatz ist. Ich frage mich, warum die das bei Eagle nicht machen. Der einzige Grund, das zu tun, der mir in den Sinn kommt ist: Kundenbindung. Fusion360 soll wohl im Profibereich Einzug halten. Das Geld für abgespeckte Versionen, die sich Hobbyisten leisten, wollen die nicht. Sie wollen, dass die Hobbyisten das Tool kennen und lieben lernen, damit sie es später in beruflich einsetzen. Warum aber nicht bei Eagle? Dazu ist zu sagen, dass aus meiner Sicht für Eagle eine mindestens so gute FOSS-Alternative existiert. KiCad. Für Fusion360 nicht. FreeCad kommt mir als einzige FOSS-SW in den Sinn, aber die ist noch lange nicht erwachsen (sagen ja sogar die Verantwortlichen). Käufliche Alternativen in jeglicher Preisklasse gibt es sowohl für Fusion360 als auch für Eagle. Was meint Ihr? BTW: Ich würde wohl auch bei KiCad bleiben, wenn Eagle für Hobbyisten umsonst wäre. Es interessiert mich aber grundsätzlich.
:
Bearbeitet durch User
KiCadSuperman schrieb: > Wenn du nicht bereit bist dich anzupassen wird dich die "..Cad - > Evolution" > gnadenlos aussortieren. Wenn Kicad die CAD-Evolution ist... geschenkt. Bisher sehe ich nur, wie Kicad versucht einige Dinge von Eagle und anderen Ecad-Programmen zu kopieren, was aber nicht recht gelingt, weil man sich zu Anfang verrannt hat und jetzt nicht von den Altlasten lassen kann. Und sich dann die Unmöglichkeit der Umsetzung mit "braucht man nicht" schönredet. Und natürlich muss sich eine neue Software an vorhandener messen lassen. LibreOffice hat das geschafft, weil sie sich sehr an MS Office orientiert haben und MS gleichzeitig viele Leute mit Ribbons und so Kram verstört haben. Und weil LibreOffice auf die gute Vorarbeit von StarOffice und OpenOffice aufbauen konnte. Sowas fehlt Kicad anscheinend.
Hallo Karl. Karl schrieb: > Ganz abgesehen davon - steht das neue Footprint dann an der gleichen > Stelle wie das alte, oder muss ich es neu platzieren? Sprich, wenn ich > 20 Widerstände von 1206 auf 0805 ändern will, muss ich die dann alle > wieder neu platzieren? Der neue Footprint wird mit seinem Ursprung an die gleiche Stelle eingefügt, wie der Ursprung des alten Footprints. Die Orientierung wird beibehalten. D.h. bei SMD Bauteilen liegt der Ursprung im allgemeinen im Symmetriepungt (Mitte) und bei nicht symmetrischen Footprints wird halt die Mitte durch halbieren der Abmessungen bestimmt. Wenn die Footprints also nach den Vorgaben der kiCad Library gemacht sind, liegt ein SMD Bauteil wie ein 0805 dann an exakt der gleichen Position wie der 1206 Vorgänger. Allerdings ist ja 0805 kleiner als 1206. Die Leiterbahnen müssen darum u.U. etwas nachgezogen werden. Komplizierter ist es aber bei THT, weil bei THT der Ursprung auf Pin 1 liegt. D.h. Pin 1 neu liegt an gleicher Stelle wie Pin 1 alt mit gleicher Orientierung. Pin 1 passt also, aber wenn halt das neue Bauteil kleiner oder größer ist, passt dann halt Pin 2 nur so ungefähr und die leiterbahn muss nachgezogen werden. Klappt so natürlich nur bei sauberen Bibliotheken. *) Ursprung in der Mitte bei SMD und auf Pin 1 bei THT und dieses Verhalten ist übrigens üblich bei sehr vielen Layout Programmen. Das ist jetzt keine KiCad spezifische Geschichte. >> Den Kram mit Deiner schlechten Strichzeichnung kann ich auch nicht >> nachvollziehen. > > Ich mein das wie im Bild. Ah, dass ist ein Sprite(?) damit du erkennen kannst, wie die verschobene oder kopierte Gruppe passt, und die sollte auch anders aussehen als das Original, damit klar ist, was Original und Kopie ist, und sie muss auch nicht so detailiert wie das Original sein, sonst ist kaum noch was zu erkennen. ;O) *) Das KiCad Library Projekt ist aus dem KiCad Projekt ausgegliedert. "Saubere Bibliotheken" meint hier nach der KiCad Library Convention: https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Auch wenn es schon spät ist, das möchte ich nicht so stehen lassen. Vier Bilder sagen hoffentlich mehr als n Worte. Zeno schrieb: > Bauform B. schrieb: >> Wie geht ein Gateswap im Board? Das suche ich seit Jahren. > > Genauso wie im Schematic. Zeno schrieb: > Bauform B. schrieb: >> Dass sich die Leitungen kreuzen ist überhaupt nicht logisch. Eagle >> könnte einfach die Pinnummern tauschen, dann ist eben Pin 2 oben und >> nicht mehr Pin 3. > > Macht er ja auch, aber er ändert deswegen die Zeichnung nicht.
Hallo Karl. Karl schrieb: > Und natürlich muss sich eine neue Software an vorhandener messen lassen. Und natürlich muss sich auch alte Software an der neuen messen lassen. ;O) Es gibt kein grundsätzliches Vorrecht für alteingesessene Platzhirsche. ;O) > LibreOffice hat das geschafft, weil sie sich sehr an MS Office > orientiert haben und MS gleichzeitig viele Leute mit Ribbons und so Kram > verstört haben. Libre Office war auch immer einen Tacken handlicher als MS Office, die wohl zu sehr einer firmeninternen Doktrin zu folgen hatten, was gut und schlecht ist, weil sie sich zusehr an ihren eigenen Altversionen orientiert haben, und konsistent mit ihren Altversionen bleiben wollten, damit ihnen die alten Kunden nicht weglaufen...... > Und weil LibreOffice auf die gute Vorarbeit von > StarOffice und OpenOffice aufbauen konnte. StarOffice war ursprünglich mal eine kommerzielle Version (Sun?). Ich erinnere mich, mal eins irgendwann bei Aldi für 10 Mark gekauft zu haben, weil in der Firma nicht genug MS Office Lizenzen für alle waren, und ich legal bleiben wollte. ;O) Erst später wurde Staroffice zuerst frei und dann zu open Office. Als dann das hickhack um den Verbleib von open office losging (Sun? HP? wollten die loswerden), hat sich libre Office abgespalten, und so gut wie alle Programmierer sind zu libre office übergelaufen. soviel zum Thema Vorarbeit...es waren halt in weiten Bereichen die gleichen Leute. > Sowas fehlt Kicad anscheinend. Schau Dir mal ganz alte KiCad Schaltplan- und Boarddateien an. Das riecht alles ganz stark nach gEDA. Die Boarddateien sind dann überarbeitet worden, und heraus kam dann eine Lisp/symbolischer Ausdruck verwande Notation. Weise Entscheidung, lässt sich gut drauf parsen. Nur neu ist das alles nicht, es wurden Erfahrungen von überall her zusammengetragen. Auch von Eagle, Protel, Altium, Genesys und anderen. Google mal, irgendwo müssen die alten Diskussionen noch liegen. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Simon H. schrieb: > Ich frage mich, warum die das bei Eagle nicht machen. Ja, das habe ich mich auch schon gefragt. Ich vermute AD wartet ab ob Eagle als Eigenständiges Produkt läuft (mit uC.net Lesern kann man wohl keine Weiterentwicklung finanzieren), oder ob es mal nur als Fusion360 Zusatzmodul vermarktet wird. Da wäre eine freie (Fast)Vollversion für <100k Umsatz schon cool. EDA ist eh nur noch eine kleine Zusatzfunktion im großen Getriebe einer Produktentwicklung.
Karl schrieb: [..] und MS gleichzeitig viele Leute mit Ribbons und so Kram > verstört haben. Koinzidenz der Ereignisse? SCNR, Holm PS: zur Sache morgen wieder..., gn8
Karl schrieb: > Bisher sehe ich nur, wie Kicad versucht einige Dinge von Eagle und > anderen Ecad-Programmen zu kopieren, was aber nicht recht gelingt, weil > man sich zu Anfang verrannt hat und jetzt nicht von den Altlasten lassen > kann. Das ist jetzt keine Unterstellung, aber man hat den Eindruck, dass du bei W.S. abgeschrieben hast :-( Karl schrieb: > Und sich dann die Unmöglichkeit der Umsetzung mit "braucht man > nicht" schönredet. Wenn du damit das "Back -Zeugsel" meinst, das braucht man wirklich nicht. Wenn man sich erfolgreiche Designer und Entwickler anschaut, die blicken immer nach vorne_ und nicht _back ;-) Ansonsten muss ich sagen, du wirkst heute ganz friedlich :-)
Bauform B. schrieb: > Auch wenn es schon spät ist, das möchte ich nicht so stehen lassen. Vier > Bilder sagen hoffentlich mehr als n Worte. > > Zeno schrieb: >> Bauform B. schrieb: >>> Wie geht ein Gateswap im Board? Das suche ich seit Jahren. >> >> Genauso wie im Schematic. > > Zeno schrieb: >> Bauform B. schrieb: >>> Dass sich die Leitungen kreuzen ist überhaupt nicht logisch. Eagle >>> könnte einfach die Pinnummern tauschen, dann ist eben Pin 2 oben und >>> nicht mehr Pin 3. >> >> Macht er ja auch, aber er ändert deswegen die Zeichnung nicht. Entschuldigung.. aber das hat mit Backward Annotation überhaupt nichts zu tun. Die heißt ja Backward weil die vom PCB Layout aus rückwärts auf den Schaltplan wirkt. Das hier ist ein normaler Schalplan Edit Vorgang den man in Eeschema auch durch Mirroring oder Austausch des Gates erreichen kann. Gruß, Holm
ZF schrieb: > Helmut schrieb: > Dem möchte ich ganz entschieden wiedersprechen. > Nein, nicht der Tatsache daß viele dieser Systeme zu komplex seien. > Aber, es ist eben kein Naturgesetz daß sie so komplex sein müssen. > > Paint ist weniger komplex als Catia. Mit beiden kann man zeichnen, und > Paint zeigt, dass es kein Naturgesetz ist, dass Programme komplex sein > müssen. Trotzdem gibt es gute Gründe dafür, dass Catia komplexer ist als > Paint. Die Kritik hast Du nicht verstanden. Paint ist vor allem nur deshalb weniger komplex weil es den geringeren Funktionsumfang bietet. Es ging ja gerade um den Vergleich von Programmen ähnlichen Funktionsumfangs. Auch Du scheinst stur davon auszugehen daß Komplexität allein linear vom Funktionsumfang/Arbeitsablauf abhängt- genau das aber wurde ja bestritten. Volker S. schrieb: > Bernd W. schrieb: > Übrigens: KiCad hindert Dich nicht wirklich, wild im Board Footprints zu > plazieren und wüst mit Leiterbahnen herumzumalen. > > Das finde ich furchtbar! Natürlich nicht nur bei KiCad, sondern überall. > Alle halbwegs professionellen Tools sollten das nicht erlauben. Doch. Genau das sollten sie. > Wenn ich mir gelegentlich Dokumentationen von Studierendenprojekten > anschauen muss, die nur ein Layout ohne Schaltplan enthalten und die > offensichtlich in einem Layouteditor zusammengeschustert wurden, weil > z.B. in der Bibliothek keine passenden Bauteile (Symbole) vorhanden > waren, könnte ich ausrasten ;-) Warum tun die Studenten das? Weil sie schnellstmöglich zu einem genügenden Ergebnis kommen wollen! Sollte eine gute Software nicht genau das ermöglichen? Das sollte Dir wirklich zu denken geben. Da es mir fürs Hobby auch genügt, gleich das Layout zu machen weil man den Schaltplan locker im Kopf behalten = später aus dem Layout auslesen kann (und die Projektkomplexität bei den vielen MC-Schaltungen heute sowieso schon auf die Software ausgelagert ist) brauch ich kein ECad Programm was mich in althergebrachte "Workflow" - Bahnen presst. Allein im Layout entscheidet sich doch sowieso Wohl und Wehe- wie die die Bauteile zusammenpassen und manchmal rückwirkend sogar wie der Schaltplan sein muß. Ich würde für meine minder schaltungskomplexen Projekte eher die umgekehrte Reihenfolge bevorzugen: Das Programm generiert mir den Schaltplan aus dem Layout!
Hier nochmal aus meiner Sicht mit KiCad Symbol gespiegelt..kein Neu zeichnen. Danach Die Verschiebung eines markierten Block mit Drag und nicht mit Move.. @Karl: Da Du dieses Orientierungsbildchen im gerade zu bearbeitenden Block als Problem ansiehst kann ja keiner ahnen..wie Bernd schrieb dient das nur der Orientierung. ..und das verhindert das Du KiCad einsetzen kannst? Echt jetzt? Gruß, Holm
Helmut schrieb: [..] > > Allein im Layout entscheidet sich doch sowieso Wohl und Wehe- wie die > die Bauteile zusammenpassen und manchmal rückwirkend sogar wie der > Schaltplan sein muß. Ich würde für meine minder schaltungskomplexen > Projekte eher die umgekehrte Reihenfolge bevorzugen: Das Programm > generiert mir den Schaltplan aus dem Layout! ..türlich hast Du Recht. Niemand, auch KiCad hindert Dich nicht im Straßenverkehr mit dem PKW ausschließlich rückwärts zu fahren. Gruß, Holm
Holm T. schrieb im Beitrag #5356882 > ..türlich hast Du Recht. Niemand, auch KiCad hindert Dich nicht im > Straßenverkehr mit dem PKW ausschließlich rückwärts zu fahren. Aber wenn man tatsächlich auf diese Weise am schnellsten vorwärts kommt?
Helmut schrieb: > Holm T. schrieb im Beitrag #5356882 >> ..türlich hast Du Recht. Niemand, auch KiCad hindert Dich nicht im >> Straßenverkehr mit dem PKW ausschließlich rückwärts zu fahren. > > Aber wenn man tatsächlich auf diese Weise am schnellsten /vorwärts/ > kommt? Deine Frage hört sich für mich ein Bisschen an wie "..wenn der Topf aber nun ein Loch hat, lieber Heinrich was dann?" Ich sach doch, kannste gerne versuchen..(Polizei wird Dich hochfädeln und nicht etwa bestrafen, die wollen nur ne Gebühr von guten Kunden). Da es aber nicht allzuviele Leute mit Deiner Ansicht gibt, ist dieser Pfad in den Programmen nicht implementiert...also das Auslesen einer Netzliste aus einer Malerei. Prinzipiell funktionieren würde das schon, auch wenn der Schaltplan wahrscheinlich nicht dem entsprechen würde was ein menschlicher Elektroniker in etwa erwartet. Gruß, holm
@Bernd: IMHO hatte das alte DOS OrCAD eine Backannotate-Funktion, für Annotate und Backannotate gab es meiner Meinung nach 2 extra Exen im Programmverzeichnis. Ich habe noch Disketten aus DDR Zeiten mit dem alten Zeuch, das habe ich damals auf einem Ec1834 ..einem XT-artigen laufen gehabt. die SUN Software Openoffice die von Staroffice abstammte ist mit andrem Zeuch (Java!) von Sun an Oracle gegangen. Da aber Larry Ellison genau wie unser ÖR über alle Maßen geldgeil ist hat man ihm die Entwicklung faktisch wieder aus der Hand genommen in dem man das Opensource-Projekt nicht zu seinen Konditionen weiter geführt, sondern geforkt hat. Gruß, Holm
Holm T. schrieb: > Helmut schrieb: > Holm T. schrieb im Beitrag #5356882 > Prinzipiell funktionieren würde das schon, > auch wenn der Schaltplan wahrscheinlich nicht dem entsprechen würde was > ein menschlicher Elektroniker in etwa erwartet. Genau auf diesem Niveau zu erstellen wäre eine Funktion, die ein leistungsfähiges=komfortables Programm haben sollte. Und der Schaltplan könnte immer gängigen Standards entsprechen. Ich möchte das aber nicht als einzig sinnvollen Weg verstanden wissen. Dem Schaltungsdesigner sollten vielmehr alle Möglichkeiten offenstehen.
Helmut schrieb: > Holm T. schrieb: >> Helmut schrieb: >> Holm T. schrieb im Beitrag #5356882 >> Prinzipiell funktionieren würde das schon, >> auch wenn der Schaltplan wahrscheinlich nicht dem entsprechen würde was >> ein menschlicher Elektroniker in etwa erwartet. > > Genau auf diesem Niveau zu erstellen wäre eine Funktion, die ein > leistungsfähiges=komfortables Programm haben sollte. Und der Schaltplan > könnte immer gängigen Standards entsprechen. > Ich möchte das aber nicht als einzig sinnvollen Weg verstanden wissen. > Dem Schaltungsdesigner sollten vielmehr alle Möglichkeiten offenstehen. Wo ist das Problem? Mach eine Ausschreibung und bezahle die Entwicklung, dann gibts das. Ein anderer Weg wäre ausreichend fähige Leute privat zu begeistern die sich hinsetzen und das für Dich (und die möglicherweise 2 weiteren Interessenten) in ihrer Freizeit erledigen.. Gruß, Holm
Holm T. schrieb: > ..unter einer funktionierenden Backward Annotation verstehe ich > eigentlich das was hier schon angesprochen wurde.. Pin oder Gate Swap im > PCB Editor. > wenn das in Eagle verboten ist....??? was fehlt dann eigentlich? Habe auch nochmal nachgeschaut: Gateswap geht zumnidest bis 7.5 im Layout nicht. Pinswap schon. Rätselhaft, aber kann man(ich) ja im Schaltplan machen ;-) Sehr, sehr oft benutze ich allerdings die Änderung des Package im Layout. Helmut schrieb: > Warum tun die Studenten das? Weil sie schnellstmöglich zu einem > genügenden Ergebnis kommen wollen! Das Ergebnis ist meiner Meinung nach absolut ungenügend. Das sehen auch Studierende erst mal so, wenn sie eine solche Dokumentation bekommen und an dem Projekt weiterarbeiten sollen. Leider wird dann meistens trotzdem "schnellstmöglich" genau so weiter gepfuscht und das Ergebnis wird mit jedem Folgeprojekt ungenügender. Irgendwann ist es dann auch bei noch so kleinem Umfang, so Schei..., dass es komplett neu gemacht werden muss ;-) Im Endeffekt steckt bei dem chaotischen Vorgehen oft viel mehr Arbeit drin, als wenn es von Anfang an "richtig" gemacht worden wäre. Das merkt dann auch fast jeder nachdem er erst mal einige Projekte so vergeigt hat. Weil das aber keiner von Anfang an einsieht, wäre es eben meiner Meinung nach gar nicht schlecht, wenn professionelle Software solchen "Murks" zumindest erschweren und nicht fördern würde.
Volker S. schrieb: > Im Endeffekt steckt bei dem chaotischen Vorgehen oft viel mehr Arbeit > drin, als wenn es von Anfang an "richtig" gemacht worden wäre. > Das merkt dann auch fast jeder nachdem er erst mal einige Projekte so > vergeigt hat. Wenn Projekte so vergeigt werden (was auch immer das im Einzelfall bedeuten mag), es also tatsächlich auf ein ungenügendes Ergebnis hinausläuft, reicht dann nicht die einfache Vorgabe an die Studenten: Mit Schaltplan? Aus meiner eigenen Praxis weiß ich aber: Ohne explizit erstellten Schaltplan kann auch genügen und muß definitiv nicht auf "Pfusch" hinauslaufen. Die Freiheit zu entscheiden sollte schon erhalten bleiben.
Holm T. schrieb: > Ich habe noch Disketten aus DDR Zeiten mit dem alten Zeuch, das habe ich > damals auf einem Ec1834 ..einem XT-artigen laufen gehabt. Ec1834 = Röhrenrechner ? :-)
Helmut schrieb: > Allein im Layout entscheidet sich doch sowieso Wohl und Wehe- wie die > die Bauteile zusammenpassen und manchmal rückwirkend sogar wie der > Schaltplan sein muß. Ich würde für meine minder schaltungskomplexen > Projekte eher die umgekehrte Reihenfolge bevorzugen: Das Programm > generiert mir den Schaltplan aus dem Layout! Ich gebe dir schon recht, dass sich vieles im Layout entscheidet und der Schaltplan sich oft nach dem Layout richtet. (Gattertausch 4fachOP, Pin am PLD...) Trotzdem werden die wenigsten Entwickler mit dem Entwurf des Layouts beginnen und daraus dann den Schaltplan ableiten oder gar auf einen Schaltplan verzichten. Ich kann mir auch nicht vorstellen, dass es viele Leute gibt, welche die Funktion einer Schaltung anhand des Layouts schneller, bzw. überhaupt erfassen können wenn es sich nicht um wirklich ganz primitive Sachen handelt. Die Symbole im Schaltplan beschreiben ja auch die Funktion, was die Packages im Layout nicht tun. Die beschreiben die physikalischen Anschlüsse und Abmessungen von Bauteilen, die mehrere Funktionsblöcke enthalten können. Gerade für Anfänger ist es zunächst wichtig, die Funktion der Schaltung zu verinnerlichen. Es sei denn, es besteht Null Interesse daran und es soll nur mal schnell ohne Verstand was kopiert werden. Die Zielgruppe einer einigermaßen professionellen Software für die Leiterplattenerstellung dürfte aber eine deutlich andere/größere als die Kopierfraktion sein. Da würde ich mir nicht allzu viel Hoffnung machen, dass irgendein ernstzunehmender Hersteller eine Funktion implementiert, den Schaltplan (leserlich, also mit quasi rückwärts auto-place und auto-route) aus dem Layout zu erstellen. Den Markt, der ein solches Angebot rechtfertigen würde, sehe ich (persönlich) nicht.
Helmut schrieb: > Die Freiheit zu entscheiden sollte schon erhalten bleiben. Für die, die wissen was sie tun kann ich das auf jeden Fall unterstützen. Nur für Einsteiger sollten die Hürden nicht zu niedrig sein.
Meine Güte da hab ich ja was losgetreten... Onkel Albert hatte wohl recht mit dem Atom und der vorgefassten Meinung!
KiCadSuperman schrieb: > Holm T. schrieb: >> Ich habe noch Disketten aus DDR Zeiten mit dem alten Zeuch, das habe ich >> damals auf einem Ec1834 ..einem XT-artigen laufen gehabt. > > Ec1834 = Röhrenrechner ? :-) In der Zeile drüber hatte ich schon geschrieben was das für ein Rechner ist. Gruß, Holm
Helmut schrieb: > Volker S. schrieb: >> Im Endeffekt steckt bei dem chaotischen Vorgehen oft viel mehr Arbeit >> drin, als wenn es von Anfang an "richtig" gemacht worden wäre. >> Das merkt dann auch fast jeder nachdem er erst mal einige Projekte so >> vergeigt hat. > > Wenn Projekte so vergeigt werden (was auch immer das im Einzelfall > bedeuten mag), es also tatsächlich auf ein ungenügendes Ergebnis > hinausläuft, reicht dann nicht die einfache Vorgabe an die Studenten: > Mit Schaltplan? Aus meiner eigenen Praxis weiß ich aber: *Ohne* > explizit erstellten Schaltplan kann auch genügen und muß definitiv > nicht auf "Pfusch" hinauslaufen. Die Freiheit zu entscheiden sollte > schon erhalten bleiben. Ich habe keine Ahnung was Deine Studenten da für Aufgaben bekommen..aber wenn die Platinen fertigen sollen ohne sich vorher Gedanken um die Schaltung gemacht zu haben ist das Ergebnis definitv unbrauchbar. woher wissen die das mit Stützkondensatoren, Impedanzen von VCC und GND, thermischen Anforderungen usw? Ich halte Dein Beispiel für an den Haaren herbei gezogen. Entweder ist es nicht der Job von Studenten solche Platinen zu erzeugen oder es ist ihr Job, dann gibts aber von vornherein ne Schaltungsentwicklung. Gruß, Holm, der 9 Jahre an einer Uni das Elektronik- und Rechnerlabor eines Instituts "gemacht" hat.
Bob A. schrieb: > Meine Güte da hab ich ja was losgetreten... > > Onkel Albert hatte wohl recht mit dem Atom und der vorgefassten Meinung! Ach, mach Dir keinen Kopf. Hier haben Leute aus unerklärlichen Gründen Angst um das auf was sie schwören und kramen deswegen einen Grund nach dem anderen aus warum man ganz unmöglich überhaupt wechseln kann und sich Deine Frage also von vornherein verbietet. Momentan diskutieren wir z.B. über die Rolle der Bedeutung, Features die man nicht braucht, die Niemanden wirklich interessieren und die keines der beiden Programme beherrscht. Schaue einfach morgen nochmal hier rein wenn gerade die Mondphasen Thema sind.. Gruß, Holm
Volker S. schrieb: > Holm T. schrieb: >> ..unter einer funktionierenden Backward Annotation verstehe ich >> eigentlich das was hier schon angesprochen wurde.. Pin oder Gate Swap im >> PCB Editor. >> wenn das in Eagle verboten ist....??? was fehlt dann eigentlich? > > Habe auch nochmal nachgeschaut: > Gateswap geht zumnidest bis 7.5 im Layout nicht. Pinswap schon. > Rätselhaft, aber kann man(ich) ja im Schaltplan machen ;-) > Sehr, sehr oft benutze ich allerdings die Änderung des Package im > Layout. > Ok. ..und würdest Du das nun als Ausschlußkriterium für ein CAD System halten wo genau das nicht geht und man das im Schaltplan machen muß und wenn ja, warum genau? Gruß, Holm
Bob A. schrieb: > ich meinte durchaus beide Lager ;-) Ich habe Dich schon verstanden. Mein Problem ist doch hier das ich mit Fachleuten über Fehler des mir eläufigen CAD Systems zanke ..die einfach nicht vorhanden sind. Leute die offenbar niemals auch nur versucht haben eine Entwicklung damit durch zu ziehen halten das Kraft Ihrer Wassersuppe für völlig unmöglich. Es ist deshalb nicht verwunderlich das hier Diejenigen die es etwas besser als die Fachleute wissen weil sie es halt können anfangen das durch den Kakao gezogene KiCad zu vereidigen..weil sie stolz auf diese Entwicklung sind und teilweise selbst dazu beigetragen haben (bei mir nicht der Fall, bzw. sehr sehr lange her). Andererseits habe ich es vermieden "über Eagle her zu ziehen" ( weil ich es gar nicht kenne und ich kenne es wegen seiner Restriktionen nicht, es macht auf dem Radar simpel keinen Punkt) auch wenn mir das hier wiederholt unterstellt aber seltsamerweise nie nachgewiesen wurde. Was soll ich Deiner Meinung nach tun? Klappe halten und die Unwahrheiten akzeptieren? KiCad durch den Kakao ziehen lassen? ..sorry, da bin ich nicht der Richtige dafür. Gruß, Holm
Volker S. schrieb: > Holm T. schrieb: >> ..unter einer funktionierenden Backward Annotation verstehe ich >> eigentlich das was hier schon angesprochen wurde.. Pin oder Gate Swap im >> PCB Editor. >> wenn das in Eagle verboten ist....??? was fehlt dann eigentlich? > > Habe auch nochmal nachgeschaut: > Gateswap geht zumnidest bis 7.5 im Layout nicht. Pinswap schon. > Rätselhaft, aber kann man(ich) ja im Schaltplan machen ;-) > Sehr, sehr oft benutze ich allerdings die Änderung des Package im > Layout. Nachtrag: Können wir uns evtl. darauf Einigen das Eagle (bis 7.5) von Backannotation keinen Plan hat und lediglich erlaubt im PCB Editor das Package zu ändern, mit dem Bonus das man Pins unter bestimmten Bedingungen auch manchmal tauschen kann? Gruß, Holm
Holm T. schrieb: > Volker S. schrieb: >> Holm T. schrieb: >>> ..unter einer funktionierenden Backward Annotation verstehe ich >>> eigentlich das was hier schon angesprochen wurde.. Pin oder Gate Swap im >>> PCB Editor. >>> wenn das in Eagle verboten ist....??? was fehlt dann eigentlich? >> >> Habe auch nochmal nachgeschaut: >> Gateswap geht zumnidest bis 7.5 im Layout nicht. Pinswap schon. >> Rätselhaft, aber kann man(ich) ja im Schaltplan machen ;-) > > Können wir uns evtl. darauf Einigen das Eagle (bis 7.5) von > Backannotation keinen Plan hat und lediglich erlaubt im PCB Editor das > Package zu ändern, mit dem Bonus das man Pins unter bestimmten > Bedingungen auch manchmal tauschen kann? "unter bestimmten Bedingungen manchmal" ist nicht einmal übertrieben, also: Einverstanden! Ach ja: beim Gateswap im Schaltplan bringt Eagle die Attribute (z.B. Bestellnr.) durcheinander, kann man also nur benutzen wenn... :)
Holm T. schrieb: > Was soll ich Deiner Meinung nach tun? Klappe halten und die Unwahrheiten > akzeptieren? KiCad durch den Kakao ziehen lassen? ..sorry, da bin ich > nicht der Richtige dafür. Nun, für mich ist das zum Teil ein durchaus gangbarer Weg: Je nachdem aus welchem Schädel der Wind bläst, schalte ich eben auch auf Durchzug ;-) Mahlzeit, Bob
Bernd W. schrieb: > Nun, ich kann an dem Punkte nur über KiCad berichten. Aktuelle KiCad > Versionen können wrl und Step Daten einlesen und dann Hallo Bernd, vielen Dank für die ausführliche Beschreibung dieser Dateien. Wenn ich mich mal besser mit Kicad auskenne dürfte das nützlich sein. Es wäre durchaus interessant ob Kicad ähnlich "zweckentfremdet" werden kann wie das Pr Programm. Aber wie es so heißt, zuerst muss man Gehen lernen bevor man laufen will... Meine CAM Tool Chain ist natuerlich teilweise schon sehr betagt. Die LPT Verdonglung ist ein weiterer Dorn im Auge weil die auf X64 Architekturen nicht mehr funktionieren und ich das Programm in einer VM verwenden muss. Ich habe gestern übrigens Versuche mit einen UV 50mW Laser zur Belichtung von Photo beschichtetem Material gemacht (Hier im Forum inspiriert). Das funktioniert auch sehr gut und die Auflösung ist bei richtiger Fokussierung sehr gut. Ursprünglich wollte ich meine CNC Maschine zum Laser Plotter adaptieren. Dann dachte ich mir, hmm, vielleicht wäre das ein guter Grund meinen uralten HP7475A Plotter wieder zum Leben als Laser Plotter zu erwecken und das kleine Laser Modul dort zu montieren. Da ich das Service Manual dazu habe, ist das elektrisch auch nicht zu umständlich. Ich hoffe nur, dass er nicht zu schnell arbeitet. Muss mir mal das HP-GL Instruktion Set ansehen ob es da Einstellungsmöglichkeiten gibt. Was ich mir übrigens wünschen würde von vielen Schaltbild Editoren, ist, eine ästhetisch formschönere Arbeitsweise. Vielen CAD Schaltbildern sieht man den Zweck ihres Daseins als elektrische Datenbank Erzeuger an, anstatt wirklich schöne, druckfähige Schaltpläne produzieren zu können. Mein altes Tange SCH Programm produzierte in PS Mode sehr gut aussehende Symbole und Schaltbilder. Auf dem Laser Drucker sahen die damals wirklich gut aus. Bis dann, Gerhard
@Bob: Dein Hessengesetz ist zumindest lustig. @Bernd: Ich habe mich indessen an den Footprint "Apfelgelee" gewöhnt, man wollte mir bei robotrontechnik.de mal nicht abkaufen das der existiert. Du warst also der Verbrecher.. @Gerhard: Ich habe seit ca. 14 Tagen aus nostalgischen Gründen einen SPL430 Plotter, bin mal gespannt was Du das auskasperst, derSPL430 sollte 7475 kompatibel sein..und ja, HPGL hat möglichkeiten die Plotgeschwindigkeit einzustellen und zu setzen. Das sollten wir aber in einem anderen Fread "CAD-System-übergreifend" behandeln. Gruß, Holm
Hallo Gerhard, Gerhard O. schrieb: > Was ich mir übrigens wünschen würde von vielen Schaltbild Editoren, ist, > eine ästhetisch formschönere Arbeitsweise. Vielen CAD Schaltbildern > sieht man den Zweck ihres Daseins als elektrische Datenbank Erzeuger an, > anstatt wirklich schöne, druckfähige Schaltpläne produzieren zu können. > Mein altes Tange SCH Programm produzierte in PS Mode sehr gut aussehende > Symbole und Schaltbilder. Auf dem Laser Drucker sahen die damals > wirklich gut aus. die mitgelieferten Symbole sind leider oft ein lieblos zusammen geklöppeltes Sammelsurium, unabhängig davon wie das Programm heißt. Die weiter oben erwähnten, von Digikey bereitgestellten Libs sind da keine positive Ausnahme. Wer ernsthaft (oder mit ästheitschem Anspruch) arbeitet, legt sich deshalb seine Libs selbst an. Wieviele Möglichkeiten gibt es allein schon beim Diodensymbol: Dreieck mit 60-60-60 Grad Winkeln oder 90-45-45 oder was anderes? Geht der Strich durchs Dreieck, oder ist das Dreieck leer, oder ist es mit schwarz oder gelb gefüllt? Da wird jeder je nach Ästheik und kultureller Prägung einen anderen Favoriten haben. Wer sich aus zusammengesuchten Libs bedient, der wird dann gleich mehrere Varianten in seinem Schaltplan finden. Das sieht nicht schön aus. Die eigenen Symbolbibliotheken vorzustellen könnte Thema eines eigenen Threads werden. Wobei, wenn es da dann Glaubenskriege um die Diodenform gibt...
Helmut schrieb: > Genau auf diesem Niveau zu erstellen wäre eine Funktion, die ein > leistungsfähiges=komfortables Programm haben sollte. Und der Schaltplan > könnte immer gängigen Standards entsprechen. Dann gucken wir mal, wann es den ersten Autoplacer&Autorouter für den Schaltplan gibt. Und wie die Ergebnisse sind.
Holm T. schrieb: > Ich habe keine Ahnung was Deine Studenten da für Aufgaben bekommen..aber > wenn die Platinen fertigen sollen ohne sich vorher Gedanken um die > Schaltung gemacht zu haben ist das Ergebnis definitv unbrauchbar. > woher wissen die das mit Stützkondensatoren, Impedanzen von VCC und GND, > thermischen Anforderungen usw? > Ich halte Dein Beispiel für an den Haaren herbei gezogen. Entweder ist > es nicht der Job von Studenten solche Platinen zu erzeugen oder es ist > ihr Job, dann gibts aber von vornherein ne Schaltungsentwicklung. Die Studierenden werden da zumindest bei den ersten Projekten in den unteren Semestern wirklich oft ins kalte Wasser geworfen und haben streng genommen nicht unbedingt das komplette Spektrum aller nötigen Vorkenntnissen. Die Kenntnisse erarbeiten sie sich dann im Laufe der Projekte. Das ist zumindest zu einem Teil bedingt durch die große Bandbreite der Projekte in der Mechatronik, die von Mechanik, Optik, Sensorik, Elektronik und jeglicher Art von Programmierung einfach alles enthalten können und auch Aufgaben mehrerer dieser Gebiete enthalten sollen. Ein wichtiger Aspekt der Übung soll auch sein, die Teilgebiete zu koordinieren, Schnittstellen zu definieren... Diese ersten Projekte werden in Gruppen von 3-6 Studierenden durchgeführt. Die Teilbereiche sind meistens überschaubar und dienen oft auch dazu Interesse an den jeweiligen Disziplinen für das weitere Studium zu wecken. Im Bereich Elektronik kann das beispielsweise eine kleine OP-Verstärkerschaltung für ein bestimmtes Sensorsignal sein. Auch wenn solche kleinen Aufgaben prinzipiell auf verschiedenste Art und Weise gelöst werden können, finde ich es gerade am Anfang nicht schlecht, wenn einem die Tools einen bestimmten Workflow mehr oder weniger aufdrängen. Es erleichtert meiner Meinung nach sogar die Arbeit, wenn ich mir keine Gedanken machen muss, was jetzt zuerst kommt. (Extremfall hier Layout oder Schaltplan)
Holm T. schrieb: > Können wir uns evtl. darauf Einigen das Eagle (bis 7.5) von > Backannotation keinen Plan hat und lediglich erlaubt im PCB Editor das > Package zu ändern, mit dem Bonus das man Pins unter bestimmten > Bedingungen auch manchmal tauschen kann? Wir können uns darauf einigen, dass DU von Eagle keinen Plan hast. Also bitte hör auf über Dinge zu reden, die Du nicht verstehst. Natürlich kann Eagle mit BA weit mehr als "nur" ein Package im Layout zu ändern, und selbst das Package im Layout ändern ist weit mehr als Kicad kann.
Hai Bernd. Bernd W. schrieb: > Es gibt kaum einen Grund, Änderungen im Board zu machen, > ohne sie vorher im Schaltplan durchgeführt zu haben. Eben doch -- das ist ja der Punkt! > ich würde das eher als "chaotischen Arbeitsstil" > interpretieren. ;O) Durchaus nicht. Lars R. hat weiter oben das Beispiel geliefert, das mich endgültig überzeugt hat: Reverse engineering. Ich gebe Dir ja völlig Recht mit der Ansicht, dass man bei einer planvollen, vernünftig angepackten Neu-Entwicklung selten in die Verlegenheit kommen wird, Änderungen im Layout rückwärts in den Schaltplan übernehmen zu müssen. Der Knackpunkt: Es gibt nicht nur planvolle, vernünftig angepackte Neu-Entwicklungen! Die "da-muss-man-eben-einfach-nur"-Sprüche helfen da nicht weiter; das Problem lässt sich dadurch nicht wegdiskutieren. Mir ist erst nachträglich eingefallen, dass ich auch mal vor dem Problem stand, einfach einen Adapter für ein fertiges Board zu brauchen. Ändern des Board-Layout kam nicht in Frage; es musste nur für ein IC, das als bedrahtetes Bauteil auf dem Board vorgesehen war, ein Adapter auf SMD hergestellt werden - also nur zwei Footprints mit Leiter- zügen dazwischen. Ich habe das (mit Eagle oder mit OrCAD, das weiss ich nicht mehr) versucht. Nach einem Wutanfall der Stufe 6.3 auf der nach oben offenen Richter-Skala habe ich den Adapter mit CorelDraw (!!) gemalt, dann auf Folie gedruckt und die Adapterplatinen geätzt. Es ist in Ordnung, wenn das Entwicklerteam sagt: "Tritt zu selten auf, Priorität nicht hoch genug, wird im Moment nicht implementiert." Es ist aber NICHT in Ordnung, wenn gesagt wird: "Kein intelligenter Antwender benötigt je diese Funktion".
Karl schrieb: > Natürlich kann Eagle mit BA weit mehr als "nur" ein Package im Layout zu > ändern, und selbst das Package im Layout ändern ist weit mehr als Kicad > kann. ... und das wäre? Der Feststellung das jemand bei einem Thema Wissenslücken hat kann man auch damit begegnen indem man versucht diese Lücken etwas aufzufüllen.
Volker S. schrieb: > Trotzdem werden die wenigsten Entwickler mit dem Entwurf > des Layouts beginnen und daraus dann den Schaltplan > ableiten oder gar auf einen Schaltplan verzichten. Das stimmt zwar -- aber man sollte nicht vergessen, dass es dafür legitime Anwendungen gibt. Für einen simplen Adapter SMD --> THD brauche ich nicht zwingend einen Schaltplan, und selbst reverse engineering muss nix Illegales sein. Der Fall, dass Ersatz für eine physisch vorliegende, aber nicht dokumentierte Baugruppe benötigt wird, der kommt durchaus vor. > Da würde ich mir nicht allzu viel Hoffnung machen, dass > irgendein ernstzunehmender Hersteller Kommerzielle Hersteller vielleicht nicht, das mag sein. > eine Funktion implementiert, den Schaltplan (leserlich, > also mit quasi rückwärts auto-place und auto-route) > aus dem Layout zu erstellen. Den Markt, der ein solches > Angebot rechtfertigen würde, sehe ich (persönlich) nicht. Schwer zu sagen. Es gibt ja offenbar immer wieder Einzelne, denen bestimmte Macken der etablierten Systeme auf den Zünder gehen, und die sich an Abhilfe versuchen. Wichtig wäre nur Datenkompatibilität, denn dann wird aus den vielen Insellösungen nämlich plötzlich ein Pool an Werkzeugen, aus dem sich jeder seinen Werkzeugsatz auswählen kann.
Karl schrieb: > Holm T. schrieb: >> Können wir uns evtl. darauf Einigen das Eagle (bis 7.5) von >> Backannotation keinen Plan hat und lediglich erlaubt im PCB Editor das >> Package zu ändern, mit dem Bonus das man Pins unter bestimmten >> Bedingungen auch manchmal tauschen kann? > > Wir können uns darauf einigen, dass DU von Eagle keinen Plan hast. Also > bitte hör auf über Dinge zu reden, die Du nicht verstehst. > Genau auf Deine unter der Gürtellinie erwartete Antwort war meine Frage ausgelegt. Klär uns doch mal bitte auf, was Eagle so unter Backanno versteht. > Natürlich kann Eagle mit BA weit mehr als "nur" ein Package im Layout zu > ändern, und selbst das Package im Layout ändern ist weit mehr als Kicad > kann. Das wußte ich..und wollte es deshalb nicht wissen. Zurück zu Sache: Eagle kann also natürlich "weit mehr" ..was kann es denn? Backward Annotation wohl schon mal nicht. Du zumindest kennst Dich ganz genau damit aus was KiCad nicht kann, obwohl Du ganz offensichtlich an den einfachsten Sachen bereits scheiterst, erkläre uns doch mal bitte was Du besser kannst als zu definieren was ich Alles nicht verstehe, sonst fange ich hier mal mit einer Aufstellung an was Du bisher alles schon nicht verstanden hast, komprende? Gruß, Holm
Bob A. schrieb: > Der Feststellung das jemand bei einem Thema Wissenslücken hat kann man > auch damit begegnen indem man versucht diese Lücken etwas aufzufüllen. Wenn Du diesen Thread ein wenig überblickst, wirst Du ellenlang Beiträge finden, in denen ein Holm T. sich damit brüstet nie im Leben Eagle angeschaut zu haben und dann erklärt, wieso und wo überall Kicad Eagle überlegen ist. Glaubst Du es besteht da auch nur ansatzweise ein Interesse, Wissenslücken zu füllen? Hab ich nicht den Eindruck... Aber um Dir zu helfen: Bauelemente auf dem Board automatisch nach Position umnummerieren, um sie leichter zu finden. Geht seit mindestens 15 Jahren. Bauelemente mit Replace auf dem Board austauschen. Pins mit Pinswap tauschen. Die Pins müssen natürlich gleiches Swaplevel haben, sprich sie müssen auch tauschbar sein. Werte der Bauelemente auf dem Board ändern. Selten, aber nützlich wenn man beim Prototyp-Löten merkt, dass da ein Wert falsch ist oder der offensichtliche IC noch keinen Wert hat. Geht schneller das im eh zum Bestücken offenen Layout zu machen als erst auf den Schematic im Hintergrund zu wechseln und das Bauteil rauszusuchen. Warum Gateswap nicht geht? Wie willst Du bei einem DIL-14 auswählen, welche Gates Du tauschen willst? Du siehst ja nur das Package, aber nicht die Symbole.
Karl schrieb: > Bob A. schrieb: >> Der Feststellung das jemand bei einem Thema Wissenslücken hat kann man >> auch damit begegnen indem man versucht diese Lücken etwas aufzufüllen. > > Wenn Du diesen Thread ein wenig überblickst, wirst Du ellenlang Beiträge > finden, in denen ein Holm T. sich damit brüstet nie im Leben Eagle > angeschaut zu haben und dann erklärt, wieso und wo überall Kicad Eagle > überlegen ist. Wen Du diesen Therad ein wenig überblickst wirst Du viele kurze Beiträge finden die Zeigen wie Karl mit KiCad nicht zurecht kommt. Alle KiCad User fragen sich warum und merken an bei Ihnen sei das nicht so. > > Glaubst Du es besteht da auch nur ansatzweise ein Interesse, > Wissenslücken zu füllen? Hab ich nicht den Eindruck... Glaubst Du es hat irgend einen sinn dem offensichtlich auf dem Rücken liegenden "Karl der Käfer" noch etwas erklären zu wollen, wo er doch so ganz offensichtlich die Voraussetzungen dafür nicht mitbringt? > > Aber um Dir zu helfen: Bauelemente auf dem Board automatisch nach > Position umnummerieren, um sie leichter zu finden. Geht seit mindestens > 15 Jahren. ..ist kein Backannotate.. aber zumindest das Annotate des EEschema bietet ähnliche Funktionen auf den Schaltplan bezogen an. Ob man diese Funktion auf dem PCB braucht, darüber kann man trefflich diskutieren.. > > Bauelemente mit Replace auf dem Board austauschen. Kann KiCad auch. > > Pins mit Pinswap tauschen. Die Pins müssen natürlich gleiches Swaplevel > haben, sprich sie müssen auch tauschbar sein. Geht also manchmal..geht in KiCad und zwar immer. > > Werte der Bauelemente auf dem Board ändern. Selten, aber nützlich wenn > man beim Prototyp-Löten merkt, dass da ein Wert falsch ist oder der > offensichtliche IC noch keinen Wert hat. Geht schneller das im eh zum > Bestücken offenen Layout zu machen als erst auf den Schematic im > Hintergrund zu wechseln und das Bauteil rauszusuchen. ..Moment... der IC hat keinen Wert im Eagle-PCB? Geht doch gar nicht, der muß einen Wert und ein Footprint haben und zwar schon vor dem Schaltplan..habe ich hier gelernt. Abgesehen davon kann das KiCad auch. > > Warum Gateswap nicht geht? Wie willst Du bei einem DIL-14 auswählen, > welche Gates Du tauschen willst? Du siehst ja nur das Package, aber > nicht die Symbole. KiCad sieht bei einem 7400 alternative 4 Subdevices, ich übrigens auch. Willste auf dem Niveau weiter machen? Kannste haben, kommt auf Deine Antwort an. Kleiner Tipp: höre auf mir übers Maul fahren zu wollen, das bereust Du. Gruß, Holm
Holm T. schrieb: > Zurück zu Sache: Eagle kann also natürlich "weit mehr" ..was kann es > denn? > Backward Annotation wohl schon mal nicht. Stimmt. Karl schrieb: > Zeno schrieb: >> Wenn Du im Layout ein Bauelement löschst, was nur bei inaktiver FB geht, >> dann sind beine inkonsistent und das läßt sich wie es scheint auch nicht >> so einfach beheben. Wenn ich beim Öffnen bewußt FB umgehe und dann >> gravierende Änderungen vornehme habe ich offensichtlich im wahrsten >> Sinne des Wortes verkackt. > > Ja, aber Eagle warnt seit mindestens V6 ganz groß und breit davor. Es > geht auch gr nicht anders, wenn das BE im Layout weg ist, sind Schaltung > und Layout nunmal nicht mehr konsistent. > > Beheben kann man das je nach Aufwand: Ein fehlendes BE im Layout kann > man im Layout - bei geschlossenem Schematic - wieder einfügen und gibt > ihm dann exakt die gleiche Bezeichnung wie im Schematic. Es muss > natürlich aus der gleichen Lib stammen. Dann Schematic öffnen und > prüfen: Geht. > > Ich hab schon Layouts mit mehreren hundert derartigen Fehlern repariert, > weil jemand ein Bauteil nur im Schematic geändert hatte. War immer noch > schneller als das Layout neu zu machen. Wenn man das hier vom "Kollega" liest (speziell den letzten Absatz) dann friert's mich. Ich wusste gar nicht was man mit Eagle so alles anstellen kann. Wenns dumm dahergeht braucht man gleich mehr Zeit zum reparieren als fürs Layouten :-(
Karl schrieb: > Warum Gateswap nicht geht? Wie willst Du bei einem > DIL-14 auswählen, welche Gates Du tauschen willst? > Du siehst ja nur das Package, aber nicht die Symbole. Verstehe ich nicht. "Das System" weiss doch, welche Pins zu welchem Gate gehören. Wenn man also zwei Pins zum Tauschen markiert, die nicht zum selben Gate gehören, dann ist doch klar, dass nicht einfach die Pins getauscht werden können, sondern die zugehörigen Gates getauscht werden müssen. Und -- ja, das sollte das System natürlich NICHT einfach ohne Rückfrage MACHEN, sondern erstmal eine geeignete Vorschau anbieten, was die Aktion denn bedeuten würde. Den Fall, dass der Anwender versehentlich Eingang_1 von Gate_1 und Ausgang_3 von Gate_3 zum Tauschen markiert, muss man natürlich abfangen und signalisieren, aber das ist ja kein Hexenwerk. Alternativ könnte man eine Möglichkeit vorsehen, die Symbole auch zusätzlich im Layout einzublenden, so dass man sieht, welcher Pin zu welcher Sub-Unit gehört.
Holm T. schrieb: > Willste auf dem Niveau weiter machen? Kannste haben, kommt auf Deine > Antwort an. > Kleiner Tipp: höre auf mir übers Maul fahren zu wollen, das bereust Du. Du hast bei Deiner Ausdrucksweise gar kein Niveau. Und noch dazu keine Ahnung von Eagle.
@Rolf Dietfurt Schau dir mal die Ausdrucksweise vom Kollega "Karl" an. Da kann man ganz schnell den Eindruck gewinnen, dass er sich vom Polier zum Elektroniker hat umschulen lassen. Mich stört das aber nicht, im Gegenteile ich finde es erfrischend. (auch die Antworten dazu von Holm)
Karl schrieb: > Warum Gateswap nicht geht? Wie willst Du bei einem DIL-14 auswählen, > welche Gates Du tauschen willst? Du siehst ja nur das Package, aber > nicht die Symbole. Bei der Ultimate-Software (gehört jetzt NI) ging das, indem man den Ausgang von Gate A mit dem von Gate C verbunden hat*. Die BA hat dann entsprechend im Schaltplan alle beteiligten Pinnummern getauscht. Ich vermisse das nicht mehr, da ich heute keine Digitalplatinen in diesem Sinne mehr mache. * Natürlich natürlich unter dem Swap-Menüpunkt.
Hallo Holm. Holm T. schrieb: > @Bernd: Ich habe mich indessen an den Footprint "Apfelgelee" gewöhnt, > man wollte mir bei robotrontechnik.de mal nicht abkaufen das der > existiert. Du warst also der Verbrecher.. Ja. War ich. Ich habe irgendwann einen ganzen Schwung Footprints in die Bibliothek geschoben, und den Kram versehentlich mit erwischt. Wann das genau passiert ist, weiss ich nicht. Ich war selber Erstaunt, als ich irgendwann wieder darauf gestossen bin. ;O) Aber bezeichnend, das keiner gemeckert hat. Darum habe ich die Sache auf sich beruhen lassen. Falls jemand Bauteilmagazine von Raaco hat, mit einem Rahmen an den Kästchen, wo ein Label eingelegt werden kann: Eine Vorlage für die Label ist auch dabei. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Karl schrieb: > Warum Gateswap nicht geht? Wie willst Du bei einem DIL-14 auswählen, > welche Gates Du tauschen willst? Du siehst ja nur das Package, aber > nicht die Symbole. Ich habe gestern zum Spaß eine Demoversion meiner alte Software installiert um zu schauen, wie das ging. Klickt man im GateSwap Befehl auf einen Pin im Decale (so hieß das Package im Layout), dann werden alle zugehörigen Pins hervorgehoben. Klickt man dann auf einen Pin eines anderen passenden Gates, dann wird geswappt. Kinderleicht und natürlich auch im Schaltplan ;-) Schade, dass diese wunderbare ältere Software nur unter Windoof vernünftig lief und anscheinend auch seit Jahren nicht mehr weiter entwickelt wird. (Kennt fast keiner, hieß Ariadne und war von so 'ner Klitsche nebenan ;-)
Holm T. schrieb: > ..ist kein Backannotate.. aber zumindest das Annotate des EEschema > bietet ähnliche Funktionen auf den Schaltplan bezogen an. Ähm hallo? Natürlich ist das mit Back Annotation, wenn die Änderung der Bauteilnummern im Layout auch die Bauteilnummern im Schematic ändert. Schau Dir mal eine ordentlich aufgeräumte professionelle Leiterplatte an, wo die Nummerierung mit R001 oben links beginnt und dann bis R199 unten rechts durchgeht. Du zeigst, dass Du keine Ahnung hast, wovon Du redest. > Geht also manchmal..geht in KiCad und zwar immer. Es ist nicht sinnvoll, dass das immer geht. Pinswap darf auch der Autorouter, und Du möchtest nicht, dass der Autorouter in+ und in- eines OPVs mal eben tauscht, weil es "immer" geht. Du zeigst, dass Du keine Ahnung hast, wovon Du redest. > ..Moment... der IC hat keinen Wert im Eagle-PCB? Geht doch gar nicht, > der muß einen Wert und ein Footprint haben und zwar schon vor dem > Schaltplan..habe ich hier gelernt. Der muss keinen Wert haben. Der muss nur eine Bauteil-ID haben. Du zeigst, dass Du keine Ahnung hast, wovon Du redest. > KiCad sieht bei einem 7400 alternative 4 Subdevices, ich übrigens auch. Im Layout? Witzig, setzt man da ein DIL-14 aus 4 3-Pinnern und den 2 Versorgungspins einzeln zusammen? Wohl kaum. > Kleiner Tipp: höre auf mir übers Maul fahren zu wollen, das bereust Du. Sonst was? Kommt sonst Dein großer Bruder?
Karl schrieb: > Geht schneller das im eh zum > Bestücken offenen Layout zu machen als erst auf den Schematic im > Hintergrund zu wechseln und das Bauteil rauszusuchen. Ich glaub KiCad kann schon rudimentäres cross-probe, sprich: Du klickst ein Bauteil im Layout an oder ein Pad und es wird im Schaltplan markiert, die Markierung ist zwar noch etwas unauffällig aber immerhin.
Wer ist eigentlich auf die Idee gekommen, den Bezugspunkt bei einfachen Bauteilen auf Pin 1 zu setzen? Das gibt ja äußerst witzige Effekte, wenn man ein Bauteil oder eine Gruppe rotieren oder von Top nach Bottom wechseln will. Kann man das anders definieren, wenn man sich seine eigenen Libs baut?
Karl schrieb: > Kann man das anders definieren, wenn man sich seine eigenen Libs baut? Ja (mach ich auch so); allerdings glaub ich jetzt gar nicht dass das in den StdLibs so ist (aber die hab ich schon seit jahren nicht mehr angeschaut)
Karl schrieb: > Wer ist eigentlich auf die Idee gekommen, den Bezugspunkt bei einfachen > Bauteilen auf Pin 1 zu setzen? Bei SMD markiere ich immer die Mitte, bei TH meist Pin 1 und bei Buchsen oft den Einbaubezugspunkt in der Mitte mit Silkscreen Frontplattenbezugspunkt. Man muss sich halt schon bei der Erstellung des Foot Prints darueber Gedanken machen. Bei SMD ist der Mitteebezugspunkt sehr wichtig wenn man Rs, Cs aufreihen will und unterschiedliche Anschlussfolgen haben wo Pin 1 und 2 je nach Notwendigkeit rotiert sind. Manchmal füge ich noch Koordinatenbezugspunkt Referenzen ein so dass man schnell zwischen Mitte, PIN-1 und sonst wo umschalten kann. Bei speziellen Buchsen hat sich das als sehr nützlich erwiesen.
:
Bearbeitet durch User
Hallo Karl. Karl schrieb: > Wer ist eigentlich auf die Idee gekommen, den Bezugspunkt bei einfachen > Bauteilen auf Pin 1 zu setzen? Wer es nun konkret war, weiss ich nicht. Das Argument war, dass diese Methodik sehr verbreitet ist (ich glaube sogar auch beim IPC), und man halt kompatibel mit dem Rest der Welt sein wollte. > > Das gibt ja äußerst witzige Effekte, wenn man ein Bauteil oder eine > Gruppe rotieren oder von Top nach Bottom wechseln will. Exakt das war mein Argument dagegen. ;O) Auch die allgemeinen Konventionen haben sich ja bei SMD von Pin 1 als Ankerpunkt abgewendet. Aber bei THT ist das wohl zu etabliert. > > Kann man das anders definieren, wenn man sich seine eigenen Libs baut? Aber sicher. Du kannst Dir den Ankerpunkt hinsetzten, wo du möchtest. Das geht auch nachträglich, d.h. Du kannst Dir vorhandene Bibliotheken mit Pin 1 als Ankerpunkt nehmen und den Ankerpunkt in die Mitte setzten. Vergiss aber nicht, den geänderten Footprint umzubenennen. Sonst wird irgendwann mal der Geänderte mit dem Original gleichen Namens überschrieben, und Dein Footprint hängt komisch auf der Platine. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Karl schrieb: >> Wer ist eigentlich auf die Idee gekommen, den Bezugspunkt >> bei einfachen Bauteilen auf Pin 1 zu setzen? > > Wer es nun konkret war, weiss ich nicht. Das Argument war, > dass diese Methodik sehr verbreitet ist (ich glaube sogar > auch beim IPC), und man halt kompatibel mit dem Rest der > Welt sein wollte. > >> >> Das gibt ja äußerst witzige Effekte, wenn man ein Bauteil >> oder eine Gruppe rotieren oder von Top nach Bottom wechseln >> will. > > Exakt das war mein Argument dagegen. ;O) Auch die allgemeinen > Konventionen haben sich ja bei SMD von Pin 1 als Ankerpunkt > abgewendet. Aber bei THT ist das wohl zu etabliert. Okay... bedeutet also folgendes: Eine anständige Bauteildatenbank muss folgende Optionen anbieten: - Bezugspunkt wie im Footprint festgelegt - Bezugspunkt einheitlich in Bauteilmitte - THT-Bezugspunkt auf Pin1, SMD-Bezugspunkt in Bauteilmitte Noch weitere?
Bauform B. schrieb: > Auch wenn es schon spät ist, das möchte ich nicht so stehen lassen. Vier > Bilder sagen hoffentlich mehr als n Worte. > > Zeno schrieb: >> Bauform B. schrieb: >>> Wie geht ein Gateswap im Board? Das suche ich seit Jahren. >> >> Genauso wie im Schematic. Sorry habe mich da vertan. Im Board gibt es wirklich kein Gateswap, da ist nur Pinswap möglich.
FYI: https://github.com/hyOzd/kicad-python/blob/master/examples/pcbannotate.py Ausserdem in eeschema: Edit -> Import Footprint Selection
KiCadSuperman schrieb: > Wenn man sich erfolgreiche Designer und Entwickler anschaut, > die blicken immer nach vorne_ und nicht _back ;-) Was hat das jetzt mit FB zu tun. Aber ansonsten spielst Du Karl eher mit Deiner Aussage KiCadSuperman schrieb: > Wenn du damit das "Back -Zeugsel" meinst, das braucht man wirklich > nicht. die Bälle zu. KiCAD hat ein bestimmtes Feature nicht also braucht man es nicht. Das ist die falsche Herangehensweise.
Hallo Possetitjel. Possetitjel schrieb: > Okay... bedeutet also folgendes: > > Eine anständige Bauteildatenbank muss folgende Optionen > anbieten: > - Bezugspunkt wie im Footprint festgelegt > - Bezugspunkt einheitlich in Bauteilmitte > - THT-Bezugspunkt auf Pin1, SMD-Bezugspunkt in Bauteilmitte > > Noch weitere? Natürlich. Unterschiedliche Footprints für Reflow, Welle (Mit Tropfenfänger) und Handverlötung Unterscheidliche Footprints für Robust, Standard und Fein. Weil kombinierbar macht das zusammen mit Deinen Vorschlägen 27 Varianten für einen einzigen Footprint. Die Datenbank wird groß. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Zeno schrieb: > KiCAD hat ein bestimmtes Feature nicht also braucht man es > nicht. Das ist die falsche Herangehensweise. Die Frage ist doch eher ob der jeweilige Nutzer bereit ist darauf zu verzichten. Das haben die "Wechsler" für sich offensichtlich mit ja beantworten können. Die Nicht KiCad Benutzer eben nicht oder noch nicht. An die richtete sich der Thread aber ursprünglich gar nicht. Ok, auch ich habe mich schon eingemischt, obwohl ich noch gar nicht gewechselt bin. Immerhin liebäugle ich mit einem Wechsel und zum Zeitpunkt meines ersten Beitrags war eh schon alles zu spät ;-) <edit> Da war der Thread schon voll von Beiträgen von Leuten die KiCad anscheinen schlimmer finden als der Teufel das Weihwasser. Die waren zwar gar nicht gefragt, haben dann aber durch ihre zum Titel unpassenden Beiträge noch Holm aufgebracht, der das verständlicherweise nicht akzeptieren konnte und das Elend nahm seinen forumüblichen Lauf... <edit2>Wenn ich es mir recht überlege, dann kännte der Thread möglicherweise genau mit diesem Ziel von einem ganz hinterhältigen Strippenzieher und Troll gestartet worden sein ;-)
:
Bearbeitet durch User
Zeno schrieb: > KiCAD hat ein bestimmtes Feature nicht also braucht man es > nicht. Das ist die falsche Herangehensweise. Ja, da gebe ich Dir recht. Für mich scheint es genau zwei Meinungen zu F/B Annotation zu geben: - Es ist absolut unnütz und kein Tool sollte so etwas haben dürfen. - Ein Tool, welches das nicht kann, darf sich nicht tool (wofür auch immer) nennen. Ich finde es ziemlich [befremlich amüsant interessant], dass in beiden Lagern die jeweilige Ansicht derart stark vertreten und verteidigt wird. Meine Meinung ist, wie schon gesagt: Backward annotation ist etwas, das manchmal wohl wirklich nützlich ist. Der übliche Workflow geht in die andere Richtung (da wird wohl auch jeder Eagle-Nutzer zustimmen). Ja, wirklich, ich finde, wenn KiCad Pin Swap im Layout beherrschen würde, wäre das cool! Oder auch einfach Zurücklesen der Netzliste ins Schema. Das einfach mit "Das DARF ein Tool nicht können, weil es schlicht falsch ist, das zu tun", halte ich für nicht korrekt. Auf der anderen Seite ist es nun wirklich kein Beinbruch, wenn man das nicht kann! Ich möchte also einen Pinswap machen. Ich klicke im Layouttool auf einen der Pins, wechsle auf den Schemaeditor (der im Idealfall auf dem anderen Bildschirm schon offen ist), da ist der zugehörige Pin schon zentriert. Jetzt tausche ich die Anschlüsse, drücke auf "update PCB" und voilà. Ich bin mir nicht mal sicher, ob das mehr Mousklicks sind als bei Eagle nötig sind. Eine Umnummerierung im Schema anhand der Position im PCB ist auch möglich, und Footprintänderungen zurück ins Schema zu tragen, ebenfalls. Es wäre ein nettes Feature. Mehr nicht. Dieses Feature bei Eagle als Teufelszeug abzutun ist falsch, es als den Heiligen Gral zu stilisieren, ebenfalls. Meine Meinung.
Rolf Dietfurt schrieb: > Holm T. schrieb: >> Willste auf dem Niveau weiter machen? Kannste haben, kommt auf Deine >> Antwort an. >> Kleiner Tipp: höre auf mir übers Maul fahren zu wollen, das bereust Du. > > Du hast bei Deiner Ausdrucksweise gar kein Niveau. Und noch dazu keine > Ahnung von Eagle. Sagt hier wer? Hast Du Ahnung von irgendwas um diese Expertise von Dir geben zu können? ..Wohl nicht. Gruß, Holm
Karl schrieb: > Holm T. schrieb: >> ..ist kein Backannotate.. aber zumindest das Annotate des EEschema >> bietet ähnliche Funktionen auf den Schaltplan bezogen an. > > Ähm hallo? Natürlich ist das mit Back Annotation, wenn die Änderung der > Bauteilnummern im Layout auch die Bauteilnummern im Schematic ändert. > > Schau Dir mal eine ordentlich aufgeräumte professionelle Leiterplatte > an, wo die Nummerierung mit R001 oben links beginnt und dann bis R199 > unten rechts durchgeht. > > Du zeigst, dass Du keine Ahnung hast, wovon Du redest. Entschuldige bitte, auf meinen unprofessionellen Platinen ist meist kein Platz für Bestückungsdruck. > >> Geht also manchmal..geht in KiCad und zwar immer. > > Es ist nicht sinnvoll, dass das immer geht. Pinswap darf auch der > Autorouter, und Du möchtest nicht, dass der Autorouter in+ und in- eines > OPVs mal eben tauscht, weil es "immer" geht. Deswegen geht es auch bei Eagle nur manchmal, sicher immer genau dann wenn man es nicht braucht.. (fühlst Du Dich immer noch wohl?) > > Du zeigst, dass Du keine Ahnung hast, wovon Du redest. > >> ..Moment... der IC hat keinen Wert im Eagle-PCB? Geht doch gar nicht, >> der muß einen Wert und ein Footprint haben und zwar schon vor dem >> Schaltplan..habe ich hier gelernt. > > Der muss keinen Wert haben. Der muss nur eine Bauteil-ID haben. Aha. ..oder ein Gewicht. .. oder eine Länge. > > Du zeigst, dass Du keine Ahnung hast, wovon Du redest. Und Du zeigst mir das Du redest ohne Ahnung zu haben, die Hauptsache scheint zu sein das Du was sagst um etwas zu sagen..Content nicht erforderlich. Du solltest mehr RTL II gucken, das beruhigt, dort sieht man das normale Leben.. > >> KiCad sieht bei einem 7400 alternative 4 Subdevices, ich übrigens auch. > > Im Layout? Witzig, setzt man da ein DIL-14 aus 4 3-Pinnern und den 2 > Versorgungspins einzeln zusammen? Wohl kaum. Aber sicher tut man das, ...wenn man will. Wenn man nicht will, dann eben nicht. > >> Kleiner Tipp: höre auf mir übers Maul fahren zu wollen, das bereust Du. > > Sonst was? Kommt sonst Dein großer Bruder? Nein..Du bereust es dann, weil ich mir das auch erlaube. Du magst zwar viel dummes Zeug schwafeln, ich denke aber nicht das Du mit verbal gewachsen bist. Du ruderst doch jetzt schon nur noch herum.. Gruß, Holm
Holm T. schrieb: > Sagt hier wer? Hast Du Ahnung von irgendwas um diese Expertise von Dir > geben zu können? Für diese "Expertise" braucht man keine Ahnung von irgendwas, Holm.
Mir kommt diese Diskussion ein bisschen so vor: (die folgende Aussage ist frei erfunden, tatsächlich habe ich keine Ahnung, wie es wirklich ist) Bei Audi muss man den Scheibenwischerhebel nach unten ziehen, um die Scheibenwischer einzuschalten. Bei BMW muss man ihn hierfür nach oben ziehen. Nun wird seitenweise und hoch polemisch darüber diskutiert, ob Audi besser ist als BMW. Und die Richtung, in die die Scheibenwischer eingeschaltet werden, ist das einzige Kriterium, das hierfür herangezogen wird. Und beide Parteien schimpfen über das Auto der anderen, dass es den Scheibenwischer gar nicht einschalten könne, oder dass Scheibenwischer eh nicht nötig sind, weil man ja eh nie im Regen fährt, oder dass ein Auto, welches mit Diesel betrieben wird, grundsätzlich IMMER die Scheibenwischer nach unten betätigen muss, und dass Audi den Scheibenwischer sowieso von BMW abgeschaut hat und das Design des Bedienhebels versemmelt hat.
Ralf C. Werner schrieb: > Holm T. schrieb: >> Sagt hier wer? Hast Du Ahnung von irgendwas um diese Expertise von Dir >> geben zu können? > > Für diese "Expertise" braucht man keine Ahnung von irgendwas, Holm. Deswegen redet der auch so viel Ohne jeden Anflug von Ahnung.. Alles klar. Gruß, Holm
Vor allem verteidigt hier ein besonders eifersüchtiger Gockel sein KiCad mit einer verbalen Aggressivität, daß man sich schon fragt was damit vernebelt, verdeckt, ausgeglichen werden soll! Ich finde allein dieses Verhalten spricht schon voll gegen das vergötterte Objekt seiner blindwütigen Begierde...
Volker S. schrieb: > Zeno schrieb: >> KiCAD hat ein bestimmtes Feature nicht also braucht >> man es nicht. Das ist die falsche Herangehensweise. > > Die Frage ist doch eher ob der jeweilige Nutzer bereit > ist darauf zu verzichten. Ja -- aber der Anwender hat des Öfteren keine ganz freie Wahl. Ein Einzelkämpfer, der völlige Gestaltungsfreiheit in seinem Arbeitsablauf hat, wird das anders sehen als jemand, der im Team öfter als Layout-Feuerwehr herhalten muss, und der wieder anders als jemand, der ab und zu Aufträge für reverse engineering bekommt. > <edit2>Wenn ich es mir recht überlege, dann kännte der > Thread möglicherweise genau mit diesem Ziel von einem > ganz hinterhältigen Strippenzieher und Troll gestartet > worden sein ;-) Erfolg oder Misserfolg liegt häufig im Auge des Betrachters. Man kann sagen: "Furchtbar hier, 25 Beiträge mit Pöbeleien!" Man kann aber auch sagen: "Super -- 475 Beiträge mit nützlichem Wissen über Eagle und KiCAD".
Simon H. schrieb: > Mir kommt diese Diskussion ein bisschen so vor: > > (die folgende Aussage ist frei erfunden, tatsächlich habe ich keine > Ahnung, wie es wirklich ist) > > Bei Audi muss man den Scheibenwischerhebel nach unten ziehen, um die > Scheibenwischer einzuschalten. Bei BMW muss man ihn hierfür nach oben > ziehen. > > Nun wird seitenweise und hoch polemisch darüber diskutiert, ob Audi > besser ist als BMW. Und die Richtung, in die die Scheibenwischer > eingeschaltet werden, ist das einzige Kriterium, das hierfür > herangezogen wird. Und beide Parteien schimpfen über das Auto der > anderen, dass es den Scheibenwischer gar nicht einschalten könne, oder > dass Scheibenwischer eh nicht nötig sind, weil man ja eh nie im Regen > fährt, oder dass ein Auto, welches mit Diesel betrieben wird, > grundsätzlich IMMER die Scheibenwischer nach unten betätigen muss, und > dass Audi den Scheibenwischer sowieso von BMW abgeschaut hat und das > Design des Bedienhebels versemmelt hat. Dieser Ansatz kommt mir bekannt vor, das habe ich hier schon ca. 3 Mal versucht rüber zu bringen ..bis auf eine Einschränkung: Ich nörgele nicht an Eagle herum (weil ich es nicht kenne) sondern sage nur das es für meine Zwecke nicht geeignet ist (begründet). Ich verteidige hier im Prinzip nur KiCad gegen ungerechtfertigtes Deklassieren. Alle Argumente "gegen Eagle" stammen nicht von mir, sondern von Eagle Nutzern dieses Threads. Das Alleine ist aber völlig ausreichend das aus mir eine "Zielperson" wird die man gerne in Grund und Boden diskutieren möchte weil nicht sein kann was nicht sein darf. Die Eagle-Gläubigen haben Geld ausgegeben..das muß viel besser.. und KiCad unbrauchbar sein, geht gar nicht anders. Den Versuch mich zu überzeugen doch Eagle zu mieten darf man wohl als gescheitert betrachten, jetzt ist nur noch Feindschaft übrig....für mich eine Fingerübung. Ich wollte noch nie Leuten gefallen die ich nicht mag weil sie mich nicht mögen, das ist mehr ne Wessikrankheit. Ich bin nicht grundsätzlich überzeugt das KiCad der Weisheit letzter Schluß ist, 1. ist das Programm verhältnismäßig jung und wird mit vergleichsweise wenig Recourcen entwickelt und 2. gibt es das noch ältere Geda sowie 3. das neue Horizon von dem ich auch denke das ich es mal antesten sollte. Ich käme gar nicht auf die Idee so verbohrt wie meine Kontrahenten hier als Religionskrieger aufzutreten weil ich dächte das mir Jemand was wegnehmen will ;-) Klar will denen Jemand Eagle wegnehmen, das bin aber nicht ich, sondern der Eigner der Software mit seiner Marktpolitik. Deswegen ist KiCad Scheiße. ...R.i.p. Eagle. Gruß, Holm
Ralf C. Werner schrieb: > Vor allem verteidigt hier ein besonders eifersüchtiger Gockel sein KiCad > mit einer verbalen Aggressivität, daß man sich schon fragt was damit > vernebelt, verdeckt, ausgeglichen werden soll! Ich finde allein dieses > Verhalten spricht schon voll gegen das vergötterte Objekt seiner > blindwütigen Begierde... Lies Dir doch mal Dein Posting durch, hältst Du das für qualifiziert? Das ich hier KiCad verteidige ohne Eagle anzugreifen schreibe ich seit 3 Seiten...guten Morgen! Frag mal jemand Anderen ob er Dir bitte Dein Spielzeug zurück geben kann damit du nicht mehr so rumheulen mußt armer Ralf.. Gruß, Holm
Hai Bernd. Bernd W. schrieb: > Possetitjel schrieb: > >> Okay... bedeutet also folgendes: >> >> Eine anständige Bauteildatenbank muss folgende Optionen >> anbieten: >> - Bezugspunkt wie im Footprint festgelegt >> - Bezugspunkt einheitlich in Bauteilmitte >> - THT-Bezugspunkt auf Pin1, SMD-Bezugspunkt in Bauteilmitte >> >> Noch weitere? > > Natürlich. > > Unterschiedliche Footprints Hmpf. Es ging mir erstmal um die Wahl des Bezugspunktes. Gibt es noch andere gängige Varianten als "Pin1" oder "Mitte"? Ich frage ganz im Ernst, ich weiss das nicht. > für Reflow, Welle (Mit Tropfenfänger) und Handverlötung > Unterscheidliche Footprints für Robust, Standard und Fein. Hmm. Interessant. Danke. -- Attribut für "Handlötung" oder "Ofen" hatte ich mir auch schon mal überlegt. Gibt es unter den gängigen EDA-Systemen eins, das das schon unterstützt? > Weil kombinierbar macht das zusammen mit Deinen Vorschlägen > 27 Varianten für einen einzigen Footprint. Eher 9, würde ich sagen: Die Wahl des Bezugspunktes ändert ja nix an den Geometriedaten selbst, sondern beeinflusst nur die weitere Verarbeitung -- das werden also keine getrennten Varianten. > Die Datenbank wird groß. ;O) Och... geht noch.
Holm T. schrieb: > Lies Dir doch mal Dein Posting durch Lies Dir nochmal Deine Postings hier durch. In einer ruhigen Minute klaren Verstandes (den ich Dir durchaus zutraue) wirst Du Dich dafür schämen. So springt nur jemand mit seinen Mitmenschen um der nichts mehr zu verlieren hat.
Ein typischer Holm Tiffe - sollte denn nicht endlich ein Mod diesen Thread dicht machen ?!! Hat mit Eagle und Kikad nun langsam wirklich nichts mehr zu tun. Droggelbecher!
Simon H. schrieb: > Zeno schrieb: >> KiCAD hat ein bestimmtes Feature nicht also braucht man es >> nicht. Das ist die falsche Herangehensweise. > > Ja, da gebe ich Dir recht. Für mich scheint es genau zwei Meinungen zu > F/B Annotation zu geben: > > - Es ist absolut unnütz und kein Tool sollte so etwas haben dürfen. > - Ein Tool, welches das nicht kann, darf sich nicht tool (wofür auch > immer) nennen. ...das interpretierst Du nicht richtig. Meine Meinung ist schon das B. Annotation eine feine Sache ist und ich bin etwas traurig das KiCad das noch nicht kann, aber: Dieses Feature ist für mich nicht derart wichtig das es zum Ausschlußkriterium werden kann, zumal sich im Verlauf des Threads nun auch noch herausstellt das Eagle das auch nicht kann, sondern nur eine Teilmenge. Ok, das ist sicher besser als gar nichts, aber KiCad ist auch weit besser als gar nichts und es ist weit besser als Eagle mieten zu müssen. Ich habe versucht heraus zu arbeiten warum ich das so sehe, habe sogar oben Bildchen zu den Streitpunkten gemacht. Als Antwort verschwindet dann das Thema von der Bildfläche, es kommt kein Wort mehr. 10 Postings weiter unten geht aber der selbe Sermon wieder los. Es handelt sich hier überhaupt nicht um eine faire Diskussion sondern nur um das Wortgefecht wer hier das Arschloch ist (ich, sowieso) und das ich keine Ahnung hätte. Die Tatsache das meine "Gegner" ganz offensichtlich auch keine Ahnung haben wird aber ignoriert. was bleibt mir weiter als schmunzelnd vor dem Rechner zu sitzen und die die mich hier vollquasen ganz langsam zur Weißglut zu bringen? > > Ich finde es ziemlich [befremlich amüsant interessant], dass in beiden > Lagern die jeweilige Ansicht derart stark vertreten und verteidigt wird. Natürlich verteidige ich KiCad wenn darüber die Unwahrheit geschrieben wird und ich bin bei Weitem nicht der Einzige. Macht nix, Wahrheiten über eagle verträgt die Gegenpartei ja auch nicht. > > Meine Meinung ist, wie schon gesagt: > Backward annotation ist etwas, das manchmal wohl wirklich nützlich ist. > Der übliche Workflow geht in die andere Richtung (da wird wohl auch > jeder Eagle-Nutzer zustimmen). du hast meine volle Zustimmung. >Ja, wirklich, ich finde, wenn KiCad Pin > Swap im Layout beherrschen würde, wäre das cool! Oder auch einfach > Zurücklesen der Netzliste ins Schema. Ja. > Das einfach mit "Das DARF ein Tool > nicht können, weil es schlicht falsch ist, das zu tun", halte ich für > nicht korrekt. habe aber auch nicht ich geschrieben, sondern die KiCadSupermann wenn ich mich recht erinnere. Er hat zumindest zum Teil Recht. Es ist Blödsinn solch eine Vorgehensweise zu unterstützen weil sie die Lebenszeit des Menschen verschwendet der da vor dem Rechner sitzt. > Auf der anderen Seite ist es nun wirklich kein Beinbruch, wenn man das > nicht kann! Ich möchte also einen Pinswap machen. Ich klicke im > Layouttool auf einen der Pins, wechsle auf den Schemaeditor (der im > Idealfall auf dem anderen Bildschirm schon offen ist), da ist der > zugehörige Pin schon zentriert. Jetzt tausche ich die Anschlüsse, drücke > auf "update PCB" und voilà. Ich bin mir nicht mal sicher, ob das mehr > Mousklicks sind als bei Eagle nötig sind. ... > > Eine Umnummerierung im Schema anhand der Position im PCB ist auch > möglich, und Footprintänderungen zurück ins Schema zu tragen, ebenfalls. > > > Es wäre ein nettes Feature. Mehr nicht. Dieses Feature bei Eagle als > Teufelszeug abzutun ist falsch, es als den Heiligen Gral zu stilisieren, > ebenfalls. > > Meine Meinung. Das mit dem Teufelszeug hat Niemand getan. Gruß, Holm
Holm T. schrieb: > ..oder ein Gewicht. .. oder eine Länge. Nein, im Schematic weder noch. Im Footprint ist die Länge dann halt der Pinabstand bei einfachen Zweibeinern. Und wenn ich statt einen 0207 mit 10mm lieber einen mit 15mm will, kann ich das ganz einfach ändern. Im Layout. Mit Backanno zum Schematic. Was wolltest Du noch gleich?
Ralf C. Werner schrieb: > Holm T. schrieb: >> Lies Dir doch mal Dein Posting durch > > Lies Dir nochmal Deine Postings hier durch. > In einer ruhigen Minute klaren Verstandes (den ich Dir durchaus zutraue) > wirst Du Dich dafür schämen. So springt nur jemand mit seinen > Mitmenschen um der nichts mehr zu verlieren hat. Ich bin bereit von nahezu Jedem zu lernen, momentan lerne ich gerade wie man als anonymer Niemand der bisher nichts zu sagen hatte (und das auch jetzt nicht hat) einfach so andere Leute vollzubrechen versuchen kann. Mach mal weiter, offensichtlich macht Dir das ja Freude. Du kannst Dir auch gerne einen runter holen wenn Du magst, bist ja ein Niemand. Gruß, Holm
Holm T. schrieb: > Es ist > Blödsinn solch eine Vorgehensweise zu unterstützen weil sie die > Lebenszeit des Menschen verschwendet der da vor dem Rechner sitzt. Mal kurz die Anzahl Deiner Beiträge überfliegen, in denen Du Dich darüber echauffierst... Du machst Dir ernsthaft Sorgen um verschwendete Lebenszeit?
Holm T. schrieb: > Ich bin bereit von nahezu Jedem zu lernen, momentan lerne ich gerade wie > man als anonymer Niemand der bisher nichts zu sagen hatte (und das auch > jetzt nicht hat) einfach so andere Leute vollzubrechen versuchen kann. Dann hast Du gerade das falsche gelernt. > Du kannst Dir > auch gerne einen runter holen wenn Du magst, bist ja ein Niemand. Wäre es das richtige gewesen würdest Du jetzt nicht weiter so primitiv um Dich schlagen.
Karl schrieb: > Holm T. schrieb: >> ..oder ein Gewicht. .. oder eine Länge. > > Nein, im Schematic weder noch. Im Footprint ist die Länge dann halt der > Pinabstand bei einfachen Zweibeinern. Und wenn ich statt einen 0207 mit > 10mm lieber einen mit 15mm will, kann ich das ganz einfach ändern. Im > Layout. Mit Backanno zum Schematic. > > Was wolltest Du noch gleich? Sachlichkeit, dann rede ich auch mit Freude mit Dir. Vorschlag: Als Erstes lasse wir das mit "Keine Ahnung" mal gegenseitig bleiben? Man kann in KiCad nicht ganz ohne jeden Aufwand die nicht vorhandene Backannotation ersetzen, aber Eagle unterstützt diese auch nur zum Teil, diese war sowohl beim uralten DOS OrCAD, und ist bei Altium heute viel weiter ausgebaut, hätte ich gerne, ist aber nicht mein Dreh- und Angelpunkt. Ich probiere es nochmal von vorne. Ich bin zu dem Zweck hier in den Thread gestolpert um evtl. Jemandem mit Problemen hinsichtlich KiCad unter die Arme greifen zu können, nicht mehr. Ich bin gewiß nicht der KiCad Crack wie Bernd..aber möchtest du vielleicht noch irgend Etwas wissen wobei ich Dir behilflich sein könnte..um Dein teilweise etwas schräges Bild von dieser Software etwas gerade zu rücken? Gruß, Holm
Ralf C. Werner schrieb: > Holm T. schrieb: >> Ich bin bereit von nahezu Jedem zu lernen, momentan lerne ich gerade wie >> man als anonymer Niemand der bisher nichts zu sagen hatte (und das auch >> jetzt nicht hat) einfach so andere Leute vollzubrechen versuchen kann. > > Dann hast Du gerade das falsche gelernt. > Och, ma nimmt halt was man kriegen kann.. >> Du kannst Dir >> auch gerne einen runter holen wenn Du magst, bist ja ein Niemand. > > Wäre es das richtige gewesen würdest Du jetzt nicht weiter so primitiv > um Dich schlagen. Ich schlage nicht, ich sitze hier und halte die Arme ruhig, ich bewege nur die Fingerspitzen... es ist wirklich bei Dir kein all zu hoher Aufwand nötig um sich an Dein Niveau anzupassen Süßer... Schmatz auf den Bauch das die Seele quietscht, Holm
Karl schrieb: > Holm T. schrieb: >> Es ist >> Blödsinn solch eine Vorgehensweise zu unterstützen weil sie die >> Lebenszeit des Menschen verschwendet der da vor dem Rechner sitzt. > > Mal kurz die Anzahl Deiner Beiträge überfliegen, in denen Du Dich > darüber echauffierst... Du machst Dir ernsthaft Sorgen um verschwendete > Lebenszeit? Karl das ist Unfug. Ich begrüße diese Vorgehensweise nicht, aber ich echauffiere mich auch nicht drüber. Ich weiß nur das nicht viel dabei heraus kommen wird und das es deswegen Unfug ist. Was ich sinnvoll finde ist beispielsweise ein Layout aus einer Zeitung als Hintergrund laden zu können um es händisch gerade ziehen zu können. Das geht bei Sprint Layout, bei KiCad soll es über Umwege auch gehen, habe mir das mal im KiCad Forum erklären lassen aber es noch nicht selber ausprobiert. Es ist der selbe Weg wie um aus Bitmaps Logos (-footprints) zu machen. Gruß, Holm
Holm T. schrieb: > es ist wirklich bei Dir kein all zu hoher > Aufwand nötig um sich an Dein Niveau anzupassen Glauben ist nicht Wissen. In Deinem gegenwärtigen Zustand wäre ich da vorsichtig. Immerhin hast Du aber gleich erkannt daß oben beschriebener eifersüchtiger Gockel nur Du sein kannst. Soviel Realitätssinn muß man Dir in Deiner engen Welt schon hoch anrechnen.
Da Holm ja etwas anders veranlagt zu sein scheint („...Süßer“) könnt ihr das nicht in einem andern Forum austragen?
Ralf C. Werner schrieb: > Holm T. schrieb: >> es ist wirklich bei Dir kein all zu hoher >> Aufwand nötig um sich an Dein Niveau anzupassen > > Glauben ist nicht Wissen. > In Deinem gegenwärtigen Zustand wäre ich da vorsichtig. > Immerhin hast Du aber gleich erkannt daß oben beschriebener > eifersüchtiger Gockel nur Du sein kannst. Soviel Realitätssinn muß man > Dir in Deiner engen Welt schon hoch anrechnen. Weißt Du Hasi Du solltest jetzt schlafen gehen, der Sandmann ist schon lange im Bett und die Sternlein leuchten am Firmament. Du hast schon ganz müde Augen (freundlich über die Wange streich..) Der Holm kommt morgen wieder vorbei und erzählt Dir eine neue Geschichte, versprochen. Schmatzi, Holm
Droggelbecher schrieb:
Im Becheldrogger-Forum?
Ist das hier eigentlich ein Wettbewerb wer den doofsten Anonymous
abgeben kann? Bist Du ne Transe Süße?
Holm
Holm T. schrieb: > Der Holm kommt morgen wieder vorbei und erzählt Dir eine neue > Geschichte Sehr gut Holm. Du hast erkannt daß Du ein wunderbarer Geschichten-Erzähler bist. Jeden Tag eine neue ?!
Schade, das sich Holm selbst hier so disqualifiziert, fachlich war er manchmal gar nicht soo schlecht!
Sheeva P. schrieb: > Possetitjel schrieb: >> gEDA ist seit längerem auf meiner privaten Kiste >> installiert, KiCAD seit ein paar Monaten -- Hauptzweck >> war bisher, auf die Schnelle mal einzelne Teilfunktionen >> ausprobieren zu können. Komplette Projekte habe ich damit >> noch nicht abgewickelt, das stimmt. > > Same with me. gEDA ist aber auch nicht der wahre Jakob Um Gottes Willen -- nein. Mir gefällt gEDA wegen seiner Modularität und gschem wegen seines schlichten und klaren GUI -- aber komplette Projekte würde ich damit auch nicht unbedingt abwickeln wollen. > und verwendet, wenn ich das richtig verstanden habe, > einen ähnlichen Workflow wie KiCad. Ja. Konsequente Trennung von Schaltplan und Layout; keine projektweite Datenbank ("Super-Stückliste"). >> - Ich habe mir eine Mini-Suchmaschine für Datenbläter >> programmiert (extrem rudimentär, aber ziemlich praktisch). > > Lustig, hab' ich auch. [...] > Ich habe mich nämlich im Laufe vieler Jahre meines privaten > und beruflichen Lebens sehr, sehr intensiv mit Datenbanken, > SQL, Modellierung, Normalformen und Performanceoptimierung > befaßt. > > Nebenbei bemerkt würde ich für Datenblätter keine SQL- > Datenbank [...] benutzen. Das Ganze ist ein extremes Kuriosum. Ich verwende das Filesystem als "Datenbank" und speziell konstruierte Dateinamen als Schlüssel. Anbindung an eine echte Datenbank ist angedacht; Zusammenarbeit mit einem Volltext-Index o.ä. sollte genauso machbar sein. Vielleicht ergänzen sich unsere Ansätze. > Wenn Du interessiert bist, können wir uns diesbezüglich > gerne austauschen. Ja... wir hatten das ja in einem anderen Thread schonmal angedacht... > Weiter oben habe ich ein (stark vereinfachtes) UML-Schema > für derartige Datenbanken gepostet, vielleicht können wir > das als Gesprächsgrundlage zum Einstieg verwenden. Leider > hat da niemand was zu gesagt, was verschiedene Vermutungen > zuläßt: a) es hat keiner verstanden, b) es ist so gut, daß > man es nicht kritisieren kann, oder c), es war den Leuten > in dieser Phase der Diskussion egal. Ich wähle a) und c)... :) > Wie auch immer: wenn Du Lust hast, plz send a PM. Ja... lass' mir ein paar Tage, um über meinen Schatten zu springen... >> (Ach so, und nur für's Protokoll: Die Idee der "Super- >> Stückliste" ist ganz offensichtlich weder trivial noch >> selbstverständlich, denn gEDA hat keine und KiCAD - >> soweit ich weiss - auch nicht .) > > Wenn ich Dein Konzept richtig verstanden habe, ist die > "Superstückliste" eine Datenstruktur, die oberhalb der > Schaltpläne und Layouts angesiedelt werden müßte Ja. > und von diesen referenziert würde, korrekt? Ja, genau. >>> Jeder muss für sich selber das Programm finden, mit dem >>> er am besten klarkommt, oder halt selber eins schreiben. >>> Siehe Horizon. Das kommt Deiner Datenbankidee (die ich >>> persönlich auch interessant finde) wohl schon sehr nahe. >> >> Kann sein, ja. > > Vielleicht sind Leute, die EDA-Software schreiben, ja auch > einfach keine eingefleischten Datenbänker und -Modellierer. Die Vermutung hat Jörg W. mit seinem charmanten Spott auch schon geäußert... Das wird so sein, ja. > Aus meiner Informatiksicht sind Bauteil-Libraries im > Wesentlichen Datenbanken mit Relationen Ja. > (dabei aber nicht notwendigerweise klassische RDBMS), Nicht notwendigerweise -- aber möglicherweise :) Man sollte die Idee nicht vorschnell verwerfen. > während Schaltpläne sowie Layouts im Prinzip zunächst eine > Sonderform von ungerichteten, und zudem häufig zyklischen > Graphen mit gruppierten Nodes (Pins) sind. Graphen: Ja, auf jeden Fall. Die Details sind ggf. noch zu diskutieren (Knoten, Kanten, Vergröberung, Teilgraphen, ...) > Die Edges des Graphen sind dann die Verbindungen zwischen > den Nodes einer Node-Gruppe, oder, elektronisch: die > Verbindungen im Schaltplan oder die Leiterbahnen eines > konkreten Layouts. Interessant ist, dass sich Graphen rechentechnisch durch Listen repräsentieren lassen. Layout als Beispiel: Jeder Leiterzug besteht aus Segmenten; jede "Unstetigkeitsstelle" im Leiterzug entspricht einer "Stützstelle" (=Knoten). Jeder Layoutknoten ist durch seine Koordinaten charakterisiert. Um das Layout zu beschreiben, braucht man "nur" eine Knoten- liste, die Knoten-ID und Koordinaten zuordnet, und eine Kantenliste, die für jedes "Leiterzugsegment" (Kante) Startknoten-ID, Endknoten-ID und ggf. weitere Attribute aufnimmt. Soweit ganz einfach :)
Sheeva P. schrieb: >> Jein... Missverständnis. Was unter Backward-Annotation >> verstanden wird, ist gar nicht so eindeutig: >> >> Wenn es eine projektweite zentrale Datenbank gibt, dann ist >> die Backward-Annotation lediglich ein Zugriff auf diese >> Datenbank von einer ungewöhnlichen Stelle aus. Das ist ein >> reines GUI-Thema; wenn User das haben wollen, soll(t)en >> sie das bekommen. > > Ok, Du siehst diesen Aspekt wieder aus Deiner Perspektive > mit einer zentralen Datenbank. Ja, klar -- weil nämlich aus dieser Perspektive verständlich wird, dass unter demselben Begriff "backward annotation" unter Umständen technisch ganz verschiedene Dinge verstanden werden, die nur von außen ähnlich aussehen! >> Wenn Schaltplan und Layout aber getrennte Datenstrukturen >> sind, sieht die Sache anders aus. > > Das wirft wieder ganz andere Probleme auf: die Synchronisation > unter im Zweifelsfall parallelen Modifikationen an verschiedenen > Stellen. Richtig! Und deshalb ist der Verzicht auf eine projektweite Datenbank NICHT von vornerhein ein Designfehler! Es kann auch ein Akt weiser Selbstbeschränkung sein! Und darüberhinaus: Ich sehe keinen Grund, warum eine solche projektweite Datenbank nicht nachträglich integriert werden können sollte, wenn die Software hübsch modularisiert entwickelt wurde. > Das Problem scheint mir weniger das Vorhandensein oder die > Absenz einer zentralen Datenbank zu sein, sondern vielmehr > a) deren Design sowie b) deren Verwendung. Eigentlich bräuchte > man nämlich zwei Datenbanken, eine für die konkrete Auswahl > beim Erstellen von Schaltplänen und PCB-Layouts, und eine > zweite für jedes konkrete Projekt. Genau. In meinem Slang: "Bauteildatenbank" und "Super-Stückliste". > Die Projekt-Datenbank müßte dann die zum konkreten > Zeitpunkt des Schaltplan- oder Platinenentwurfes genutzten > Elemente enthalten. Genau.
Zeno schrieb: > Aber ansonsten spielst Du Karl eher mit Deiner Aussage > > KiCadSuperman schrieb: >> Wenn du damit das "Back -Zeugsel" meinst, das braucht man wirklich >> nicht. > > die Bälle zu. KiCAD hat ein bestimmtes Feature nicht also braucht man es > nicht. Das ist die falsche Herangehensweise. Sagen wir es so: KiCad hat ein bestimmtes Feature nicht, weil die Entwickler es nicht für besonders nützlich halten. Das tun sie mutmaßlich darum nicht, weil es dem von den Entwicklern vorgesehenen, geordneten Workflow (Schematic -> Layout) zuwiderlaufen und außerdem höchstwahrscheinlich Inkonsistenzen zwischen PCB und Schaltplan provozieren würde. Trotzdem gibt es mindestens ein Drittwerkzeuge, das dieses Feature anbietet.
Simon H. schrieb: > Der übliche Workflow geht in die andere Richtung (da wird wohl auch > jeder Eagle-Nutzer zustimmen). (gemeint ist nach vorne) Ja gut, dann könnten wir diesen Teilaspekt zugunsten von KiCad at Acta legen ;-) Lasst uns ein anders Kapitel aufschlagen was den "Wechslern" bestimmt auch interessieren könnte: KiCAd 3D und Step. Ich sag's euch seit bei mir 3D so flutscht, kann ich mir stundenlang meine fertigen Projekte von allen Seiten anschauen. Manchmal übertreibe ich es und baue in FreeCad noch Gehäuse drum rum und lass das wiederum vor meinen Augen rotieren. Mir gefällt das einfach um nicht zu sagen es ist geil. (Seit das bei mir so perfekt funzt schaue ich keine Heimatfilme mehr an ;-) ;-)
Sheeva P. schrieb: > Sagen wir es so: KiCad hat ein bestimmtes Feature nicht, weil die > Entwickler es nicht für besonders nützlich halten. Das tun sie > mutmaßlich darum nicht, weil es dem von den Entwicklern vorgesehenen, > geordneten Workflow (Schematic -> Layout) zuwiderlaufen und außerdem > höchstwahrscheinlich Inkonsistenzen zwischen PCB und Schaltplan > provozieren würde. Trotzdem gibt es mindestens ein Drittwerkzeuge, das > dieses Feature anbietet. Für die Features Pin&Gate-Swap findet sich immerhin ein Roadmap-Eintrag für V6. Wird noch dauern, da gerade erst V5 auf Release zu geht, aber ist nicht im Zustand "braucht man nicht": "Pin and Part Swapping ## {#pcb_drc} Goal: Allow Pcbnew to perform pin and/or part swapping during layout so the user does not have to do it in Eeschema and re-import the net list. Task: - Provide forward and back annotation between the schematic and board editors. - Define netlist file format changes required to handle pin/part swapping. - Update netlist file formatter and parser to handle file format changes. - Develop a netlist comparison engine that will produce a netlist diff that can be passed between the schematic and board editors. - Create pin/part swap dialog to manipulate swappable pins and parts. - Add support to handle net label back annotation changes. Dependencies: - S-expression schematic file format. - Convert to a single process application." Neben der Tatsache, daß KiCad nichts kostet, was für manche "Fehler" entschädigt, wurde es auch nicht "am Stück" entwickelt. Deshalb gibt es (Datei-)Schnittstellen zwischen den "Einzelteilen". Als Monolith versucht, gäbe es den Diskusionsgegenstand vermutlich heute gar nicht. Aber auch das steht, da Voraussetzung für pin/part-swap, auf der Roadmap: "Convert to a Single Process Application. ## {#kiway} Goal: Merge common schematic and board code into to separate dynamic objects to allow Eeschema and Pcbnew to run under a single process."
Hallo, ich weiß nicht ob das hilft, aber ich hatte bisher das Vergnügen mit 3 CAD Systemen zu arbeiten. Nähmlich Eagle, Target und Kicad. Ich bin mit allen dreien zurechtgekommen. Eine Einarbeitungsphase vorausgesetzt. Bei allen 3 Tools hatte ich auch Probleme bei der Vorgehensweise bei bestimmten Problemen. Ich konnte sie aber lösen. Im Detail fallen mir die Probleme nicht mehr ein. Aber brauchbare Ergebnisse liefern alle Tools. Wenn ich mich heute auf ein System festlegen müßte wäre das Kicad. Fragt mich nicht warum, aber im Hobbybereich und für meine Ansprüche im beruflichen Alltag reicht es aus. Und wenn wie im obigen Beitrag erwähnt Features wie die BackwardAnnotation eventuell hinzugefügt werden, zeigt das doch das man von Kicad in Zukunft noch mehr erwarten kann. gruß ralf
Karl schrieb: > Warum Gateswap nicht geht? Wie willst Du bei einem DIL-14 auswählen, > welche Gates Du tauschen willst? Du siehst ja nur das Package, aber > nicht die Symbole. Stelle ich mir nicht so schwer vor: Netz anwählen welches "nicht passt". Gateswap "anfordern". Die Software zeigt automatisch die Pins die in Frage kommen würden. Idealerweise auch welche Pins davon noch betroffen sind. Der Benutzer entscheidet sich für eine Variante, oder keine. Fertsch!
Droggelbecher schrieb: > Schade, das sich Holm selbst hier so disqualifiziert, fachlich war er > manchmal gar nicht soo schlecht! >Ein typischer Holm Tiffe - sollte denn nicht endlich ein Mod diesen >Thread dicht machen ?!! Hat mit Eagle und Kikad nun langsam wirklich >nichts mehr zu tun. > >Droggelbecher! Ich hätte mich sicherlich lieber mit den Sachthemen beschäftigt und nicht mit solchen hinterhältigen Beinpissern wie Dir, Du hast nichts beizutragen, tauchst anonym auf hast aber ne Meinung was Dir serviert werden sollte? Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? Gruß, Holm
Volker S. schrieb: > <edit2>Wenn ich es mir recht überlege, dann kännte der Thread > möglicherweise genau mit diesem Ziel von einem ganz hinterhältigen > Strippenzieher und Troll gestartet worden sein ;-) Nö, ich hab mich nur über mich selbst gewundert, da ich mich am Anfang mit KiCad so schwer tat, und nun nach 2 Jahren eagle-Abstinenz tu ich mich mit dem eagle wiederum schwer. Aber was solls, nach kurzer (Wieder-)Eingewöhnungsphase passts wieder ;-) Hier hab ich zugegebenermassen immer wieder schmunzelnd mitgelesen. Und viel gelernt! Weder über KiCad oder eagle, eher über das Zwischenmenschliche in all seinen Schattierungen Ralf C. Werner schrieb: > Vor allem verteidigt hier ein besonders eifersüchtiger Gockel sein KiCad > mit einer verbalen Aggressivität, daß man sich schon fragt was damit > vernebelt, verdeckt, ausgeglichen werden soll! Ich finde allein dieses > Verhalten spricht schon voll gegen das vergötterte Objekt seiner > blindwütigen Begierde... Wenn das deine Grundlage ist um ein Stück Software zu bewerten, dann möchte ich nicht wissen wie du /hier überlasse ich es dem geneigten Leser und seiner Phantasie nach Gutdünken einzufügen was ihm passend erscheint/ ausgesucht hast... Ohne Ironie: Sehr sachlich finde ich das nicht
Holm T. schrieb: > Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? Ähmm... du bist dir aber schon bewusst dass der über jedem deiner Postings in dem kleinen orangefarbenen Balken für jedermann lesbar auftaucht?
Holm T. schrieb: > solchen hinterhältigen Beinpissern wie Dir > werden sollte? > du Arsch? Ob er es noch lernt sich in einem Forum angemessen zu verhalten? > tauchst anonym auf Dir ist schon bekannt daß auch Angemeldete meist anonym sind und sich Accounts hier beliebig anonym anlegen lassen? Bleib doch bitte sachlich und beim Thema. Drohende Protzerei mit verbaler Überlegenheit, garniert mit Beleidigungen aller Art sind selten dazu angetan hier zu überzeugen. Bob A. schrieb: > Ohne Ironie: Sehr sachlich finde ich das nicht Da gebe ich Dir Recht. Es könnte aber dazu beitragen die weitere Diskussion hier zu versachlichen. Ohne Ironie.
Hallo Holm, > ich denke aber nicht das Du mit verbal gewachsen bist. und > Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? Ich finde, es gehört nicht viel dazu dir verbal gewachsen zu sein. rhf
Possetitjel schrieb: > Sheeva P. schrieb: >> Weiter oben habe ich ein (stark vereinfachtes) UML-Schema >> für derartige Datenbanken gepostet, vielleicht können wir >> das als Gesprächsgrundlage zum Einstieg verwenden. Leider >> hat da niemand was zu gesagt, was verschiedene Vermutungen >> zuläßt: a) es hat keiner verstanden, b) es ist so gut, daß >> man es nicht kritisieren kann, oder c), es war den Leuten >> in dieser Phase der Diskussion egal. > > Ich wähle a) und c)... :) Die weißen Felder bilden Datenbanktabellen oder Elasticsearch-Doctypes ab, die gestrichelten Linien die Referenzen dazwischen. Die eingefärbten Felder zeigen, welche Teile der DB für welche Produktionsstufe notwendig sind. Und ja, es fehlen die Attribute in den Tabellen. Vermutlich nicht der Weisheit letzter Schluß, aber immerhin ein Anfang. >> Wie auch immer: wenn Du Lust hast, plz send a PM. > > Ja... lass' mir ein paar Tage, um über meinen Schatten > zu springen... Ich bin hier. ;-) >> Wenn ich Dein Konzept richtig verstanden habe, ist die >> "Superstückliste" eine Datenstruktur, die oberhalb der >> Schaltpläne und Layouts angesiedelt werden müßte > > Ja. > >> und von diesen referenziert würde, korrekt? > > Ja, genau. Dann wäre diese Superstückliste also ein Superset der Bauelemente-DB, in das die Bauelemente kopiert (think Abkündigung oä.) werden müssen. >> Aus meiner Informatiksicht sind Bauteil-Libraries im >> Wesentlichen Datenbanken mit Relationen > > Ja. > >> (dabei aber nicht notwendigerweise klassische RDBMS), > > Nicht notwendigerweise -- aber möglicherweise :) > Man sollte die Idee nicht vorschnell verwerfen. Das Problem klassischer RDBMs sehe ich dabei vor allem darin, daß diese in der Regel ein festes Schema brauchen -- es sei denn, man würde etwas nutzen wie zum Beispiel den HStore oder die JSON-Features von PostgreSQL, die dann aber software- und/oder SQL-seitig anders gehandhabt werden müssen. Mit den modernen NoSQL-DBs hätte man dabei den Vorteil, daß ein festes Schema nicht notwendig ist, und jedes Bauelement genau die Attribute haben kann, die es braucht -- und auf Wunsch sogar noch mehr. >> während Schaltpläne sowie Layouts im Prinzip zunächst eine >> Sonderform von ungerichteten, und zudem häufig zyklischen >> Graphen mit gruppierten Nodes (Pins) sind. > > Graphen: Ja, auf jeden Fall. > > Die Details sind ggf. noch zu diskutieren (Knoten, Kanten, > Vergröberung, Teilgraphen, ...) Ja, aber das wäre ggf. ein nächster Schritt. >> Die Edges des Graphen sind dann die Verbindungen zwischen >> den Nodes einer Node-Gruppe, oder, elektronisch: die >> Verbindungen im Schaltplan oder die Leiterbahnen eines >> konkreten Layouts. > > Interessant ist, dass sich Graphen rechentechnisch durch > Listen repräsentieren lassen. Adjazenzlisten, hach ja... ;-) > Layout als Beispiel: Jeder > Leiterzug besteht aus Segmenten; jede "Unstetigkeitsstelle" > im Leiterzug entspricht einer "Stützstelle" (=Knoten). Hm, ich weiß nicht, ob ich das so modellieren würde. Eigentlich würde ich eher die Bauelemente als Nodes und die Leiterzüge als Edges sehen, und die Koordinaten ("Unstetigkeitsstellen") als Listen von Attributen abbilden. Aber, wie gesagt, das wäre ein nächster Schritt.
Bob A. schrieb: > Holm T. schrieb: >> Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? > > Ähmm... du bist dir aber schon bewusst dass der über jedem deiner > Postings in dem kleinen orangefarbenen Balken für jedermann lesbar > auftaucht? Ja. Gruß, Holm
Ralf C. Werner schrieb: > Holm T. schrieb: > >> solchen hinterhältigen Beinpissern wie Dir >> werden sollte? >> du Arsch? > > Ob er es noch lernt sich in einem Forum angemessen zu verhalten? Na dan versuche doch mal mit gutem Beispiel voran zu gehen Schatzi. > >> tauchst anonym auf > > Dir ist schon bekannt daß auch Angemeldete meist anonym sind und sich > Accounts hier beliebig anonym anlegen lassen? > > Bleib doch bitte sachlich und beim Thema. > Drohende Protzerei mit verbaler Überlegenheit, garniert mit > Beleidigungen aller Art sind selten dazu angetan hier zu überzeugen. Dein dümmliches Gequatsche aber auch nicht. > > Bob A. schrieb: >> Ohne Ironie: Sehr sachlich finde ich das nicht > > Da gebe ich Dir Recht. Es könnte aber dazu beitragen die weitere > Diskussion hier zu versachlichen. Ohne Ironie. Ach? Wie wäre es denn verlaufen wenn Du mal sachlich in die Diskussion eingestiegen wärst und mich nicht dumm angemacht hättest? Gruß, Holm
Roland F. schrieb: > Hallo Holm, > >> ich denke aber nicht das Du mit verbal gewachsen bist. > > und > >> Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? > > Ich finde, es gehört nicht viel dazu dir verbal gewachsen zu sein. > > rhf Goto -> Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern" Gruß, Holm
Possetitjel schrieb: > Man kann sagen: "Furchtbar hier, 25 Beiträge mit Pöbeleien!" > Man kann aber auch sagen: "Super -- 475 Beiträge mit > nützlichem Wissen über Eagle und KiCAD". Schön wäre es wenn wenn dann von den 475 Beiträgen mit nützlichem Wissen, diese sich dann auch irgendwie am Thread-Titel orientieren würden. Hier posaunen doch viele völlig unpassend ihre persönlichen Weisheiten heraus. Leider mit meist negativem Inhalt um irgendwas schlecht zu machen Nur weil das die absolut beste Möglichkeit ist einen Thread zu zerstören?
Ralf C. Werner schrieb: > Bleib doch bitte sachlich und beim Thema. Das ist ein ebenso guter wie weiser Hinweis. Schade nur, daß er von jemandem kommt, der IIRC noch nicht ein einziges Wort zur Sache beigetragen hat. > Es könnte aber dazu beitragen die weitere Diskussion > hier zu versachlichen. Ohne Ironie. Ja, Du aber auch. Holm zu provozieren scheint mir auch nicht eben geeignet, die Diskussion zu versachlichen, zumal Droggelbecher und Du meines Wissen bisher noch so gar nichts zum Thema gesagt habt.
Possetitjel schrieb: > Es ging mir erstmal um die Wahl des Bezugspunktes. Gibt > es noch andere gängige Varianten als "Pin1" oder "Mitte"? > Ich frage ganz im Ernst, ich weiss das nicht. In allen Systemen, die ich bisher verwendet habe gibt es da keine Einschränkungen. Der Referenzpunkt von Schaltplan-Symbolen und Layout-Bauformen ist völlig frei platzierbar. Im Laufe der Zeit bin ich persönlich davon abgekommen Pin1 zu nehmen und wähle eigentlich immer die Mitte, wenn ich Symbole oder Bauformen selber erstelle. Possetitjel schrieb: > Hmm. Interessant. Danke. -- Attribut für "Handlötung" oder > "Ofen" hatte ich mir auch schon mal überlegt. > Gibt es unter den gängigen EDA-Systemen eins, das das schon > unterstützt? Alle? Das sind doch nur unterschiedliche Bauformen, mit unterschiedlich großen Pads. Ein Bauteil konnte bisher bei allen meinen Systemen mehrere unterschiedliche Bauformen haben.
Holm T. schrieb: > Na dan versuche doch mal mit gutem Beispiel voran zu gehen Schatzi. Wenn man das wenigstens als Eingeständnis werten könnte daß Deines bislang kein besonders leuchtendes war wären wir einen (kleinen) Schritt weiter. > Dein dümmliches Gequatsche aber auch nicht. Wir wärs wenn Du solche Beleidigungen einfach mal sein lässt? Probiers mal! > mich nicht dumm angemacht hättest? Was Du schon "dumm anmachen" nennst ist meist nur sachliche Kritik. Die verträgst Du schlecht. Und antwortest dann geradezu inflationär wirklich dumm anmachend, auf unterster Evolutionsstufe. Sheeva P. schrieb: > Ja, Du aber auch. Holm zu provozieren scheint mir auch nicht eben > geeignet, die Diskussion zu versachlichen Nein, irgendjemand muß diesem ausfallenden Herren hier mal die Grenzen aufzeigen. Das dürfte langfristig eher deeskalierend wirken, so meine Hoffnung.
Volker S. schrieb: > In allen Systemen, die ich bisher verwendet habe gibt es da keine > Einschränkungen. Der Referenzpunkt von Schaltplan-Symbolen und > Layout-Bauformen ist völlig frei platzierbar. Im Laufe der Zeit bin ich > persönlich davon abgekommen Pin1 zu nehmen und wähle eigentlich immer > die Mitte, wenn ich Symbole oder Bauformen selber erstelle. Im Grunde ist die Bezugspunktwahl recht unerheblich wenn man sich nur an ein konstantes Schema hält, um später bei der Anwahl nicht gar so wild im Nebel rumzustochern. Bei mir ist das ein markierter Gehäuserand Nähe Pin1. Der Pin1 selber ist nicht immer sofort ersichtlich, die Mitte trifft man auch nicht immer sicher.
Ralf C. Werner schrieb: > Holm T. schrieb: >> Na dan versuche doch mal mit gutem Beispiel voran zu gehen Schatzi. > > Wenn man das wenigstens als Eingeständnis werten könnte daß Deines > bislang kein besonders leuchtendes war wären wir einen (kleinen) Schritt > weiter. > >> Dein dümmliches Gequatsche aber auch nicht. > > Wir wärs wenn Du solche Beleidigungen einfach mal sein lässt? > Probiers mal! > >> mich nicht dumm angemacht hättest? > > Was Du schon "dumm anmachen" nennst ist meist nur sachliche Kritik. > Die verträgst Du schlecht. Und antwortest dann geradezu inflationär > wirklich dumm anmachend, auf unterster Evolutionsstufe. > > Sheeva P. schrieb: >> Ja, Du aber auch. Holm zu provozieren scheint mir auch nicht eben >> geeignet, die Diskussion zu versachlichen > > Nein, irgendjemand muß diesem ausfallenden Herren hier mal die Grenzen > aufzeigen. Das dürfte langfristig eher deeskalierend wirken, so meine > Hoffnung. Ausgerechnet Du, der hier damit glänzt nur völlig inhaltsleeres Geschwätz ohne jeden technischen Bezug von sich zu geben fühlst Dich berufen mir hier die Grenzen aufzuzeigen? Ich würde mich in Deinem Fall Dieter Nuhr anschließen: https://www.youtube.com/watch?v=rq68A07CDcM Gruß, Holm
Holm T. schrieb: > Ausgerechnet Du, der hier damit glänzt nur völlig inhaltsleeres > Geschwätz ohne jeden technischen Bezug von sich zu geben fühlst Dich > berufen mir hier die Grenzen aufzuzeigen? Nein Holm, nicht ausgerechnet ich. Dazu wäre jeder halbwegs zivilisierte Mensch in der Lage. Dein vorhandenenes KiCad Wissen ersetzt leider den Anstand nicht.
Ralf C. Werner schrieb: > Holm T. schrieb: >> Ausgerechnet Du, der hier damit glänzt nur völlig inhaltsleeres >> Geschwätz ohne jeden technischen Bezug von sich zu geben fühlst Dich >> berufen mir hier die Grenzen aufzuzeigen? > > Nein Holm, nicht ausgerechnet ich. Dazu wäre jeder halbwegs zivilisierte > Mensch in der Lage. Dein vorhandenenes KiCad Wissen ersetzt leider den > Anstand nicht. Du aber bist der anständigste Mensch hier im Forum und schreibst ausschließlich sachlich bezogene Beiträge? >Vor allem verteidigt hier ein besonders eifersüchtiger Gockel sein KiCad >mit einer verbalen Aggressivität, daß man sich schon fragt was damit >vernebelt, verdeckt, ausgeglichen werden soll! Ich finde allein dieses >Verhalten spricht schon voll gegen das vergötterte Objekt seiner >blindwütigen Begierde... Entschuldige bitte: Reality check. Wie soll ich mit dieser sachlichen Art Eingrenzung eines Begrenzugspfahls Deiner Meinung nach umgehen? Genau, ich trete dieses unsachliche, arrogante Arschloch einfach in den Hintern. Gruß, Holm
Beitrag #5358632 wurde von einem Moderator gelöscht.
Ralf G. schrieb im Beitrag #5358632: > Holm T. schrieb: >> Ausgerechnet Du, der hier damit glänzt nur völlig inhaltsleeres >> Geschwätz ohne jeden technischen Bezug von sich zu geben fühlst Dich >> berufen mir hier die Grenzen aufzuzeigen? > > Dann füll' ich das mal mit Inhalt: > > Holm T. schrieb: >> Die Contenance verliere ich allerings niemals :-) > Holm T. schrieb: >> Ich bin völlig ruhig und gefaßt. > > Holm T. schrieb: >> Du bist mir ein ganzes Stück zu primitiv. > Holm T. schrieb: >> Du gehst mir unendlich auf die Eier. > Holm T. schrieb: >> Du bist ein kranker Mann. > Holm T. schrieb: >> wahrscheinlich fehlen Dir dazu aber die Eier in der Hose. >> [...] >> Du hast in meinen Augen eine völlig neue Qualifikationsstufe erreicht, >> die liegt aber leider nicht höher als die Vorhergehende. >> >> Ist das schon präsenile Demenz? Ich weiß es nicht... > Holm T. schrieb: >> Du kannst Dir auch gerne einen runter holen wenn Du magst, bist ja ein Niemand. > Holm T. schrieb: >> hinterhältigen Beinpissern wie Dir, >> [...] >> du Arsch > > Holm T. schrieb: >> Ach? Wie wäre es denn verlaufen wenn Du mal sachlich in die Diskussion >> eingestiegen wärst und mich nicht dumm angemacht hättest? > > Ralf C. Werner schrieb: >> Nein, irgendjemand muß diesem ausfallenden Herren hier mal die Grenzen >> aufzeigen. Das dürfte langfristig eher deeskalierend wirken, so meine >> Hoffnung. Ja und? Mach Dir mal jetzt bitte die Mühe die jeweiligen Anlässe dazu zu zitieren. ..ach zu viel Arbeit? Na Sowas. Gruß, Holm
Ach menno, Leute! Ich (und vielleicht noch ein paar andere) verfolgen diesen Thread mit echtem Interesse, und euer kindisches Gestänkere geht mir sowas von auf den Sack! Noch dazu wo es hier nichtmal eine ignore-Funktion gibt... also reissts euch bitte etwas zusammen, und benehmts euch wie halbwegs erwachsene Menschen.
Holm T. schrieb: > Du aber bist der anständigste Mensch hier im Forum und schreibst > ausschließlich sachlich bezogene Beiträge? Zunächst mal geht es um anständige Umgangsformen. Grundvoraussetzung um jedwede Sache zu diskutieren. Hat Dir die Deine Mutti nicht beigebracht? > Entschuldige bitte: Reality check. Wie soll ich mit dieser sachlichen > Art Eingrenzung eines Begrenzugspfahls Deiner Meinung nach umgehen? Ganz easy: Du hättest Dich gar nicht angesprochen fühlen müssen. Irgendwo wirst Du Dich aber darin schon wieder erkannt haben.
Michael R. schrieb: > Ach menno, Leute! > > Ich (und vielleicht noch ein paar andere) verfolgen diesen Thread mit > echtem Interesse, und euer kindisches Gestänkere geht mir sowas von auf > den Sack! Ich schließe mich Deiner Meinung vorbehaltlos an! > > Noch dazu wo es hier nichtmal eine ignore-Funktion gibt... > > also reissts euch bitte etwas zusammen, und benehmts euch wie halbwegs > erwachsene Menschen. Sieh mal nach wie oft ich versucht habe zu den technischen Tatsachen zurück zu kehren aber es taucht immer eine neue Namenlose Nulpe auf die Krieg spielen will. Ich fange nicht an zu stänkern, ich höre aber auch nicht eher auf als das provokante Gestänkere in meine Richtung endet. Gruß, Holm
Ralf C. Werner schrieb: > Holm T. schrieb: >> Du aber bist der anständigste Mensch hier im Forum und schreibst >> ausschließlich sachlich bezogene Beiträge? > > Zunächst mal geht es um anständige Umgangsformen. > Grundvoraussetzung um jedwede Sache zu diskutieren. > Hat Dir die Deine Mutti nicht beigebracht? Du hältst das was Du tust fü anständig? Aus welcher Kloake stammst Du? > >> Entschuldige bitte: Reality check. Wie soll ich mit dieser sachlichen >> Art Eingrenzung eines Begrenzugspfahls Deiner Meinung nach umgehen? > > Ganz easy: Du hättest Dich gar nicht angesprochen fühlen müssen. > Irgendwo wirst Du Dich aber darin schon wieder erkannt haben. Du doch auch nicht, Dein Name ist eh nicht ernst zu nehmen da Du als Gast postest. Warum also fühlst du Dich angesprochen und zu irgendwas berufen? Hallo Du Niemand! Gruß, Holm
Holm T. schrieb: > Ich fange nicht an zu stänkern, ich höre aber auch nicht eher auf als > das provokante Gestänkere in meine Richtung endet. Du hättest aber meinen großen ehrlichen Respekt, wenn du genau das tätest (genauso wie alle anderen)
Holm T. schrieb: > Aus welcher Kloake stammst Du? Tja Holm, Du scheinst ein hoffnungsloser Fall zu sein. Anders als so kannst Du Dich nicht argumentieren? > Du doch auch nicht, Dein Name ist eh nicht ernst zu nehmen da Du als > Gast postest. Achte bitte auf den Inhalt, nicht auf irgendeine Anmeldung.
Holm T. schrieb: > Roland F. schrieb: >> Hallo Holm, >> >>> ich denke aber nicht das Du mit verbal gewachsen bist. >> >> und >> >>> Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? >> >> Ich finde, es gehört nicht viel dazu dir verbal gewachsen zu sein. >> >> rhf > > Goto -> > Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern" @Holm Lass dich nicht provozieren! Ziehe in Betracht dass es durchaus sein könnte, dass ein und der selbe HATER mit verschiedenen Identitäten hier auftaucht. (sollten Leute hier jetzt behaupten das geht nicht - dann stimmt das nicht, die Möglichkeiten der MODs sind hier begrenzt.) Solche Leute versuchen dich wie ein Wolfsrudel anzugreifen. Wenn man das erkennt gibt es aber durchaus Abwehrmechanismen. Poster "Droggelbecher" wäre nach meinem Dafürhalten so ein Kandidat. Auch bei "Ralf C. Werner" wäre ich mir nicht sicher. (der zeigt hier mit dem Moral-Zeigefinger umher, er selber nimmt sich aber davon aus) Ein Gegenbeispiel dazu wäre der Poster "Karl" der redet zwar wie er denkt (nicht immer salonfähig) er wirkt aber dadurch authentisch (und harmlos ;-).
Ralf C. Werner schrieb: > Sheeva P. schrieb: >> Ja, Du aber auch. Holm zu provozieren scheint mir auch nicht eben >> geeignet, die Diskussion zu versachlichen > > Nein, irgendjemand muß diesem ausfallenden Herren hier mal die Grenzen > aufzeigen. Das dürfte langfristig eher deeskalierend wirken, so meine > Hoffnung. Bisher wirkt es eher eskalierend, so meine Feststellung.
Ralf C. Werner schrieb: > Holm T. schrieb: >> Aus welcher Kloake stammst Du? > > Tja Holm, Du scheinst ein hoffnungsloser Fall zu sein. > Anders als so kannst Du Dich nicht argumentieren? > Ich kann mich überhaupt nicht argumentieren, allenfalls artikulieren. Ich bescheinige Dir die Hoffnungslosigkeit für den Fall das Du mich mit Deiner Nörgelei klein zu kriegen versuchst, ja. Als Alternative kann ich Dir empfehlen einfach mal zu probieren mit mir sachlich über das Thema des Threads hier zu diskutieren. >> Du doch auch nicht, Dein Name ist eh nicht ernst zu nehmen da Du als >> Gast postest. > > Achte bitte auf den Inhalt, nicht auf irgendeine Anmeldung. Ja, durchaus..es kam aber von Dir bisher nur Noise, kein Signal. Ein Anonymling versucht mir an die Karre zu fahren, das ist bisher Alles von Deiner Seite. Auf welchen Inhalt genau zielst Du also ab? Gruß, Holm
KiCadSuperman schrieb: > Lass dich nicht provozieren! Glaub mir KiCadSuperman, es wäre viel gewonnen wenn Holms schon oft angemahnte üble Beleidigungen Geschichte wären. Glaubst Du denn wirklich, bloß weil einem die sauer aufstoßen ist man gleich "Hater"?
Holm T. schrieb: > Auf welchen Inhalt genau zielst Du also ab? Bist Du wirklich nicht in der Lage zu erkennen wie Du hier auftrittst? Dann wird man Dich weiter daran erinnern müssen. Vielleicht bist Du doch noch lernfähig, obwohl Anstand und KiCad recht unterschiedliche Kategorien sind.
KiCadSuperman schrieb: > Holm T. schrieb: >> Roland F. schrieb: >>> Hallo Holm, >>> >>>> ich denke aber nicht das Du mit verbal gewachsen bist. >>> >>> und >>> >>>> Hab ich Dich gebeten meinen Nachnamen hier zu posten du Arsch? >>> >>> Ich finde, es gehört nicht viel dazu dir verbal gewachsen zu sein. >>> >>> rhf >> >> Goto -> >> Beitrag "Re: Erfahrungen mit KiCAD von Eagle-Wechslern" > > @Holm > > Lass dich nicht provozieren! > > Ziehe in Betracht dass es durchaus sein könnte, dass ein und der selbe > HATER mit verschiedenen Identitäten hier auftaucht. Davon gehe ich aus. > (sollten Leute hier jetzt behaupten das geht nicht - dann stimmt das > nicht, > die Möglichkeiten der MODs sind hier begrenzt.) > > Solche Leute versuchen dich wie ein Wolfsrudel anzugreifen. > Wenn man das erkennt gibt es aber durchaus Abwehrmechanismen. Es ist doch absolut irre. Du hast Recht mir kommt das auch so vor, dabei ist meine einzige Verfehlung das ich KiCad benutze..muß man sich mal überlegen was da hier abgeht. Eagle scheint wirklich so eine Art Kirchengemeinde aka Sekte zu sein > > Poster "Droggelbecher" wäre nach meinem Dafürhalten so ein Kandidat. Ich auch. > Auch bei "Ralf C. Werner" wäre ich mir nicht sicher. > (der zeigt hier mit dem Moral-Zeigefinger umher, er selber nimmt sich > aber davon aus) Ich halte den durchaus auch für echt, er weiß nur indessen das er sich vergallopiert hat und will nun nicht klein bei geben. Vermutlich wird er aber nun langam wiklich sachlich werden, schaunmermal. > > Ein Gegenbeispiel dazu wäre der Poster "Karl" der redet zwar wie er > denkt > (nicht immer salonfähig) er wirkt aber dadurch authentisch (und harmlos > ;-). Karl..ja Karl..Karl ist unzufrieden damit das aus seiner User-Gemeinde Nutzer abfließen (darf er ja auch sein). Er ist nicht Schuld daran und an dieser Sache können wir auch nichts ändern. Mehr oder weniger unbewußt läßt er aber seinen Frust darüber nun an den Leuten aus, die Eagle nicht benutzen und versucht den Anreiz abzuwandern abzuschaffen in dem er KiCad durch den Kakao zieht. Ich denke er wird sich KiCad aber nochmal näher anschauen, denn etliche der "offensichtlichen" Unzulänglichkeiten lösen sich bei näherer Betrachtung ja in Luft auf, das habe nicht nur ich hier gezeigt. Bei etlichen Eagle Nutzern (auch ehemaligen) kann man aus dem Kontext lesen das Eagle auch ein Mistvieh hinsichtlich Bedienung ist, das KiCad alles Andere als rund in dieser Hinsicht ist steht dabei auch außer Frage, das habe ich ja nie behauptet. Ich denke aber das KiCad sich über die letzten Jahre relativ kontinuierlich verbessert hat. Man sollte einfach nur fair vergleichen.. und dabei evtl. berücksichtigen das sich die Gestehungskosten von KiCad auf die eigene Einarbeitungszeit beschränken, und sich Eagle für die Meissten hier gerade maßlos verteuert hat. Das ist hier mein einziger Casus knacksus. Gruß, Holm
Holm T. schrieb: > Ich kann mich überhaupt nicht argumentieren, allenfalls artikulieren. Mit deinen Fremdwörtern kannst du mir überhaupt nicht imprägnieren ;-)
Ralf C. Werner schrieb: > Holm T. schrieb: >> Auf welchen Inhalt genau zielst Du also ab? > > Bist Du wirklich nicht in der Lage zu erkennen wie Du hier auftrittst? kommentiere mal bitte Dein Auftreten (eg. kehre erst mal vor der eigenen Türe) bevor Du Deine Meinung hier Robin Hood mäßig zu vertreten gedenkst. > Dann wird man Dich weiter daran erinnern müssen. Vielleicht bist Du doch > noch lernfähig, obwohl Anstand und KiCad recht unterschiedliche > Kategorien sind. Jaja, mach mal. Du kannst mir über Anstand ganz offensichtlich nichts erzählen denn die Wortwahl ist nicht das Einzige was Anstand ausmacht. Mach einfach weiter mit mir, das geht so lange bis ein Mod hier den Thread abdreht, dann hast Du geschafft was Du wolltest. Du kannst Dir dann anständig selbst auf die Schulter klopfen Du mein Held... Gruß, Holm
Holm T. schrieb: > Eagle scheint wirklich so eine Art > Kirchengemeinde aka Sekte zu sein Tja, schlimmer wie Seientologie ;-)
Michael R. schrieb: > Holm T. schrieb: >> Ich fange nicht an zu stänkern, ich höre aber auch nicht eher auf als >> das provokante Gestänkere in meine Richtung endet. > > Du hättest aber meinen großen ehrlichen Respekt, wenn du genau das > tätest (genauso wie alle anderen) Ich habe mir das auch überlegt, wenn man aber die ersten Seiten hier liest stell man fest das KiCad dann unter den Eagle-Warriors unter geht. Es war nicht meine Idee pampig zu werden. Ich habe hier nachweislich so 5-6 Mal versucht den Disput in einen sachlichen zu verwandeln und nachgefragt ob ich irgendwelche Fragen beantworten kann, geerntet habe ich bisher immer ein kindisches "Du bist doof" in verschiedenen Variationen.. Gruß, Holm
Holm T. schrieb: > Du kannst mir über Anstand ganz offensichtlich nichts > erzählen denn die Wortwahl ist nicht das Einzige was Anstand ausmacht. Ja sicher! Tür aufhalten, Stuhl ranrücken, aus dem Mantel helfen, im Bus einen Sitzplatz anbieten... Nur: ich sehe hier nur Text.
> "Du bist doof"
Dann denk dir doch einfach "Kindermund tut Wahrheit kund" und gut ist
;-)
Wenn ich die Entscheidung für meines nächsten EDA-Systems an der
Community und deren Verhalten messe, täte ich vermutlich gut daran,
weder Eagel noch Kicad zu wählen. Insofern erweisen die "Warriors" hier
beiden Systemen einen Bärendienst.
Ralf G. schrieb: > Holm T. schrieb: >> Du kannst mir über Anstand ganz offensichtlich nichts >> erzählen denn die Wortwahl ist nicht das Einzige was Anstand ausmacht. > > Ja sicher! Tür aufhalten, Stuhl ranrücken, aus dem Mantel helfen, im Bus > einen Sitzplatz anbieten... > Nur: ich sehe hier nur Text. Da fehlt z.B. noch sich freundlich und zuvorkommend zu verhalten. Gruß, Holm
Michael R. schrieb: >> "Du bist doof" > > Dann denk dir doch einfach "Kindermund tut Wahrheit kund" und gut ist > ;-) Danke, ich stelle die Blumen in eine Vase. > > Wenn ich die Entscheidung für meines nächsten EDA-Systems an der > Community und deren Verhalten messe, täte ich vermutlich gut daran, > weder Eagel noch Kicad zu wählen. Insofern erweisen die "Warriors" hier > beiden Systemen einen Bärendienst. Stellst Du hier einen Zusammenhang zwischen dem Postings und den CAD Systemen her? Wieso? Hier gibts doch gar Keinen.. Gruß, Holm
Holm T. schrieb: > Mach einfach weiter mit mir, das geht so lange bis ein Mod hier den > Thread abdreht, dann hast Du geschafft was Du wolltest. Wenn, dann sollte Leuten die sich verbal nicht mehr unter Kontrolle haben hier der Saft abgedreht werden. Was Dich davor rettet scheinen nur Deine paar KiCad Kenntnisse zu sein. Das was Du anderen an den Kopf wirfst bist Du im wesentlichen selbst. Solcherlei Angriffe als vermeintlich beste Verteidigung gehen nur nach hinten, in Deine Richtung los. Holm T. schrieb: > Es war nicht meine Idee pampig zu werden. Da kommen einem ja die Tränen. Junge, soll man jetzt auch noch Mitleid mit Dir haben?
Ralf C. Werner schrieb: > Wenn, dann sollte Leuten die sich verbal nicht mehr unter Kontrolle > haben hier der Saft abgedreht werden. Ich will dir nicht zu nahe treten, bei einer solchen Aktion bist du aber vorneweg auch mit dabei. Ralf C. Werner schrieb: > Was Dich davor rettet scheinen nur > Deine paar KiCad Kenntnisse zu sein. Was rettet dich?
Was ist mit Euch los? Seit ihr alle auf die Bäume geklettert, weil das böse KiCad - Krokodil unterwegs ist :-)
KiCadSuperman schrieb: > Was ist mit Euch los? > > Seit ihr alle auf die Bäume geklettert, weil das > böse KiCad - Krokodil unterwegs ist :-) Wer diskutiert denn gerne wenn üble Beschimpfungen hier zu den normalen Reaktionen zählen? Du etwa?
Holm T. schrieb: > Karl ist unzufrieden damit das aus seiner User-Gemeinde > Nutzer abfließen (darf er ja auch sein). Das ist Deine Meinung. Ich sehe keinerlei Nachteil für mich, selbst wenn ich der letzte Eagle-Nutzer auf der Welt wäre. Und selbst wenn kein Fertiger mehr Eagle-Dateien annehmen würde, könnte ich immer noch Gerber exportieren. > Man sollte einfach nur fair vergleichen.. und dabei evtl. > berücksichtigen das sich die Gestehungskosten von KiCad auf die eigene > Einarbeitungszeit beschränken, Uiuiui. Wenn ich mir die Libs so anschaue, wären da schon Wochen nötig, um die auf den Stand meiner eigenen Eagle-Libs zu bringen und die häufigsten von mir verwendeten Bauteile anzulegen. Was über Jahre Gewachsenes baut man nicht mal eben schnell nach. > und sich Eagle für die Meissten hier > gerade maßlos verteuert hat. Dabei gehst Du davon aus, dass man immer eine neue Version eines Programmes benötigt. Das mag für Online-gebundene Software wie Webbrowser gelten, die Sicherheitslücken flicken muss, oder für Steuersoftware, die sich an geänderte Gesetzgebung anpassen muss. Ich sehe keinen Grund, immer den neuesten Features hinterherzurennen, wenn es funktioniert.
Karl schrieb: > Holm T. schrieb: >> Karl ist unzufrieden damit das aus seiner User-Gemeinde >> Nutzer abfließen (darf er ja auch sein). > > Das ist Deine Meinung. Ich sehe keinerlei Nachteil für mich, selbst wenn > ich der letzte Eagle-Nutzer auf der Welt wäre. Und selbst wenn kein > Fertiger mehr Eagle-Dateien annehmen würde, könnte ich immer noch Gerber > exportieren. > Ja Karl, das ist meine Meinung und ich denke das Deine Meinung aus Deiner Sicht durchaus für mich akzeptabel ist, ich muß sie nur nicht teilen. >> Man sollte einfach nur fair vergleichen.. und dabei evtl. >> berücksichtigen das sich die Gestehungskosten von KiCad auf die eigene >> Einarbeitungszeit beschränken, > > Uiuiui. Wenn ich mir die Libs so anschaue, wären da schon Wochen nötig, > um die auf den Stand meiner eigenen Eagle-Libs zu bringen und die > häufigsten von mir verwendeten Bauteile anzulegen. Was über Jahre > Gewachsenes baut man nicht mal eben schnell nach. Ja, auch das mag bei Dir so sein. Andere gehen prinzipiell davon aus, das sie alle "Libs" selber machen wollen. > >> und sich Eagle für die Meissten hier >> gerade maßlos verteuert hat. > > Dabei gehst Du davon aus, dass man immer eine neue Version eines > Programmes benötigt. Das mag für Online-gebundene Software wie > Webbrowser gelten, die Sicherheitslücken flicken muss, oder für > Steuersoftware, die sich an geänderte Gesetzgebung anpassen muss. Ja, ich ging von neu erworbenen Lizenzen aus, da alte wohl nicht zu haben sind (warum wohl). > > Ich sehe keinen Grund, immer den neuesten Features hinterherzurennen, > wenn es funktioniert. Auch das ist ok, deswegen arbeite ich auch mit einem OS ohne Update- und Spionagewahn. Gruß, Holm
Ralf C. Werner schrieb: > KiCadSuperman schrieb: >> Was ist mit Euch los? >> >> Seit ihr alle auf die Bäume geklettert, weil das >> böse KiCad - Krokodil unterwegs ist :-) > > Wer diskutiert denn gerne wenn üble Beschimpfungen hier zu den normalen > Reaktionen zählen? Du etwa? Ich lache dich einfach aus, Du lamentierst ja sogar noch wweiter wenn gar Keienr mit Dir redet, Du merkst nicht mehr wirklich was, deshalb verschreibe Dir mal folgendes Dokument das ich Jahrzehnte lang nicht mehr anfassen mußte, Sowas wie Du scheint selten zu sein:
1 | (ACHTUNG: das untenstehende Dokument ist auf eine bestimmte Lebensform |
2 | ausgestellt und immer noch gültig. Es darf nur als Vorlage benutzt |
3 | werden. Bitte keine Kaffeflecken.) |
4 | |
5 | ------------------------------------------------------------- |
6 | _MERKBEFREIUNG_ |
7 | |
8 | Die nachstehend eindeutig identifizierte Lebensform |
9 | |
10 | Name : Werner_________________ |
11 | Vorname : Ralf C.________________ |
12 | Handle : bessix_________________ |
13 | Geburtsdatum : leider |
14 | Geburtsort : Müllhalde/Ecke Chemiefabrik |
15 | Personalausweisnummer: Asylverfahren läuft noch |
16 | Usenet-Kennzeichen : ab heute keines mehr |
17 | IQ : < 10___________________ |
18 | |
19 | ist hiermit für den Zeitraum von |
20 | |
21 | (_) 2 Sekunden |
22 | (_) 6 Monaten |
23 | (_) 12 Monaten |
24 | (_) 24 Monaten |
25 | (_) unbefristet |
26 | (X) Rest des unnatürlichen Lebens |
27 | |
28 | davon befreit, etwas zu merken, d.h. wesentliche |
29 | Verhaltensänderungen bei der Interaktion mit denkenden Wesen zu |
30 | zeigen. Die Einstufung der o.a. Person nach dem amtlichen Index |
31 | für Merkbefreiungen liegt bei dem Äquivalent von |
32 | |
33 | (_) einer Zeitung von gestern |
34 | (_) einem Mensaessen vom Vortag |
35 | (_) drei Hartkeksen in löslichem Kaffee |
36 | (_) einer Kiste Schwarzbrot in Dosen |
37 | (X) einem Quadratmeterstück Torfmoos während einer |
38 | sechswöchigen Sommerdürre |
39 | (_) einem Container erodiertem Sandstein |
40 | (Streusandqualität) |
41 | (_) einer Tomate nach der Begegnung mit einer |
42 | Dampfwalze |
43 | |
44 | Die ausgesprochene _Merkbefreiung_ erlischt mit |
45 | |
46 | (_) dem Ablauf der o.g. Frist, beginnend mit dem |
47 | Zeitpunkt der Ausstellung |
48 | (_) dem Ablauf des __.__.____ |
49 | (_) der vollständigen Erosion der körperlichen |
50 | Bestandteile der o.a. Lebensform |
51 | (X) nach dem zweimaligen Anschauen aller Folgen |
52 | der Serie "Reich und Schön"; |
53 | |
54 | und gilt, egal ob die o.a. Lebensform durch das nachstehende |
55 | Kennzeichen als merkbefreit zu identifizieren ist: |
56 | |
57 | - eine rote Plastiknase |
58 | - eindeutig unbefristet merkbefreiter Gesichtsausdruck |
59 | - T-Shirt mit Aufschrift "Ich bin Merkbefreit, bitte helfen |
60 | Sie mir über die Straße"; |
61 | |
62 | Befund nach Prüfung durch das Bundesamt: |
63 | |
64 | [_] kurzzeitiger Aussetzer durch Übermüdung des Merkerit- |
65 | deflektionsstudentes. Einstellung eines zweiten solchen |
66 | wird empfohlen. |
67 | [_] Hohe Konzentrationen an Trollium und Merkerit |
68 | [_] Extrem hohe Konzentrationen an Trollium und Merkerit |
69 | [_] Extrem hohe Konzentrationen an Trollium und Merkerit |
70 | [x] Alle bekannten Therapien sind wirkungslos |
71 | [_] Einstufung in die Gefahrenklasse |
72 | (_) ELCH - A I |
73 | (_) DAU - B II |
74 | (X) TROLL - DO NOT FEED |
75 | |
76 | Die o.a. Lebensform ist durch den Erwerb dieses |
77 | Merkbefreiungsscheins automatisch für die folgenden Tätigkeiten |
78 | qualifiziert: |
79 | |
80 | [_] Markierungshütchen bei Abmarkierungsarbeiten auf |
81 | Bundesautobahnen |
82 | [_] Garderobenständer und Regenschirmständer in |
83 | Restaurants bis zu, aber nicht eingeschlossen, 3 |
84 | Sterne |
85 | [X] Regelstab in Schwerwasserreaktoren |
86 | [_] Markierungsstab für das Fahrwasser im Nationalpark |
87 | Wattenmeer |
88 | [X] Landschaftsmerkmal/Orientierungshilfe in der Wüste |
89 | Gobi |
90 | [_] Mitarbeiter in einer EDV-Firma, Abteilung Hygienepersonal |
91 | und Rasenmäherzündkerzenwechsler |
92 | |
93 | Die _Merkbefreiung_ für die o.a. Lebensform wurde in einem |
94 | öffentlichen Merkbefreiungsverfahren ausgesprochen und ist nach |
95 | Ablauf der Einspruchsfrist von 17 Sekunden rechtskräftig. |
96 | |
97 | Weitere Auflagen und Entscheidungen: |
98 | |
99 | [_] PLONK [x] GEH WEG! |
100 | [_] PLATSCH [_] Get a life! |
101 | [X] PATSCH [_] Sie sind raus! |
102 | [_] 42. |
103 | [X] Du hättest nicht kommen sollen, Obiwan |
104 | |
105 | Weitere Betreuung durch: |
106 | [x] /dev/null - QUARANTÄNE |
107 | [_] ______________________ |
108 | |
109 | Es wird die [_] vorläufige Aufbewahrung |
110 | [_] Zwischenlagerung |
111 | [X] Endlagerung |
112 | |
113 | in der Newsgroup [_] de.alt.gruppenkasper |
114 | [_] de.alt.0d |
115 | [_] de.tests |
116 | [X] at.test |
117 | angeordnet. |
118 | |
119 | |
120 | Hochachtungsvoll! |
121 | |
122 | Das Bundesamt für die Verwaltung des Netzes |
123 | Dezernat II - Abteilung f<FC>r Troll- und DAU-Sachbearbeitung |
124 | |
125 | Datum Unterschrift Dienstsiegel |
126 | 2018-03-21 [unleserlich] plonk |
127 | |
128 | Stirnabdruck des Merkbefreiten |
129 | |
130 | bonk |
Gruß, Holm
Karl schrieb: > Uiuiui. Wenn ich mir die Libs so anschaue, wären da schon Wochen nötig, > um die auf den Stand meiner eigenen Eagle-Libs zu bringen und die > häufigsten von mir verwendeten Bauteile anzulegen. Was über Jahre > Gewachsenes baut man nicht mal eben schnell nach. ab v5.0 sollte Importieren (ab eagle v6) kein Problem darstellen. Höchstens etwas Nacharbeit.
Holm T. schrieb: > Karl schrieb: > Holm T. schrieb: > deswegen arbeite ich auch mit einem OS ohne Update- und > Spionagewahn. Der Wahn wurde nur vor den Rechner verlagert :)
Bob A. schrieb: > Karl schrieb: >> Uiuiui. Wenn ich mir die Libs so anschaue, wären da schon Wochen nötig, >> um die auf den Stand meiner eigenen Eagle-Libs zu bringen und die >> häufigsten von mir verwendeten Bauteile anzulegen. Was über Jahre >> Gewachsenes baut man nicht mal eben schnell nach. > > ab v5.0 sollte Importieren (ab eagle v6) kein Problem darstellen. nicht nur sollte: Kein Problem. Die ganzen importierten Footprints und Symbole werden dabei in das Projektverzeichnis abgelegt. > Höchstens etwas Nacharbeit. Wäre mir jetzt noch nicht aufgefallen. Höchstens wenn man diese Libs für andere Projekte zugänglich machen möchte. Dann muß man halt etwas hin- und herkopieren. Die Symbole sind alle in einer Datei zu finden. Die weiter benötigten müßte man dann rauskopieren.
Hans schrieb: > Holm T. schrieb: >> Karl schrieb: >> Holm T. schrieb: >> deswegen arbeite ich auch mit einem OS ohne Update- und >> Spionagewahn. > > Der Wahn wurde nur vor den Rechner verlagert :) ..kein Problem, habe ihn schon zusammengekehrt und weggeschmissen. Gruß, Holm
Holm T. schrieb: >> Es ist nicht sinnvoll, dass das immer geht. Pinswap darf auch der >> Autorouter, und Du möchtest nicht, dass der Autorouter in+ und in- eines >> OPVs mal eben tauscht, weil es "immer" geht. > > Deswegen geht es auch bei Eagle nur manchmal, sicher immer genau dann > wenn man es nicht braucht.. Was Du jetzt geschrieben hast ist natürlich Humbuck und Du weist das auch. Natürlich ist es nicht sinnvoll für alle Pins Pinswap zu zulassen. Das Beispiel von Karl ist eines Vielen. Bei Versorgungsspannungen möchtest Du nicht wirklich Pinswap bei Adressleitungen auch nicht usw.. Ach ja ob man FB braucht oder nicht, darüber läßt sich halt trefflich. Die KiCAD User scheinen es nicht zu vermissen und können auch offensichtlich ganz gut damit leben. Deshalb ist die Aussage KiCAD kann es nicht, deshalb brauch man es nicht dennoch mehr als. Andere User sehen das eben anders und für die sind eben genau diese Features wichtig und unter Umständen ein Ausschlußkriterium für diese Software.
Zeno schrieb: > Was Du jetzt geschrieben hast ist natürlich Humbuck Das muß man nicht mehr dazuschreiben.
Beitrag #5360147 wurde von einem Moderator gelöscht.
Ich mache den Thread, der vor Beleidigungen nur so strotzt, jetzt einfach mal dicht. Und wenn sich die Gemüter beruhigt haben und der Thread auf die zweite Seite gerutscht ist, dann kann man ihn ja wieder aufmachen. Und komm mir jetzt bloß keiner, er müssen noch zu diesem oder jenem unbedingt seinen Senf abgeben. Oder, er möchte irgendwas Bestimmtes gelöscht haben (ich werde den Thread jetzt auch nicht durchlesen und auf Beleidigungen untersuchen): hier zahlt offenbar jeder mit gleicher Münze, deshalb braucht sich keiner beschweren.