Hallo zusammen, wenn man sich mal die Threads anschaut, kann man feststellen, dass sich mehr und mehr mit dem Layoutprogramm KiCAD beschäftigt wird. Ggf. liegt es u.a. an der Lizenzpolitik des EAGLE Nachfolgers. Auch in meinem Umfeld sind jetzt viele von EAGLE auf KiCAD umgestiegen. Mit diesem Schwung wird sicherliche KiCAD nochmal einige Unterstützung erfahren dürfen.
:
Verschoben durch Moderator
Ist natürlich einerseits schön. Andererseits kommen sehr viele Nutzer zu Kicad, die sich lieber erstmal in irgendein CAD-Programm einarbeiten sollten. Sieht man ja leider sehr oft, dass selbst einfachste Konzepte nicht verstanden werden und die Leute z.B. nichtmal ein eigenes Bauteil erstellen können. Da kann man nur hoffen, dass sich die Entwickler nicht darauf einlassen, noch mehr sinnlose Anfänger-Bibliotheks-Funktionen einzubauen, sondern lieber die Entwicklung des Kernprogramms weiter verfolgen. Das war ja in der Vergangenheit schon sehr erfolgreich.
someone schrieb: > lieber erstmal in irgendein CAD-Programm einarbeiten sollten Ist KiCad denn nicht auch ein Teil der Menge „irgendein CAD-Programm“?
someone schrieb: > Ist natürlich einerseits schön. Andererseits kommen sehr viele Nutzer zu > Kicad, die sich lieber erstmal in irgendein CAD-Programm einarbeiten > sollten. Zum Beispiel trommelwirbel KiCad. Man kann ja einfach auf gute Tutorials verweisen.
Jörg W. schrieb: > someone schrieb: >> lieber erstmal in irgendein CAD-Programm einarbeiten sollten > > Ist KiCad denn nicht auch ein Teil der Menge „irgendein CAD-Programm“? Selbstverständlich. Wie du aber vielleicht sehen kannst, gibt es viele Leute, die sich nicht darin einarbeiten (wollen?) und daher nervige Fragen stellen. Bisher war das ja eher die Domäne des Einfach Anzuwendenden Grafischen Layout Editors, da konnte man sich als Kicad-Nutzer (der sich übrigens eingearbeitet hat, war gar nicht so schwierig!) wenigstens darauf verlassen, dass man relevante Antworten gefunden hat und die Entwicklung zumindest häufig die wichtigen Baustellen angepackt hat. Ich habe da leider eine gewisse Verschlechterung feststellen müssen, nachdem Leute auf die Idee kamen, Cloud-Libraries einzuführen (blöde Idee), die dann noch nicht einmal gut sind (nach einer fast verhunzten Platine mit nahezu unlötbaren 0603-Footprints aus einer neueren Version der Standard-Library habe ich endgültig den Internetkram abgeschaltet und mir alle Bauteile eigenhändig neu gezeichnet); das ist wohl ein Versuch, Kicad "benutzbarer" zu machen. Wie dem auch sei, es ist natürlich gut, dass mehr Leute Kicad benutzen wollen, aber um die Einarbeitung kommt man nicht herum. Es ist halt ein komplexes Programm mit UI-Eigenheiten und recht großer Abstraktion. Die kann man mögen oder nicht, aber man muss halt damit umgehen. Mir gefällt die Abstraktion und ich finde es schade, dass die einzelnen Komponenten zunehmend gebündelt werden, aber so ist das nunmal. Jedenfalls muss man sich eben in diese Software einarbeiten, dafür gibt es genügend Tutorials und andere Informationen. Wer das nicht will, der ist da falsch aufgehoben. Ich nutze Kicad schon seit etwa 5 Jahren und habe vorher kurz (1 Jahr oder so) mit Eagle rumgespielt, war auch okay, aber irgendwie total sperrig. Kicad war damals schon deutlich besser und wird natürlich auch mit der Zeit nicht schlechter. Zumindest noch nicht.
Lötauge schrieb: > Ggf. liegt es u.a. an der Lizenzpolitik des EAGLE Nachfolgers. Mit Sicherheit. Eine Lösung, für die man regelmäßig online gehen muß, damit sie sich nicht deaktiviert, ist halt vollkommen inakzeptabel. Besonders, weil man dann nicht mal eben 5 Jahre alte Daten nochmal modifizieren kann, weil die damalige Version der Software nicht mehr aktivierbar ist und die neue schlimmstenfalls das Dateiformat seit zwei Jahren nicht mehr fehlerfrei importieren kann.
Die wenigsten Artikel sind: "Ach wie toll ist doch KiCAD"! Die meisten folgen: "Wie kann ich..." oder "XXX geht nicht". Man sollte die Aussage mit einem lachenden und einem weinenden Auge betrachten.
Beitrag #4934904 wurde von einem Moderator gelöscht.
Das Dateiformat kann mit jedem Texteditor gelesen und bearbeitet werden und ist deshalb zukunftssicher. Klar gibt es immer mal ecken in so einem Programm wo der Nutzer noch nie gewesen ist und sich wundert.
:
Bearbeitet durch User
Lutz H. schrieb: > Das Dateiformat kann mit jedem Texteditor gelesen und bearbeitet > werden und ist deshalb zukunftssicher. Das Zeug von MS Office (docx, pptx, xlsx) ist xml (Datei als zip speichern und entpacken-> anschauen) und deswegen heißt das noch garnix. Was soll das besser / zukunfstssicherer machen ??
Lutz H. schrieb: > Das Dateiformat kann mit jedem Texteditor gelesen und bearbeitet werden > und ist deshalb zukunftssicher. Das ist es beim Adler allerdings auch. someone schrieb: > Wie du aber vielleicht sehen kannst, gibt es viele Leute, die sich nicht > darin einarbeiten (wollen?) und daher nervige Fragen stellen. Kein Vorteil ohne Nachteil, pflegte eine frühere Kollegin von mir immer zu sagen. Wenn's mehr Nutzer gibt, gibt es eben auch mehr, die sich erstmal hinstellen und glauben, für alles müsse es schon irgendwo eine fertige Lösung für sie geben. Man sollte sie also einfach auf die existierenden Tutorials verweisen und darauf, dass es gerade im professionellen Bereich völlig gang und gäbe ist, dass sich jeder seine eigenen Bibliotheken pflegt. Davon abgesehen, für nicht so ganz triviale Bauteile kann man sich schon auch mal die eine oder andere Stunde Freizeitarbeit sparen, wenn man auf ein fertiges Bauteil eines anderen Forennutzers zurückgreifen kann. Ich freu' mich auch, wenn ich mal wieder eine Uhr baue, dass mir vor Jahren ein Forenteilnehmer mal einen Code für die DCF77-Dekodierung überlassen hat, und ich dieses Fahrrad eben nicht nochmal erfinden musste.
Beitrag #4935138 wurde vom Autor gelöscht.
someone schrieb: > Jedenfalls muss man sich eben in diese Software einarbeiten, > dafür gibt es genügend Tutorials und andere Informationen. Wer das nicht > will, der ist da falsch aufgehoben. Das das Programm etwas anspruchsvoller und für Anfänger eigentlich nicht geeignet ist, würde ich bedenkenlos unterschreiben. Das es für die vielen Versionen ausreichend Tutorials gibt, dagegen nicht. Mir scheint, dass die Leute im CERN, die ja da noch gar nicht so lange dran beteiligt sind, da die "Hilfe" und die Dokumentation vernachlässigt haben, müsste doch auch anderen schon aufgefallen sein, oder? Ohne ist es nämlich, ohne Erfahrung, recht schwer sich zurecht zu finden.
Eigentlich ist es ja ok, wenn die Leute nun scharenweise zu KiCAD wechseln. Jeder Anfänger und Laie wird damit gebunden sein und man hat weniger solche Fragen bei den anderen Programmen. KiCAD wird alleine aus dem Grund das am besten geeignete Programm für diese Gruppe der Neulinge sein, weil soviele Leute ja gar nicht irren können! Und wenn jeder fortgeschrittene KiCAD Nutzer so stark Werbung für KiCAD macht, werden schon eine Menge dieser Leute dort eingefangen werden.
Ja, die Ausbildung zum Elektroniker dauert. Hier mal eine Kurzanleitung für KICAD Am besten mit zwei Kondensatoren durchspielen. Kicad aufrufen Datei-> neues Projekt (Namen eingeben) 1. Schaltplan Datei mit *.sch am ende öffnen (Doppelklick) geöffneten Schaltplan auf der Taskleiste suchen und öffnen mit dem Operationsverstärkersymbol Bauteile zufügen. (device) mit dem grünen Strich die elektrischen Verbindungen zeichnen Annotation durchführen mit net Netzliste abspeichern mit opv/dip die Fußabdrücke der Bauteile zuordnen. (abspeichern)*. mit net Netzliste abspeichern 2.Leiterplatte kicad.pcb öffnen auf der Taskleiste suchen öffnen net Netzliste einlesen mit rechter Maustaste Fußabdrücke positionieren mit der grünen Linie die Leiterbahnen verlegen. Mit Edge.Cuts ein gelbes Rechteck als Leiterplattenrand zeichnen Abspeichern. Zum Leiterplattenhersteller kicad.pcb hochladen und bestellen
Lutz H. schrieb: > Ja, die Ausbildung zum Elektroniker dauert. Aber noch länger dauert die Ausbildung Tutor-Schreiberling :-( Du bist aber auf einen guten Weg dorthin ;-)
Ich finde KiCad eher abschreckend als intuitiv. Ohne sich intensiv mit Tutorials zu beschäftigen würde ich keine Gerberdaten dabei raus bekommen. Mag ja am Ende durchdachter sein als Eagle aber solange die 5er und 6er Versionen noch laufen werde ich dabei bleiben.
Hans schrieb: > Ich finde KiCad eher abschreckend als intuitiv. Ohne sich intensiv mit > Tutorials zu beschäftigen würde ich keine Gerberdaten dabei raus > bekommen. Mag ja am Ende durchdachter sein als Eagle aber solange die > 5er und 6er Versionen noch laufen werde ich dabei bleiben. Und ich weiß ohne nachzugucken auch nicht, wie man bei Eagle/Altium/Pads/[...] Gerber exportiert. Da kann die Software doch nix für...
Habe versucht nach obiger Anleitung vorzugehen Diese Fehler traten auf während des Ladens der Footprints: IO_FEHLER: http GET command failed Konnte das Zip-Archiv 'https://codeload.github.com/KiCad/Housings_SOT.pretty/zip/master'; nicht herunterladen. Bibliothekspfad: 'https://github.com/KiCad/Housings_SOT.pretty'; Grund: 'Not found' von C:/Jenkins/workspace/windows-kicad-msys2-stable/src/kicad/pcbnew/github/ github_plugin.cpp : remote_get_zip() : line 584 So einfach geht es also doch nicht wie beschrieben. Libs in teilweise "dubiosen Verzeichnissen" die schon tot sind? Siehe Fehlermeldung oder sind das nicht vertrauenswürdige https-Verbindungen und es scheitert daran. Wie löse ich dieses Problem?
:
Bearbeitet durch User
Danish B. schrieb: > Hast du einen Proxy? > Evtl. im Firmennetzwerk? > > Ich hatte das Problem mal... nicht ins blaue spekulieren, einfach mal die links klicken.
Angehängte Dateien:
-
Housings.png
9 KB
google kennt diese Seite auch nicht und meine Installation braucht diese Seite auch nicht. Kicad fängt an mit Altlasten zu kämpfen. Fehler was 2015 aktuell. https://forum.kicad.info/t/cvpcb-error-loading-footprints/1747/2
:
Bearbeitet durch User
Cyborg schrieb: > die "Hilfe" und die Dokumentation vernachlässigt habe Ja nun, KiCad ist ein Opensource-Projekt. Daraus folgt erfahrungsgemäß mit hoher Wahrscheinlichkeit, daß die Doku wahlweise irreführend, veraltet oder nicht vorhanden ist.
http://docs.kicad-pcb.org/stable/en/getting_started_in_kicad.html Schaut eigentlich recht brauchbar aus? Grad bei einem opensource Projekt, bei dem sich so schnell vieles ändert, ist das Nachziehen der Doku natürlich keine einfache Aufgabe.
Nop schrieb: > Daraus folgt erfahrungsgemäß mit hoher Wahrscheinlichkeit Aus Aussagen wie deiner folgt erfahrungsgemäß, dass sie wahlweise Humbug, FUD oder einfach nur unzulässige Verallgemeinerungen sind. Es gibt weiß Gott genügend gut dokumentierte Opensource-Projekte auf Erden. Man muss allerdings die „irgendwo muss Opensource doch immer einen Haken haben!“-Filterbrille absetzen, wenn man was sehen will. Bezüglich der github-URLs: die Idee hat natürlich was, dass man auf diese Weise immer gut aktualisierte Bauteile zur Verfügung hat, aber erstens sollte dann natürlich niemand mehr anfangen, Kategorien umzusortieren, und zweitens ziehe ich es vor, lieber eine lokale Kopie der Bauteilbibliotheken zu benutzen, die ich dann manuell pflege. Ansonsten könnte es ja passieren, dass das Bauteil, welches ich vorige Woche in einem Projekt einsetze, nächste Woche im nächsten Projekt ganz anders aussieht. (Innerhalb eines Projekts wird es ja zum Glück gecachet.) Kann man aber natürlich nach Belieben in den Pfaden einstellen, wie man das haben möchte.
:
Bearbeitet durch Moderator
Kennt jemand ein gutes Tutorial für das aktuelle KiCad auf Deutsch? (egal ob Video oder PDF, habe bisher mit Eagle gearbeitet)
Jörg W. schrieb: > Es gibt weiß Gott genügend gut dokumentierte Opensource-Projekte auf > Erden. Man muss allerdings die „irgendwo muss Opensource doch immer > einen Haken haben!“-Filterbrille absetzen, wenn man was sehen will. ... und darüber hinaus sollte man immer auch im Hinterkopf behalten, dass gute Software (einschließlich guter Doku) nicht magisch aus dem Nichts entsteht bzw. "einfach da ist", sondern dass es immer Leute braucht, die (zumeist) ihre Freizeit opfern, um das zu erstellen. Daher: Wenn Ihr Open-Source-Software (welcher Art auch immer) nutzt, gebt bitte etwas zurück (und bedient Euch nicht nur aus den schier endlosen Ressourcen)! Helfen kann jeder und immer, "kann ich nicht" zählt nicht. Auch wenn man es sich nicht zutraut, im Code rumzuhacken - Bugs im offiziellen Bugtracker melden, wenn man welche findet, sollte selbstverständlich sein (und bringt deutlich mehr, als sich über irgendwelche Fehler in irgendwelchen Foren auszulassen), Doku schreiben, übersetzen, Homepage/Webauftritt ausbauen etc. können auch die meisten, und wenn man gar nicht anders helfen kann, sind bei vielen Projekten natürlich sehr gerne auch Sach- (Entwicklungshardware, Server (intern, extern) etc.) bzw. Geldspenden gesehen. Sorry, aber das musste mal wieder sein ;)
Jörg W. schrieb: > Es gibt weiß Gott genügend gut dokumentierte Opensource-Projekte auf > Erden. Gibt es. Bestreite ich auch nicht. Aber Fakt ist, daß Doku ein ungeliebtes Stiefkind ist, weil Hacken mehr Spaß macht. In Firmen nennt sich das "grunt work", und es wird gemacht, weil und wenn man Geld dafür bekommt und die Anweisung kriegt, es zu tun. Bei Projekten mit hoher Freiwilligenquote wird das demzufolge schlicht nicht passieren, das ist strukturell bedingt.
Acn schrieb: > Kennt jemand ein gutes Tutorial für das aktuelle KiCad auf Deutsch? Was willst du denn mit einem Tutorial? Lies dir doch einfach die Handbücher mal komplett durch (ja, die gibts auch in deutscher Sprache).
Nop schrieb: > Aber Fakt ist … dass das genau der gleiche Unfug ist wie deine vorherige Pauschalisierung. Du solltest einfach mal nicht von dir auf andere schließen. Kann ja sein, dass du es nicht magst, Doku zu schreiben, aber das heißt noch lange nicht, dass das generell ein ungeliebtes Kind wäre. Es gibt aber natürlich (wie im restlichen Leben) solche und solche: es gibt Projekte mit vorbildlicher Doku (trotz Opensource, trotz überwiegender Freizeitarbeit) und welche, bei denen sie eben nicht so toll ist. Einen Aufruf zur Mitarbeit gab's ja schon.
Acn schrieb: > Kennt jemand ein gutes Tutorial für das aktuelle KiCad auf Deutsch? > (egal ob Video oder PDF, habe bisher mit Eagle gearbeitet http://timogruss.de/kicad-loesung-fuer-die-leiterplatten-entwicklung/
Alexander S. schrieb: > Lies dir doch einfach die > Handbücher mal komplett durch (ja, die gibts auch in deutscher Sprache). Und warum bietest du nicht gleich einen Link dazu? Darauf zielte die Intention des Users nämlich ab.
Danish B. schrieb: > Hast du einen Proxy? > Evtl. im Firmennetzwerk? > > Ich hatte das Problem mal... Ich habe kienen Proxy. Ich werde heute Abend mal KiCAD 4.05 deinstallieren und die neueste Version 4.06 intallieren. Gibt es bestimmte Verzeichniss und/oder Registry in der ich auch "Reste" der vorherigen KiCAD-Installation löschen sollte bevor ich es neu installiere?
Cyborg schrieb: > Und warum bietest du nicht gleich einen Link dazu? http://docs.kicad-pcb.org/ Handbücher zu: EESchema: 123 Seiten PCBNew: 136 Seiten Gerbview: 10 Seiten CvPCB: 23 Seiten IDF_Exporter 11 Seiten KiCad allg: 15 Seiten PL_Editor: 26 Seiten Getting_Started: 43 Seiten Insgesamt 387 Seiten Doku; in zig Sprachen und für jede Version. Da kann ich die Kritik bezüglich mangelnder Doku nicht verstehen. Ich geb zu, bei KiCad stand ich auch erst wie der Ochs vorm Scheunentor. Aber das durchackern der kompletten Doku hat erstaunlicherweise geholfen...
Lötauge schrieb: > Mit diesem Schwung wird sicherliche KiCAD nochmal einige Unterstützung > erfahren dürfen. Kürzlich hat hier jemand geschrieben, KiCAD hätte 200+ OS Entwickler plus zwei 'halbe' Entwicklerstellen beim Cern. Nun ist es ja doch so, dass KiCAD vor dem Einstieg des Cern eher eine interessante Baustelle als eine nutzbare ECAD-Software war. Nein, ich nutze KiCAD weder jetzt noch habe ich das vor dem Cern-Einstieg getan. Um eine Ahnung vom Entwicklungsstand von KiCAD vor Cern zu bekommen, reicht es aber vollkommmen aus, die früheren Diskussionsfäden bis 2014/15 (auch) hier im Board zu lesen. Wenn nun plötzlich ein Hype entstehen sollte und weitere Leute KiCAD unterstützen, wie der TO spekuliert, bringt das dann die Software wirklich voran? Ob nun 200 oder 300 Leute in ihrer Freizeit daran rumschrauben, entscheidend scheint, wie lange sich die beiden Entwickler am Cern während ihrer Arbeitszeit noch damit beschäftigen dürfen. Falls diese beiden halben Stellen gestrichen würden, sähe ich die Zukunft von KiCAD doch sehr skeptisch. Alexander S. schrieb: > Insgesamt 387 Seiten Doku; in zig Sprachen und für jede Version. Da kann > ich die Kritik bezüglich mangelnder Doku nicht verstehen. > > Ich geb zu, bei KiCad stand ich auch erst wie der Ochs vorm Scheunentor. > Aber das durchackern der kompletten Doku hat erstaunlicherweise > geholfen... Mit Verlaub, wenn ich mich erst durch 387 Seiten Dokumentation wechselnder Qualität kämpfen muss, damit ich mit einer Software umgehen kann, ist das für mich ein klares Ausschlusskriterium. Wer anschließend beruflich täglich damit arbeitet, für den ist eine Woche Einarbeitungszeit sicher vertretbar. Ob so jemand aber der typische KiCAD-Anwender ist? Vor einigen Wochen habe ich mich einen Abend lang mit KiCAD auseinandergesetzt. Das hat mir zur Abschreckung vollkommen genügt. Für mich sind KiCAD oder Eagle nicht Selbstzweck, sondern Werkzeuge, die ich ohne Studium nutzen möchte. Es ist ja nicht so, dass es nicht genügend Alternativen mit wesentlich steilerer Lernkurve gäbe.
Cyborg schrieb: > Das das Programm etwas anspruchsvoller und für Anfänger eigentlich nicht > geeignet ist, würde ich bedenkenlos unterschreiben. Das kann ich nicht nachvollziehen, mir hat der Umstieg von Eagle nach KiCAD sehr wenig Mühe bereitet. Der Umstieg von MS Office auf Libre Office war nerviger, weil es immer nur Kleinigkeiten sind, die anders funktionieren. Da ein CAD-Programm etwas komplexer ist, als Paint und Consorten, muss man eben ein wenig mehr verstehen, um halbwegs damit umgehen zu können. Wer das nicht will, sollte sich eine andere Beschäftigung suchen...
Erwin E. schrieb: > Falls diese beiden halben Stellen gestrichen würden, sähe ich die > Zukunft von KiCAD doch sehr skeptisch. Du vergisst, dass es bei Opensource einen gewissen Schneeballeffekt gibt: ab dem Moment, wo ein entsprechendes Projekt für eine hinreichend große Masse an Leuten interessant ist, weil sie es auch benutzen wollen, gibt es dann auch wesentlich mehr Leute, die dazu ernsthaft etwas beizutragen bereit sind. So gesehen würde es sicher auch nach dem Wegfall dieser Leute dennoch schneller weitergehen als davor. Allerdings zweifle ich an, dass es davor ernsthaft 200+ aktive Entwickler gab. Man könnte sich ja durch die Commitlogs hangeln und nachsehen, wie viele Leute da jemals mehr als nur einen Commit beigetragen haben. Selbst, wenn von 200 Leuten nur 10 % halbwegs aktiv sind, bringt das ein solches Projekt durchaus vorwärts. > Es ist ja nicht so, dass es nicht genügend Alternativen mit wesentlich > steilerer Lernkurve gäbe. Ganz gewiss :-), auch wenn das vermutlich nicht das war, was du damit wirklich sagen wolltest …
Erwin E. schrieb: > wenn ich mich erst durch 387 Seiten Dokumentation > wechselnder Qualität kämpfen muss, damit ich mit einer Software umgehen > kann, ist das für mich ein klares Ausschlusskriterium. Wie möchtest du es gerne haben , Nürnberger Trichter ? :-( Erwin E. schrieb: > Vor einigen Wochen habe ich mich einen Abend lang mit KiCAD > auseinandergesetzt. Das hat mir zur Abschreckung vollkommen genügt. Leg deine EAGLE CD oder was Vergleichbares unter dein Kopfkissen, das verhindert in deinem Fall bestimmt Alpträume und zwar in der Art, dass dich deine Bienen die ganze Zeit stechen, nur weil du das gute KiCad verschmähst :-))
Kicad geht für Hobby-Projekte, für professionelle Ergebnisse leider nicht. Eagle beinhaltet 30 Jahre Know-how von spezialisierten Ings. Kicad ist ein Amateurprojekt, wo mal dieser, mal jener, bisschen, mit und ohne Konzept, herumprogrammiert. Das merkt man auch an allen Stellen. Zu Eagle 8.0: Keiner zwingt einen, 8.0 zu verwenden. Ich werde 7.x solange verwenden, bis die Manager ihre Kinderkrankheiten überwunden haben oder ausgetauscht wurden.
Ralf S. schrieb: > Kicad geht für Hobby-Projekte, für professionelle Ergebnisse leider > nicht. Solche Blankostatements, natürlich völlig ohne jede Begründung, sind immer besonders hübsch. ;-) Andere Leute geben ähnliche Statements über Eagle ab. Keine von beiden Aussagen ist auch nur annähernd war.
Normalerweise war immer: -Windows gegen Linux -C gegen Pascal -Hertha gegen Werder Bremen Die neue Sportart ist scheinbar: -KiCad gegen Eagle :(( MfG Paul
Jörg W. schrieb: > Kann ja sein, dass du es nicht magst, Doku zu schreiben, > aber das heißt noch lange nicht, dass das generell ein > ungeliebtes Kind wäre. Bist du der Meinung, dass es einen nennenswerten Anteil an Leuten mit Ahnung gibt, die gerne Dokumentation schreiben oder zumindest nichts dagegen haben? Meine Erfahrung ist auch, dass das eigentlich keiner machen will.
Jörg W. schrieb: > Ralf S. schrieb: >> Kicad geht für Hobby-Projekte, für professionelle Ergebnisse leider >> nicht. > > Solche Blankostatements, natürlich völlig ohne jede Begründung, sind > immer besonders hübsch. ;-) > > Andere Leute geben ähnliche Statements über Eagle ab. > > Keine von beiden Aussagen ist auch nur annähernd war. Das opensource für "professionell" nicht funktioniert, dass habt ihr Deutschen ja Eindrucksvoll bewiesen. ;) Grund dafür ist aber bekannterweise nicht die mangelnde Qualität der Software, sondern indoktrinierte Nudldrucker (= "Sesselpupser"?) in der Chefetage, die ähnliche Kommentare wie den oben abgeben... Aber gut, nur weil KiCad jetzt die Anforderungen für dieses... wie hieß das noch... Zern, Kern, Fern? erfüllt, heißt das noch lange nicht, dass es den Anforderungen deutscher Qualitäts-Elektronik-Schmieden entspricht! Außerdem hab ich gehört is dieses Zern ja ein crowdfounding Projekt!!! Meine Güte, was dort für Amateure am Werk sind kann man sich ja vorstellen.
Dussel schrieb: > Bist du der Meinung, dass es einen nennenswerten Anteil an Leuten mit > Ahnung gibt, die gerne Dokumentation schreiben oder zumindest nichts > dagegen haben? Die funktionierenden Opensource-Projekte mit ordentlicher Doku beweisen das Gegenteil. Bei FreeBSD bekommste schon seit 20+ Jahren keinen Commit mehr durch, wenn du nicht zugleich auch die Doku ergänzt. Die Doku des GCC ist nun auch nicht gerade klein – wenngleich nicht immer so konsequent gepflegt, hängt dort stark von den Leuten ab. Seit bspw. Georg-Johann Lay das AVR-Backend pflegt, ist es deutlich besser dokumentiert. Für meine eigenen Projekte kann ich auch auf viele tausend Zeilen Doku verweisen. Leider verstehen manche Leute nicht, dass ihre ach so tollen Patches eben genau deshalb nicht sofort im Code drin sind, weil sie keine Ergänzung der Doku mitliefern. Wenn ich die dann selbst nachstoppeln muss, kann ich mir halt überlegen, ob ich in der gleichen dafür zu investierenden Stunde nicht stattdessen zwei andere Patches reinnehme, die ordentlich dokumentiert sind. KiCad hat eher andere Schwächen (wie beispielsweise die Inkonsistenz zwischen der Handhabung der verschiedenen Renderer) als die Doku.
Dussel schrieb: > Meine Erfahrung ist auch, dass das eigentlich keiner machen will. Meine Erfahrung ist, dass sie es nicht können und deswegen keine Lust haben, sich damit zu befassen. Gute Dokumentationen zu schreiben, lernt man eben nicht in der Grundschule...
Paul B. schrieb: > Die neue Sportart ist scheinbar: > -KiCad gegen Eagle > > :(( Das ':((' interpretiere ich so, dass du dich um deinen alten 'Sportclub' sorgen machst, und dich um einen anderen (neueren, angenehmeren) 'Sportclub' umschaust ;-)
Hallo Nop. Nop schrieb: >> Es gibt weiß Gott genügend gut dokumentierte Opensource-Projekte auf >> Erden. > > Gibt es. Bestreite ich auch nicht. Aber Fakt ist, daß Doku ein > ungeliebtes Stiefkind ist, weil Hacken mehr Spaß macht. In Firmen nennt > sich das "grunt work", und es wird gemacht, weil und wenn man Geld dafür > bekommt und die Anweisung kriegt, es zu tun. Bei Projekten mit hoher > Freiwilligenquote wird das demzufolge schlicht nicht passieren, das ist > strukturell bedingt. Das habe ich persönlich aber anders Kennengelernt. Die Doku bleibt liegen, weil der Chef Druck macht und Ergebnisse sehen will, also aus Zeitmangel. Da diese Form des Drucks bei OpenSource fehlt, findet man daher bei OpenSource Projekten öfters gut und sauber gestaltete Doku. Manchmal finden sich sogar Doku-Freaks ein, die dann Kleinode zaubern. In komerziellen Projekten findest Du soetwas nur selten. Wenn dort Doku über das lieblose Zusammenkopieren von Notizen hinaus geht, dann ist diese Gestaltung dem Vertrieb geschuldet. Also muss sie in erster Linie den Entscheidern gefallen, die dann eimal drüber blättern und beeindrukt sein sollen. Das hat wenig mit dem zu tun, was der Anwender des Programmes wünscht, um sich einzuarbeiten. Hinzu kommt, dass kommerzielle Software "Compliance-Fest" sein muss. D.h. Du findest dort jede Menge Kram, der dort aus rein juristischen Gründen steht, und eigentlich nicht viel zur Sache beiträgt, wenn man es genau betrachtet. Bei größeren Sachen ist das Anteilmäßig nicht so viel, aber bei kleinen Projekten kann das mehr als 50% des Manuals ausmachen. Desweiteren möchte kommerzielle Software aus Konkurenzgründen und Geheimhaltungsgründen oft nicht allzuviel über die Struktur im Hintergrund des Programmes verraten. Der Grund entfällt bei OpenSource, und oft kann dann die Kenntnis über Hintergründe eine ungeahnte Performance bringen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02,de
Vincent H. schrieb: > Außerdem hab ich gehört is dieses Zern ja ein crowdfounding Projekt!!! > Meine Güte, was dort für Amateure am Werk sind kann man sich ja > vorstellen. Leute so wie du, die so arrogant daherkommen, finden auch immer sehr schnell ihren Meister .
Hallo Dussel. Dussel schrieb: >> Kann ja sein, dass du es nicht magst, Doku zu schreiben, >> aber das heißt noch lange nicht, dass das generell ein >> ungeliebtes Kind wäre. > Bist du der Meinung, dass es einen nennenswerten Anteil an Leuten mit > Ahnung gibt, die gerne Dokumentation schreiben oder zumindest nichts > dagegen haben? Meine Erfahrung ist auch, dass das eigentlich keiner > machen will. Das Du es nicht magst, und kaum einer der für Geld arbeitet es sich leisten kann gute Doku zu machen, weil sie nicht zur "Kernkompetenz" des Produktes zählt und der Chef ärgerlich wird, wenn man zuviel Zeit in Doku steckt, bedeutet das nicht, dass das "keiner machen will". ;O) Für OpenSource gibt es kein Geld. also gilt nicht "time is money" weil es ja eh kein Geld gibt. Also schadet es nichts, wenn man sich hinsetzt und das ganze etwas Aufwändiger und liebevoll gestaltet. Und es kommt kein Chef, der sagt: Das Kapitel können sie streichen, das weiss doch jeder vom Fach. Unsere Kunden fühlen sich beleidigt und belästigt, wenn sie das lesen sollen". Und so fallen die Anfänger hinten runter. Bei openSource Doku kannst Du das so auswalzen, wie Du das benötigt hättest, als Du selber Anfänger warst. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02,de
Nop schrieb: > Daraus folgt erfahrungsgemäß > mit hoher Wahrscheinlichkeit, daß die Doku wahlweise irreführend, > veraltet oder nicht vorhanden ist. Das gilt nicht nur für OpenSource-Programme. Hatte heute im Betrieb ein Programm dessen Doku noch Stand XP ist. :-( mfg Olaf
Hallo Nop und Erwin. Nop schrieb: > Ja nun, KiCad ist ein Opensource-Projekt. Daraus folgt erfahrungsgemäß > mit hoher Wahrscheinlichkeit, daß die Doku wahlweise irreführend, > veraltet oder nicht vorhanden ist. Dagegen: Erwin E. schrieb: >> Insgesamt 387 Seiten Doku; in zig Sprachen und für jede Version. Da kann >> ich die Kritik bezüglich mangelnder Doku nicht verstehen. > > Mit Verlaub, wenn ich mich erst durch 387 Seiten Dokumentation > wechselnder Qualität kämpfen muss, damit ich mit einer Software umgehen > kann, ist das für mich ein klares Ausschlusskriterium. Typischer Fall von "Wat dem ingen sin Uhl, is dem annern sin Nachtigall" ;O) Hier stehen also Ansichten gegenüber. Aus Erfahrung weiss ich, das keine Doku perfekt ist. Aber Pauschalisierungen sind immer Mist. KiCad ist, auch verglichen mit kommerziellen Produkten, eher gut bis sehr gut Dokumentiert. > Wer > anschließend beruflich täglich damit arbeitet, für den ist eine Woche > Einarbeitungszeit sicher vertretbar. Nur keine Panik. Ich lese in Doku immer nur das, was ich aktuelle benötige. Ein Einführungstutorial ist in einer Stunde durch. Der Rest sind meist durchsuchbare PDFs. Wenn ich vor ein Problem renne, kann ich tiefer in der Doku suchen. Aus dem Tutorial habe ich dann im allgemeinen auch ein paar passende Fachausdrücke, nach denen ich dann suchen kann. In Härtefällen stellt man Fragen in einschlägigen Foren und User Groups. Und Google gibt es ja auch noch. Wenn es ganz hart kommt, kann man auch mal eine E-Mail an einen Entwickler direkt schreiben. Letzteres ist fast ein Alleinstellungsmerkmal von OpenSource. ;O) Was ich eher nervig finde, sind Video Tutorials, weil die immer viel zu schnell sind.... > Ob so jemand aber der typische > KiCAD-Anwender ist? Der Typ kommt öfters vor. Ein anderer typischer User Fall ist der Student, der sich darin einarbeitet. > Vor einigen Wochen habe ich mich einen Abend lang mit KiCAD > auseinandergesetzt. Das hat mir zur Abschreckung vollkommen genügt. Für > mich sind KiCAD oder Eagle nicht Selbstzweck, sondern Werkzeuge, die ich > ohne Studium nutzen möchte. Es ist ja nicht so, dass es nicht genügend > Alternativen mit wesentlich steilerer Lernkurve gäbe. Wenn Die Alternativen Dir zusagen, so sehe ich für Dich kein Hindernis, diese zu benutzen. Viel Erfolg. Auch bei OpenSource halte ich eine gewisse Konkurenz für wichtig. Alleine, um schon Vergleichsfälle und Lehrbeispiele für die Weiterentwicklung zu bekommen. Von daher kann ich es nur empfehlen, sich auch mal mit anderen Systeme zu Beschäftigen. Mache ich doch auch. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02,de
someone schrieb: > endgültig den Internetkram abgeschaltet und mir alle Bauteile > eigenhändig neu gezeichnet); das ist wohl ein Versuch, Kicad > "benutzbarer" zu machen. Das mache ich auch so. Und wenn man sich erstmal bei ein paar kleineren Projekte mit KiCad durchgebissen hat, dann flutscht es auch richtig. Ich nutze Eagle seit Ende der 90er sehr regelmäßig (ca. eine Leiterplatte je Monat). Im Moment nutze ich es immernoch, aber die Tendenz ist stark fallend. Seit gut einem Jahr habe ich KiCad immer mal wieder für kleinere Projekte herausgeholt. Langsam aber sicher werden die Projekte immer größer und umfangreicher. Und mit der neuen Lizenzpolitik wird die Talfahrt für Eagle bei mir immer schneller.
Erwin E. schrieb: > Kürzlich hat hier jemand geschrieben, KiCAD hätte 200+ OS Entwickler > plus zwei 'halbe' Entwicklerstellen beim Cern. Nun ist es ja doch so, > dass KiCAD vor dem Einstieg des Cern eher eine interessante Baustelle > als eine nutzbare ECAD-Software war. Woher nimmst Du dieses Wissen? Wir nutzen KiCad schon seit 2006 für unsere gesamte PCB-Entwicklung. > Nein, ich nutze KiCAD weder jetzt > noch habe ich das vor dem Cern-Einstieg getan. Um eine Ahnung vom > Entwicklungsstand von KiCAD vor Cern zu bekommen, reicht es aber > vollkommmen aus, die früheren Diskussionsfäden bis 2014/15 (auch) hier > im Board zu lesen. Offenbar reicht das nicht - siehe oben. > Falls diese > beiden halben Stellen gestrichen würden, sähe ich die Zukunft von KiCAD > doch sehr skeptisch. KiCad war auch vorher schon sehr gut benutzbar. Aber natürlich hat das CERN sehr nützliche Funktionen hinzugefügt (die man bei deutlich teureren Programmen immer noch vermisst). Daher auch unsere Spenden dorthin. Das ist das Mindeste, was wir tun können.
Lötauge schrieb: > wenn man sich mal die Threads anschaut, kann man feststellen, dass sich > mehr und mehr mit dem Layoutprogramm KiCAD beschäftigt wird. Ja. Man könnte es mit Shakespeare sagen (viel Lärm um Kicad). Viel Traffic in den Foren heißt hier offenbar, daß das betreffende Programm besonders gut sein muß. Das sehe ich nicht so. Das gilt auch für die Dokumentation. Viele Seiten heißt nicht "gute Dokumentation". Das leidige Thema hatten wir schon mit Doxygen. Und nochwas: Was nützt es, eine schlechte Konstruktion gut zu dokumentieren? Die Sache selbst müßte verbessert werden - aber die Kicad-Leute wehren sich mit Händen und Füßen dagegen. Bloß nicht zuhören, bloß nicht Kritik akzeptieren, immer nur sagen "du mußt dich an das Programm gewöhnen und es lieben lernen". Und zugleich Mitarbeit erwarten? Ach nö, der Wurm muß dem Fisch schmecken und nicht dem Angler. Tja, wenn man sich die Threads anschaut.. Diejenigen unter meinen Bekannten, die Kicad mal ausprobierten, haben es längst wieder von der Platte geputzt. W.S.
W.S. schrieb: > Viel Traffic in den Foren heißt hier offenbar, daß das betreffende > Programm besonders gut sein muß. Ganz genau :-)? So was nennt sich Schwarmintelligenz und die ist unfehlbar :-)? So Leute wie du mit einer abweichenden Meinung sind halt 'statistische Ausreiser' das muss man halt erdulden :( ☹️
il Conte schrieb: > So was nennt sich Schwarmintelligenz und die ist unfehlbar :-)? Yo, und Gefühle sind die neuen Fakten... ;-)
Jörg W. schrieb: > Dussel schrieb: >> Bist du der Meinung, dass es einen nennenswerten Anteil an Leuten mit >> Ahnung gibt, die gerne Dokumentation schreiben oder zumindest nichts >> dagegen haben? > > Die funktionierenden Opensource-Projekte mit ordentlicher Doku > beweisen das Gegenteil. Dass es gemacht werden muss, bestreite ich ja nicht. Bernd W. schrieb: > Das Du es nicht magst, und kaum einer der für Geld arbeitet es sich > leisten kann gute Doku zu machen, weil sie nicht zur "Kernkompetenz" des > Produktes zählt und der Chef ärgerlich wird, wenn man zuviel Zeit in > Doku steckt, bedeutet das nicht, dass das "keiner machen will". ;O) Ich habe eben immer wieder mitgekriegt 'Oh nee, danach muss ich noch die Doku machen' aber nie 'Endlich ist es fertig, jetzt kann ich endlich die Doku machen' (außer es war eine Pflicht). Deshalb hatte ich den Eindruck bekommen, dass es kaum einer machen will. Deshalb meine Frage.
Helmut S. schrieb: >>> Diese Fehler traten auf während des Ladens der Footprints: IO_FEHLER: http GET command failed Konnte das Zip-Archiv 'https://codeload.github.com/KiCad/Housings_SOT.pre... nicht herunterladen. ..... > Danish B. schrieb: >> Hast du einen Proxy? >> Evtl. im Firmennetzwerk? >> >> Ich hatte das Problem mal... > > > Ich habe kienen Proxy. > > Ich werde heute Abend mal KiCAD 4.05 deinstallieren und die neueste > Version 4.06 intallieren. > > Gibt es bestimmte Verzeichniss und/oder Registry in der ich auch "Reste" > der vorherigen KiCAD-Installation löschen sollte bevor ich es neu > installiere? Ich habe jetzt die alte Version deinstalliert und sicherheitshalber alles was den Namen Kicad enthält aus der Registry gelöscht. Dann habe ich die neueste Version installiert. Ich konnte jetzt die "Footprints" zuweisen. Das ist schon mal ein guter Anfang.
Tom schrieb: > Yo, und Gefühle sind die neuen Fakten... ;-) Du meinst die neuen alternativen Fakten ;-) (klingt heutzutage auch irgendwie glaubwürdiger :-))
Dussel schrieb: > Deshalb meine Frage. Es war mir neu, dass man eine Frage mit der Behauptung „fakt ist“ stellt … daher der Gegenwind.
Hallo Graf. il Conte schrieb: > Leute so wie du, die so arrogant daherkommen, > finden auch immer sehr schnell ihren Meister . Die Schwelle Deines Ironie- und Sarkasmus Detektors it etwas zu hoch eingestellt. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
W.S. schrieb: > Ach nö, der Wurm muß dem Fisch schmecken und nicht dem Angler. Tja, wenn > man sich die Threads anschaut.. Diejenigen unter meinen Bekannten, die > Kicad mal ausprobierten, haben es längst wieder von der Platte geputzt. Daß Du dagegen bist, ist für mich eine starke Empfehlung. Also habe ich es jetzt mal installiert und ausprobiert. Ich konnte in wenigen Minuten einen einfachen Schaltplan erstellen, ohne in die Dokumentation zu schauen. Das gefällt mir -- jedenfalls gut genug, daß ich mich die Tage mal durch das Tutorial arbeiten will. Daher: vielen Dank!
Bernd W. schrieb: > Nop schrieb: >> Ja nun, KiCad ist ein Opensource-Projekt. Daraus folgt erfahrungsgemäß >> mit hoher Wahrscheinlichkeit, daß die Doku wahlweise irreführend, >> veraltet oder nicht vorhanden ist. > > Dagegen: > > Erwin E. schrieb: >> Mit Verlaub, wenn ich mich erst durch 387 Seiten Dokumentation >> wechselnder Qualität kämpfen muss, damit ich mit einer Software umgehen >> kann, ist das für mich ein klares Ausschlusskriterium. > > Typischer Fall von "Wat dem ingen sin Uhl, is dem annern sin Nachtigall" > ;O) > Hier stehen also Ansichten gegenüber. Verzeihung, aber diese Ansichten stehen einander nicht gegenüber. Der Eine behauptet, daß die Dokumentation falsch, veraltet oder nicht vorhanden sei. Angesichts von fast 400 Seiten vorhandener und aktueller Dokumentation kann man das wohl nur in den Bereich "alternative Fakten" einordnen. Der andere will Software einfach benutzen, ohne die Dokumentation lesen zu müssen. Die verbindende Gemeinsamkeit der beiden Ansichten ist ihre arrogante Ignoranz -- und man sich nicht wundern darf, wenn man mit dieser Eigenschaft nunmal nicht allzu weit kommen kann. Lustig ist, daß solche Menschen nach meiner Erfahrung diese Ansprüche nur an OpenSource-Software, jedoch gänzlich andere Ansprüche an sich und ihre Software haben, sobald sie Geld dafür bezahlt haben. Dann ist die Lektüre der Dokumentation nämlich kein Problem, schließlich hat man dafür bezahlt und will jetzt gefälligst nutzen, wofür man teuer bezahlt hat. ;-)
Sheeva P. schrieb: > Lustig ist, daß solche Menschen nach meiner Erfahrung diese Ansprüche > nur an OpenSource-Software, jedoch gänzlich andere Ansprüche an sich und > ihre Software haben, sobald sie Geld dafür bezahlt haben. Dann ist die > Lektüre der Dokumentation nämlich kein Problem, schließlich hat man > dafür bezahlt und will jetzt gefälligst nutzen, wofür man teuer bezahlt > hat. ;-) Tja das sind richtig arme Hunde, je teurer die CAD'sche Saftware ist umso mehr müssen die in die DOKU einsteigen, (meistens dann auch noch ohne begleitende Bilder) um nicht als Nulltschecker dar zustehen :-( Für die ist dann die Nörgelei an OpenSource so eine Art Frustventil ;-)
"Der andere will Software einfach benutzen, ohne die Dokumentation lesen zu müssen. Die verbindende Gemeinsamkeit der beiden Ansichten ist ihre arrogante Ignoranz -- und man sich nicht wundern darf, wenn man mit dieser Eigenschaft nunmal nicht allzu weit kommen kann.2" Genau diese Argumentation ist schuld daran weshalb sich solche Programme oder Linux nicht verbreiten... Ein gutes Programm ist auch intuitiv benutzbar und wenn nicht sollte es schnell in Kommentare kommen wie"Wenn ich damit arbeiten will, sollte ich mich auch ins Handbuch arbeiten" sind einfach nur dumm und zeigen Warum Stephe Jobs so erfolgreich ist. Denn der wollte es eben einfach benutzbar...so grundlegend wie möglich so aufwendig wie unbedingt erforderlich. Das unterscheidet erfolgreiche Unternehmen von ewigen klitschen...der eine orientiert sich am Kunden (Was nicht bedeutet, das der Kunde gefragt wird wie er es denn gerne hätte, das gibt ganz sicher nichts!!) der andere setzt es einfach um wie er es gut findet und sagt dann..wenn die meine Software benutzen wollen, müssen sie sich halt einarbeite und meinem Stiel anpassen.. Sorry, aber das ist dumm! Und das sieht man in dieesem Forum heirs tändig..jeder meint das jemand der hier schreibt ein Frak sein muss..nicht das er womöglich Hobypilot ist und Autorennen fährt und als eines der vielen nebenhobies sich mit der Elektronik beschäftig..nein.,..laut der Meinung dieses Forums muss er all seien Zeit dann auch mit der Elektronik verbringen und soll keine nervigen Fragen stellen.. Armselige Einstellung vieler hier..leider
Mr.Tom schrieb: > Ein gutes Programm ist auch intuitiv benutzbar Nun geht es hier um KiCAD - und zumindest für mich ist es intuitiv genug. Das Problem scheint mir ein anderes zu sein: Offenbar funktioniert KiCAD in Teilbereichen völlig anders als z.B. Eagle. Also muß es schlecht sein.
Sheeva P. schrieb: > Lustig ist, daß solche Menschen nach meiner Erfahrung diese Ansprüche > nur an OpenSource-Software, jedoch gänzlich andere Ansprüche an sich und > ihre Software haben, sobald sie Geld dafür bezahlt haben. Dann ist die > Lektüre der Dokumentation nämlich kein Problem, schließlich hat man > dafür bezahlt und will jetzt gefälligst nutzen, wofür man teuer bezahlt > hat. ;-) Bei teurer Software gibts zunächst eine Schulung. Und der Rest geht über den Support.
Jörg W. schrieb: > Dussel schrieb: >> Deshalb meine Frage. > > Es war mir neu, dass man eine Frage mit der Behauptung „fakt ist“ > stellt … daher der Gegenwind. Wer ist denn der Meinung, dass man auf diese Art eine Frage stellt?
Peter schrieb: > Acn schrieb: >> Kennt jemand ein gutes Tutorial für das aktuelle KiCad auf Deutsch? >> (egal ob Video oder PDF, habe bisher mit Eagle gearbeitet > > http://timogruss.de/kicad-loesung-fuer-die-leiterplatten-entwicklung/ Das Tutorial ist ansich cool, aber leider von 2013. Anscheinend funktioniert z.B. die Bauteilebibliothek mittlerweile zum Teil anders.
Sheeva P. schrieb: > Angesichts von fast 400 Seiten vorhandener und aktueller > Dokumentation Welche Version nutzt du denn? Ist die Hilfe mit installiert worden? Woher weißt du, dass dein Handbuch aktuell ist? Ein Link um Zweifler zu erleuchten, wäre sicher nicht schlecht, um deine Behauptung zu stützen.
Meine Meinung dazu ist, daß jemand der sich bereits in einem ähnlichen Programm auskennt, innerhalb weniger Stunden in der Lage sein muß ein einfaches brauchbares Resultat liefern zu können. Sonst ist es für die Tonne und schade für alle Beteiligten. Wer einen Führerschein hat, muß jedes Auto fahren können. Gaspedal und Bremse sind immer gleich. Und ein Handbuch nur für wirklich eingemachtes!
Abdul K. schrieb: > Meine Meinung dazu ist, daß jemand der sich bereits in einem ähnlichen > Programm auskennt, innerhalb weniger Stunden in der Lage sein muß ein > einfaches brauchbares Resultat liefern zu können. Sonst ist es für die > Tonne und schade für alle Beteiligten. > Wer einen Führerschein hat, muß jedes Auto fahren können. Gaspedal und > Bremse sind immer gleich. Der Vergleich ist absolut treffend! Ich habe vorher mich allgemein in das Layouten von PCBs eingearbeitet und dazu Eagle genutzt. Eagle gefiel mir aus vielen Gründen aber nicht so wirklich und dann habe ich KiCad mal eine Chance gegeben. Nach ein paar kleineren Problemen (der Fehler lag bei mir!) lief es einwandfrei und ich habe mich sofort zurechtgefunden. Klar, das ein oder andere Panel sieht anders aus aber prinzipiell habe ich mich sofort wohl gefühlt. Und gerade das Trennen von Schaltplansymbolen und Footprints oder andere schöne Dinge sind wirklich eine Verbesserung gegenüber Eagle. Klar, als es dann "ans Eingemachte" ging, klar, da musste ich mal kurz Google fragen. Aber das habe ich bei Eagle auch machen müssen. Wenn man aber sowas wie abgespecktes wie Fritzing (oder gar Paint! (sic!)) nutzt - ja dann muss man sich grundsätzlich in jede Art von halbwegs komplexeren Layout-Programmen einarbeiten.
:
Bearbeitet durch User
Cyborg schrieb: > Woher weißt du, dass dein Handbuch aktuell ist? > Ein Link um Zweifler zu erleuchten, wäre sicher nicht schlecht, um > deine Behauptung zu stützen. Hier sind die Quellen: http://kicad-pcb.org/help/documentation/ Wenn man da in die PDF's reinklickt dann sind die alle vom 5 März 2017!! Sheeva hat mit seiner Feststellung durchaus recht. Sheeva P. schrieb: > Verzeihung, aber diese Ansichten stehen einander nicht gegenüber. Der > Eine behauptet, daß die Dokumentation falsch, veraltet oder nicht > vorhanden sei. Angesichts von fast 400 Seiten vorhandener und aktueller > Dokumentation kann man das wohl nur in den Bereich "alternative Fakten" > einordnen.
Abdul K. schrieb: > Wer einen Führerschein hat, muß jedes Auto fahren können. Gaspedal und > Bremse sind immer gleich. > Und ein Handbuch nur für wirklich eingemachtes! Bei den CAD's ist es aber manchmal leider so,(um bei deinem Bild zu bleiben) dass Kupplung und Bremse vertauscht sind.
Stefan S. schrieb: > Klar, das ein oder andere Panel sieht anders aus aber prinzipiell habe > ich mich sofort wohl gefühlt. Und gerade das Trennen von > Schaltplansymbolen und Footprints oder andere schöne Dinge sind wirklich > eine Verbesserung gegenüber Eagle. Genau dieses ist imho fürchterlich und der Grund dafür daß KiCad sowohl bei mir als auch in meinem Bekanntenkreis einen Abflug gemacht hat. Wenn ich ein Bauteil anlege, will ich es auch nutzen können und nicht jedes Mal, wenn ich den Boardeditor öffne (übrigens ein eigenständiges Programm), erstmal wieder den Footprint anlegen. Ich weiß, durch seperates Importieren in die entsprechenden zusätzlich anzulegenenden Libs geht das, aber das ist unnötiger Arbeitsaufwand. KiCad mag einige schöne Seiten (push and shove z.B.) haben, aber solche Sachen gehen gar nicht.
il <conte schrieb: > il <conte (Gast) = il Conte. @MODs Ich habe die 'Shift' Taste mit '>' verwechselt und bitte um Vergebung. Ich möchte mir nicht unbedingt einen Verweis einhandeln :-( (bei der Strenge der MODs - kann man nie sicher sein :-(
Eagle4-User schrieb: > Genau dieses ist imho fürchterlich und der Grund dafür daß KiCad sowohl > bei mir als auch in meinem Bekanntenkreis einen Abflug gemacht hat. Das ist eine subjektive Meinung von dir. Andere Leute sehen das gerade anders herum. Es gibt halt Leute so wie dich, die sich mit einer Umstellung sehr schwer tun, anderen wiederum geht die Umstellung ganz leicht von der Hand. Besser zu Recht im Berufsleben kommen aber die letzteren.
Mr.Tom schrieb: > Genau diese Argumentation ist schuld daran weshalb sich solche Programme > oder Linux nicht verbreiten... Nö, es sind einfach verschiedene Anforderungen und Erwartungen, die diese Leute an OpenSource- und an kommerzielle Software stellen. Bei OpenSource muß immer alles gleich so funktionieren, wie der Einfältige glaubt, sonst ist nicht die Einfalt, sondern OpenSource blöd. An kommerzielle Produkte werden solche idiotischen Maßstäbe hingegen nicht angelegt. Natürlich hat dieses Verhaltensmuster auch psychologische Hintergründe: einerseits ist die Motivation, sich in eine Software gründlich einzuarbeiten und deren Dokumentation zu lesen, wesentlich größer, wenn man bereits Geld für den Erwerb dieser Software ausgegeben hat. Andererseits muß der Betreffende aber auch vor sich selbst rechtfertigen, daß er Geld für etwas ausgegeben und hat, das gleich er um die Ecke auch kostenlos bekommen hätte. > Ein gutes Programm ist auch intuitiv benutzbar und wenn nicht sollte es > schnell in Kommentare kommen wie"Wenn ich damit arbeiten will, sollte > ich mich auch ins Handbuch arbeiten" sind einfach nur dumm und zeigen > Warum Stephe Jobs so erfolgreich ist. Tja, Steve Jobs ist leider tot. Nein, im Ernst: ich kenne genau so viele Möglichkeiten, ein CAD-Programm zu bedienen, wie ich CAD-Programme kenne. Kommerzielle CAD-Software wie Autocad, Nemetschek, Eagle und CADdy sind genauso wenig intuitiv wie Kicad, FreeCAD, LibreCAD und gEDA. Die meisten bekommen mit ihrer Intuition vielleicht noch ein paar Striche hin oder ein Bauteil positioniert, aber spätestens dann ist die Intuition zuende, auch wenn der Proband schon ein oder mehrere andere CAD-Programme gut kennt. Was das mit Linux zu tun haben soll, erschließt sich mir nicht. Schließlich hat Linux mit Ausnahme des Desktops überall gewonnen, und sogar dort einen signifikanten Marktanteil erreicht. Dafür daß Linux keine unerschöpflichen Werbebudgets hat und nicht mit wettbewerbswidrigen Mafia-Methoden in den Markt gedrückt wird, ist es sogar unglaublich erfolgreich, und zwar nicht zuletzt wegen seiner Benutzerfreundlichkeit, Stabilität und Flexibilität. Sogar Du selbst (wenn Du derselbe "Mr. Tom" bist) hat in anderen Fällen offensichtlich keine Berührungsängste mit der Dokumentation und verweist hier [1] und hier [2] auf die Datenblätter der diskutierten Bauelemente. Aber Software, die wesentlich komplexer und vielseitiger ist ein jedes einzelne Bauelement, soll man ohne Dokumentation verstehen? Insofern tut es mir leid, aber ich bleibe bei meiner vorherigen Aussage: jemand, der komplizierte Technik benutzen will, ohne die Dokumentation zu lesen, ist arrogant und ignorant und darf sich nicht wundern, wenn er mit diesen Eigenschaften auf die Nase fällt. [1] Beitrag "Re: Funktionsweise 74HC112" [2] Beitrag "Re: Lampe flackert bei selbstgebauten Amplitudendimmer"
Michael X. schrieb: > Bei teurer Software gibts zunächst eine Schulung. Und der Rest geht über > den Support. Das erklärt die mangelhafte Qualität der Dokumentation und des Supports mancher kommerzieller Software, die ich kenne... ;-)
Angehängte Dateien:
-
kicad.png
53 KB
Eagle4-User schrieb: > Wenn > ich ein Bauteil anlege, will ich es auch nutzen können und nicht jedes > Mal, wenn ich den Boardeditor öffne (übrigens ein eigenständiges > Programm), erstmal wieder den Footprint anlegen. Zum wievielten Mal schreibe ich das jetzt? Genau so kannst Du es machen - oder man weist später dynamisch zu: KiCad lässt Dir die Freiheit, es so zu machen, wie Du möchtest. > Ich weiß, durch > seperates Importieren in die entsprechenden zusätzlich anzulegenenden > Libs geht das, aber das ist unnötiger Arbeitsaufwand. > KiCad mag einige schöne Seiten (push and shove z.B.) haben, aber solche > Sachen gehen gar nicht. Offenbar habt Ihr KiCad noch nie eingesetzt, sondern einfach nur installiert und 30 Minuten sehr grob damit rumgespielt. Anders kann ich mir wirklich nicht mehr erklären, woher das Falschwissen stammt. Angehängt ist ein Screenshot des "Field properties" Dialog aus dem Bibliothekseditor. Was meinst Du wohl, was der Button "Assign footprint" (der aktiv wird, wenn man das Feld "Footprint" auswählt) bewirken könnte? Alternativ kannst Du den auch händisch in "Field value" eintragen.
Eagle4-User schrieb: > Genau dieses ist imho fürchterlich und der Grund dafür daß KiCad sowohl > bei mir als auch in meinem Bekanntenkreis einen Abflug gemacht hat. Wenn > ich ein Bauteil anlege, will ich es auch nutzen können und nicht jedes > Mal, wenn ich den Boardeditor öffne (übrigens ein eigenständiges > Programm), erstmal wieder den Footprint anlegen. Und was mast du, wenn es das Teil in verschiedenen Bauformen gibt? Jedesmal den Schaltplan neu zeichnen? Nein, die Trennung ist schon in Ordnung.
Abdul K. schrieb: > Wer einen Führerschein hat, muß jedes Auto fahren können. Gaspedal und > Bremse sind immer gleich. Beim Computer sind Tastatur, Bildschirm und Maus gleich, deshalb muss der Nutzer auch alle Programme Nutzen können? Beim Auto gibt es extra Führerscheine für Krankenfahrstühle, PKW und BUS. Zur Leiterplattenentwicklung existieren unterschiedliche Programme. So werden unterschiedliche Anforderungen von unterschiedlich Programmen erfüllt. Der Hobby- Anwender braucht oft keine Wärme- oder EMV- Simulation.
Sheeva P. schrieb: > Andererseits muß der Betreffende aber auch vor sich selbst > rechtfertigen, daß er Geld für etwas ausgegeben und hat, das gleich er > um die Ecke auch kostenlos bekommen hätte. Ich muss gestehen, dass ich diesen Eindruck nicht nur einmal hatte, wenn ich mir so diverse 'Platinen' Threads Revue passieren lasse.
Eagle4-User schrieb: > Genau dieses ist imho fürchterlich und der Grund dafür daß KiCad sowohl > bei mir als auch in meinem Bekanntenkreis einen Abflug gemacht hat. Wenn > ich ein Bauteil anlege, will ich es auch nutzen können und nicht jedes > Mal, wenn ich den Boardeditor öffne (übrigens ein eigenständiges > Programm), erstmal wieder den Footprint anlegen. Ich weiß, durch > seperates Importieren in die entsprechenden zusätzlich anzulegenenden > Libs geht das, aber das ist unnötiger Arbeitsaufwand. > KiCad mag einige schöne Seiten (push and shove z.B.) haben, aber solche > Sachen gehen gar nicht. Ich finde es im Gegensatz zu dir als absoluten Segen! Die Trennung dieser ist perfekt. Als Hobbybastler nicht mehr wegzudenken. Beispielsweise: Ich plane mit dem einem Mosfet, ordne im ein Footprint zu und gut. Der Prototyp ist ok, aber könnte verbessert werden, also anderen Mosfet wählen. Aber herrje, der hat eine andere Footprint. => Schaltung belassen und neuen Footprint zuordnen. Feddich! Ich habe erst den Adler probiert, den finde ich persönlich grauenhaft. Danach Target und KiCad getestet. Seitdem mache ich alles mit KiCad. Ist nicht alles Schön-Wetter mit KiCad, aber meines Erachtens schöner als mit den anderen beiden. Altium etc. liegen "out of budget" und habe ich somit erst gar nicht angeschaut. Warum auch, bin zufrieden mit KiCad insbesondere durch die Verbesserungen seit Cern dabei ist.
Also ich weiß überhaupt nicht was ihr habt. Ich habe vor kurzem meine erste Leiterplatte mit Kicad designt und hatte vorher noch nie mit einem CAD Programm gearbeitet. Ich habe mir ein paar Videos angeschaut und ein bisschen in der Dokumentation gelesen und dann ging das eigentlich ganz einfach. Wer Kicad nicht bedienen kann für den ist das Hobby Elektronik wahrscheinlich sowieso nicht das richtige.
Markus S. schrieb: > Also ich weiß überhaupt nicht was ihr habt. Ich habe vor kurzem meine > erste Leiterplatte mit Kicad designt und hatte vorher noch nie mit einem > CAD Programm gearbeitet. > Ich habe mir ein paar Videos angeschaut und ein bisschen in der > Dokumentation gelesen und dann ging das eigentlich ganz einfach. Sei froh darum, du hattest das Glück der 'Unberührtheit'. Behalte es gut in Errinnerung dein (CAD) 'Erstesmal' ;-)? ?
Cyborg schrieb: > Sheeva P. schrieb: >> Angesichts von fast 400 Seiten vorhandener und aktueller >> Dokumentation > > Welche Version nutzt du denn? Ist die Hilfe mit installiert worden? Lokal installiert die Version 4.0.2 mit der zugehörigen Dokumentation aus KUbuntu 16.04.2 LTS. > Woher weißt du, dass dein Handbuch aktuell ist? Die Zeitstempel der Dateien, die Commitlogs des Dokumentations-Repository und die Änderungsdaten innerhalb der Dateien reichen mir zunächst aus. Auf einen Beleg für die Behauptung, daß die Dokumentation nicht aktuell sei, warten wir ja -- trotz Nachfrage -- noch immer, so daß für die Behauptung weiterhin gilt, was Jörg Wunsch dazu geschrieben hat: "wahlweise Humbug, FUD oder einfach nur unzulässige Verallgemeinerungen". > Ein Link um Zweifler zu erleuchten, wäre sicher nicht schlecht, um > deine Behauptung zu stützen. Ich fürchte, daß ein Link auf meine lokal installierte Dokumentation nicht sonderlich hilfreich ist, aber wenn es der Wahrheitsfindung dient, bitte: file:///usr/share/doc/kicad/help/de/ Ansonsten findest Du dieselbe Dokumentation für die letzten Versionen, säuberlich nach Versionsnummern geordnet, unter http://docs.kicad-pcb.org/
Abdul K. schrieb: > Meine Meinung dazu ist, daß jemand der sich bereits in einem ähnlichen > Programm auskennt, innerhalb weniger Stunden in der Lage sein muß ein > einfaches brauchbares Resultat liefern zu können. Sonst ist es für die > Tonne und schade für alle Beteiligten. Wenn alle Programme für eine Aufgabe gleich bedient würden, bräuchte man keine unterschiedlichen Programme. Tatsächlich können viele Programme aber gerade deswegen produktiver genutzt werden als ihre Wettbewerber, weil sie eine andere Benutzerführung verwenden. > Wer einen Führerschein hat, muß jedes Auto fahren können. Gaspedal und > Bremse sind immer gleich. Die meisten Führerscheininhaber möchte ich aber trotzdem nicht in einem Gabelstapler, Sattelzug oder Bagger sehen.
die Frage ist doch, ob man als Heimanwender überhaupt vom alten EAGLE zum neuen wechseln MUSS... Was treibt einen denn dazu? Geilheit auf die neueste Version? Lasst die alte drauf und bleibt glücklich, dann müsst ihr euch auch nich mit Versionsmurks von Kicad und anderem rumärgern.
Mike B. schrieb: > die Frage ist doch, ob man als Heimanwender überhaupt vom alten EAGLE > zum neuen wechseln MUSS... > Was treibt einen denn dazu? Geilheit auf die neueste Version? > Lasst die alte drauf und bleibt glücklich, dann müsst ihr euch auch nich > mit Versionsmurks von Kicad und anderem rumärgern. Ich bin KiCad Fan aber Dein Argument gefällt mir. Jetzt mußt Du mir nur noch erklären warum das für Windows-Versionen nicht gilt: kaum setzt Microsoft einen neuen Schiß schon sind die Fliegen wie wahnsinnig hinter der neuen Kacke her, dabei weiß doch eigentlich Jeder das das Zeug vor Service Packe 2 nicht zu gebrauchen ist... Gruß, Holm
Wenn man Gas und Bremse tauscht und damit mehr Konplexität erzeugt, dann muß das einen wahrhaften Vorteil haben, ansonsten ist es sinnloser Humbug. Nun gibt es aber zwei Klassen von Programmierern und eine davon ist eine Qual für die Menschheit. Man ist mit Windows schon genug gestraft. Oft würde es schon deutlich helfen, wenn eigentliche Algorithmen und UI von getrennten Leuten designt würden. Ich schreibe dazu nun auch nichts mehr. Die eine Hälfte ist leider unbelehrbar.
Abdul K. schrieb: > Die eine Hälfte ist leider > unbelehrbar Und die andere Hälfte belehrt gerne ;-)
Cyborg schrieb: > für Anfänger eigentlich nicht > geeignet ist, würde ich bedenkenlos unterschreiben. Ich nicht. Ich bin kein Profi, fand KiCAD aber einleuchtend und einfach.
Abdul K. schrieb: > Man ist mit Windows schon genug gestraft. Oft würde es schon deutlich > helfen, wenn eigentliche Algorithmen und UI von getrennten Leuten > designt würden. Das ist in aller Regel der Fall - anders wären nicht-triviale Programme nicht pflegbar. Der Punkt ist: es gibt zwar für die Funktionen, die in allen Programmen vorkommen - also das, was in den GUI-Werkzeugkisten schon fest verdrahtet ist - Konventionen zur Bedienung, aber nicht für anwendungsspezifische Spezialfunktionen. Selbst bei den klassischen Office-Programmen gibt es Unterschiede - selbst zwischen MS-Office und LibreOffice gibt es diese Unterschiede. > Ich schreibe dazu nun auch nichts mehr. Die eine Hälfte ist leider > unbelehrbar. Na, da solltest du dich erst mal selbst belehren... ;-)
Was mir an KiCad nicht gefällt ist der Zwang zur Einhaltung eines recht komplexen Ablaufs: http://docs.kicad-pcb.org/stable/de/images/de/kicad_flowchart.png Einfach hinsetzen und eine Platine zeichnen so wie bei Eagle ist nicht.
Ich schreibe Hardware und auf die ist absoluter Verlaß. Sagen andere, aber ich höre es natürlich gern. Man muß einfach selbst erkennen was einem liegt und was nicht. Also Dinge auch sein lassen können.
Angehängte Dateien:
-
Einfuegen_Bauteil.png
11 KB
Schon im vierten Kästchen ist die erste Stolperstelle.
Abdul K. schrieb: > Wenn man Gas und Bremse tauscht und damit mehr Konplexität erzeugt, dann > muß das einen wahrhaften Vorteil haben, ansonsten ist es sinnloser > Humbug. Das stimmt an sich schon. Nur daraus zu folgern, dass KiCad oder Eagle schlecht ist, weil es eine etwas andere Herandgehensweise für letztendlich das selbe Ziel (Gerberfiles etc.) wählt, halte ich für falsch. Wie weiter oben schon geschrieben wurde: Wenn sich zwei Programme exakt gleich verhalten, ist eines davon obsolet. Nehmen wir zwei Programmiersprachen (ich verzichte mal auf Beispiele, um nicht was loszutreten... ;-) ). Die wohl allermeisten Probleme lassen sich sowohl mit Sprache A als auch mit Sprache B lösen. Aber die Herangehensweise ist manchmal ein bisschen unterschiedlich. Und wie beim Programmieren ist es auch beim Leiterplattendesign: Man lernt das Handwerk, wobei eigentlich sekundär ist, mit welchem Tool, resp. mit welcher Sprache. Ein Umstieg in eine andere Sprache/ein anderes Tool darf resp. sollte bezüglich der Notwendigkeit durchaus hinterfragt weden. Aber zu sagen, dass die andere sprache/das andere Tool schlecht ist, weil einiges ein bisschen anders funktioniert, sagt m.E. mehr über den Anwender aus als über die Sprache7das Tool.
Nop schrieb: > Mit Sicherheit. Eine Lösung, für die man regelmäßig online gehen muß, > damit sie sich nicht deaktiviert, ist halt vollkommen inakzeptabel. Nö. Sie wird in Zeiten wo ein Online-Anschluß überall immer selbstverständlicher wird immer akzeptabler! > Besonders, weil man dann nicht mal eben 5 Jahre alte Daten nochmal > modifizieren kann, weil die damalige Version der Software nicht mehr > aktivierbar ist und die neue schlimmstenfalls das Dateiformat seit zwei > Jahren nicht mehr fehlerfrei importieren kann. Habe das soeben mal Layoutdaten einer V7.2 mit V8.1 gelesen, dort zurück gespeichert und konnte sie problemlos wieder in V7.2 öffnen. Irgendwann wird das vermutlich nicht mehr funktionieren, warum sollte es aber auch, wenn dann hauptsächlich mit V8 und größer gearbeitet wird. Wichtig ist doch nur, daß ältere Layouts überhaupt noch eingelesen werden können (was ich mal als selbstverständlich voraussetzen würde) und daß man seine Projekte nach ausgelaufenem Abo zumindest anzeigen/ausgeben kann.
Simon H. schrieb: > Aber zu sagen, dass die andere sprache/das andere > Tool schlecht ist, weil einiges ein bisschen anders funktioniert, sagt > m.E. mehr über den Anwender aus als über die Sprache7das Tool Du gehst also davon aus, es gäbe keine guten/schlechten Tools sondern nur dumme/schlaue Anwender??? Ich glaube bei Deiner Betrachtung ignorierst Du vor allem eines: Software sollte sich nach den Bedürfnissen des Anwenders richten, nicht umgekehrt. Je mehr Anwender eine Software dank einfacher, komfortabler Abläufe erreicht desto besser für sie- und die Anwender! Komplexität liegt nicht immer und unbedingt allein in der Sache (hier: dem Leiterplatten-Design) begründet.
Gegenfrage: Gehst Du davon aus, dass es nur eine gute Programmiersprache gibt?
Abdul K. schrieb: > Ich schreibe Hardware und auf die ist absoluter Verlaß. Und ich löte Software ....?
Gustav schrieb: > Ich glaube bei Deiner Betrachtung > ignorierst Du vor allem eines: Software sollte sich nach den > Bedürfnissen des Anwenders richten, nicht umgekehrt. Da gehe ich mit dir einig, nur kann man eben ein gutes Tool so oder auch anders programmieren und damit sind wir wieder so schlau wie vorher...
(ups, zu spät zum Editieren) Um Deine Frage doch noch zu beantworten: Doch, ich glaube, es gibt gute und schlechte Software. Und ich glaube auch, es gibt gute und schlechte Programmiersprachen. Das widerspricht aber nicht meiner obigen Aussage. Ach ja, und ich glaube auch, es gibt kluge und dumme Menschen. Aber das ist ein anderes Thema. :-)
:
Bearbeitet durch User
il Conte schrieb: > Abdul K. schrieb: >> Ich schreibe Hardware und auf die ist absoluter Verlaß. > > Und ich löte Software ....? Diodenmatrix? :-D
Gustav schrieb: > Du gehst also davon aus, es gäbe keine guten/schlechten Tools sondern > nur dumme/schlaue Anwender??? Wenn ein kluger Anwender mit einer Software nicht zurecht kommt, lernt er, wie er damit umgehen muß, oder sucht sich eine andere. Ein dummer Anwender meckert hingegen lieber über die Software. > Ich glaube bei Deiner Betrachtung ignorierst Du vor allem eines: Software > sollte sich nach den Bedürfnissen des Anwenders richten, nicht umgekehrt. Eine Software muß zuerst vor allem die ihr gestellte Aufgabe lösen. Wenn diese Aufgabe komplex ist und eventuell auch noch aus mehreren Schritten besteht, dann schlägt sich das in der Bedienung der Software nieder. Dazu können verschiedene Programme unterschiedliche Wege gehen, um dieses Ziel zu erreichen. Das ist sogar eher die Regel als die Ausnahme, und trotzdem sagt das weniger über die Qualität oder die Benutzerfreundlichkeit dieser Programme, sondern höchstens etwas über die Eignung für den individuellen Anwender aus: der Eine kommt mit diesem Programm besser klar, ein Anderer eben mit jenem. Manche Nutzer kommen sogar mit überhaupt keiner Software klar -- aber das liegt dann meistens nicht an der Software... > Komplexität liegt nicht immer und unbedingt > allein in der Sache (hier: dem Leiterplatten-Design) begründet. Im Wesentlichen schon. Ich kenne kein einziges Programm für diese Aufgabe, welches sich jedem Anwender sofort und ohne jemals in die Dokumentation zu schauen erschließen würde, und trotzdem brauchbare Ergebnisse liefert. Darüber hinaus gilt: sobald Du Deine Software idiotensicher gemacht hast, kommt die Natur und erfindet bessere Idioten. ;-)
Sheeva P. schrieb: > Ansonsten findest Du dieselbe Dokumentation für die letzten Versionen, > säuberlich nach Versionsnummern geordnet, unter > > http://docs.kicad-pcb.org/ Das ist aber keine Lösung, sondern nur eine Referenz. Zu einer Lösung gehört auch eine Beschreibung, wie damit umgegangen werden muss. Eine .hlp-Datei(oder welches Attribut haben die Hilfe-Dateien?) und wie man einen Pfad (im Hauptmenü unter Einstellungen) eintragen und nutzen kann, waren bisher nicht beschrieben worden. Im Netz gibts ein paar Artikel darüber aber die Lösung ist auch da nur referenziert und das reicht halt nicht. Eine Lösung muss auch Schritt für Schritt nachvollziehbar, auch von den Pfadangaben, beschrieben werden, sonst nutzt es nichts.
Dussel schrieb: > Jörg W. schrieb: >> Dussel schrieb: >>> Deshalb meine Frage. >> >> Es war mir neu, dass man eine Frage mit der Behauptung „fakt ist“ >> stellt … daher der Gegenwind. > Wer ist denn der Meinung, dass man auf diese Art eine Frage stellt? „Nop“: Beitrag "Re: KiCAD ist im Kommen" Abdul K. schrieb: > Meine Meinung dazu ist, daß jemand der sich bereits in einem ähnlichen > Programm auskennt, innerhalb weniger Stunden in der Lage sein muß ein > einfaches brauchbares Resultat liefern zu können. Vermutlich wird jemand, der vorher mit Altium oder sowas gearbeitet hat, diesem deinen Anspruch gemäß sogar mit KiCad zurechtkommen. Die beiden teilen sich halt wesentlich mehr konzeptionelle Gemeinsamkeiten als Eagle und KiCad (ohne dass ich jetzt Altium und KiCad auch nur ansatzweise gleichsetzen würde). Daraus darfst du übrigens auch schlussfolgern, dass jemand, der jahrelang mit Eagle gearbeitet hat, keineswegs innerhalb von ein paar Stunden mit Altium ein brauchbares Resultat bringen wird. Ist Altium nun nur deshalb großer Mist? Leider ist die Standardisierung eben selbst der grundlegenden Konzepte bei EDA-Software bei weitem noch nicht in dem Topf, wie die sie das bei Autos ist. Kann aber auch daran liegen, dass es Autos schon seit mehr als 100 Jahren gibt, EDA-Software erst seit 30.
Jörg W. schrieb: > Dussel schrieb: >> Jörg W. schrieb: >>> Dussel schrieb: >>>> Deshalb meine Frage. >>> >>> Es war mir neu, dass man eine Frage mit der Behauptung „fakt ist“ >>> stellt … daher der Gegenwind. >> Wer ist denn der Meinung, dass man auf diese Art eine Frage stellt? > > „Nop“: > > Beitrag "Re: KiCAD ist im Kommen" Ich verstehe es nicht. Wo schreibt der denn irgendwas von einer Frage? Aber das ist auch nicht so wichtig, das ist nicht das Thema hier. Von mir aus…
Cyborg schrieb: > Sheeva P. schrieb: >> Ansonsten findest Du dieselbe Dokumentation für die letzten Versionen, >> säuberlich nach Versionsnummern geordnet, unter >> >> http://docs.kicad-pcb.org/ > > Das ist aber keine Lösung, sondern nur eine Referenz. Vielleicht reden wir an einander vorbei, aber dort findest Du neben den Referenzhandbüchern der einzelnen Komponenten von Kicad auch eine Datei "getting_started_in_kicad" in den Formaten HTML, PDF und EPUB, die für Einsteiger gedacht ist. Für die aktuellest Kicad-Version 4.0.6 findest Du diese HTML-Datei auch online: [1]. Außerdem sind hier [2] noch weitere externe Tutorials verlinkt, da ist sicher auch etwas für Dich dabei. [1] http://docs.kicad-pcb.org/4.0.6/de/getting_started_in_kicad.html [2] http://kicad-pcb.org/help/tutorials/
Sheeva P. schrieb: > Vielleicht reden wir an einander vorbei Ja, weil du nach wie vor referenzierst, aber nichts erklärst. So kommt keiner weiter. Gemein hin erwarte ich Hilfe-Dateien wie sie bei Windowsanwendungen üblich sind, mit Stichwortsuche usw. usf.. Das scheint Kicad nicht zu liefern, statt dessen nur Tutorials in HTML, PDF, EPUB (was immer das letzte für ein seltsames Format (ebook gemäß Wikipedia) sein soll). Tutorials in diesen Formaten sind eben nicht das, was man von anderen Anwendungen an Hilfe gewöhnt ist. Target macht da ja auch sein eigenes Ding, aber die sind dann bei der Installation schon dabei und man muss nicht rum raten. Begreifst du die Unsicherheit?
Beitrag #4938823 wurde von einem Moderator gelöscht.
Gustav schrieb im Beitrag #4938823: > Sheeva P. schrieb: >> Ich kenne kein einziges Programm für *diese* >> Aufgabe, welches sich jedem Anwender sofort und ohne jemals in die >> Dokumentation zu schauen erschließen würde, und trotzdem brauchbare >> Ergebnisse liefert. > Die gibts millionenfach: Wordpad, Paint... Selbst der Eagle- > Layouteditor macht den Einstieg ohne großes Studium recht einfach, schon > weil kein fixer Arbeitsablauf zu erlernen und einzuhalten ist. Hm, mit Paint kann man mit viel gutem Willen vielleicht ein Layout zeichnen, aber mit Wordpad?? Dass in KiCAD das Umschalten zwischen Schaltplan und Layout grottig ist, sehe ich auch so, aber es laesst sich trotzdem ordentlich damit arbeiten, man gewoehnt sich einfach dran. Wie dass man in C in Funktionen Arrays nur als Pointer uebergeben kann. Uebelste Steinzeit, aber im Ganzen halt immernoch konkurenzfaehig im Jahr 2017.
Gustav schrieb im Beitrag #4938823: > Eine gute Software zeichnet sich dadurch aus daß möglichst wenige > Anwender meckern. Meckern? Meckerer kann man getrost ignorieren - die haben offensichtlich nichts besseres zu tun. Fundierte und nachvollziehbare Kritik ist was anderes - die setzt aber wirklich ernsthafte Beschäftigung mit dem kritisierten Programm voraus und hat mit "meckern" nichts zu tun. > Gute und schlechte Software unterscheidet sich darin, wieviel (Bedien-) > Arbeit sie dem Anwender überlässt und wieviel sie selbst übernimmt. Am Ende soll sie wohl noch erraten, was der Dau vor der Tastatur meint, aber leider nicht artikulieren kann, weil er zu faul ist, sich ordentlich einzuarbeiten? > Die gibts millionenfach: Wordpad, Paint... Selbst der Eagle- > Layouteditor macht den Einstieg ohne großes Studium recht einfach, schon > weil kein fixer Arbeitsablauf zu erlernen und einzuhalten ist. Warum meckerst du dann über KiCad? Nimm doch einfach Wordpad, Paint, Eagle um deine Layouts zu machen... > Ich sehe keinen ernsthaften Anwender als Idioten an. Und DU hälst dich für einen ernsthaften KiCad-Anwender?
Feldstecher schrieb: > Dass in KiCAD das Umschalten zwischen Schaltplan und Layout grottig ist, > sehe ich auch so, aber es laesst sich trotzdem ordentlich damit > arbeiten, man gewoehnt sich einfach dran. Was ist daran "grottig"? Das Umschalten geht mit einem Klick - zumindest unter Linux.
Uhu U. schrieb: > Was ist daran "grottig"? Mein letztes Projekt ist zwei Jahre her, es kann sich durchaus was gebessert haben. Damals wars in etwa so: Netzliste exportieren, Netzlistenkonfigurator oeffnen/zuordnen/speichern, Netzliste im Layout neu laden. Das fuehlt sich einfach unnoetig kompliziert an und erschwert den Einstieg. Obwohl es nach einer gewissen Eingewoehnung auch flott von der Hand geht.
Netzliste ausgeben und Netzliste einlesen sind bei Windows 8 Klicks. Da im Schaltplan an die Schaltkreisanschlüsse nur noch die Namen drangeschrieben werden und jeder Schaltkreis auf ein extra Blatt kommt, ist ein Umschalten nicht mehr so wichtig.
Angehängte Dateien:
-
kicad.png
37 KB
Cyborg schrieb: > Sheeva P. schrieb: >> Vielleicht reden wir an einander vorbei > > Ja, weil du nach wie vor referenzierst, aber nichts erklärst. Was soll ich denn erklären? > So kommt keiner weiter. Gemein hin erwarte ich Hilfe-Dateien > wie sie bei Windowsanwendungen üblich sind, mit Stichwortsuche > usw. usf.. Das scheint Kicad nicht zu liefern, statt dessen nur > Tutorials in HTML, PDF, EPUB (was immer das letzte für ein seltsames > Format (ebook gemäß Wikipedia) sein soll). Tutorials in diesen > Formaten sind eben nicht das, was man von anderen Anwendungen > an Hilfe gewöhnt ist. Target macht da ja auch sein eigenes Ding, > aber die sind dann bei der Installation schon dabei und man muss > nicht rum raten. Begreifst du die Unsicherheit? Es tut mir leid, aber die Unsicherheit begreife ich nicht. Denn genau dieselben HTML-Dateien, auf deren Online-Quellen ich oben referenziert habe, hat mir Kicad auch auf meine Festplatte installiert. Wenn ich im Programm auf "Hilfe" klicke, erscheint ein Hilfemenü wie oben im Anhang zu sehen, genau wie das auch bei Windows-Anwendungen üblich ist. Wenn ich in diesem Hilfemenü auf "Getting Started in KiCad" klicke, dann geht ein Fenster meines Webbrowsers auf und zeigt genau dieselbe Datei an, die ich Dir oben in diesem Beitrag [1] unter "[1]" verlinkt habe. Wenn ich stattdessen auf "KiCad Manual" klicke, geht das Referenzhandbuch von KiCad in meinem Webbrowser auf -- genau dieselbe HTML-Datei, die Du auch unter meinen Links oben finden kannst. Genau dasselbe gilt auch für die anderen Applikationen der KiCad-Suite. Du siehst: genau wie Du es von Deinen Windows-Anwendungen gewöhnt bist, gibt es auch in KiCad eine Hilfe innerhalb des Programms. Die ruft genau wie die WinHelp oder die HTMLHelp unter Windows ein externes Programm auf, im Falle von KiCad den Webbrowser, und zeigt dort die Hilfe an -- nichts, das einen erfahrenen Windowsuser unsicher machen könnte. Und wie sich das für eine HTML-Datei gehört, ist die Dateinamenserweiterung der HTML-Hilfe von KiCad natürlich .html. Da es sich bei diesen Dateien um ganz einfache Single-Page-Webapps handelt, kann ich die mit dem Browser natürlich auch problemlos nach Stichworten durchsuchen. Als Linuxnutzer und bekennender Freund von Kommandozeilen, ipython und Elasticsearch habe ich natürlich noch deutlich weiter gehende Möglichkeiten in petto. ;-) Obendrein gibt es dieselben Hilfedateien aber noch in anderen Formaten, nämlich EPUB mit der Dateinamenserweiterung .epub sowie als PDF mit der Dateinamenserweiterung .pdf. Die kannst Du benutzen, wenn Du abends im Bettchen mit Deinem Tablet noch schnell was nachschauen willst. Das ist aber nur ein zusätzliches Serviceangebot, das Du nicht nutzen mußt. Die von Dir oben erwähnten .hlp-Dateien unter Windows gelten übrigens als veraltet. Bereits mit Windows Vista wurde kein Viewer mehr für diese Art von Hilfe-Dateien ausgeliefert und konnte später nur noch als optionale Erweiterung installiert werden, um die Abwärtskompatibilität zu wahren, dasselbe dann nochmals unter Windows7. Seit IIRC 1997 verwendet Windows das Dateiformat "compressed HTML help" (.chm) für die Hilfe. Ansonsten möchte ich Dir von KiCad abraten, wenn Dich schon so winzige Abweichungen von Windows' Pseudostandards dermaßen verunsichern. Leider kann ich Dir dann jedoch auch kein anderes CAD-Programm empfehlen, denn alle mir bekannten CAD-Programme -- sei es für Elektronik, Maschinenbau oder Architektur -- weichen in vielerlei Hinsicht stark von Microsofts Styleguide "Design Universal Windows Platform" ab und könnten Benutzer, die völlig auf Windows fokussiert sind, irritieren oder verunsichern. [1] Beitrag "Re: KiCAD ist im Kommen"
Feldstecher schrieb: > Damals wars in etwa so: Netzliste exportieren, > Netzlistenkonfigurator oeffnen/zuordnen/speichern, Netzliste im Layout > neu laden. Das ist noch so, hat aber mit dem Umschalten vom Schaltplan ins Layout rein gar nichts zu tun. Das könnte man vereinfachen, aber ich muss sagen, mich stört es nicht sonderlich, wie es im Moment ist. > Obwohl es nach einer gewissen Eingewoehnung auch flott von der Hand geht. Eben.
Ich meine gehört oder gelesen zu haben, dass es in der nächsten Version einen Knopf im Sinne von "update PCB" geben wird.
Beitrag #4938885 wurde von einem Moderator gelöscht.
Um Meckerer - das war dein Wort - muss man sich nicht kümmern - egal, was man macht.
Uhu U. schrieb: > Und was mast du, wenn es das Teil in verschiedenen Bauformen gibt? > Jedesmal den Schaltplan neu zeichnen? Nein natürlich nicht. In Eagle tausche ich einfach das Bauteil aus, d.h. ich wähle einfach die Bauform die ich haben möchte. Das geht mit 3 KLicks : Funktion Bauteil tauschen wählen, zu tauschendes Bauteil anklicken und neues Bauteil aus der Liste wählen - fertig. Jörg M. schrieb: > Ich finde es im Gegensatz zu dir als absoluten Segen! Die Trennung > dieser ist perfekt. Als Hobbybastler nicht mehr wegzudenken. > Beispielsweise: > Ich plane mit dem einem Mosfet, ordne im ein Footprint zu und gut. Der > Prototyp ist ok, aber könnte verbessert werden, also anderen Mosfet > wählen. Aber herrje, der hat eine andere Footprint. => Schaltung > belassen und neuen Footprint zuordnen. Feddich! Der Ansatz in KiCad ist falsch. Ich konstruiere eine Schaltung und verwende in selbiger ein bestimmtes Bauteil, z.B. einen bestimmten IC Typ. Ich möchte die Schaltung "klassisch" nicht mit SMD Bauelementen realisieren. Unter diesen Voraussetzungen ist der Footprint für das Bauteil festgelegt und ich wähle das Bauteil entsprechend aus der Bibliothek aus. Das in KiCad benutzte Verfahren macht nur Sinn wenn ich mit generischen Bauteilen arbeite also einem nicht spezifizierten OPV, Transistor, Mosfet etc. Letztendlich muß jeder mit dem Werkzeug arbeiten, von dem er meint das es für ihn am besten geeignet ist. Ich habe KiCad in der aktuellen Version probiert und mir ist es zu sperrig. Ich komme mit Eagle besser zurecht. Ich muß auch nicht unbedingt die Version 8.0 haben. Version 7.3 ist für mich völlig ausreichend, so das mich das neue Lizensmodell nicht wirklich tangiert. Wenn ich mit PCB mein Geld verdienen müßte, würde ich weder Eagle noch KiCad sondern höchstwahrscheinlich Pulsonix benutzen. Zeno
Gustav schrieb im Beitrag #4938885: > Solcherlei getroffene eigene Befindlichkeiten und persönliche Angriffe > sind meistens bei Programmierern anzutreffen die erwarten, daß sich der > Anwender an die Software anzupassen habe und nicht umgekehrt. Das > scheint mir hier das Kernproblem zu sein. Kritik=Meckern, natürlich von > DAU's und Idioten. Programmierer-Überheblichkeit par excellence. Da hast Du den Nagel auf en Kopf getroffen.
Gustav schrieb im Beitrag #4938885: > Der Programmierer tut immer gut daran, Beschwerden aller Art zur > Kenntnis zu nehmen. Das darf man als Programmierer, und erst Recht als Entwickler, unter keinen Umständen tun. Wer jedem Gemecker hinterherläuft, tötet sein Projekt. Du bist kein Entwickler, oder? Dann versuche ich mal, das zu erklären. Schau, die Entwicklung größerer Softwareprojekte ist eine sehr komplexe und komplizierte Angelegenheit. Aus der Idee für eine Software wird ein Design, und daraus wiederum die Architektur, welche dann mit Leben (Funktionalität) gefüllt werden muß. Und das eigentlich Wichtige, nämlich die Abbildung der erwarteten Daten, habe ich noch gar nicht erwähnt. Schon eine funktionsfähige Software zu entwickeln, ist schwierig genug. Da braucht es keine "Beschwerden", die einem erzählen, daß die eigene Software doch bitte wie das Programm X funktionieren sollte. Wozu meine Software gut sein soll, wenn das Programm X die gewünschten Funktionen bereit hat? Ahja, meine Software ist OpenSource und daher kostenlos... Jedoch, weißt Du, haben Architekten, Entwickler, Designer und Programmierer immer genügend zu tun. Fehlermeldungen und vernünftige, konstruktive Kritik werden gerne berücksichtigt. Für dummes Gemecker von Idioten, die nicht die Dokumentation lesen können, haben wir aber einfach keine Zeit -- sollen die sich doch andere Software suchen und deren Entwickler nerven. Die OpenSource-Community ist nicht dazu da, Deine Wünsche zu befriedigen. Wenn Du das haben willst, bezahl' jemanden dafür. Wenn Du das verstanden hast, bist Du herzlich eingeladen, mitzumachen. Viel Spaß! :-)
Beitrag #4938910 wurde von einem Moderator gelöscht.
Lutz H. schrieb: > Netzliste ausgeben und Netzliste einlesen sind bei Windows 8 Klicks. Aber völlig unnötig, siehe Target.
Zeno schrieb: > Jörg M. schrieb: >> Ich finde es im Gegensatz zu dir als absoluten Segen! Die Trennung >> dieser ist perfekt. Als Hobbybastler nicht mehr wegzudenken. >> Beispielsweise: >> Ich plane mit dem einem Mosfet, ordne im ein Footprint zu und gut. Der >> Prototyp ist ok, aber könnte verbessert werden, also anderen Mosfet >> wählen. Aber herrje, der hat eine andere Footprint. => Schaltung >> belassen und neuen Footprint zuordnen. Feddich! > > Der Ansatz in KiCad ist falsch. Ich konstruiere eine Schaltung und > verwende in selbiger ein bestimmtes Bauteil, z.B. einen bestimmten IC > Typ. Ich möchte die Schaltung "klassisch" nicht mit SMD Bauelementen > realisieren. Unter diesen Voraussetzungen ist der Footprint für das > Bauteil festgelegt und ich wähle das Bauteil entsprechend aus der > Bibliothek aus. Das ist übrigens nicht nur der Ansatz von KiCad, sondern z.B. auch von Altium. Du sagst, der Ansatz sei falsch, weil Du von Anfang an die (physikalische) Komponente definieren willst. Bei mir ist es nun mal genau anders herum. Selbst wenn ich weiss, dass ich primär in 0603 bestücke, möchte ich bei der Schaltplaneingabe einfach mal einen Widerstand setzen. Dazu kommt noch, dass ich z.B. bei Kondis a priori nicht genau weiss und es mich auch nicht interessiert, ob die gewünschte Kapazität verbunden mit der Spannungsfestigkeit etc. überhaupt in 0603 erhältlich ist. Ich finde es wesentlich einfacher, am Schluss nach Schaltplaneingabe Mal die Komponenten durchzugehen, die Seite des Distributors daneben geöffnet zu haben und entsprechend die passenden Footprints schnell zuzuordnen Wenn Du aber eine fixe Zuweisung möchtest, kannst Du das in KiCad ja machen! Wie hier schon wiederholt geschrieben wurde. Ich mache das bei "speziellen" Komponenten auch. Dann kommt noch etwas anderes dazu: Kicad wird wohl demnächst eine Spice Integration bekommen. Dies abstrahiert dann das Schaltplansymbol wieder vollständig vom physikalischen Device.
:
Bearbeitet durch User
Simon H. schrieb: > Ich finde es wesentlich einfacher, am Schluss nach Schaltplaneingabe Mal > die Komponenten durchzugehen, die Seite des Distributors daneben > geöffnet zu haben und entsprechend die passenden Footprints schnell > zuzuordnen das ist halt Bastler..... Wenn die Library nicht korrekt ist....... Bastler halt....
Simon H. schrieb: > Schaltplansymbol In KICAD kann ich einem Schaltzeichen genau einen Footprint zuweisen. Dann muss ich die Verwendung nur einmalig bestätigen und kann den Footprint trotzdem während der Entwicklung noch ändern.
Lutz H. schrieb: > Simon H. schrieb: >> Schaltplansymbol > > In KICAD kann ich einem Schaltzeichen genau einen Footprint zuweisen. > Dann muss ich die Verwendung nur einmalig bestätigen und kann den > Footprint trotzdem während der Entwicklung noch ändern. Eben. Weiter oben gibt es sogar eine Anleitung mit Bildern, wie das gemacht wird. ACDC schrieb: > das ist halt Bastler..... > Wenn die Library nicht korrekt ist....... > Bastler halt.... Altium ist demnach auch ein Basteltool. Und was bitteschön soll jetzt das mit "wenn die Library nicht korrekt ist" zu tun haben? Aber der Text darüber und darunter lässt darauf schliessen, dass Argumente nicht zu erwarten sind.
Sheeva P. schrieb: > Wenn ich im > Programm auf "Hilfe" klicke, erscheint ein Hilfemenü wie oben im Anhang > zu sehen, genau wie das auch bei Windows-Anwendungen üblich ist. Ich bekomme da nur eine Message: "Die Hilfedatei `Kicad` wurde nicht gefunden" Wenn darüber nichts geschrieben steht, wie soll man das Problem lösen? Auch das wiederholte Installieren von anderen Versionen brachte keine Besserung. Hast du ne Idee, aber eine die ich nachvollziehen kann?
Cyborg schrieb: > Ich bekomme da nur eine Message: > "Die Hilfedatei `Kicad` wurde nicht gefunden" Also bei mir funktioniert das in der Version 4.0.6 klaglos.
ACDC schrieb: > das ist halt Bastler..... > Wenn die Library nicht korrekt ist....... > Bastler halt.... Teure Systeme arbeiten ebenso. Dort ist es dann üblich daß die Bauteile eine eigene eineindeutige Nummer bekommen die dann mit einer Datenbank verknüpft ist. In der Datenbank stehen dann die Ordercodes, Preis, Verfügbarkeit, Lieferant etc. EoL-Management wird so einfacher. Gebastel ist das nicht.
Cyborg schrieb: > Wenn darüber nichts geschrieben steht, wie soll man das Problem lösen? > Auch das wiederholte Installieren von anderen Versionen brachte keine > Besserung. Hast du ne Idee, aber eine die ich nachvollziehen kann? Da fällt mir ein Sketch von Harald Junke ein: (ist ein wenig Offtopic *), könnte aber dazu dienen dich aufzumuntern ;-) Junke hat im Kaufhaus einen Koffer mit Zahlenschloss gekauft und kam am nächsten Tag wieder zurück. Er regte sich fürchterlich auf weil sich sein Koffer nicht öffnen lies, obwohl er die korrekte Nummer eingegeben hatte. Das Ganze ist dann soweit eskaliert, dass von der Direktion der 'Troubleshooter' in Marsch gesetzt wurde. Letztlich fragte er den Junke nach der 'korrekten' Nummer. Er antwortete: Es sei das Geburtsdatum seiner Frau. Woraufhin der 'Troubleshooter' ihm etwas ins Ohr flüsterte. Er schaute Ihn mit großen Augen an, machte sich am Koffer zu schaffen und sieh da: Es machte 'Klack' 'Klack' und der Koffer war offen. Tja große Probleme haben meistens kleine Ursachen - es war das Geburtsdatum seiner Freundin. *) und auch weil Freitag ist ;-)
Cyborg schrieb: > Sheeva P. schrieb: >> Wenn ich im >> Programm auf "Hilfe" klicke, erscheint ein Hilfemenü wie oben im Anhang >> zu sehen, genau wie das auch bei Windows-Anwendungen üblich ist. > > Ich bekomme da nur eine Message: > "Die Hilfedatei `Kicad` wurde nicht gefunden" > > Wenn darüber nichts geschrieben steht, wie soll man das Problem lösen? Meditieren? > Auch das wiederholte Installieren von anderen Versionen brachte keine > Besserung. Hast du ne Idee, aber eine die ich nachvollziehen kann? ..schwiergig wenn Du forderst das Du das nachvollziehen können willst..wo Du doch nicht mal den Rückschluß ziehst das Du aus irgend einem Grund die Doku nicht installiert hast. (hab ich auch nicht, aber bei mir ist das eine Git-Developer-Version ohne Anspruch an die Funktionaliät). An Deiner Stelle würde ich mal mit passenden Begriffen, gerne in englisch mit einer Suchmaschine Deiner Wahl Ursachenforschung betreiben.. Gruß, Holm
Habt ihr denn alle Nichts zu tun, daß ihr Euch mit Gewalt in ein anderes Programm einarbeiten wollt? Wer garantiert, daß das nicht sang -und klanglos von der Bildfläche verschwindet? MfG Paul
Das garanitert nie jemand. Weder bei Eagle, noch bei Altium, noch bei KiCad. Aber es gibt gute Gründe sich ein anderes EDA-Programm mal genauer anzusehen: - erweitern des eigenen Horizonts - Möglichkeit eines direkten Vergleichs wenn z.B. in der Firma eine Neuanschaffung ansteht - Man rostet in der Denkensweise nicht ein. Man bleibt anpassungsfähig. - Stellenweise endeckt man dabei auch ungeahnte Möglichkeiten Und es ist bei jedem ernsthaft komplexen Programm das selbe: Wenn man auf ein anderes Programm wechselt, muss man sich da erst einmal einarbeiten. Dabei ist es egal ob es eine EDA-Software, ein CAD-Programm oder eine IDE ist. Wie andere hier schon gesagt haben: Wären alle gleich zu bedienen, würde ja warscheinlich kaum jemand die Vielfallt brauchen.
Paul B. schrieb: > Wer garantiert, daß das nicht sang -und > klanglos von der Bildfläche verschwindet? Mal ganz ehrlich: Das fragen sich bestimmt einige in Bezug auf EAGLE und Autodesk :-( Paul B. schrieb: > Habt ihr denn alle Nichts zu tun, daß ihr Euch mit Gewalt in ein anderes > Programm einarbeiten wollt? Gewalt kann ich nicht erkennen, die machen das freiwillig, wohl auch deshalb weil sie die 'Subscription Gängelei' von Autodesk nicht mehr mitmachen wollen.
Paul B. schrieb: > Habt ihr denn alle Nichts zu tun, daß ihr Euch mit Gewalt in ein anderes > Programm einarbeiten wollt? Wer garantiert, daß das nicht sang -und > klanglos von der Bildfläche verschwindet? > > MfG Paul Ich benutze das schon ewig, da hieß der Vorgänger des PCB-Editors noch "pcb". In so fern nehme ich kein anderes Programm. Ich amüsiere mich aber köstlich über all die, die so tun als wäre ihnen ihr Lieblingsspielzeug weg genommen worden (Eagle) und nun der Meinung sind KiCad habe so zu funktionieren wie sie es gewöhnt sind.. Gruß, Holm
Paul B. schrieb: > Habt ihr denn alle Nichts zu tun, daß ihr Euch mit Gewalt in ein anderes > Programm einarbeiten wollt? Wer garantiert, daß das nicht sang -und > klanglos von der Bildfläche verschwindet? Ich (und viele andere). Außerdem kannst Du auch selbst dafür sorgen. Denn ich habe hier alle Sourcen und kann sie problemlos über Github etc. zur Verfügung stellen. OpenSource-Projekte, die öffentlich gehostet werden, können eben nicht so einfach verschwinden. Man ist auch nicht auf irgendeinen Lizenzserver oder auch nur Internetverbindung angewiesen, damit KiCad arbeitsfähig ist.
Beitrag #4939520 wurde von einem Moderator gelöscht.
Gustav schrieb im Beitrag #4939520: > - es kostet Zeit > - die Einarbeitung macht Mühe > - das vorhandene Programm langt doch völlig (nämlich Eagle). Au Mann, das Leben ist soooo anstrengend - lass dich einbalsamieren, dann ist alles ganz easy...
:
Bearbeitet durch User
Gustav schrieb im Beitrag #4939520: > ist keine Gängelei sondern schlicht eine flexiblere, ganz natürliche und > übliche Zahlmethode, genau für die Nutzungszeit und keinen Deut länger > zu bezahlen. Das ist für mich wie Kühe melken ohne dass man sie füttert. Das Ende kann man voraussehen.
Beitrag #4939546 wurde von einem Moderator gelöscht.
Gustav schrieb im Beitrag #4939546: > Chris D. schrieb: >> Denn ich habe hier alle Sourcen und kann sie problemlos über Github etc. >> zur Verfügung stellen. > > Wieviele von denen die "alle Sourcen haben" können damit wirklich was > anfangen? Offenbar genug. Es ging Paul ja auch ums Verschwinden - und solange ich hier die Sourcen habe, kann das Projekt eben nicht verschwinden :-) >> Man ist auch nicht auf irgendeinen Lizenzserver oder auch nur >> Internetverbindung angewiesen, damit KiCad arbeitsfähig ist. > > Internet ist allgegenwärtig. Eagle etwa fragt den Server alle 14 Tage... Solange der Lizenzserver lebt. Tut er das nicht mehr, hat man ein Problem. Davon abgesehen hat KiCad eben auch einige Sachen wie PnS anzubieten, die Eagle nicht hat. Da kann es durchaus sinnvoll sein, sich umzustellen. Damals ist uns das jedenfalls rasch und recht problemlos gelungen. Ich denke, andere schaffen das auch :-)
Gustav schrieb im Beitrag #4939546: > Nö. Das Leben ist soooo kurz, da sollte man seine Zeit schon sinnvoll > nutzen! Sich in diverse Programme zum gleichen Zweck einzuarbeiten > zähle ich jetzt mal nicht dazu, ausgenommen natürlich sowas ist zum > Hobby erkoren :) Lass mich schätzen: du bist schon über 85...
:
Bearbeitet durch User
Beitrag #4939560 wurde von einem Moderator gelöscht.
Gustav schrieb im Beitrag #4939520: > ist keine Gängelei sondern schlicht eine flexiblere, ganz natürliche und > übliche Zahlmethode, genau für die Nutzungszeit und keinen Deut länger > zu bezahlen. Moby, altes Haus, lange nicht mehr gesehen :-)
il Conte schrieb: > Also bei mir funktioniert das in der Version 4.0.6 Die hab ich jetzt mal herunter geladen und installiert. Jetzt geht die Hilfe, so wie das hier schon beschrieben wurde. Die Kicad-Version BZR 59..., die ich vorher hatte, war da wohl schon zu alt.
Beitrag #4939580 wurde von einem Moderator gelöscht.
Gustav schrieb im Beitrag #4939580: > Chris D. schrieb: >> Solange der Lizenzserver lebt > > Das könnte ein einziges Argument gegen Subskription-Eagle sein. Ich > sehe bloß weit und breit keinen technischen oder organisatorischen > Grund, warum der Server sein Leben für bedeutsame Zeit aushauchen > sollte. Daß unser Leben aber heute immer mehr vom Funktionieren der > Technik abhängt ist jetzt nichts speziell Lizenzserver-spezifisches. Was für ECAD-Software aber vollkommen unnötig ist - siehe KiCad. Warum kompliziert, wenn es auch einfach geht. Also: besser keinen Server als einen Server :-) >> Davon abgesehen hat KiCad eben auch einige Sachen wie PnS anzubieten, >> die Eagle nicht hat. Da kann es durchaus sinnvoll sein, sich >> umzustellen. > > Eagle ist in großen Schritten dabei aufzuholen. Schon die aktuelle 8.1 > angeschaut? Ja. Das ist nicht einmal ansatzweise das, was PnS ausmacht. Und wie "groß" die Schritte waren, konnte ich über die Jahre verfolgen. Da ist praktisch nichts passiert. Warum also sollte man viel Geld für etwas bezahlen, das offenbar selbst kostenfreier Software funktional hinterherläuft?
Gustav schrieb im Beitrag #4939580:
> Eagle ist in großen Schritten dabei aufzuholen.
Überholen ohne einzuholen... war da nicht mal was?
Gustav schrieb im Beitrag #4939580: > warum der Server sein Leben für bedeutsame Zeit aushauchen > sollte. Einfach einen 3 wöchigen windstillen Winter. Keine Kohle, keine Atomkraftwerke, kein Wind, kein Licht. Ich weiß, es ist politisch verboten an so ein Wetter zu denken.
Simon H. schrieb: > Ich meine gehört oder gelesen zu haben, dass es in der nächsten Version > einen Knopf im Sinne von "update PCB" geben wird. Gibt es schon.
Gustav schrieb im Beitrag #4939580: > Das könnte ein einziges Argument gegen Subskription-Eagle sein. Ich > sehe bloß weit und breit keinen technischen oder organisatorischen > Grund, warum der Server sein Leben für bedeutsame Zeit aushauchen what? https://www.golem.de/news/ddos-massiver-angriff-auf-dyndns-beeintraechtigt-github-und-amazon-1610-123966.html https://www.golem.de/news/ausfall-massive-probleme-bei-amazon-web-services-1702-126459.html http://www.spiegel.de/netzwelt/web/panne-bei-cloudflare-trifft-hunderttausende-websites-a-886710.html http://www.handelsblatt.com/unternehmen/handel-konsumgueter/aws-serverausfall-was-der-cloud-ausfall-fuer-amazon-bedeutet/19468246-2.html
Angehängte Dateien:
Danish B. schrieb: > Simon H. schrieb: >> Ich meine gehört oder gelesen zu haben, dass es in der nächsten Version >> einen Knopf im Sinne von "update PCB" geben wird. > > Gibt es schon.
Cyborg schrieb: > Ich bekomme da nur eine Message: > "Die Hilfedatei `Kicad` wurde nicht gefunden" Merkwürdig, dann wurde die Dokumentation wohl nicht installiert -- oder jedenfalls nicht dort, wo sie hingehört. Keine Ahnung, wo die unter Windows hingehört; Standardpfade für so etwas wie /usr/share/doc/, die Linux und andere UNIX-artige Systeme für sowas haben, kennt Windows ja dummerweise nicht. Bestimmt kann Dir ein Windows-User von KiCad weiterhelfen. > Wenn darüber nichts geschrieben steht, wie soll man das Problem lösen? > Auch das wiederholte Installieren von anderen Versionen brachte keine > Besserung. Hast du ne Idee, aber eine die ich nachvollziehen kann? Natürlich ist es immer eine gute Idee, das eigene Gehirn zu benutzen. Also, sofern man eines hat und damit umgehen kann. Ansonsten könntest Du -- das ist aber eher etwas für Fortgeschrittene -- nachschauen oder einen Windows-User von KiCad fragen, wo die Dokumentation unter Windows hingehört, sie herunterladen und dann einfach dahin kopieren. Aber, wie gesagt, das erfordert fortgeschrittene Computerkenntnisse wie das Herunterladen von Dateien und das Kopieren oder Verschieben von Dateien auf der lokalen Festplatte. Sowas kann leider nicht jeder -- da mußt Du selbst schauen, ob Du Dir das zutraust. ;-) Ansonsten gibt es in Deiner Nähe vielleicht auch eine Windows User Group oder einen Windows-Stammtisch mit netten Menschen, die Dir gerne helfen.
Sheeva P. schrieb: > Natürlich ist es immer eine gute Idee, das eigene Gehirn zu benutzen. > Also, sofern man eines hat und damit umgehen kann. Und was bringt jetzt diese abwertende Aussage? Fühlst du dich jetzt besser? Mach dir lieber Gedanken, was andere über DICH denken. Sicher bis du auch kein Alleswisser oder -könner. Zumindest hab ich mal il Contes Gedankengang aufgegriffen und hab mal die 4.0.6 installiert. Jetzt verlinkt die Hilfe zu file:///C:/Programme/KiCad/share/doc/kicad/help/de/kicad.html Sheeva P. schrieb: > Ansonsten gibt es in Deiner Nähe vielleicht auch eine Windows User Group > oder einen Windows-Stammtisch mit netten Menschen, die Dir gerne helfen. Ist das Forum nicht nah genug? Physisch ist doch so enger Kontakt gar nicht nötig.
Uhu U. schrieb: > Was ist das für eine Version? Gute Frage, weiß kicad selber nicht so genau xd. "Version: no-vcs-found, release build" Habe mir allerdings den Quelltext am 4. März geladen und kompiliert. (Also ca. 2 Wochen alt).
Gustav schrieb im Beitrag #4939520: > Vielfalt brauchen tut niemand. Gebraucht wird eine Lösung, mit der das > konkrete Ziel möglichst einfach zu realisieren ist. Das ist leider aus meiner Sicht bei Eagle nicht der Fall. Entweder finde ich die Einstellung nicht, oder Eagle 6.5 kann z.B. nur Runde Durchkontaktierungen. Es gibt z.B. Wandler die längliche Befestigungsfräsungen benötigen.
Danish B. schrieb: > Habe mir allerdings den Quelltext am 4. März geladen und kompiliert. Dann ist da wohl eine Hiobsbotschaft für die E*-Fans in der Mache...
Gustav schrieb im Beitrag #4938885: > Solcherlei getroffene eigene Befindlichkeiten und persönliche Angriffe > sind meistens bei Programmierern anzutreffen die erwarten, daß sich der > Anwender an die Software anzupassen habe und nicht umgekehrt. Das > scheint mir hier das Kernproblem zu sein. Kritik=Meckern, natürlich von > DAU's und Idioten. Programmierer-Überheblichkeit par excellence. Niemand hat was gegen Kritik. Aber was Du bisher in diesem Thread erbrochen hast, war nur dreistes Gemecker. Daß Du Dich jetzt zum Opfer stilisierst und das beleidigte Leberwürstchen gibst, paßt perfekt dazu.
Uhu U. schrieb: > Was ist das für eine Version? Das was du suchst gibt es z.Z. nur in den 'nigthly Versions'. Man sollte es aber mit bedacht nutzen. Wir bevorzugen hier immer den 'geraden' Weg: Jede Änderung kommt zuerst in den Schaltplan .. (auch wenn es sich um simple Montagelöcher handelt) Eeschema > (Anotation) > ECR > Fehler korrigieren > Netzliste generieren > PCBnew > Netzliste einlesen ...
Chris D. schrieb: > Es ging Paul ja auch ums Verschwinden - und solange ich > hier die Sourcen habe, kann das Projekt eben nicht verschwinden :-) Ja, ist ja Alles chic (um mal die Worte meiner Nachbarin zu nutzen). Die Frage ist doch. WER zwingt die Leute, eine neue Version von Eagle zu benutzen und sich mit dem Lizenzserver zu beharken? Ich kann doch hier bis zum jüngsten Tag z.B. bei der Version 7.2 bleiben, wenn mir das gefällt. Ich Nicht schrieb: > Entweder finde ich die Einstellung nicht, oder Eagle 6.5 kann z.B. nur > Runde Durchkontaktierungen. Du findest die Einstellung nicht. Das ist Alles. MfG Paul
Dann sag mir wenigstens bitte, wie es geht. (Es geht um die Bohrung, nicht um die Fläche)
Cyborg schrieb: > Sheeva P. schrieb: >> Natürlich ist es immer eine gute Idee, das eigene Gehirn zu benutzen. >> Also, sofern man eines hat und damit umgehen kann. > > Und was bringt jetzt diese abwertende Aussage? Ach, ich hatte irgendwie das Gefühl, daß Du Dich absichtlich blöd stellst. Aber ich hatte das trotzdem nicht abwertend, sondern ganz allgemein als Tipp gemeint. Tut mir leid, daß es anders bei Dir angekommen ist. > Fühlst du dich jetzt besser? Bis auf die fiese Erkältung gehts mir prima, danke der Nachfrage. > Mach dir lieber Gedanken, was andere über DICH denken. Och, nö, das hab' ich mir längst abgewöhnt. Es gibt höchstens zehn Leute auf der Welt, auf deren Meinung über mich ich Wert lege. Und die kennen mich (und meinen Humor) gut genug, um nicht gleich jedes Wort von mir auf die Goldwaage zu legen. ;-) > Sicher bis du auch kein Alleswisser oder -könner. Danke, aber für meine bescheidenen Bedürfnisse reicht es. > Zumindest hab ich mal il Contes Gedankengang aufgegriffen und > hab mal die 4.0.6 installiert. Jetzt verlinkt die Hilfe zu > file:///C:/Programme/KiCad/share/doc/kicad/help/de/kicad.html Na prima, geht doch! Dann steht Dir ja nichts mehr im Wege. Vielleicht magst Du ja später mal einen Erfahrungsbericht ins Forum schreiben? > Sheeva P. schrieb: >> Ansonsten gibt es in Deiner Nähe vielleicht auch eine Windows User Group >> oder einen Windows-Stammtisch mit netten Menschen, die Dir gerne helfen. > > Ist das Forum nicht nah genug? Physisch ist doch so enger Kontakt > gar nicht nötig. Tja, aber zu so einer User Group oder einem Stammtisch kann man seinen Rechner mitnehmen oder umgekehrt einen der Experten, die man dort trifft, nach Hause einladen. Dann kann der das Problem direkt vor Ort lösen, was häufig wesentlich einfacher ist als eine indirekte Assistenz. Persönlicher Kontakt ist IMHO durch nichts zu ersetzen.
il Conte schrieb: > W.S. schrieb: >> Viel Traffic in den Foren heißt hier offenbar, daß das betreffende >> Programm besonders gut sein muß. > > Ganz genau :-)? > So was nennt sich Schwarmintelligenz und die ist unfehlbar :-)? > So Leute wie du mit einer abweichenden Meinung sind halt > 'statistische Ausreiser' das muss man halt erdulden :( ☹️ Töröh! Genau! Die Schwarm-Intelligenz war's! Hätt ich gleich drauf kommen sollen - auf den Schwarm. Gottseidank ist noch nicht Sommer, da halten sich die Fliegenschwärme noch in Grenzen... nein, ich führe jetzt nicht bis zum logischen Ende aus, wo sich Fliegen am liebsten versammeln. Leute, ihr redet euch ja immer noch die Köpfe heiß. Davon wird Kicad auch bloß nicht besser. Sheeva P. schrieb: > Daß Du dagegen bist, ist für mich eine starke Empfehlung. Also... > Daher: vielen Dank! Bitte sehr, gern geschehen. Eagle als professionelle Alternative hast du ja ohnehin nicht mehr, sofern du das neue Lizenzmodell nicht annehmen willst. Stefan S. schrieb: > Und gerade das Trennen von > Schaltplansymbolen und Footprints oder andere schöne Dinge sind wirklich > eine Verbesserung gegenüber Eagle. Du hast es noch immer nicht verstanden. Auch bei Eagle sind Symbole und Footprints getrennte Dinge. Verbunden sind sie über Devices, die den tatsächlich existierenden Bauelementen entsprechen. Aber im krassen Gegensatz zu Kicad sind bei Eagle diese Verbindungen in den Bibliotheken enthalten, so daß man sicher sein kann, daß zumindest bei einer geprüften und als richtig befundenen Bibliothek diese Zuordnung korrekt ist - ohne daß man sich im Projekt darum kümmern müßte. Uhu U. schrieb: > Und was mast du, wenn es das Teil in verschiedenen Bauformen gibt? > Jedesmal den Schaltplan neu zeichnen? > > Nein, die Trennung ist schon in Ordnung. Nein, ist sie nicht. Wenn es das Teil in verschiedenen Bauformen gibt, dann wählt man bei Eagle einfach die andere Version aus. Dazu gibt es nämlich die Varianten in den Libs. Die Gegenfrage wäre hier viel eher zu diskutieren: Was machst du denn, wenn zu einem Bauteil und damit einem Footprint mehrere Symbole gehören? Wie ordnest du dann (nach Doku) den Footprint dem Symbol zu? Umgekehrt wäre es in Ordnung, aber so herum ist es Bockmist. Stell dir bloß mal einen 7400 oder einen Vierfach-OpV vor. Hier argumentieren immerzu die Ahnungslosen, daß sie ihren Schaltplan zunächst mit generischen Bauteilen anfangen und das Umsetzen auf echte Bauteile auf später verschieben wollen und daß das gut sei. Nein, das ist Mumpitz, richtig großer Mumpitz. Wer sich schon mal die Pinouts aktueller Bauteile angeschaut hat, der sieht ganz klar, daß es für viele reale Bauteile eben keine generischen Bauteile gibt. Die Zeit des µA709 ist vorbei und heutige OpV's zum Beispiel haben bei gleichem Footprint unterschiedliche Pinouts. Das führt ins Chaos, wenn man am Anfang mal eben mit irgendeinem Symbol anfängt und sich sagt, daß man den konkreten Typ ja erst später festlegen will. Und die OpV's sind nur ein Beispiel von vielen. Kurzum, es ist schon so, daß man nicht nur seine Schaltung zuvor planen muß, sondern auch die korrekten Bauteile dabei einplanen muß und das führt dazu, daß man in den Schaltplan eben nicht irgendwelche Symbole einfügen darf, sondern konkrete Bauteile, die natürlich auch ihren konkreten Footprint und ihre (mehrere) Symbole haben. Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. W.S.
W.S. schrieb: > Hier argumentieren immerzu die Ahnungslosen, daß sie ihren Schaltplan > zunächst mit generischen Bauteilen anfangen und das Umsetzen auf echte > Bauteile auf später verschieben wollen und daß das gut sei. Nein, das > ist Mumpitz, richtig großer Mumpitz. Ich kann dein Verbohrtheit einfach nicht kapieren :( Du könntest doch mal eine andere Meinung auch mal stehen lassen. Stattdessen führst du dich hier auf wie das Rumpelstilzchen :-( Auf der anderen Seite wenn man deine Beiträge zu Embedded HW und SW liest, gibt es da durchaus Beiträge von dir, denen man beipflichten kann. Wie gesagt ich verstehe dein Verhalten nicht. W.S. schrieb: > Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. Damit machst du dir nur Feinde, bei mir löst sowas nur Sarkasmus-Spott aus. (siehe dein Eingangs Zitat oben)
Gustav schrieb im Beitrag #4939546: [..] > > Wieviele von denen die "alle Sourcen haben" können damit wirklich was > anfangen? Ich z.B... ich habe mich gerade erst wieder drum gekümmert das es auf FreeBSD läuft und in den Sourcen herumgemurkst. Wird Dich nicht anheben weil Dich wahrscheinlich FreeBSD auch nicht interessiert. > >> OpenSource-Projekte, die öffentlich gehostet werden, können eben nicht >> so einfach verschwinden. > > Eagle wird auch nicht verschwinden. Bei Eagle ist das anders aus meiener Sicht..es war immer verschwunden. 2 Layer mit 50x80 waren keine Option ..und ich möchte Platinen manchmal verkaufen (oder besser das Design). > >> Man ist auch nicht auf irgendeinen Lizenzserver oder auch nur >> Internetverbindung angewiesen, damit KiCad arbeitsfähig ist. > > Internet ist allgegenwärtig. Eagle etwa fragt den Server alle 14 Tage... Ja.. und Du hast nichts zu verbergen, ich weiß... Gruß, Holm
Gustav schrieb im Beitrag #4939580: > Chris D. schrieb: >> Solange der Lizenzserver lebt > > Das könnte ein einziges Argument gegen Subskription-Eagle sein. Ich > sehe bloß weit und breit keinen technischen oder organisatorischen > Grund, warum der Server sein Leben für bedeutsame Zeit aushauchen > sollte. Daß unser Leben aber heute immer mehr vom Funktionieren der > Technik abhängt ist jetzt nichts speziell Lizenzserver-spezifisches. Ich habe noch Eins: Woher weißt Du was der Lizenzserver da von Deiner Mühle zieht? Du weißt, dass er sich um die Lizensierung kümmert (auf eine unbekannte nicht dokumentierte Weise). Was weißt Du noch? Willichnich. > >> Davon abgesehen hat KiCad eben auch einige Sachen wie PnS anzubieten, >> die Eagle nicht hat. Da kann es durchaus sinnvoll sein, sich >> umzustellen. > > Eagle ist in großen Schritten dabei aufzuholen. Schon die aktuelle 8.1 > angeschaut? Und..warum sollte man den Nachahmer benutzen wollen? Mekrst Du nicht das Deine Argumentation völliger Käse ist? Gruß, Holm
Also ich finde die generischen Bauteile bei Widerständen, Kondensatoren und Spuelen sehr praktisch. Allerdings wüsste ich nicht, was einen daran hindert, selbst die Bauteile korrekt zu erstellen und diesen ein Footrpint zuzuweisen. Ich selbst nutze außer bei den genannten Teilen auch nur fest definierte Bauteile. Und bei diesen Bauteilen ist auch ein Footprint zugewiesen. Ich verstehe daher gerade die ganze Diskussion nicht, da beide Möglichkeiten in KiCad bestehen. Jeder kann es so nutzen wie er will. Und falls jemand Eagle/KiCad/Dipttrace/Altium/Circuitstudio/Pulsonix/PCAD/PADS usw. benutzen will, so hällt ihn doch nichts davon ab. Aber mann muss deswegen nicht die Nutzer von anderen Programmen persöhnlich angreifen.
Gustav schrieb im Beitrag #4939580: > Solange der Lizenzserver lebt > > Das könnte ein einziges Argument gegen Subskription-Eagle sein. Ich > sehe bloß weit und breit keinen technischen oder organisatorischen > Grund, warum der Server sein Leben für bedeutsame Zeit aushauchen > sollte. Es passiert aber, dass Lizenzserver abgeschaltet werden oder ältere Programm-Versionen nicht mehr unterstützt werden. Ein Schelm wer Böses dabei denkt - money rules the world. mfg Olaf
Ich muss mich an einer Stelle korrigieren: Ich verwende in KiCand entsprechende Footprintfilter als Zuweisung.
Paul B. schrieb: > Chris D. schrieb: >> Es ging Paul ja auch ums Verschwinden - und solange ich >> hier die Sourcen habe, kann das Projekt eben nicht verschwinden :-) > > Ja, ist ja Alles chic (um mal die Worte meiner Nachbarin zu nutzen). > Die Frage ist doch. WER zwingt die Leute, eine neue Version von > Eagle zu benutzen und sich mit dem Lizenzserver zu beharken? > > Ich kann doch hier bis zum jüngsten Tag z.B. bei der Version 7.2 > bleiben, wenn mir das gefällt. [..] > > MfG Paul Na Paul ist doch ok. Das ist doch das worüber ich schrieb das ich mich amüsiere. Bleib einfach dabei bis Microsoft Dein Windows von Weitem ausmacht, denn das das passieren wird ist Fakt wie da Amen in der Kirche. (Trouble um Kaby-Lake und Win 7/8 Updates zwecks Win10 Durchsetzung..). ..aber ich emuliere auch für verschiedene Sachen XP oder gar Dos in einer VM.. Das Problem ist doch aber genau anders herum: Hier schreibt Jemand "KiCad im Kommen" ..und dann gibts die Eagle Freaks die mit "Das darf nicht sein, Eagle fetzt und KiCad ist blöd" um sich werfen. Nimm doch Eagle..aber laß Andere KiCad ausprobieren. Gruß, Holm
Ich Nicht schrieb: > Aber mann muss > deswegen nicht die Nutzer von anderen Programmen persöhnlich angreifen. Wenn du damit W.S meinst, dann würde ich das nicht auf die Goldwaage legen - der ist halt so. (da gibt es bei weitem schlimmere Gesellen hier im Forum)
W.S. schrieb: > il Conte schrieb: >> W.S. schrieb: [..] > > Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. > > W.S. Sachma...Du bist ja bekanntermaßen manchmal etwas schwer von Begriff, das hatten wir ja schon mal geklärt (Lochbandkapazität)... Warum kannst Du mit diesem Wissen nicht einfach akzeptieren das Andere Leute anderer Ansicht als Du sein können und wollen ? Auf gut Deutsch..damit es auch bei Dir ankommt: Du gehst mir mit diesem blöden Argument nun schon mindestens ein knappes Jahr wiederholt gehörig auf den Wecker, eben weil ich das begründet anders sehe als Du. Du kannst Doch Dein Super-Eagle benutzen wie Du willst und damit glücklich werden, aber kannst Du es bitte final lassen die Arbeit Anderer regelmäßig mit dem selben dümmlichen Argument in den Dreck zu ziehen? Danke! Holm
il Conte schrieb: > W.S. schrieb: >> Hier argumentieren immerzu die Ahnungslosen, daß sie ihren Schaltplan >> zunächst mit generischen Bauteilen anfangen und das Umsetzen auf echte >> Bauteile auf später verschieben wollen und daß das gut sei. Nein, das >> ist Mumpitz, richtig großer Mumpitz. > > Ich kann dein Verbohrtheit einfach nicht kapieren :( > Du könntest doch mal eine andere Meinung auch mal stehen lassen. > Stattdessen führst du dich hier auf wie das Rumpelstilzchen :-( > > Auf der anderen Seite wenn man deine Beiträge zu Embedded HW und SW > liest, gibt es da durchaus Beiträge von dir, denen man beipflichten > kann. > Wie gesagt ich verstehe dein Verhalten nicht. > > W.S. schrieb: >> Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. > > Damit machst du dir nur Feinde, bei mir löst sowas nur > Sarkasmus-Spott aus. (siehe dein Eingangs Zitat oben) Das kann ich vollumfänglich unterschreiben. Gruß, Holm
Holm T. schrieb: > Hier schreibt Jemand "KiCad im Kommen" ..und dann gibts die Eagle Freaks > die mit "Das darf nicht sein, Eagle fetzt und KiCad ist blöd" um sich > werfen. Dazu gehöre ich nicht und habe mich auch nicht in dieser Richtung geäußert > Nimm doch Eagle..aber laß Andere KiCad ausprobieren. Das mach ich doch. Ich habe nur den Eindruck, daß eine panikartige Reaktion um sich greift. /Ironie Das läßt mich eine gewisse Ruhe und Gelassenheit, wie ich sie sonst von den Forenteilnehmern kenne, vermissen. :)) MfG Paul
Holm T. schrieb: > W.S. schrieb: >> il Conte schrieb: >>> W.S. schrieb: > [..] >> >> Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. >> >> W.S. Ich hoffe mal du meinst bei deinem Zitaten-Wirrwarr nicht mich :-( ?
il Conte schrieb: > Ich hoffe mal du meinst bei deinem Zitaten-Wirrwarr nicht mich :-( ? @Holm Hat sich mit deinem letzten Beitrag erledigt.
Holm T. schrieb: > bis Microsoft Dein Windows von Weitem ausmacht Und hier haben wir direkt Anschauungsmaterial, wie sowas abläuft: Windows 7 und 8.1: Keine Windows Updates mit neuen Prozessoren https://www.heise.de/newsticker/meldung/Windows-7-und-8-1-Keine-Windows-Updates-mit-neuen-Prozessoren-3656807.html Also wenn das Mainboard mit dem alten, aber bezahlten und nicht mehr erhältlichen Prozessor den Löffel wirft, dann wirds richtig spaßig... Gustav schrieb im Beitrag #4939580: > Ich sehe bloß weit und breit keinen technischen oder organisatorischen > Grund, warum der Server sein Leben für bedeutsame Zeit aushauchen > sollte. Daß unser Leben aber heute immer mehr vom Funktionieren der > Technik abhängt ist jetzt nichts speziell Lizenzserver-spezifisches. Ich schon: heute hat hier in der Gegend ein Bagger ein dickes Kabel geschreddert und 30.000 Anschlüsse haben weder Internet noch Telefon - der Lizenzserver für Eagle ist dann natürlich auch nicht mehr erreichbar...
il Conte schrieb: > Holm T. schrieb: >> W.S. schrieb: >>> il Conte schrieb: >>>> W.S. schrieb: >> [..] >>> >>> Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. >>> >>> W.S. > > Ich hoffe mal du meinst bei deinem Zitaten-Wirrwarr nicht mich :-( ? ..das weißte doch selber besser, oder? :-) Gruß, Holm
Grundsätzlich soll doch jeder die Software benutzen, die ihm gefällt, mit der er zurecht kommt und die das macht, was er will/braucht. Nun kann ich ja noch verstehen, dass Leute, die FOSS nutzen, versuchen, auch Andere dafür zu begeistern. Immerhin bedeutet dort eine größere Community auch mehr Contributions und mehr Entwicklung. OK. Aber was zur Hölle treibt Leute dazu, die eine kommerzielle Software benutzen, - andere missionieren zu wollen? - in einem KiCAD Thread von Eagle zu posten? - kommerzielle Software als "professionell" zu bezeichnen? - etc. pp. Glauben die etwa, dass ihre Lizenzgebühren billiger werden? Oder haben die Angst, dass der Hersteller ihrer geliebten "professionellen" Software untergeht und sie sich in etwas Neues einarbeiten müssten, was ihnen offenbar sehr schwer fällt oder sie so viel Zeit kostet, dass sie es als signifikante Verschwendung von Lebenszeit empfinden (geht Euch das eigentlich bei jeder Art von Lernen so?)? Oder ist das einfach dieser Drang zur Rechtfertigung einer (monetären) Investition, die ja nicht falsch sein darf, nachdem man sie bereits getätigt hat? Überhaupt, wenn ich oben so lese, was da alles als absolut "falsch" bezeichnet wird, dabei jedoch höchstens relative Bedeutung hat und mindestens Ansichtssache ist... da möchte man nicht glauben in einem naturwissenschaftlich/technisch orientierten Forum unterwegs zu sein. War nicht irgendwann mal "wahr" und "falsch" etwas unabhängig Überprüfbares, Beweisbares, unabhängig von der Person des Betrachters?
Ich oute mich mal als einer, der Eagle überhaupt nicht kennt. (Ich masse mir deswegen auch nicht an, zu sagen, KiCad sei besser.) Die Fragen in diesem Post sind denn auch nicht rhetorisch. W.S. schrieb: > Hier argumentieren immerzu die Ahnungslosen, daß sie ihren Schaltplan > zunächst mit generischen Bauteilen anfangen und das Umsetzen auf echte > Bauteile auf später verschieben wollen und daß das gut sei. Nein, das > ist Mumpitz, richtig großer Mumpitz. > > Wer sich schon mal die Pinouts aktueller Bauteile angeschaut hat, der > sieht ganz klar, daß es für viele reale Bauteile eben keine > generischen Bauteile gibt. Richtig, sehr viele Bauteile sind heute nicht mehr "generisch". Aber einige sind es doch noch. Das Hühnerfutter im Wesentlichen. Bei denen macht der generische Ansatz also durchaus Sinn. Du sagst, es sei Mumpitz, das Bauteil generisch zu betrachten. Wie ist das denn nun bei Eagle? Ist ein Widerstand mit 5.1kOhm ein anderes Libraryelement als ein Widerstand mit 6.8kOhm? Ich nehme es nicht an, aber ich habe schon mit Tools gearbeitet, bei denen es so war (resp. mit derart aufgebauten Libs). Diese "Devices": Sind das logische Elemente, die Schemasymbole und Footprints (und Anderes?) referenzieren? Und ist jeweils nur ein Element referenziert oder gibt es eine Auswahl? Ich frage, weil ich mir nicht sicher bin, ob der konzeptionelle Unterschied wirklich so massiv ist wie einige glauben.
:
Bearbeitet durch User
np r. schrieb: > Aber was zur Hölle treibt Leute dazu, die eine kommerzielle Software > benutzen, > […] > - in einem KiCAD Thread von Eagle zu posten? Guck mal bei Windowsfragen. Ständig muss da jemand mit Linux trollen. np r. schrieb: > Aber was zur Hölle treibt Leute dazu, die eine kommerzielle Software > benutzen, > […] > - kommerzielle Software als "professionell" zu bezeichnen? Weil sie das im Allgemeinen ist.
Noch was zur Aussage, dass generisches Schaltplandesign Mumpitz sei, in Anlehnung an meine Frage oben: Wenn ich eine Schaltung entwickle, muss ich a priori für jeden Widerstand genau wissen, welchen Wert er hat. 5.1 oder 6.8kOhm. Einfach mal einen Widerstand setzen und später mal durchrechnen, wie gross der sein soll, ist Mumpitz. Denn dann wäre der Widerstand ja generisch. Kicad, und sicher auch Eagle, erlaubt es, mit Bibliotheken zu arbeiten, bei denen Art.Nr. 132309984 (5.1kOhm Widerstand) von xyz.com ein Schemaelement mit zugehörigem Footprint ist. Wenn man später doch lieber Art.Nr. 132309985 (6.8kOhm) einsetzen will, löscht man das Bauteil und setzt es neu. Kann man so machen. Grosse Firmen machen es oft so. Ich nehme jetzt einfach mal an, der übliche Workflow bei Eagle ist aber nicht so streng. Voila. Auch bei Eagle hat man wohl eine gewisses "generisches Vorgehen". Man kann jetzt streiten, wie viel "Generik" gut ist. Und da seine Ansichten anbringen. Aber zu sagen, dass ein generischer Ansatz per se Mumpitz sei, ist.... Ja. eben. Mumpitz. Nachtrag: Wenn wir uns aber darauf einigen, dass es durchaus Sinn macht, den WERT mal generisch zu lassen, dann frage ich mich, warum es Teufelszeug sein soll, aufgrund dieses Wertes eventuell später den Footprint festzulegen. Denn vom Wert hängt dieser oft ab (bei Kondis). Wenn ich den Wert ändere, darf ich das ohne Bauteiltausch. Aber nicht, wenn ich den Footprint ändere?
:
Bearbeitet durch User
...die Ansicht ist ja auch Müll. An der Schaltung ändert sich Nichts, egal ob ich einen 74HCT00 in DIL14 oder in SO14 einsetze, oder aber einen BC556 in TO92 oder BC856 in SOT23 und ein 1K Widerstand sieht in der Schaltung gleich aus, egal ob in THT oder 0603. (Verlustleistungen und zulässige Betriebsspannungen mal außen vor). ..trotzdem wird W.S. nicht müde immer wieder die selbe olle Kamelle aufzuwärmen, er kann ja von mir aus nach seiner Fasson glücklich werden, aber Leute die nicht seiner Meinung sind als "zu doof" zu verunglimpfen geht mir ein Stück zu weit. Gruß, Holm
Dussel schrieb: > Guck mal bei Windowsfragen. Ständig muss da jemand mit Linux trollen. Wie gesagt, ich kann ja noch verstehen, wenn jemand für eine FOSS-Community werben will. Das macht ja Sinn. Da kann man ja noch ein gewisses Mitdenken unterstellen. Aber wieso, aus welchem vernünftigen Grund würde irgendjemand, der nicht bei MS angestellt ist, in einem Linux-Thread mit Windows trollen? Da muss doch irgendetwas nicht ganz richtig verschaltet sein... Dussel schrieb: > - kommerzielle Software als "professionell" zu bezeichnen? > Weil sie das im Allgemeinen ist. Ah ja - SuperMario für die "professionellen" Zocker? Und Apache, Firefox, gcc, PostgreSQL, RasMol, LAMMPS, CP2K zum Spielen für die "Amateure"? Du kennst Dich aber nicht gut mit Software, Computern und so'n Zeugs aus, oder?
Simon H. schrieb: > Nachtrag: Wenn wir uns aber darauf einigen, dass es durchaus Sinn macht, > den WERT mal generisch zu lassen, dann frage ich mich, warum es > Teufelszeug sein soll, aufgrund dieses Wertes eventuell später den Ich sag nicht, dass es Teufelszeug ist, aber Stolpersfallen lauern dabei doch, bspw gibt es Transistoren im gleichen Gehaeuse einmal in BCE-Belegung und einmal in CBE. Waehlt man den falschen Footprint, dann hat man den Salat. Vielleicht ist das auch in der Praxis nicht relevant, aber ein Gefuehl der Unsicherheit war bei mir schon da. Aber das ist eine konzeptuelle Festlegung, die ihre gutem Gruende hat und in der Kosten-Nutzen-Abwaegung sicherlich gut dasteht. Bei Eagle zum Beispiel ist es mir mal passiert ein zu Anfang des Projektes verwendetes Dummy-Symbol "vergessen" zu haben. Auf den fehlenden Footprint wurde ich nicht mehr hingewiesen...
Dussel schrieb: > Weil sie das im Allgemeinen ist. Wenn das ja hier die Strickcommunity wäre oder Erikas Esoterik-Zirkel - aber in einem naturwissenschaftlich-technischen Forum so ein leerer Allgemeinplatz?
np r. schrieb: > Dussel schrieb: >> Guck mal bei Windowsfragen. Ständig muss da jemand mit Linux trollen. > > Wie gesagt, ich kann ja noch verstehen, wenn jemand für eine > FOSS-Community werben will. > Aber wieso, aus welchem vernünftigen Grund würde irgendjemand, der nicht > bei MS angestellt ist, in einem Linux-Thread mit Windows trollen? Naja, ein Forum ist doch dazu da, a) Hilfe von Anderen zu bekommen b) Anderen zu helfen (gibts tatsaechlich~) c) Seine Meinung Kund zu tun (meistens) Wenn jemand ueberzeugt von einem Produkt ist, dann wird er es eben im Rahmen von b) und c) bewerben.
Feldstecher schrieb: > Ich sag nicht, dass es Teufelszeug ist, aber Stolpersfallen lauern dabei > doch, bspw gibt es Transistoren im gleichen Gehaeuse einmal in > BCE-Belegung und einmal in CBE. Waehlt man den falschen Footprint, dann > hat man den Salat. Ja, das ist ein Argument. Ich meine mich zu erinnern, dass in einer uralten Version von Protel in den Standard-Libraries eine Diskrepanz zwischen den Schemasymbolen und den Footprints der Dioden bestand. Nicht so schlimm, dass es eine Verwechslung gab, sondern Pinnummern 1 und 2 im Schemasymbol, sowie Pinnummern (sic!) A und K im Footprint. Aber über Protel resp. Altium reden wir ja nicht. Das Grundproblem existiert, da hast Du recht. Ich bin halt einer der paranoiden Anwender, die (abgesehen vielleicht vom Hühnerfutter) grundsätzlich nur eigene Libraries benutzt. Nicht, dass ich alles immer selber zeichne, aber ich kopiere sie in meine persönliche Library rein und überprüfe sie einzeln. Und bei Transistoren habe ich tatsächlich gerne Footprints, welche explizit dem Transistor zugeordnet sind. Genau aus diesem Grund
:
Bearbeitet durch User
Simon H. schrieb: > Wenn ich eine Schaltung entwickle, muss ich a priori für jeden > Widerstand genau wissen, welchen Wert er hat. 5.1 oder 6.8kOhm. Einfach > mal einen Widerstand setzen und später mal durchrechnen, wie gross der > sein soll, ist Mumpitz. Denn dann wäre der Widerstand ja generisch. > > Kicad, und sicher auch Eagle, erlaubt es, mit Bibliotheken zu arbeiten, > bei denen Art.Nr. 132309984 (5.1kOhm Widerstand) von xyz.com ein > Schemaelement mit zugehörigem Footprint ist. Wenn man später doch lieber > Art.Nr. 132309985 (6.8kOhm) einsetzen will, löscht man das Bauteil und > setzt es neu. Kann man so machen. Grosse Firmen machen es oft so. Bitte befasse dich doch etwas mit EAGLE! Es nutzt nichts, über etwas zu zelebrieren, was man nicht kennt. Man kann jederzeit die Bezeichnung und den Wert eines Bauelementes ändern. W.S. schrieb: > Uhu U. schrieb: >> Und was mast du, wenn es das Teil in verschiedenen Bauformen gibt? >> Jedesmal den Schaltplan neu zeichnen? >> >> Nein, die Trennung ist schon in Ordnung. > > Nein, ist sie nicht. Wenn es das Teil in verschiedenen Bauformen gibt, > dann wählt man bei Eagle einfach die andere Version aus. Dazu gibt es > nämlich die Varianten in den Libs. So ist es. Warum kommen hier Kikad Vertreter immer wieder mit solchen falschen Behauptungen? Und dann noch so aggresiv? Holm T. schrieb: > ..die Ansicht ist ja auch Müll. An der Schaltung ändert sich Nichts, > egal ob ich einen 74HCT00 in DIL14 oder in SO14 einsetze, oder aber > einen BC556 in TO92 oder BC856 in SOT23 und ein 1K Widerstand sieht in > der Schaltung gleich aus, egal ob in THT oder 0603. > > (Verlustleistungen und zulässige Betriebsspannungen mal außen vor). > > ..trotzdem wird W.S. nicht müde immer wieder die selbe olle Kamelle > aufzuwärmen, er kann ja von mir aus nach seiner Fasson glücklich werden, > aber Leute die nicht seiner Meinung sind als "zu doof" zu verunglimpfen > geht mir ein Stück zu weit. Und du solltest dich auch zurücknehmen, weil es einfach falsch ist, was du behauptest.
michael_ schrieb: [..] > > Und dann noch so aggresiv? > > Holm T. schrieb: >> ..die Ansicht ist ja auch Müll. An der Schaltung ändert sich Nichts, >> egal ob ich einen 74HCT00 in DIL14 oder in SO14 einsetze, oder aber >> einen BC556 in TO92 oder BC856 in SOT23 und ein 1K Widerstand sieht in >> der Schaltung gleich aus, egal ob in THT oder 0603. >> >> (Verlustleistungen und zulässige Betriebsspannungen mal außen vor). >> >> ..trotzdem wird W.S. nicht müde immer wieder die selbe olle Kamelle >> aufzuwärmen, er kann ja von mir aus nach seiner Fasson glücklich werden, >> aber Leute die nicht seiner Meinung sind als "zu doof" zu verunglimpfen >> geht mir ein Stück zu weit. > > Und du solltest dich auch zurücknehmen, weil es einfach falsch ist, was > du behauptest. Danke, ebenso. Wenn mich nicht alles täuscht schrieb Jörg in einem anderen Posting das die Vorgehensweise bei Altium die selbe wie bei KiCad ist. Ist Altium jetzt auch Schrott? Eagle das einzig Wahre? Geht in die Kneipe, laßt eure Weisheiten und Euren Frust dort ab und ersäuft ihn anstatt uns hier mir dem immer selben Käse zu zu lamentieren. Gruß, Holm
michael_ schrieb: > Bitte befasse dich doch etwas mit EAGLE! > Es nutzt nichts, über etwas zu zelebrieren, was man nicht kennt. > Man kann jederzeit die Bezeichnung und den Wert eines Bauelementes > ändern. Warum sollte ich? Ich bin zufrieden mit KiCad. Wenn Du meinen Post nur wenig weiter oben gelesen hättest, hättest Du gesehen, dass ich mir NICHT anmasse, zu sagen, KiCad sei besser als Eagle. Und auch, dass ich geschrieben habe, dass ich nicht vermute, dass Eagle das nicht zulässt. Darum ging es aber nicht. Sondern um die Aussage, dass es schlecht sei, generische Bauteile zu haben. Diese Aussage würde bedeuten, dass auch Eagle (als gutes Programm, welches so Teufelszeug nicht macht) eine Wertänderung eben NICHT zulassen sollte. Ich argumentierte nicht gegen Eagle. Sondern gegen einige Eagle-Nutzer, die nicht über den Tellerrand hinausschauen können oder wollen und schreiben, dass jeder, der ein Tool verwendet, das ein bisschen anders funktioniert, ein Bastler und/oder ein Idiot sei. michael_ schrieb: > Holm T. schrieb: >> ..die Ansicht ist ja auch Müll. An der Schaltung ändert sich Nichts, >> egal ob ich einen 74HCT00 in DIL14 oder in SO14 einsetze, oder aber >> einen BC556 in TO92 oder BC856 in SOT23 und ein 1K Widerstand sieht in >> der Schaltung gleich aus, egal ob in THT oder 0603. >> >> (Verlustleistungen und zulässige Betriebsspannungen mal außen vor). >> >> ..trotzdem wird W.S. nicht müde immer wieder die selbe olle Kamelle >> aufzuwärmen, er kann ja von mir aus nach seiner Fasson glücklich werden, >> aber Leute die nicht seiner Meinung sind als "zu doof" zu verunglimpfen >> geht mir ein Stück zu weit. > > Und du solltest dich auch zurücknehmen, weil es einfach falsch ist, was > du behauptest. Welche Aussage ist nun falsch? Dass er sie verunglimpt? Nein, ist nicht falsch. Oder die andere Meinung über ein sinnvolles Vorgehen bei der Bauteil-Footprint-Zuordnung? Genau das meinte ich weiter oben. :-) Nachtrag: Sogar im SELBEN Post schrieb ich, dass ich davon ausgehe, dass Eagle das zulässt. Also bitte. Wenn Du mit mir diskutieren willst, dann lies wenigstens das komplett durch, was Du dann ansprichst. Sonst kann man das nicht so recht ernst nehmen. michael_ schrieb: >> Nein, ist sie nicht. Wenn es das Teil in verschiedenen Bauformen gibt, >> dann wählt man bei Eagle einfach die andere Version aus. Dazu gibt es >> nämlich die Varianten in den Libs. > > So ist es. > Warum kommen hier Kikad Vertreter immer wieder mit solchen falschen > Behauptungen? > > Und dann noch so aggresiv? Aggressiv? Also wenn ich den Thread revuepassiere, ist der Tenor in etwa so, dass einige "Eagle-Jünger" alle, die (nicht mal Eagle schlechtreden, sondern bloss) sagen, dass KiCad durchaus eine prüfenswerte Alternative ist, selbige als Bastler und Idioten abtun. Die KiCad-Jünger auf der anderen Seite, die.... gibt es eigentlich gar nicht. Nur solche, die sagen, dass KiCad seine Schwächen hat, aber eigentlich ein sehr gutes Tool ist. Und dazu kostenlos. Und erwiesenermassen einiges kann (namentlich PnS), das Eagle nicht kann. Die Polemik von der "KiCad-Fraktion" richtet sich kaum gegen Eagle, sondern gegen die Reaktion einiger "Eagler". Und zeige mir doch mal, wo obiges behauptet wurde. Es ist im Gegenteil genau andersrum. Niemand hat hier je behauptet, dass Eagle schlecht sei, weil man sich auf einen Footprint festlegen muss. Wohl aber wurde wiederholt nicht nur bemängelt sondern arrogant belächelt, dass KiCad eine solche Festlegung nicht zulasse - obwohl das ebenfalls wiederholt, einmal sogar mit Bildchen, widerlegt wurde. Einerseits wurde diese Tatsache konsequent ignoriert, und andererseits wurde jeder als Idiot diskreditiert, der schrieb, dass die Nicht-Festlegung zu Beginn durchaus ihre Berechtigung haben kann... Und jetzt kommst Du und schreibst, die bösen KiCad-Menschen verbreiten Lügen, dass Eagle nicht könne, was aber ja offenbar eh nicht gemacht werden darf.... Also was denn nun? Also, ich denke man kann folgende Tatsachen zusammenfassen: 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. Sind alle damit einverstanden?
:
Bearbeitet durch User
Cyborg schrieb: > Sicher bis du auch kein Alleswisser oder -könner. Doch! Er stellt die anderen immer als ein biss'l blöd dar. Man sollte dies einfach ignorieren er wird sich nicht ändern.
Angehängte Dateien:
-
AK_b03.png
18 KB
Feldstecher schrieb: > Simon H. schrieb: >> Nachtrag: Wenn wir uns aber darauf einigen, dass es durchaus Sinn macht, >> den WERT mal generisch zu lassen, dann frage ich mich, warum es >> Teufelszeug sein soll, aufgrund dieses Wertes eventuell später den > Ich sag nicht, dass es Teufelszeug ist, aber Stolpersfallen lauern dabei > doch, bspw gibt es Transistoren im gleichen Gehaeuse einmal in > BCE-Belegung und einmal in CBE. Waehlt man den falschen Footprint, dann > hat man den Salat. Vielleicht ist das auch in der Praxis nicht relevant, > aber ein Gefuehl der Unsicherheit war bei mir schon da. Um den 'Salat' schmackhafter zu machen, hier ein Vorschlag falls es jemand noch nicht kennt. (gilt für KiCAD) Es ist doch so dass man beim Erstellen eines Schaltplan-Symbols Zahlen zur Pin-Nummerierung benutz, weil es halt so gängig ist oder weil es mit Copy und Paste passiert. Es gehen aber auch Buchstaben zur Pin-Nummerierung!! Im Fall einer Diode wäre es dann 'A' und 'K' das gleiche macht man dann auch konsequenter weise bei der Erstellung des Footprintes an Hand des Datenblattes. Das Besagt gilt dann ebenso für Transistoren und FETs. Man muss lediglich einmal bei der Footprintgestaltung aufpassen, dann gibt es hinterher keine Probleme. Und das Schöne am KiCAD ist eben, dass man einem Symbol später alle möglichen Bauformen zuordnen kann.?? Ich möchte nicht wissen wie oft es schon 'Dioden - Verdreher' wegen der der blöden 1 - 2 Nummerierung gegeben hat.?
np r. schrieb: > Aber was zur Hölle treibt Leute dazu, die eine kommerzielle Software > benutzen, > - andere missionieren zu wollen? > - in einem KiCAD Thread von Eagle zu posten? > - kommerzielle Software als "professionell" zu bezeichnen? Das habe ich oben schon angedeutet, die psychologischen Mechanismen nennen sich "Selbstrechtfertigung" und "Eskalierendes Commitment". Diese Menschen haben Geld und Zeit in ihre Software investiert, und jetzt kommt plötzlich einer um die Ecke und bietet eine ganz ähnliche Software kostenlos an. Das führt bei denen, die ihr gutes Geld dafür ausgegeben haben, dann zu einer kognitiven Dissonanz: daß sie eine schlechte Entscheidung getroffen und ihr Geld verschwendet haben, kann und darf einfach nicht sein. Deswegen müssen diese Menschen ihre Entscheidung dann rechtfertigen, indem sie die eigene Software als so viel besser darstellen und die Alternative heruntermachen, daß die Ausgabe wieder als lohnenswert erscheint. Das sind übrigens keine pathologischen Verhaltensmuster, sondern das ganz normale Verhalten von psychisch gesunden Menschen. Nicht daß man mir noch unterstellt, ich wolle irgendwen als psychisch krank darstellen. Dieses Störfeuer ist für Leute, die über die kostenlose Alternative reden wollen, zwar nervig -- aber andererseits ist das ein Indiz für die hohe Leistungsfähigkeit der Alternative. Denn wenn die Alternative so schlecht wäre, wie sie den Geldausgebern geredet wird, wäre es doch offensichtlich, daß deren Ausgabe gerechtfertigt war. Gegen die Alternative zu pöbeln ist lediglich dann notwendig, wenn die Unterschiede in der Leistungsfähigkeit gerade nicht offensichtlich sind. Insofern: Ruhe bewahren, nicht ärgern. Wie Gandhi sagte: first they ignore you, then they laugh at you, then they fight you, and then you win. ;-)
:
Bearbeitet durch User
np r. schrieb: > Dussel schrieb: >> - kommerzielle Software als "professionell" zu bezeichnen? >> Weil sie das im Allgemeinen ist. > > Ah ja - SuperMario für die "professionellen" Zocker? > Und Apache, Firefox, gcc, PostgreSQL, RasMol, LAMMPS, CP2K zum Spielen > für die "Amateure"? np r. schrieb: > Dussel schrieb: >> Weil sie das im Allgemeinen ist. > > Wenn das ja hier die Strickcommunity wäre oder Erikas Esoterik-Zirkel - > aber in einem naturwissenschaftlich-technischen Forum so ein leerer > Allgemeinplatz? Das scheint dich ja sehr zu beschäftigen, wenn du direkt in zwei Beiträgen darauf eingehen musst. np r. schrieb: > Du kennst Dich aber nicht gut mit Software, Computern und so'n Zeugs > aus, oder? Ich muss mich dir geschlagen geben. Gegen so eine durchdachte und hochqualitative Argumentation komme ich natürlich nicht an. (Falls du es nicht verstehst, das war Ironie, Sarkasmus oder sowas ähnliches)
il Conte schrieb: > Im Fall einer Diode wäre es dann 'A' und 'K' das gleiche macht man dann > auch konsequenter weise bei der Erstellung des Footprintes an Hand des > Datenblattes. > Das Besagt gilt dann ebenso für Transistoren und FETs. > Man muss lediglich einmal bei der Footprintgestaltung aufpassen, > dann gibt es hinterher keine Probleme. Ein sehr guter Tipp!
Dussel schrieb: > Das scheint dich ja sehr zu beschäftigen, Ja, seit meiner Kindheit beschäftigt mich neben den Naturwissenschaften auch das Wesen des menschlichen Denkens. Besonders dann, wenn es völlig erratisch und nicht nachvollziehbar scheint. Dieser Kontrast zwischen Naturwissenschaft und menschlichen Verhaltensweisen ist einfach witzig, findest Du nicht? Trotzdem findet man Gründe und Ursachen auch für unlogische Verhaltensweisen und kann selbst das Unlogische erklären, wie ja oben auch Sheeva Plug versucht hat. Daher analysiere ich einfach Dein Verhalten, wenn Du nichts dagegen hast. Solltest Du aber den Anspruch erheben, mit Deiner Bemerkung "Weil sie das im Allgemeinen ist." etwas Sachliches beigetragen zu haben, dann nenne doch bitte zu den von mir genannten Anwendungen eine kommerzielle Alternative und warum diese "professioneller" ist: > Und Apache, Firefox, gcc, PostgreSQL, RasMol, LAMMPS, CP2K zum Spielen > für die "Amateure"? Nur ganz kurz. Es kann ja dann auch nicht so schwer sein.
Feldstecher schrieb: > Naja, ein Forum ist doch dazu da, > a) Hilfe von Anderen zu bekommen > b) Anderen zu helfen (gibts tatsaechlich~) > c) Seine Meinung Kund zu tun (meistens) Naja, aber ich würde z.B. nicht in ein Windows-Forum gehen, wenn ich Linux benutze, a) da mir die Leute dort nicht helfen können und ich keine Hilfe mit Windows brauche, b) da ich den Leuten nicht helfen kann, weil ich mich mit Windows nicht auskenne, c) da ich auch nicht in die Kirche gehe, um den Pfarrer von der Kanzel zu schubsen und der Gemeinde zu erklären, warum ich Atheist bin. Irgendwie würde mich das auch mit großer Sorge bezüglich meines eigenen Geisteszustandes erfüllen. Denn eine Meinung kund zu tun ist ja in Ordnung, so lange danach gefragt war, und so lange sie nicht von einer Art ist, die José Ortega y Gasset meinte, als er zur Charakterisierung des "Massenmenschen" schrieb: "Der Massenmensch hält es nicht für nötig, sich eine Meinung zu bilden. Aber er hat eine."
Simon H. schrieb: > il Conte schrieb: >> Im Fall einer Diode wäre es dann 'A' und 'K' das gleiche macht man dann >> auch konsequenter weise bei der Erstellung des Footprintes an Hand des >> Datenblattes. >> Das Besagt gilt dann ebenso für Transistoren und FETs. >> Man muss lediglich einmal bei der Footprintgestaltung aufpassen, >> dann gibt es hinterher keine Probleme. > > Ein sehr guter Tipp! Oh. Ich dachte, das machen alle schon immer so :-} Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für Fehler.
Chris D. schrieb: > Oh. Ich dachte, das machen alle schon immer so :-} > > Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für > Fehler. Ich denke nicht, dass das viele so machen. Obwohl es m.E. sehr sinnvoll ist. Und schon sind wir wieder beim Thema genersche Komponenten. Dieses Vorgehen funktioniert nur, wenn man einen Footprint für einen bestimmten Transistor erzeugt. Resp. alle, die diese Anordnung haben. Das könnte man, wenn man sehr konsequent arbeitet, einigermassen gefahrlos machen, indem man das im Namen klar deklariert. Ein Footprint für EINEN Transistor ist aber wohl die sicherere Variante. Sowieso gibt es dann aber keinen generischen TO92 Footprint mehr. Ich selber (obwohl ich bis jetzt immer wieder die Vorteile von generischen Komponenten hervorhob) bevorzuge bei Transistoren ebenfalls diese Methode. Aber eben: Kicad lässt es Dich machen, wie Du willst. Und Eagle ja eigentlich auch (nehme ich an, ohne es zu kennen). Nur halt ein bisschen anders. Irgendwie habe ich das Gefühl, die Unterschiede sind gar nicht sooooo gross, wie einige (Eagler) hier glauben.
:
Bearbeitet durch User
Wie ist das eigentlich bei Eagle? (Ehrliche Frage, nicht rhetorisch) Ich möchte einen neuen Transistor in der Bibliothek anlegen. Ich erzeuge also die Komponente Dann gebe ich ihm ein Schemasymbol. Dieses kann ich von der bestehenden Bibliothek übernehmen. Dann gebe ich ihm einen (oder mehrere) Footprint. Z.B. TO-92. Und nun muss ich Eagle die Pin-Pad Zuordnung beibringen. Wie geht das? Mit einer Tabelle? Bei KiCad geht das zum Beispiel (es gibt wie gesagt unterschiedliche Paradigmen) so: Schemasymbol anlegen (kopieren von bestehendem Transistor) Footprint anlegen (kopieren von bestehendem TO-92) Pads mit E,B,C benennen gemäss Datenblatt. Beim Schemasymbol die Footprintzuordnung definieren.
:
Bearbeitet durch User
np r. schrieb: > Dussel schrieb: >> - kommerzielle Software als "professionell" zu bezeichnen? >> Weil sie das im Allgemeinen ist. > > Ah ja - SuperMario für die "professionellen" Zocker? Es gibt einen Unterschied zwischen "Die Software ist professionell" und "Die Software ist für professionelle $irgendwas". Ersteres bedeutet, dass jemand Geld damit verdient, die Software zu programmieren und zu verteilen, zweiteres, dass jemand Geld damit verdient, die Software zu benutzen. Chris D. schrieb: > Oh. Ich dachte, das machen alle schon immer so :-} > > Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für > Fehler. An der Stelle sehe ich einen großen Vorteil im Eagle-Device-Konzept. Hier habe ich einen (Platinen-)Footprint mit Pad-Nummern (z.B. 1, 2, 3) und kann beliebig viele Devices erzeugen, die ein (Schaltplan-)Symbol mit Pin-Bezeichnungen (z.B. B, C, E) mit diesem Footprint verbinden. Für KiCad müssen die Bezeichnungen von Footprint und Symbol identisch sein, dass heißt, ich muss zum Beispiel ein SOT23-Footprint mehrfach kopieren, wenn ich Bipolar-Transistoren, Dioden, Doppel-Dioden, FETs... in SOT23-Footprint nutzen will, oder ich muss den Schaltplan-Symbolen schon Pin-Nummern geben. Wenn jetzt vor dem Kopieren ein Fehler im Footprint, muss ich alle Kopien korrigieren... Aber das sehen die KiCad-Entwickler anders (das Thema kommt in unregelmäßigen Abständen auf der Mailingliste auf) und damit kann ich auch leben. MfG, Arno
Simon H. schrieb: > Wie ist das eigentlich bei Eagle? (Ehrliche Frage, nicht rhetorisch) > > Ich möchte einen neuen Transistor in der Bibliothek anlegen. > Ich erzeuge also die Komponente > Dann gebe ich ihm ein Schemasymbol. Dieses kann ich von der bestehenden > Bibliothek übernehmen. > Dann gebe ich ihm einen (oder mehrere) Footprint. Z.B. TO-92. > Und nun muss ich Eagle die Pin-Pad Zuordnung beibringen. Wie geht das? > Mit einer Tabelle? Ja. Hier ist ein Screenshot: http://www.amateurfunkbasteln.de/eagle_lib/device4.gif (von http://www.amateurfunkbasteln.de/eagle_lib/eagle_lib.html) Wie eben angesprochen finde ich das ein sehr geschicktes Konzept, das sehen die KiCad-Entwickler aber anders. MfG, Arno
> Für KiCad müssen die Bezeichnungen von Footprint und Symbol identisch > sein, Für die Anschlusspins ist es irgendwie sinnvoll die Adressleitung 1 im Schaltplan als Adressleitung 1 auf der Leiterplatte wiederzufinden. wenn die 1 die 5 und die 8 die 4und die 135 die 153 ist ...
:
Bearbeitet durch User
Arno schrieb: > np r. schrieb: >> Dussel schrieb: >>> - kommerzielle Software als "professionell" zu bezeichnen? >>> Weil sie das im Allgemeinen ist. >> >> Ah ja - SuperMario für die "professionellen" Zocker? > > Es gibt einen Unterschied zwischen "Die Software ist professionell" und > "Die Software ist für professionelle $irgendwas". Ersteres bedeutet, > dass jemand Geld damit verdient, die Software zu programmieren und zu > verteilen, zweiteres, dass jemand Geld damit verdient, die Software zu > benutzen. Genau das. Ich glaube kaum, dass ein Laie SuperMario mit den Mitteln unter den gegebenen Umständen hingekriegt hätte. Heute, mit schnellen Rechnern, guten Compilern, Simulatoren, Debuggern und sowas ist das relativ(!) einfach, aber sowas gab es damals nur mit sehr begrenzter Funktion.
Arno schrieb: > Ja. Hier ist ein Screenshot: > http://www.amateurfunkbasteln.de/eagle_lib/device4.gif (von > http://www.amateurfunkbasteln.de/eagle_lib/eagle_lib.html) > > Wie eben angesprochen finde ich das ein sehr geschicktes Konzept, das > sehen die KiCad-Entwickler aber anders. Also wie ich vermutete, mit einer Tabelle. Ich muss gestehen, gerade für die typischen Dreibeiner ist das sicher sehr praktisch. Ich kenne die Diskussionen mit den Entwicklern nicht und somit auch nicht die Gründe, warum es das in Kicad so nicht gibt. Bei Zweibeinern sehe ich den Vorteil nicht wirklich, weil da z.B. ein Diodenfootprint sowieso ein A und ein K Pad haben wird. Egal, welchen Typs er ist. Bei den Dreibeinern ist es elegant. Da wäre die KiCad-Alternative z.B. Footprints mit der Bezeichnung TO92-ECB rsp. TO92-CEB etc. Komplizierter wird es dann z.B. bei Dreibeinern im SO8 Gehäuse. Da wird wird wohl kein Weg daran vorbeiführen, entweder dedizierte Footprints zu generieren oder (eher) dedizierte Schemasymbole. Die haben dann eben Pinnummern 1-8 statt E,C und B. Bei Vielbeinern ist wohl der wesentliche Unterschied, dass die Anschlüsse bereits im Schemasymbol fix einer Pinnummer zugeordnet sind. Wenn ich also einen Prozi habe, den es in verschiedenen Footprints gibt, wobei aber die Pinzuordnung sich auch wiederum unterscheiden kann, dann wäre so eine Tabelle wiederum nützlich. (Bsp. 40-Pinner vs 44-Pinner mit zusätzlichen GND - würde das in Eagle funktionieren? Mehrere Pads für einen Pin oder Pins, die gar kein Pad haben?) Ich freue mich darüber, dass es doch noch wirkliche Argumente gibt, die für das Paradigma gemäss Eagle sprechen. Es bekräftigt aber letztendlich wiederum meine Vermutung, dass soooooo riesig die Unterschiede in den Religionen nicht sind. Beide glauben an Schemasymbole und Footprints. Und sehen die Erlösung in den Fabrikationsdaten.
Lutz H. schrieb: >> Für KiCad müssen die Bezeichnungen von Footprint und Symbol identisch >> sein, > > Für die Anschlusspins ist es irgendwie sinnvoll die Adressleitung 1 im > Schaltplan als Adressleitung 1 auf der Leiterplatte wiederzufinden. Kann man ja mit einem Device (wie es bei Eagle heißt) - einer Verknüpfung von Footprint und Symbol - immer noch anzeigen. Sonst hat man immer die Frage, welche Bezeichnung verwendet man? Die Funktionsbezeichnung des Pins (A, K, IN+, IN-, OUT, RESET, D, CLK, PB1, bei mehreren Einheiten pro Gehäuse auch gern A1, K1, A2, K2...) oder die (idealerweise JEDEC-)Positionsbeschriebung des Pads (1..x)? Typischerweise - und so ist es bei KiCad heute auch - ergibt das ein Mischmasch und viele Kopien der Footprints, die sich theoretisch nur in der Padbezeichnung unterscheiden, praktisch aber auch in anderen Dingen. MfG, Arno
Arno schrieb: > praktisch aber auch in anderen Dingen. Worüber sprechen wir? Über eine Grenze die so nicht existiert. Das Gehäuse der Schaltkreises muss irgendwie mit der Leiterplatte verbunden werden. Diese Schnittstelle ist von vielen Anforderungen gekennzeichnet. Ob die Erfüllung dieser Anforderungen der Leiterplatte oder dem Schaltkreis zugeordnet werden, hängt von dem Vorstellungen der Entwickler der Leiterplatte ab. Es ist möglich nur Pads auf die Leiterplatte zu zeichnen und diese zu verbinden oder sogar Paint dafür zu nutzen und die Zeichnung auf die Leiterplatte zu platzieren. Kicad ordnet einem Schaltzeichen ein Gebilde zu, wo der Schaltkreis auf die Leiterplatte gelötet werden kann. Diese Zuordnung wird in einem übersichtlichen Programm gepflegt.
Chris D. schrieb: > Oh. Ich dachte, das machen alle schon immer so :-} Das hat für mich etwas von 'oben herab' :-( (jedenfalls kommt es so rüber) Chris D. schrieb: > Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für > Fehler. Wenn du es e schon wusstes , dann hätte es wohl dir zugestanden eine Tipp abzugeben :-(halt nur 'hätte')
Was bei der Device-Geschichte auch noch dazukommt: Jeder Bibliotheksauthor nimmt sein Symbol woanders her. Das führt dazu, dass man im Schaltplan für FETs verschiedene Symbole hat, je nachdem welchen Typ man verwendet. Klar, bei eigenen Bibliotheken ist man frei, aber viele Entwickler sparen sich den Aufwand. Man kann jetzt sagen, das ist auch Wurscht, FET bleibt FET und Diode bleibt Diode, aber ein Mischmasch ist halt auch nicht gerade professionell. Bei KiCad kann das genauso auftreten, aber doch deutlich abgeschwächt.
il Conte schrieb: > Chris D. schrieb: >> Oh. Ich dachte, das machen alle schon immer so :-} > > Das hat für mich etwas von 'oben herab' :-( (jedenfalls kommt es so > rüber) Dann liegst Du falsch. > Chris D. schrieb: >> Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für >> Fehler. > > Wenn du es e schon wusstes , dann hätte es wohl dir zugestanden eine > Tipp abzugeben :-(halt nur 'hätte') Du musst lesen, was ich schreibe: ich bin davon ausgegangen, dass das bereits jeder so macht.
Simon H. schrieb: > Arno schrieb: >> Ja. Hier ist ein Screenshot: >> http://www.amateurfunkbasteln.de/eagle_lib/device4.gif (von >> http://www.amateurfunkbasteln.de/eagle_lib/eagle_lib.html) >> >> Wie eben angesprochen finde ich das ein sehr geschicktes Konzept, das >> sehen die KiCad-Entwickler aber anders. > > Also wie ich vermutete, mit einer Tabelle. Ich muss gestehen, gerade für > die typischen Dreibeiner ist das sicher sehr praktisch. > Ich kenne die Diskussionen mit den Entwicklern nicht und somit auch > nicht die Gründe, warum es das in Kicad so nicht gibt. Ich kann es gerade auch nicht zusammenfassen, aber die Diskussion kommt bestimmt bald wieder auf ;) > Bei Zweibeinern sehe ich den Vorteil nicht wirklich, weil da z.B. ein > Diodenfootprint sowieso ein A und ein K Pad haben wird. Egal, welchen > Typs er ist. Da ist es vor allem deshalb recht egal, weil die meisten Zweibeiner einfach umgedreht werden können ;) Vorteile hat das allenfalls bei "universellen" Footprints, z.B. der gleiche 0805 für Widerstände, Kondensatoren, Elkos (mit + und -) und LEDs. > Bei den Dreibeinern ist es elegant. Da wäre die KiCad-Alternative z.B. > Footprints mit der Bezeichnung TO92-ECB rsp. TO92-CEB etc. > Komplizierter wird es dann z.B. bei Dreibeinern im SO8 Gehäuse. Da wird > wird wohl kein Weg daran vorbeiführen, entweder dedizierte Footprints zu > generieren oder (eher) dedizierte Schemasymbole. Die haben dann eben > Pinnummern 1-8 statt E,C und B. Genau, in KiCad geht der Trend hin zu letzerem, auch für Dreibeiner (zumindest mein Eindruck, früher gab es mehr TO92-ECB, TO92-123, TO92-DGS, wenn ich das richtig in Erinnerung habe) Reste sieht man noch: ./Diodes_ThroughHole.pretty/Diode_TO-220_Dual_CommonCathode_Horizontal.k icad_mod ./Diodes_ThroughHole.pretty/Diode_TO-220_Horizontal.kicad_mod ./Power_Integrations.pretty/TO-220.kicad_mod ./TO_SOT_Packages_THT.pretty/TO-220_Neutral123_Horizontal.kicad_mod Ich hab das jetzt nicht geprüft, aber idealerweise ist das mechanisch immer der gleiche Footprint... > Bei Vielbeinern ist wohl der wesentliche Unterschied, dass die > Anschlüsse bereits im Schemasymbol fix einer Pinnummer zugeordnet sind. > Wenn ich also einen Prozi habe, den es in verschiedenen Footprints gibt, > wobei aber die Pinzuordnung sich auch wiederum unterscheiden kann, dann > wäre so eine Tabelle wiederum nützlich. (Bsp. 40-Pinner vs 44-Pinner mit > zusätzlichen GND - würde das in Eagle funktionieren? Mehrere Pads für > einen Pin oder Pins, die gar kein Pad haben?) Nein, mehrere Pads für einen Pin kann Eagle soweit ich weiß nicht (wobei ich dazusagen muss, dass meine letzte Eagle-Version glaub ich eine 5 oder 6 am Anfang hatte) und wenn Pins übrig sind, die kein Pad bekommen, hat sich Eagle glaube ich auch geweigert. Der gleiche AVR-Controller im PDIP40 oder PLCC44-Gehäuse sind bei Eagle zwei verschiedene Devices. Das ist Mist. Ich bin auch mit der KiCad-Lösung nicht wirklich zufrieden - ich kann ja einem Symbol ein Footprint mit falscher Padanzahl zuordnen, KiCad "verbindet" nur die Pins und Pads, die die gleiche Bezeichnung haben, alles andere wird ignoriert. Wenn ich ein Bauteil mit vier GND-Pins habe (wie einen 78L05 im SO8-Gehäuse) kann ich entweder vier GND-Pins in das Symbol zeichnen oder die Pads im Footprint alle gleich benennen. Natürlich gibt es in der "Standard"-Library auch beide Varianten. Im ersten Fall muss ich an dem Schaltplan herumbasteln, wenn ich z.B. statt des SO8-78L05 einen SOT23-78L05 verwenden will, obwohl sich logisch nichts ändert. Im zweiten Fall brauche ich für den 78L05 ein anderes SO8-Footprint als zum Beispiel für einen ATTiny25 (wenn das der 8-Pinner war) und muss bei Änderungen im JEDEC-Standard oder in den Anforderungen meines Fertigers beide Footprints ändern. Ich kann sogar einem Symbol mit Pins BCE einen Footprint mit Pads 123 zuordnen (probier mal einen 7805 mit einem TO220), der Footprint hat dann eben keine Verbindungen auf der Platine. Und das sehe ich nur, wenn ich beim Einlesen der Netlist zwischen den ganzen "Success"-Meldungen auch die "Error"-Meldungen finde. Wenn ich mir etwas wünschen dürfte, wäre das eine N-zu-M-Zuordnungstabelle von Pins zu Pads. Gerne mit Überprüfung, ob alle Pins und Pads zugeordnet sind (und wenn die Pads explizit auf NC gesetzt werden). Dann ist es denke ich auch nur noch ein kleiner Schritt hin zu Gateswap (was Eagle kann, KiCad aber bisher nicht, soweit ich weiß). Und es braucht nur noch "neutrale" Footprints und "neutrale" Symbole, die Komplexität kommt erst durch die Kombination der beiden. Vielleicht baue ich im nächsten Urlaub mal einen Proof-of-Concept-Library-Manager für KiCad, der genau das tut. Vielleicht kommt ein Teil davon auch schon mit Waynes neuem "Symbol library format", was seit Monaten im Hintergrund steht. MfG, Arno
np r. schrieb: > kommerzielle Alternative und warum diese "professioneller" ist: >> Und Apache, Firefox, gcc, PostgreSQL, RasMol, LAMMPS, CP2K zum Spielen >> für die "Amateure"? > > Nur ganz kurz. Es kann ja dann auch nicht so schwer sein. ... Entschuldigung, er hat aber Recht. Professionell ist eine Software dann, wenn diese zwecks Verkauf erstellt wird, also Kommerz. Der Duden meint zu Bedeutung von Profession: "Arbeit, Beruf, Beschäftigung, Gewerbe, Handwerk, Metier". Die Professionellen leben also davon. Das sagt allerdings nichts über die Qualität der Software aus bzw. hat damit gar Nichts zu tun..und das ist das worauf Du hinaus wolltest. Gruß, Holm
Simon H. schrieb: > Chris D. schrieb: >> Oh. Ich dachte, das machen alle schon immer so :-} >> >> Pinnummern an Dioden und Transis? Das ist ein echtes Einfallstor für >> Fehler. > > Ich denke nicht, dass das viele so machen. Obwohl es m.E. sehr sinnvoll > ist. Und schon sind wir wieder beim Thema genersche Komponenten. Dieses > Vorgehen funktioniert nur, wenn man einen Footprint für einen bestimmten > Transistor erzeugt. Resp. alle, die diese Anordnung haben. Das könnte > man, wenn man sehr konsequent arbeitet, einigermassen gefahrlos machen, > indem man das im Namen klar deklariert. Ein Footprint für EINEN > Transistor ist aber wohl die sicherere Variante. Sowieso gibt es dann > aber keinen generischen TO92 Footprint mehr. > Ich selber (obwohl ich bis jetzt immer wieder die Vorteile von > generischen Komponenten hervorhob) bevorzuge bei Transistoren ebenfalls > diese Methode. KiCad bietet mehrere Footprints für TO92 an, mit runden oder länglichen Lötaugen, liegend, stehend etc. pp.. Das würde bedeuten das man Bei Eagle das Ganze weiter aufdröseln muß, BC556 liegend, stehend, mit länglichen Lötaugen oder runden und das für jeden TO92 Transistor. Wo zum Teufel ist da der Vorteil? > > Aber eben: Kicad lässt es Dich machen, wie Du willst. Und Eagle ja > eigentlich auch (nehme ich an, ohne es zu kennen). Nur halt ein bisschen > anders. > > Irgendwie habe ich das Gefühl, die Unterschiede sind gar nicht sooooo > gross, wie einige (Eagler) hier glauben. Eben. Es kann aber nicht sein was nicht sein darf. Gruß, Holm
Arno schrieb: > An der Stelle sehe ich einen großen Vorteil im Eagle-Device-Konzept. > Hier habe ich einen (Platinen-)Footprint mit Pad-Nummern (z.B. 1, 2, 3) > und kann beliebig viele Devices erzeugen, die ein (Schaltplan-)Symbol > mit Pin-Bezeichnungen (z.B. B, C, E) mit diesem Footprint verbinden. Du stellst das als ein 'Non plus Ultra' Feature von Eagle hin, ohne den es sich nicht lohnt zu CAD'eln ;-)? Ist es aber (aus meiner Sicht) bei weiten nicht. Viel wichtiger für den CAD Alltag sind Features wie hierarchische Schaltplaneingabe, Online DRC und P&S! Das bietet nun mal KiCAD, weshalb ich über durchaus vorhanden Ecken und Kanten darüber hinweg schaue. Wenn du mal diese 3 Dinge lieben lernst ? schaust du kein anders CAD mehr an ;-) Bei der Zuordnung von den Footprint zu den Symbolen habe ich persönlich absolut null Probleme - es erfordert halt ein klein wenig Konzentration.
Chris D. schrieb: > Du musst lesen, was ich schreibe: ich bin davon ausgegangen, dass das > bereits jeder so macht. Das nehme ich dir jetzt so ab.
Holm T. schrieb: > Professionell ist eine Software dann, wenn diese zwecks Verkauf erstellt > wird, also Kommerz. Der Duden meint zu Bedeutung von Profession: > "Arbeit, Beruf, Beschäftigung, Gewerbe, Handwerk, Metier". > Die Professionellen leben also davon. Ein Attribute fehlt aber noch : TEUER :-(
Vorsicht! Nicht auf der eigenen Schleimspur ausgleiten... http://www.hwtips.de/streik/Transp9.jpg :(( -Paul-
:
Bearbeitet durch User
il Conte schrieb: > wie hierarchische > Schaltplaneingabe, Online DRC öh... gibt es das bei Eagle nicht? (ehrliche Frage!)
:
Bearbeitet durch User
Paul B. schrieb: > auif Brütest du gerade an einer neuen Programiersprache herum, die sich nun in deinen Bemerkungen zur Lage der CAD's, weg bahnt :-))?
Paul B. schrieb: > Vorsicht! Nicht auf der eigenen Schleimspur ausgleiten... > > http://www.hwtips.de/streik/Transp9.jpg > > :(( > > -Paul- Auf wen oder was beziehst Du Dich denn? Gruß, Holm
Was für mich auch wichtig ist, ist eine unkomplizierte Zusammenarbeit mit einem CAD-Programm. Allerdings sehe ich da bei beiden Programmen verbesserungsbedarf. Keines der beiden Programme kann meines Wissens nach mit STEP-Dateien arbeiten. Wobei ich hier noch immer einen Vorteil bei KiCad sehe, da es DXF-Dateien ohne ULP's importieren kann und die 3D-Ansicht wenigstens auch exportieren kann. Wobei der Teil noch nacharbeit braucht, da es keine STEP-Datei ist.
Simon H. schrieb: > öh... gibt es das bei Eagle nicht? Die Frage müsste man an die EGALE User weiterreichen, so viel ich weiss in der Form wie es KiCAD bietet nicht.
il Conte schrieb: > Arno schrieb: >> An der Stelle sehe ich einen großen Vorteil im Eagle-Device-Konzept. >> Hier habe ich einen (Platinen-)Footprint mit Pad-Nummern (z.B. 1, 2, 3) >> und kann beliebig viele Devices erzeugen, die ein (Schaltplan-)Symbol >> mit Pin-Bezeichnungen (z.B. B, C, E) mit diesem Footprint verbinden. > > Du stellst das als ein 'Non plus Ultra' Feature von Eagle hin, > ohne den es sich nicht lohnt zu CAD'eln ;-)? Sorry, dann komme ich falsch rüber. Es ist IMHO ein deutlicher Vorteil, es reicht aber lange nicht, dass ich deshalb bei Eagle geblieben wäre. (Habe gerade mal nachgesehen: Meine neueste Eagle-Datei wurde 2013 das letzte Mal geöffnet, seitdem nutze ich nur noch KiCad - wahrscheinlich gibt es aus 2010 sogar irgendwo einen Patch von mir im KiCad-Codetree) > Bei der Zuordnung von den Footprint zu den Symbolen habe ich persönlich > absolut null Probleme - es erfordert halt ein klein wenig Konzentration. ...und Recherche, wenn ich doppelte Arbeit vermeiden will. Schließlich hat ja bestimmt schon jemand den Footprint erstellt, den ich brauche, aber welcher von den vier TO220_Horizontal ist es jetzt? Worin unterscheiden die sich überhaupt? Und welcher davon passt am Besten zu meinem Part, so dass ich den wenigsten Aufwand habe bei der Anpassung? Da ist KiCad in letzter Zeit auch ein gutes Stück besser geworden, sowohl was die Libraries angeht als auch was die Vorschaufunktionen angeht, das war vor zwei-drei Jahren noch deutlich mehr Aufwand. MfG, Arno
Holm T. schrieb: > Auf wen oder was beziehst Du Dich denn? Auf die plötzlichen Lobgesänge auf ein Programm, was es schon lange, lange gibt. Nur, weil bei einem anderen Programm irgendwelche Lizenzverfahren verändert wurden, ändert das doch an der Benutzbarkeit nichts -aber auch gar nichts. Die Penetranz, mit der "il Conte" hier zentimeterdick die vermeintlichen Vorteile vorträgt -die stößt mich erst recht von einer Installation ab. Paul
Ich habe es bereits privat vor den Änderungen bei Eagle genutzt. Auf Arbeit arbeite ich nach wie vor mit Eagle 6.5. Also sind zumindest meine "Lobesgesänge" nicht plötzlich. Was ich aber auch sehr interressant finde, ist dass du meine Eaglespezifische Frage nicht beantwortet hast. Vor allen Dingen, da diese absolut ernst gemeint ist. Das würde nämlich das ein oder andere Problem auf Arbeit lösen.
Lutz H. schrieb: > Arno schrieb: >> praktisch aber auch in anderen Dingen. > > Worüber sprechen wir? Zum Beispiel gibt es für eine LED in LEDs.pretty nur eine 0805-Footprint-Option, für einen Widerstand in Resistors_SMD.pretty gibt es zwei, die beide mechanisch anders aussehen als die der LED. > Kicad ordnet einem Schaltzeichen ein Gebilde zu, wo der Schaltkreis auf > die Leiterplatte gelötet werden kann. Diese Zuordnung wird in einem > übersichtlichen Programm gepflegt. ...wenn Schaltzeichen und Footprint zusammenpassen, und zwar für eine sehr weitgehende Definition von "zusammenpassen". Sonst geht das schief, siehe das Beispiel TO220-Neutral mit einem 7805. MfG, Arno
Ich Nicht schrieb: > Was ich aber auch sehr interressant finde, ist dass du meine > Eaglespezifische Frage nicht beantwortet hast. Ich werde mich hüten, hier in diesem Thread eine Eagle-spezifische Frage zu beantworten. Da würde hier der Mond platzen. Paul
Ich Nicht schrieb: > Keines der beiden Programme kann meines Wissens nach mit STEP-Dateien > arbeiten. Kommt in KiCad. Ist bisher nur über Zwischenschritte möglich, aber ich schätze, es wird in absehbarer Zeit, vermutlich in 5.0, integriert sein: https://forum.kicad.info/t/wrl-step-import/4043 Da läuft gerade unter der Haube einiges an Refactoring, um zum Beispiel solche neuen Import-Filter einfacher zu machen. MfG, Arno
Das am Step-Export von KiCad gearbeitet wird, habe ich schon irgendwo gelesen. Privat setze ich Hoffnungen in KiCad. Auf Arbeit habe ich leider einige Kollegen, die recht eingefahren auf Eagle sind und daher Probleme hätten, sich von der Arbeitsweise zu lösen. Das betrifft aber nicht nur KiCad sondern auch die höherpreisigen EDA-Pakete. @ paul_baumann: Mit dieser Reaktion hatte ich gerechnet. Schade drum.
Paul B. schrieb: > Die Penetranz, mit der "il Conte" hier > zentimeterdick die vermeintlichen Vorteile vorträgt -die stößt mich erst > recht von einer Installation ab. Nenne es aus deiner Sicht Penetranz, das Echo hier in diesen Threat zeigt mir was anderes. Und wie nennst du dann eigentlich das Auftreten von 'W.S.' und 'Dussel' Auch Penetrant? Für mich vertreten die eine Meinung wo man (mit Verlaub) auch mal sachlich dagegenhalten darf - oder? Deine Sturheit und die Aversion gegen über KiCAd, zeugt eigentlich nur davon, dass du dich in die Enge gedrückt fühlst. Der Gedanke das irgendwann alle auf KiCAD umschwenken und du alleine zurückbleibst löst bei dir anscheinend Angstzustände aus. Warum denn eigentlich? Sei doch offen für was neues? Schade eigentlich ich kenne dich hier als ein Foren 'Original' dessen Wortwitz ich immer (und noch) mochte. Holm T. schrieb: > Auf wen oder was beziehst Du Dich denn? Ich habe das sehr wohl verstanden auf wen er(Paul) das beziehst. Es würde besser zu seinem Charakter passen wenn er mit offenem Visier auftreten würde.
Paul B. schrieb: > Holm T. schrieb: >> Auf wen oder was beziehst Du Dich denn? > > Auf die plötzlichen Lobgesänge auf ein Programm, was es schon lange, > lange gibt. Nur, weil bei einem anderen Programm irgendwelche > Lizenzverfahren verändert wurden, ändert das doch an der /Benutzbarkeit/ > nichts -aber auch gar nichts. Die Penetranz, mit der "il Conte" hier > zentimeterdick die vermeintlichen Vorteile vorträgt -die stößt mich erst > recht von einer Installation ab. > > Paul Paul ...Du enttäuschst mich ein Bisschen. Mach mal einen Reality Check: "Wir KiCadler" hier müssen uns im gesamten Thread ständig gegen "aber Eagle ist besser, wer das nicht begreift ist doof" verteidigen. Wenn es dann zu sachlichen Gegenargumenten kommt ist das dann Schleimspur? Ich sags nochmal: Niemand nimmt Euch Eagle weg. Ich verstehe sehr gut das man ein Werkzeug an das man sich gewöhnt hat nicht aus der Hand legen möchte. Ein Equivalent dazu ist ein Editor (gut, unter Windows sind fast Alle gleich). Ich habe mal über den VI geflucht vor vielen Jahren, hab ihn halt bedienen gelernt in der Zwischenzeit und möchte den beim programmieren benutzen. Ich bin damit viel viel schneller als mit irgendwelcher Mausklickerei zu bewerkstelligen ist. Ergo: Jede IDE mit integriertem Editor != VI ist Mist. Das ist meine Ansicht und die wirst Du auch nicht aus meinem Kopf bekommen, ich würde aber deshalb nicht versuchen einem Windowsfreak das Ding einreden zu wollen, soll er doch machen mit der Maus.. Hier spielt scheinbar wirklich der psychologische Effekt eine Rolle das den Eagle Freaks weh getan wurde weil die Zukunft ihrer geliebten Software ungewiß ist, gleichzeitig interessieren sich mehr Leute (auch aus diesen Lizenzgründen) für KiCad das in letzter zeit sehr viel Fortschritte gemacht hat. ..das tut Euch irgendwie weh und darf wohl nicht sein, anders kann ich mir die Überreaktion der "Eagler" nicht erklären. Hier wird sowieso nicht über "entweder oder" entschieden..warum also der Zank? Laßt uns doch in Ruhe KiCad lieben ..und ich nehme das im Prinzip schon lange wie ich schon mal schrub, habe auch über Dreckeffekte und Abstürze fluchen müssen bin aber bei der Stange geblieben. Warum darf ich mich jetzt nicht freuen? Ich habe nichts gegen Eagle, ich benutze es nur nicht. Ich kotze aber über diese .sch und .brd Files die ich mir ohne Kopfstände nicht angucken kann. Gruß, Holm
Holm T. schrieb: > Hier spielt scheinbar wirklich der psychologische Effekt eine Rolle das > den Eagle Freaks weh getan wurde weil die Zukunft ihrer geliebten > Software ungewiß ist, gleichzeitig interessieren sich mehr Leute (auch > aus diesen Lizenzgründen) für KiCad das in letzter zeit sehr viel > Fortschritte gemacht hat. ..das tut Euch irgendwie weh und darf wohl > nicht sein, anders kann ich mir die Überreaktion der "Eagler" nicht > erklären. Diesen psychologischen Effekt kann man auch sehr gut bei Kleinkindern beobachten wenn sie im Laufstall sitzen und nimmt ihnen den 'Lieblings-Schnuller' weg. Mir hat man erzählt, dass es die Katze war die meinen 'Lieblings-Schnuller' verzogen hat. (auf Nimmerwiedersehen:-( So habe ich schon sehr früh gelernt mich umzuorientieren :)
Holm T. schrieb: > Paul ...Du enttäuschst mich ein Bisschen. Dann hast du nur noch nicht gemerkt, wie der Herr wirklich tickt...
Hallo Simon. Simon H. schrieb: > il Conte schrieb: >> wie hierarchische >> Schaltplaneingabe, Online DRC > > öh... gibt es das bei Eagle nicht? > (ehrliche Frage!) Mittlerweile schon. Hierarchische Schaltpläne kennt Eagle erst seit Version 6 oder 7 oder so. Vorher nicht. Die hierarchischen Schaltpläne waren für mich so 2009 mit einer der Gründe, von Eagle auf KiCad zu wechseln, zusammen mit der handlicheren Bedienung. Ich denke, ohne KiCad hätte Eagle heute noch keine hierarchischen Schaltpläne. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Mal aus Interesse: wie viele hier Nutzen den KiCad für professionelle/gewerbliche Zwecke? Zeitersparnis mit Altium hin oder her, für mich lohnt sich die teure Lizenz nicht.
Bernd W. schrieb: > Hierarchische Schaltpläne kennt Eagle erst seit Version 6 oder 7 oder > so. Vorher nicht. Mich wunder es, dass man keine Lobpreisungen in dieser Richtung hört. Geht die Hirachie bei EAGLE (sowie bei KiCAD) über mehrere Ebenen nach unten? Oder ist sie flach?
Hallo Graf. il Conte schrieb: >> Hierarchische Schaltpläne kennt Eagle erst seit Version 6 oder 7 oder >> so. Vorher nicht. > > Mich wunder es, dass man keine Lobpreisungen in dieser Richtung hört. > Geht die Hirachie bei EAGLE (sowie bei KiCAD) über mehrere Ebenen nach > unten? > Oder ist sie flach? Es ist schon eine echte Hierarchie nach unten. Wenn Du es so siehst, also "flach", konnte das Eagle auch schon vorher, weil man ja mehrere Schaltplanblätter nebeneinander anlegen kann. ;O) Persönlich habe ich das aber nie benutzt, weil ich mit Eagle 4 aufgehört habe, dienstlich Eagle zu verwenden. Wo ich jetzt arbeite, wird PCAD bzw. Altium verwendet. Aber da ich keine Designs mache, nutze ich nur die Viewer. > Mich wunder es, dass man keine Lobpreisungen in dieser Richtung hört. Vieleicht verwendet der "typische Eagle User" so Teufelszeug nicht? Immerhin haben die ja auch bezüglich Bibliotheken andere Philosophien. ;O) Jedenfalls kenne ich zwei Firmen, die wegen der hierarchischen Schaltpläne von Eagle zu Altium gewechselt sind, weil so etwas ist wirklich praktisch. Aber hier lesen ja genug Eagle User mit, die können Dir berichten. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hey, wollte Kicad auch mal wieder eine Chance geben, also flux die aktuelle Version 4.0.6 installiert. Ich finde die Bedienung immer noch nicht intuitiv. Beispiele: Footprint-Zuordnung: Man klickt auf "Automatisch zuordnen" und würde dann erwarten das die Zuordnungen gemacht werden. Aber es werden die Zeilen nur "blau" markiert?! Klar, RTFM, aber es ist nicht intuitiv. Die verschiendenen Canvas im PcbNew. WTF? Das Verhalten ist völlig Unterschiedlich je nach Canvas. Bin fast verrückt geworden, da ich im Standard Canvas nicht die Bauteile verschieben konnte, sondern immer ein Kontextmenü kam. Intuitiv? Autorouter? FreeRoute? Nein, erst Java-Geraffel und dann die Sourcen von Github installieren :-\ Ja, es ist frei und deswegen sage ich auch nicht das es schlecht ist, aber intuitiv ist anders für mich.
Markus M. schrieb: > Ich finde die Bedienung immer noch nicht intuitiv. Beispiele: Auf diesem Niveau zu diskutieren, bringt leider nichts... Manche Sachen sind eben verbesserungswürdig, andere Gewohnheitssachen und wieder andere einfach dem technischen Fortschritt bei gleichzeitigem Zwang, keine bewährten Funktionen zu verlieren, geschuldet. Die Eingewöhnung in ein neues Programm dieser Komplexität ist eben immer mit Unbquemlichkeiten verbunden und das nervt, weil man dauernd an Kleinigkeiten hängen bleibt, die man in der altgewohnten Umgebung ohne große Überlegung hinbekommt - aber das weiß eigentlich jeder und deswegen lohnt es sich nicht, darüber zu lamentieren.
Hm, komisch. Bei mir funktioniert KiCad out of the Box. Das einzige was noch nachgeladen werden musste, konnte via Wizard geladen werden.
Hallo Markus. Markus M. schrieb: > Hey, wollte Kicad auch mal wieder eine Chance geben, also flux die > aktuelle Version 4.0.6 installiert. 4.0.6. ist nicht wirklich aktuell. Da müstest Du schon mit einer frischen Testing Version vorbeikommen. ;O) > Ich finde die Bedienung immer noch nicht intuitiv. Beispiele: Wenn ich intuitiv bedienbare Software will, fürchte ich, muss ich mir die selber schreiben. ;O) Jedenfalls habe ich nicht über drei Generationen Schlipskopf Intuitionen sozial vererbt bekommen, um irgendeine standard Software, z.B. Office Kram, intuitiv Bedienen zu können. Insofern teile ich nicht Deine Erwartungen an Intuitivität, weil das eh selten funktioniert. Und gerade so ein komplexes Thema wie Leiterplatten erwartet immer eine gewisse Einarbeitung. ;O) > Autorouter? FreeRoute? Nein, erst Java-Geraffel und dann die Sourcen von > Github installieren :-\ Push und shove sind eine guter Ersatz für Autorouter. Schliesslich muss ich das Ergebnis eines Autorouter ja auch immer manuell überarbeiten. Da ist Push und shove direkter und effizienter. ;O) > > Ja, es ist frei und deswegen sage ich auch nicht das es schlecht ist, > aber intuitiv ist anders für mich. "Frei" (nicht "kostenlos") ist ein großer strategischer Vorteil. Siehe die aktuelle Diskussion wegen der Autodesk Politik. ;O) Wenn meine Software nicht frei ist, bin ich halt zu einem gewissen Grade erpressbar. Ich muss für mich selber entscheiden, was es mir Wert ist, weniger erpressbar zu sein. ;O) Und je kleiner ich bin, um so erpressbarer bin ich. Mag sein, das die Toleranzschwelle in diesem Punkte bei Dir wesentlich höher ist als bei mir. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Mal eine einfache Frage: könnte man KiCad auch ohne Java benutzen? Worauf müsste man verzichten?
eagle user schrieb: > Mal eine einfache Frage: könnte man KiCad auch ohne Java benutzen? Ja. > Worauf müsste man verzichten? Auf den Autorouter.
Hallo Eagle user. eagle user schrieb: > Mal eine einfache Frage: könnte man KiCad auch ohne Java benutzen? > Worauf müsste man verzichten? Auf jeden Fall auf einige Plugins in Eeschema, mit denen Du Stücklisten erstellst. Theoretisch könntest Du das aber durch Python oder irgendwas anderes ersetzten, Du musst dort nicht zwangsläufig Java verwenden. Das Plugin besteht darin, dass ein Skript aus Eeschema gestartet wird, die Schaltplan Datei beackert, und eine Ausgangsdatei erstellt. Über die Startzeile kannst Du festlegen, welcher Interpreter gestartet werden soll. Also sollte eigentlich auch was anderes als Java gehen. Und natürlich kannst Du Dir irgendetwas in einer X-Beliebigen Sprache schreiben, dass Du von hand startest, und das die Schaltplandatei durchliesst und daraus eine Stückliste in einem von Dir bestimmten Format erstellt. Ausserdem kannst Du auch Stücklisten aus PCBnew exportieren....das ist direkt in PCBnew und kein Plugin. Wofür darin sonst noch Java verwendet wird, weiss ich nicht. Ich bin kein Programmierer. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Das ist ja nett, vielen Dank! Ohne Autorouter kann ich leben und für die Stückliste hab' ich schon für Eagle ein Programm geschrieben. Da müsste ich ja nur das "vordere Drittel" anpassen. Bernd W. schrieb: > Das Plugin besteht darin, dass ein Skript aus Eeschema gestartet wird, > die Schaltplan Datei beackert, und eine Ausgangsdatei erstellt. > Über die Startzeile kannst Du festlegen, welcher Interpreter gestartet > werden soll. Also sollte eigentlich auch was anderes als Java gehen. Zumindest unter Linux kann man wohl davon ausgehen.
Angehängte Dateien:
-
Screenshot.png
27 KB
Ich bin mir nicht sicher, ob man für die Stückliste Java braucht. Ich habe zwei verschiedene Stücklistenplugins installiert, beide sind in xslt geschrieben und werden bei mir (unter Linux) von xsltproc ausgeführt. Ich habe zwar Java auf der Maschine, aber nicht für KiCad.
:
Bearbeitet durch User
Holm T. schrieb: > Professionell ist eine Software dann, wenn diese zwecks Verkauf erstellt > wird, also Kommerz. Der Duden meint zu Bedeutung von Profession: > "Arbeit, Beruf, Beschäftigung, Gewerbe, Handwerk, Metier". > Die Professionellen leben also davon. Wenn wir schon beim Duden sind - dann hätte "Dussel" schreiben müssen: "professionell hergestellte Software". Andernfalls würde es bedeuten, dass die Software selbst für "Arbeit, Beruf, Beschäftigung, Gewerbe, Handwerk, Metier" ist, ähnlich wie man die Begriffe "professionelles Werkzeug" und "Heimwerker-Werkzeug" verwendet. Vom ersten erwartet man mehr Leistung und Standfestigkeit, das zweite langt so für den gelegentlichen Gebrauch, ist aber billig. Ich gehe davon aus, dass "Dussel" das genau so gemeint hat, und hätte das gerne an den Beispielen Apache, Firefox, gcc, PostgreSQL, RasMol, LAMMPS, CP2K verifiziert gesehen. Da traut er sich aber nicht ran. Dussel schrieb: > Ich glaube kaum, dass ein Laie Hier wird seine Sichtweise genau deutlich: Er meint, FOSS wird von Laien programmiert. Wenn ich einen Laien einstelle und bezahle, macht er also "professionelle Software". Programmiert ein Profi quelloffene Software, so ist sie dagegen automatisch Amateur-Software und taugt nix (egal, ob er von seinem Arbeitgeber, von Google, RedHat, usw. dafür bezahlt wird oder nicht). Holm T. schrieb: > Das sagt allerdings nichts über die Qualität der Software aus Eben. Es gibt eine ganze Menge professionell hergestellten Schrott auf dieser Welt, und viele leben davon. Ganz professionell.
np r. schrieb: > Wenn ich einen Laien einstelle und bezahle, macht er also > "professionelle Software". Das stimmt so nicht ;-) Zuerst macht dein Laie nur 'Software' Erst wenn der BWL'er ins Spiel kommt und diese 'Software' für teures Geld an den Mann zu bringen versucht, mutiert es zur 'professionellen Software' :-)
np r. schrieb: > Holm T. schrieb: >> Professionell ist eine Software dann, wenn diese zwecks Verkauf erstellt >> wird, also Kommerz. Der Duden meint zu Bedeutung von Profession: >> "Arbeit, Beruf, Beschäftigung, Gewerbe, Handwerk, Metier". >> Die Professionellen leben also davon. > Wenn wir schon beim Duden sind - dann hätte "Dussel" schreiben müssen: > "professionell hergestellte Software". > Andernfalls würde es bedeuten, dass die Software selbst für "Arbeit, > Beruf, Beschäftigung, Gewerbe, Handwerk, Metier" ist, ähnlich wie man > die Begriffe "professionelles Werkzeug" und "Heimwerker-Werkzeug" > verwendet. Vom ersten erwartet man mehr Leistung und Standfestigkeit, > das zweite langt so für den gelegentlichen Gebrauch, ist aber billig. Naja komm, ich wußte was professionell bedeutet, wollte aber eine verbindliche Definition hier füs Forum finden. Es war nicht mein Plan über die Ausdrucksweise oder Rechtschreibung Anderer zu philosophieren... > > Ich gehe davon aus, dass "Dussel" das genau so gemeint hat, und hätte > das gerne an den Beispielen Apache, Firefox, gcc, PostgreSQL, RasMol, > LAMMPS, CP2K verifiziert gesehen. Da traut er sich aber nicht ran. Muß auch Niemand tun es sei denn er bekommt einen "professionellen" Auftrag.. biste interessiert ne Recherche zu beauftragen? :-) > > Dussel schrieb: >> Ich glaube kaum, dass ein Laie > Hier wird seine Sichtweise genau deutlich: Er meint, FOSS wird von Laien > programmiert. > Wenn ich einen Laien einstelle und bezahle, macht er also > "professionelle Software". Programmiert ein Profi quelloffene Software, > so ist sie dagegen automatisch Amateur-Software und taugt nix (egal, ob > er von seinem Arbeitgeber, von Google, RedHat, usw. dafür bezahlt wird > oder nicht). > > Holm T. schrieb: >> Das sagt allerdings nichts über die Qualität der Software aus > Eben. > Es gibt eine ganze Menge professionell hergestellten Schrott auf dieser > Welt, und viele leben davon. Ganz professionell. ...genau. "professionell" bedeutet nur das es Geld kostet, Nichts weiter. Denke mal an die vielen Profi-Tools im Baumarkt. Damit wird dort Geld verdient, Nichts weiter... Gruß, Holm
Holm T. schrieb: > ich wußte was professionell bedeutet Das habe ich nicht bestritten. Holm T. schrieb: > Denke > mal an die vielen Profi-Tools im Baumarkt. Damit wird dort Geld > verdient Mit den Hobby-Tools aber auch - und nicht zu knapp. Sind die dann auch "professionell"? Oder nur "professionell hergestellt"? Oder vielleicht eher zusammengepfuscht, aber "professionell vermarktet"? ;-) Mich nervt einfach dieses FOSS = Amateur, und sobald es Geld kostet, ist es "professionell", weil diese Kategorien in diesem Zusammenhang überhaupt nichts bringen sondern nur als Not-Ersatz für handfeste Argumente gebraucht werden, während ja offenbar nicht einmal Einigkeit darüber besteht, was "professionelle Software" eigentlich ist.
Professionell ist halt das was sich verkauft... http://www.dict.cc/deutsch/Professionelle%5BProstituierte%5D.html ;-)
Hallo np r. np r. schrieb: > Mich nervt einfach dieses FOSS = Amateur, und sobald es Geld kostet, ist > es "professionell", weil diese Kategorien in diesem Zusammenhang > überhaupt nichts bringen sondern nur als Not-Ersatz für handfeste > Argumente gebraucht werden, während ja offenbar nicht einmal Einigkeit > darüber besteht, was "professionelle Software" eigentlich ist. ;O) Umgekehrt kann ich auch fragen: Werde ich zum Amateur, sobald mir mein Job Spass macht? Ich glaube, es gibt wirklich Leute, die das so sehen. Natürlich ist es für mich wichtig, eine *professionelle Distanz" zu meinem Job, dem Werkzeug und den Werkstücken zu haben. und ich kann mir vorstellen, dass mir das je nach Situation schwer werden kann..... Auf der anderen Seite ist es der Motivation zutrählich. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Angehängte Dateien:
-
mpad.GIF
23 KB
Arno schrieb: > Nein, mehrere Pads für einen Pin kann Eagle soweit ich weiß nicht (wobei > ich dazusagen muss, dass meine letzte Eagle-Version glaub ich eine 5 Doch Eagle kann das(s. Screenshot). Das wird mit dem "Append" Button gemacht
il Conte schrieb: > Der Gedanke das irgendwann alle auf KiCAD umschwenken und > du alleine zurückbleibst löst bei dir anscheinend Angstzustände aus. Denke nicht das er alleine da steht. Ich komme für meine (privaten) Zwecke prima mit Eagle, sogar mit der freien Version, zurecht und das wird voraussichtlich auch noch lange so bleiben. Es gibt für mich derzeit keinen Grund auf eine andere Software umzuschwenken. Sollte es irgendwann dann doch mal erforderlich werden was Anderes zu benutzen, dann kann man sich jederzeit ein anderes Programm anschauen. Zeno
Zeno schrieb: > Es gibt für mich > derzeit keinen Grund auf eine andere Software umzuschwenken. Sollte es > irgendwann dann doch mal erforderlich werden was Anderes zu benutzen, > dann kann man sich jederzeit ein anderes Programm anschauen. Gegen eine solche Einstellung ist absolut nichts einzuwenden! In deinem zitierten Satz ging es um eine Antwort an Paul B. der mich zu vor auf eine sehr subtile Art angegriffen hat , sowas lasse ich nicht einfach so stehen. Schade um ihn, ich mochte eigentlich immer seinen Wortwitz recht gerne, wenn er auch meistens bei den anderen damit angestoßen ist.
Hallo, ich habe oft den Eindruck, Open-Source Software würde sich besser durchsetzen, wenn sie sich als kostenpflichte Software ausgeben würde und auf anderen Webseiten irgendwelche Kopierschutz Umgehungsbatchscripts erhältlich sind, die das Programm dann freischalten würden. Denn erst dann muss es sich somit um ein Profi-Tool handeln. Zwei reale Begebenheiten: ================================= - Einmal wurde von jemanden Scilab belächelt, weil es keine Simulink-Dateien öffnen kann. Aber wenn Simulink keine XCOS Dateien öffnen kann ist es OK. - Es gab ein Problem mit einem M$ Produkt. Ich warf in die Runde: "Ruft doch den so viel zitierten Support an." Ich wurde dann belächelt. Dann habe ich gemeint: "Komisch, bei wxMaxima habe ich einen Bug-Fix innerhalb von 3 Tagen bekommen. Das nennt man Support." KiCAD ist super! Und mit PnS habe ich wirklich einmal ein durch ein aussichtsloses Nadelöhr doch noch 3 Leiterbahnen mit mehreren Vias durchbekommen. Lg
il Conte schrieb: > ich mochte eigentlich immer seinen Wortwitz recht gerne, > wenn er auch meistens bei den anderen damit angestoßen ist. Es ist nicht sein Wortwitz, der anstößig ist, es sind die Aggressionen, die er dahinter zu verbergen sucht.
Sheeva P. schrieb: >>> Das habe ich oben schon angedeutet, die psychologischen Mechanismen nennen sich "Selbstrechtfertigung" und "Eskalierendes Commitment". Diese Menschen haben Geld und Zeit in ihre Software investiert, und jetzt kommt plötzlich einer um die Ecke und bietet eine ganz ähnliche Software kostenlos an. Das führt bei denen, die ihr gutes Geld dafür ausgegeben haben, dann zu einer kognitiven Dissonanz: daß sie eine schlechte Entscheidung getroffen und ihr Geld verschwendet haben, kann und darf einfach nicht sein. Deswegen müssen diese Menschen ihre Entscheidung dann rechtfertigen, indem sie die eigene Software als so viel besser darstellen und die Alternative heruntermachen, daß die Ausgabe wieder als lohnenswert erscheint. Das sind übrigens keine pathologischen Verhaltensmuster, sondern das ganz normale Verhalten von psychisch gesunden Menschen. Nicht daß man mir noch unterstellt, ich wolle irgendwen als psychisch krank darstellen. Dieses Störfeuer ist für Leute, die über die kostenlose Alternative reden wollen, zwar nervig -- aber andererseits ist das ein Indiz für die hohe Leistungsfähigkeit der Alternative. Denn wenn die Alternative so schlecht wäre, wie sie den Geldausgebern geredet wird, wäre es doch offensichtlich, daß deren Ausgabe gerechtfertigt war. Gegen die Alternative zu pöbeln ist lediglich dann notwendig, wenn die Unterschiede in der Leistungsfähigkeit gerade nicht offensichtlich sind. Insofern: Ruhe bewahren, nicht ärgern. Wie Gandhi sagte: first they ignore you, then they laugh at you, then they fight you, and then you win. ;-) <<< Dieser Beitrag von Sheeva ist zu gut , als dass man ihn in der Vesenkung belässt.??
Zeno schrieb: > Arno schrieb: >> Nein, mehrere Pads für einen Pin kann Eagle soweit ich weiß nicht (wobei >> ich dazusagen muss, dass meine letzte Eagle-Version glaub ich eine 5 > > Doch Eagle kann das(s. Screenshot). Das wird mit dem "Append" Button > gemacht Und das mindestens ab der V.3.50. Die neuen feinen Funktionen werden doch total überbewertet. 99% die hier diskutieren machen doch das nicht im Broterwerb. Da reicht z.Bsp. mir meine oben genannte kleine gewerbliche Version von 1990. Es gibt keinerlei Grund, eine neuere Version oder gar ein anderes Programm zu verwenden. Als Neueinsteiger sieht das aber ganz anders aus. Und berufsmäßig muß man das nehmen, was in der Branche üblich ist. Egal ob einem das gefällt.
michael_ schrieb: > Es gibt keinerlei Grund, eine neuere Version oder gar ein anderes > Programm zu verwenden. Ich habe noch einen Eagle 2.0 mit Dongle - dass der noch auf einem heutigen Windows läuft, da habe ich so meine Zweifel...
Warum? Ich bin mit meinen W98 auf einen kleinen ThinkCentre umgezogen. Da laufen noch viele andere Sachen, wo du nicht mal von träumst.
il Conte schrieb: > In deinem zitierten Satz ging es um eine Antwort an Paul B. > der mich zu vor auf eine sehr subtile Art angegriffen hat , sowas lasse > ich nicht einfach so stehen. Laßt einfach mal alle Emotionen raus - das Leben wird so viel einfacher. Es ist hier in diesem Forum leider oft so das sich einige Leute sofort persönlich angegriffen fühlen, wenn irgend einer etwas gegen das Lieblingsprogramm, die Lieblings-IDE, das Lieblings-OS etc. etc. sagt. Einfach mal cool bleiben, eine andere Meinung auch mal akzeptieren - auch wenn diese mal spitz formuliert ist, denn es wird nichts so heiß gegessen wie es gekocht wird. Das Forum würde hierdurch unglaublich gewinnen. Zeno
michael_ schrieb: > Die neuen feinen Funktionen werden doch total überbewertet. > 99% die hier diskutieren machen doch das nicht im Broterwerb. > Da reicht z.Bsp. mir meine oben genannte kleine gewerbliche Version von > 1990. > > Es gibt keinerlei Grund, eine neuere Version oder gar ein anderes > Programm zu verwenden. > Als Neueinsteiger sieht das aber ganz anders aus. > Und berufsmäßig muß man das nehmen, was in der Branche üblich ist. > Egal ob einem das gefällt. So sehe ich das eigentlich auch. Die Beharkerei in Thread ist völlig überflüssig - egal von welcher Seite.
Ich habe mir das Kicad installiert. Mal sehen ob ich noch dahintersteige. Mindestens ist es nicht anfängerfreundlich. Erstmal weiß man nicht gleich, welches Programmteil zu starten ist. Dann gibt es einen Button für Vorlagen, aber der geht ins leere. Bei Target und Eagle hat man die sofort vor sich. Mal sehen.
Aber es macht sich. Als ich vor Jahren es getestet habe, konnte es keine V/R Annotation. Damals wurde das als Vorteil herausgestellt. Heute scheint es das zu können.
Zeno schrieb: > Es ist hier in diesem Forum leider oft so das sich einige Leute sofort > persönlich angegriffen fühlen, wenn irgend einer etwas gegen das > Lieblingsprogramm, die Lieblings-IDE, das Lieblings-OS etc. etc. sagt. Wetten, du meinst bestimmt EAGLE :-) Zeno schrieb: > Einfach mal cool bleiben, genau, hol dir eine cooles Bier und lese mal in aller Ruhe den Beitrag von Sheeva durch. (ein par Einträge weiter oben) Es wird dir gefallen. Tja da bekommt man z.B bei den Beiträgen von 'michael_' auf einmal einen ganz neuen Sichtweise :-)
il Conte schrieb: > genau, hol dir eine cooles Bier und lese mal in aller Ruhe den Beitrag > von Sheeva durch. Ich habe dies nicht geschrieben, damit Du es als Waffe auf Deinem Kreuzzug mißbrauchen kannst. Bitte laß' das und versteh' meinen Beitrag als das, was er sein soll: eine Erklärung dafür, wie sich manche Menschen verhalten und warum sie das tun. Meistens übrigens unterbewußt -- weshalb Deine Verweise auf meinen Beitrag sogar doppelt kontraproduktiv sind. Wenn Du ernsthaft für KiCad werben willst, ist das enorm einfach. Sei nett und freundlich zu Interessierten und neuen Benutzern, hilf' ihnen, schreib' vielleicht ein paar Tutorials für die Artikelsektion hier -- und halt Dich aus Eagle-Threads heraus, solange niemand nach KiCad fragt. Danke.
il Conte schrieb: > Wetten, du meinst bestimmt EAGLE :-) Nein! Die Aussage gilt für beide Seiten. Es gibt auf beiden Seiten Sturköppe die der Meinung sind, sie müßten den jeweils anderen missionieren. Ich habe bewußt keine Namen genannt, da ich dann höchst wahrscheinlich was los treten würde, womit niemanden geholfen wäre. Möge jeder mal seine Posts völlig emotionslos durchlesen und dabei mal darüber nachdenken was er da geschrieben hat. Mit ein bissel Abstand und mit dem Wissen um die Antwort erscheint dann manches in einem ganz anderen Licht. Und wenn jeder ehrlich zu sich selbst ist, dann wird er auch was finden was er lieber so nicht geschrieben hätte - da nehme ich mich selbst nicht aus. il Conte schrieb: > genau, hol dir eine cooles Bier und lese mal in aller Ruhe den Beitrag > von Sheeva durch. (ein par Einträge weiter oben) > Es wird dir gefallen. > Tja da bekommt man z.B bei den Beiträgen von 'michael_' > auf einmal einen ganz neuen Sichtweise :-) Ob mir der angesprochene Beitrag gefällt sei mal dahin gestellt. Im übrigen kann ich mir schon mein eigenes Urteil über die Beträge bilden. Michael hat halt eine andere Sicht auf die Dinge und das sollte man einfach mal akzeptieren, denn so ganz unbegründet sind seine Posts nun auch wieder nicht, da gibt es ganz andere Leute hier. Zeno
Hallo Sheeva Plug, Sheeva P. schrieb: > eine Erklärung dafür, wie sich manche > Menschen verhalten und warum sie das tun. Ich frage mich noch immer, ob diese Erklärung die ganze Wahrheit ist. Ja, es gibt Menschen, für die eine bestimmtes Auto das "Beste", "Vernünftigste", usw. ist, sobald sie es gekauft haben. Alles andere ist Mist, deswegen haben sie ja diesen gekauft. Das ändert sich dann, wenn der nächste ein anderes Modell oder sogar eine andere Marke wird. (Dann kann man plöttzlich sogar über den "Alten" lästern.) Aber : Ich tummele mich jetzt nicht so in Auto-Foren, aber ich glaube nicht, dass da jemand gezielt z.B. das Peugeot-Forum aufsucht, um dort für "seinen" Fiat oder VW Werbung zu machen. Ich habe mal nachgeschaut: nein, Fehlanzeige. Auch auf strickcommunity.net oder strickforum.de finde ich niemanden, der dort ständig "Häkeln ist besser als Stricken" postet. Und ganz ehrlich: Ich würde das dann auch nicht mehr als "das ganz normale Verhalten von psychisch gesunden Menschen" bezeichnen, wie Du es tust. Es muss also noch irgendetwas Anderes eine (große) Rolle spielen, so dass sich Ingenieure und Hobby-Elektroniker in bezug auf Software anders verhalten als die Woll-Freunde (obwohl die ja sogar die ganze Zeit mit so aggressiven Werkzeugen umgehen...). Sheeva P. schrieb: > Wenn Du ernsthaft für KiCad werben willst,... Vollkommen einverstanden!
Zeno schrieb: > Die Aussage gilt für beide Seiten. Es gibt auf beiden Seiten Sturköppe > die der Meinung sind, sie müßten den jeweils anderen missionieren. > Ich habe bewußt keine Namen genannt, da ich dann höchst wahrscheinlich > was los treten würde, womit niemanden geholfen wäre. > Möge jeder mal seine Posts völlig emotionslos durchlesen und dabei mal > darüber nachdenken was er da geschrieben hat. Mit ein bissel Abstand und > mit dem Wissen um die Antwort erscheint dann manches in einem ganz > anderen Licht. > Und wenn jeder ehrlich zu sich selbst ist, dann wird er auch was finden > was er lieber so nicht geschrieben hätte - da nehme ich mich selbst > nicht aus. Beste Aussage bisher!
Sheeva P. schrieb: > Ich habe dies nicht geschrieben, damit Du es als Waffe auf Deinem > Kreuzzug mißbrauchen kannst. Das kling so, als ob selbiges dein geistiges Eigentum ist - das sehe ich nicht so. Ich sehe in deinem Beitrag eine perfekt dargestellte und ausformulierte 'psychologische' Erklärung über Zusammenhänge die man mit Sicherheit überall nachgoogeln kann. Stichwort 'Kognitive Dissonanz'. Aber wenn es tatsächlich so sein sollte, dann schreib halt ein 'Copyrigt' unten drunter - basta.
Bernd W. schrieb: > Umgekehrt kann ich auch fragen: Werde ich zum Amateur, sobald mir mein > Job Spass macht? > > Ich glaube, es gibt wirklich Leute, die das so sehen. Natürlich ist es > für mich wichtig, eine *professionelle Distanz" zu meinem Job, dem > Werkzeug und den Werkstücken zu haben. und ich kann mir vorstellen, dass > mir das je nach Situation schwer werden kann..... Ach Bernd, eigentlich wäre es nützlich und gut, den sprachlichen Begriffen ihre eigentliche Bedeutung wiederzugeben anstatt sie - wie heutzutage sehr häufig - als Platzhalter für andere Inhalte zu mißbrauchen. Also: Ein Amateur ist im Grunde nur jemand, der sich aus persönlichem Interesse einer Sache widmet. Ein Professioneller hingegen ist einer, der sich dieser Sache nur deshalb widmet, weil er damit seinen Lebensunterhalt verdient. Das ist eigentlich der ganze Unterschied. Und JA, wenn du deinen Beruf mit Freude daran ausübst, bist auch du in dieser Hinsicht ein Amateur und Profi zugleich. Nicht mehr und nicht weniger. Alle anderen gemeinerweise unterlegten Bedeutungen wie Amateur=Nichtkönner oder doof und Profi=Könner oder schlau oder so ähnlich, sind falsch und auch verwerflich. Allerdings ist es häufig wohl so, daß die Liebe blind macht - wie man sagt. Ist zwar übertrieben, aber für das Zwischenmenschliche dringend erforderlich - aber das ist ein anderes Thema. ABER: wenn die Liebe zu einem Ding/Programm/technischem Irgendwas zu heftig wird, so daß man es mental zu hoch hängt und die immer vorhandenen Beschränktheiten nicht wahrnehmen will, sondern zu Anderen, denen selbige auffallen sagt "Lerne sie zu akzeptieren", dann ist man eben das, was hier "Fanboy" genannt wird. Kommen wir zu Begriffen wie "professionelles Werkzeug": Sowas gibt es zu Recht, auch im Baumarkt. Es ist ein Unterschied, ob man mal ein Werkzeug benötigt, um einige wenige Dinge zu tun (Bilder aufhängen nach Umzug) oder ob man tagaus tagein damit sein Geld verdienen muß. Für Ersteres braucht das Werkzeug nicht so durabel zu sein wie für Letzteres. Sinngemäß gilt das auch für EDA-Software. Es ist ein Unterschied, ob man sowas für's Hobbybasteln und Selberätzen oder für die Mainboard-Entwicklung bei Asus benötigt. Dazwischen gibt es eine ganze Reihe von Abstufungen und eben auch Programme verschiedener "Stufen". Da gibt es eben NICHT das allergrößte alleinseligmachende Programm, was alle Anderen in den Schatten stellt, sondern man sollte schauen, für welchen Bereich welches Programm geeignet ist. Regelmäßig sind die teuersten und "höchsten" Programme nur von Leuten bedienbar, die speziell dafür geschult sind und sie sind unbenutzbar für einen Allrounder, der nur gelegentlich mal ne LP macht. Andere Programme sind eher für eben diesen Allrounder gemacht und so weiter. Du selbst hast ja auch geklagt, daß du mit Eagle nicht zurande kamest - es gibt also wirklich die Schere zwischen verschiedensten Betätigungs- bzw. Berufs-Bereichen und den dafür geeigneten Programmen. So, nun kommen wir zur Bereichs-Einordnung von Kicad. Wo also paßt dieses Programm denn hin? Für welches Klientel ist es das Richtige? Das wären die Fragen, die hier zu diskutieren wären - anstelle der albernen Anpöbeleien. Ich selbst hatte durchaus große Hoffnungen auf Kicad, sehe aber, daß selbige am Verschwinden sind, weil ich nicht sehen kann, daß sich das Programm in eine gute Richtung entwickelt, weil eben in den Fundamenten schlechte Entscheidungen getroffen wurden, die umso schwerer zu korrigieren sind, je mehr Zeit ins Land geht. Ich hatte das mit dir schon viel früher ausführlich diskutiert. Natürlich könnte ich achselzuckend Kicad links liegen lassen, aber mich ärgert es durchaus, mit ansehen zu müssen, wie dort etwas schief läuft und viele Entwicklerstunden dabei vergeigt werden. Genau deshalb reite ich ja auf dem momentan ärgsten Bug im Grundentwurf so vehement herum. Glaub nicht, daß mir das Spaß macht - ich tu's weil ich eben die leise Hoffnung habe, daß es einer der Macher mal liest und akzeptiert - und daß es noch nicht zu spät ist, das Ruder herumzureißen. W.S.
W.S. schrieb: > Allerdings ist es häufig wohl so, daß die Liebe blind macht Das gilt auch und besonders für die Eigenliebe. Oder wie erklärst Du Dir Äußerungen wie diese: W.S. schrieb: > Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof. W.S. schrieb: > mich ärgert es durchaus, mit ansehen zu müssen, wie dort etwas schief > läuft und viele Entwicklerstunden dabei vergeigt werden. > > Genau deshalb reite ich ja auf dem momentan ärgsten Bug im Grundentwurf > so vehement herum. OK, ich verstehe ja, dass es Dich ärgert, wenn ein Programm nicht so funktioniert, wie Du es gerne hättest. Aber musst Du deshalb diesen Ärger zum Leitmotiv Deiner Postings machen? Was haben denn Deine Mitmenschen getan, dass sie nun Opfer Deines Ärgers werden müssen? Dabei gibt es doch ganz andere Möglichkeiten, wie Du die durch Deinen Ärger freigesetzte Energie sinnvoll einsetzen kannst: - Es ist doch quelloffen! Mache einfach einen Fork. Wenn Deine Lösung von der Mehrheit als besser angesehen wird, hast Du auch nicht viel Arbeit damit - das Ding wird ein Selbstläufer. - Wenn es ein Bug ist, mache einen Bug-Report. Wenn Andere das anders sehen, dann ist es wohl kein Bug in der Software sondern vielleicht ein Problem bei Dir. Oder einfach nur eine alternative Betrachtungsweise. Oder meinst Du, indem Du andere als "doof" oder ahnungslos beschimpfst, motivierst Du sie, Dir eine Software nach Deinem Gusto zu schreiben?
np r. schrieb: > auf dem momentan ärgsten Bug im Grundentwurf >> so vehement herum. Ichschaue mir gern Bilder an. Könnte dieser Bug erläutert werden, damit auch ich diesen verstehe?
np r. schrieb: > OK, ich verstehe ja, dass es Dich ärgert, wenn ein Programm nicht so > funktioniert, wie Du es gerne hättest. > Aber musst Du deshalb diesen Ärger zum Leitmotiv Deiner Postings machen? Natürlich. Wenn keiner den Programmierern sagt, was ihn ärgert, dann werden die es nie erfahren. Um die Sache mal ein bissel karer zum Ausdruck zu bringen, zitiere ich hier mal was, es ging um's Koordinatensystem: by straubm ("https://forum.kicad.info/users/straubm";): "If KiCad wants to successfully play in the field of professional CAD, it simply has to tackle the issue. But then, does anybody really want to be in this field in the developer community? I feel that KiCad will be facing the chasm (refer to Geoffrey A. Moore's marketing book) really soon now and will have to decide whether it wants to cross it, or not. Marketing mechanisms also apply to KiCad, that's not a matter of free/paid for product, it is about market penetration. Sorry to mention marketing in a tech environment, but that's what it is. So: what is the "market"? This has to be decided. But then: how and by whom? There are a lot of issues currently in discussion - at least in this forum - which point in the same direction: the layer manager discussion, customer configurable menus, the coordinate issue, library structure and management, to name only a few of them. It will be interesting to see what KiCad wants to be, where it will be headed." Ja, man wird ja sehen, wohin die Reise bei Kicad gehen wird. Die mit weitem Abstand am meisten angeführten Argumente für Kicad und gegen den Rest der EDA-Welt bestehen aus: 1. es ist frei verfügbar und kostet nix, 2. es ist quelloffen. 3. es hat nen Push&Shove-Router. Was da jedoch alles dagegen spricht, sind eben die vielfältigen im Zitat genannten "issues": 1. Bibliotheksstrukturen und Bibliotheksmanagement (eben das worauf ich hier herumhacke) 2. hakeliges Userinterface. Punkt 2 kann man verbessern, ohne an den Grundfesten zu sägen. Dazu gehört auch das Koordinaten- und Nullpunkt-Problem. In diesem speziellen Punkt ist Kicad nicht allein, sowas wie Pulsonix hat auch den Nullpunkt links unten und benimmt sich beim Zoomen daneben - im Gegensatz zu Eagle, was das alles richtig macht. Punkt 1 hingegen kann nur durch Sägen an den Grundfesten wirklich in Ordnung gebracht werden. Einen anderen Weg sehe ich nicht. Es ist eben die Herangehensweise Symbol-->Footprint, die sozusagen eine Einbahnstraße in die falsche Richtung darstellt. W.S.
Lutz H. schrieb: > Ichschaue mir gern Bilder an. Könnte dieser Bug erläutert werden, damit > auch ich diesen verstehe? Siehe hier im Nachbar-Thread: Beitrag "Re: Autodesk Eagle 8.0 ist da." Es geht W.S. offenbar darum, wann im Workflow die Verbindung zwischen schematischem Symbol und Footprint gemacht wird. Die von W.S. gewünschte Variante ist auch mit KiCAD möglich, wie ihm, wenn ich das richtig sehe, auch bereits erklärt wurde. Sie erfordert allerdings Eigeninitiative, die er jedoch lieber bei Anderen sucht als bei sich selbst. Bug-Report, Fork oder Contribution entsprechend konfigurierter Symbole fallen mir dazu spontan als Lösungsmöglichkeiten ein. Alle haben aber den Nachteil, dass sie über bloßes Meckern hinausgehen und man sich ggfs. für den Unsinn, den man selber gemacht hat, kritisieren lassen muss, statt Andere beschimpfen zu können.
W.S. schrieb: > > Aber musst Du deshalb diesen Ärger zum Leitmotiv Deiner Postings machen? > > Natürlich. Ah so - OK. Alternativ könnte man auch den Ärger 'runterschlucken und ganz sachlich argumentieren und vor allem: ergebnisoffen. Wäre das vielleicht eine Option für Dich? Es könnte solche Ausfälle vermeiden helfen: W.S. schrieb: > Wer das nicht kapieren will, ist für's Leiterplatten-Machen zu doof.
W.S. schrieb: > np r. schrieb: >> OK, ich verstehe ja, dass es Dich ärgert, wenn ein Programm nicht so >> funktioniert, wie Du es gerne hättest. >> Aber musst Du deshalb diesen Ärger zum Leitmotiv Deiner Postings machen? > > Natürlich. Wenn keiner den Programmierern sagt, was ihn ärgert, dann > werden die es nie erfahren. Und du glaubst ernsthaft, indem du hier in jedem Thema deinen Ärger zu KiCad ablässt, erfährt irgendeiner der Programmierer davon? Das ist das falsche Forum... MfG, Arno
W.S. schrieb: > Es ist eben > die Herangehensweise Symbol-->Footprint, die sozusagen eine > Einbahnstraße in die falsche Richtung darstellt. Falsch, weil es dir nicht gefällt oder falsch, weil du dich nicht umgewöhnen willst? Ich will jetzt nicht nochmal über diese Thematik diskutieren, aber du solltest dir angewöhnen, dass es auch andere Meinungen auf diesem Planeten gibt. Ich finde diese herangehensweise richtig und bin damit auch nicht alleine. Begründungen gab es hier schon genug. Du kannst gerne sagen, es gefällt dir nicht. Aber nur deswegen ist es noch lange kein Designfehler. Es ist und bleibt eine Frage der Sichtweise.
Hi np rn, np r. schrieb: > Sheeva P. schrieb: >> eine Erklärung dafür, wie sich manche >> Menschen verhalten und warum sie das tun. > > Ich frage mich noch immer, ob diese Erklärung die ganze Wahrheit ist. Vermutlich nicht. > Und ganz ehrlich: Ich würde das dann auch nicht mehr als "das ganz > normale Verhalten von psychisch gesunden Menschen" bezeichnen, wie Du es > tust. Verzeihung, das ist ein Mißverständnis. Ich habe damit nicht gemeint, daß sich psychisch gesunde Menschen so verhalten müssen -- die allermeisten Verhaltensweisen psychisch gesunder Menschen geschehen nicht zwangsläufig. Im Gegenteil sind Zwangshandlungen ja häufig eine Folge einer psychischen Krankheit. Mir ging es mit dem Hinweis darauf, daß diese Verhaltensweisen die eines psychisch gesunden Menschen sind, hingegen ausdrücklich darum, daß ich das Verhalten nicht als "krank" darstellen wollte. > Es muss also noch irgendetwas Anderes eine (große) Rolle spielen, so > dass sich Ingenieure und Hobby-Elektroniker in bezug auf Software anders > verhalten als die Woll-Freunde (obwohl die ja sogar die ganze Zeit mit > so aggressiven Werkzeugen umgehen...). Die Woll-Freunde haben dabei andere Trigger, aber auch da gibt es hin und wieder erbitterte Diskussionen um Moulesing, Stricknadeln, Stricknadel-Hersteller, -Materialien und die richtige Stricknadel für eine bestimmte Wolle, denn nicht jeder Wolletyp gleitet auf jeder Nadel gleich gut. Hinzu kommen zum Teil heiße Diskussionen über Wollwickler, Maschenmarkierer und allerlei anderes Strickgerät. (Was für ein Zufall, daß Du gerade dieses Beispiel gewählt hast. Da konnte ich die beste Ehefrau von allen fragen, die betreut nämlich die Social Media-Aktivitäten und die Online-Community eines der größten deutschen Wollanbieter. ;-)
il Conte schrieb: > Das kling so, als ob selbiges dein geistiges Eigentum ist - > das sehe ich nicht so. Darum geht es nicht. Ich wollte ein normales menschliches Verhalten erklären und darauf hinweisen, daß es weder böswillig geschieht noch als persönlicher Angriff zu verstehen ist. Du jedoch mißbrauchst meine deeskalierend gemeinte Erklärung zur Provokation, um Dein Gegenüber zu unterstellen, es sei -- ja, was eigentlich? Ein normaler Mensch mit normalem, menschlichem Verhalten?
Sheeva P. schrieb: > Du jedoch mißbrauchst meine > deeskalierend gemeinte Erklärung zur Provokation, um Dein Gegenüber zu > unterstellen Mit Verlaub das weise ich zurück. Du hast hier ein Auftreten wie der 'KTG'. Du hast selbst ja nur abgeschrieben, und ich habe es zugegebener maßen auch, mehr nicht. Und was die 'Unterstellungen' anbetrifft - fasst dich mal an die eigene Nase :-(
il Conte schrieb: > 'KTG' Bevor Ihr da lange rumrätselt was das zu bedeuten hat: 'KTG' ist die Abkürzung für Karel-Theodor zu Guttenberg. Das ist derjenige der sein Doktorarbeit abgeschrieben hat. (zusammen mit der Frau Schawan, die war es auch die ihn zuvor hingehängt hat :(
il Conte schrieb: > il Conte schrieb: Jetzt hör doch endlich auf, der Thread ist doch eh schon kaputt :-((
Beitrag #4944439 wurde von einem Moderator gelöscht.
Beitrag #4944450 wurde von einem Moderator gelöscht.
W.S. schrieb: [..] > > Kommen wir zu Begriffen wie "professionelles Werkzeug": Sowas gibt es zu > Recht, auch im Baumarkt. Es ist ein Unterschied, ob man mal ein Werkzeug > benötigt, um einige wenige Dinge zu tun (Bilder aufhängen nach Umzug) > oder ob man tagaus tagein damit sein Geld verdienen muß. Für Ersteres > braucht das Werkzeug nicht so durabel zu sein wie für Letzteres. Ich weiß ja nicht was Du für Baumärkte kennst, aber die in denen ich herumlaufe zeichnen sich eigentlich durchgängig dadurch aus das genau der Kram als "Profi" gekennzeichnet ist, der diesen Zweck keinesfalls erfüllt. Gutes Werkzeug macht eigentlich keinen Gebrauch von solchen "werbewirksamen" (aber indessen verbrannten) Begriffen, sondern ist einfach nur teuer (zumindest zum Teil zurecht). Genau so war das was ich schrieb auch gemeint. > > Sinngemäß gilt das auch für EDA-Software. Es ist ein Unterschied, ob man > sowas für's Hobbybasteln und Selberätzen oder für die > Mainboard-Entwicklung bei Asus benötigt. Kennst Du ein Asus Mainboard das mit Eagle entwickelt wurde oder haust Du einfach mal wieder auf den Schlamm? [..] > So, nun kommen wir zur Bereichs-Einordnung von Kicad. > > Wo also paßt dieses Programm denn hin? > > Für welches Klientel ist es das Richtige? Es befindest sich mitten in der Kategorie "worksforme" und auch in der "worksforCern". > Das wären die Fragen, die hier zu diskutieren wären - anstelle der > albernen Anpöbeleien. ...wie z.B. zu doof zum Platinen machen? > > Ich selbst hatte durchaus große Hoffnungen auf Kicad, sehe aber, daß > selbige am Verschwinden sind, weil ich nicht sehen kann, daß sich das > Programm in eine gute Richtung entwickelt, weil eben in den Fundamenten > schlechte Entscheidungen getroffen wurden, die umso schwerer zu > korrigieren sind, je mehr Zeit ins Land geht. Ich hatte das mit dir > schon viel früher ausführlich diskutiert. > > Natürlich könnte ich achselzuckend Kicad links liegen lassen, aber > mich ärgert es durchaus, mit ansehen zu müssen, wie dort etwas schief > läuft und viele Entwicklerstunden dabei vergeigt werden. Hmm... Mach einfach weiter, das wird der Akzeptanz von KiCad keinen Schaden zu fügen sondern nur der Einordnung des Anonymous "W.S." als PCB-Cad-Nichtfachmann dienen. Du machst Dich unmöglich, merkst es aber nicht mal. > Genau deshalb reite ich ja auf dem momentan ärgsten Bug im Grundentwurf > so vehement herum. Glaub nicht, daß mir das Spaß macht - ich tu's weil > ich eben die leise Hoffnung habe, daß es einer der Macher mal liest und > akzeptiert - und daß es noch nicht zu spät ist, das Ruder herumzureißen. > > W.S. Guten Ritt noch..Hals und Beinbruch oderwieauchimmer. Da Dir das keinen Spaß macht bescheinige ich Dir hier mein aufrichtiges Mitleid bei diesem geradezu heroischen Kampf.. Gruß, Holm
Also ich wollte mich jetzt mal über den Stand bei KiCad informieren. Da fang ich den Thread von unten an bis ich auf einen Beitrag stoße den ich schon kenne. Das was ich da lesen muss ist endloses PsychoGeschwafel irgendwelcher Typen um diese oder jene Umgangs- bzw. Verfahrensform. Die einzige inhaltliche "Meinung" zu dem Thema die ich gefunden habe wird mit dem Vorwurf erwidert doch selber Beizutragen. Das was dieser User dann "zitiert" -wenn die Entwickler dies und das wollen dann müssen Sie jenes und welches tun- ist einer dieser übergiffigen Beiträge von Schlaumeiern die alles besser wissen aber es nicht selber können/wollen. Auf die hat die Welt natürlich genau so gewartet wie auf diejenigen die so ein getrolle auch noch füttern See you next year, ich bleib bei meinem Programm.
Beitrag #4944481 wurde von einem Moderator gelöscht.
radiostar schrieb: > der Thread ist doch eh schon kaputt :-(( Na, dann führen wir den Thread doch einfach auf sein Thema zurück: KiCAD ist im Kommen! (Juchhe!) Auch ich bin vor ein paar Jahren nach KiCAD umgestiegen, allerdings nicht von Eagle sondern von gEDA. (Öhm, das disqualifiziert mich jetzt, oder?) Egal, also, auch ich benutze nun KiCAD und bin sehr zufrieden damit. Denn obwohl es quelloffen ist und man nichts dafür bezahlen muss, außer etwas "Lebenszeitverschwendung" für das Erlernen seiner Bedienung, kann man damit Leiterplatten designen, die erfolgreich hergestellt und bestückt werden können. Und am Ende funktioniert der Kram sogar wie designt! Ich freue mich also, dass KiCAD neue Nutzer findet (natürlich allesamt doofe Fanboys), die hoffentlich viel zu KiCAD beitragen, so dass das Programm feature-reicher und noch besser bedienbar wird. Insbesondere freue ich mich natürlich auf die Beiträge von - unter Anderen - W.S., die für KiCAD sicher ein Quantensprung sein werden. Prost!
X4U schrieb: > Also ich wollte mich jetzt mal über den Stand bei KiCad informieren. Oh, da hat Dir aber jemand ein X für ein U vorgemacht. Der Thread "KiCAD ist im Kommen" hatte wohl kaum die Absicht, Dich über "den Stand" bei KiCAD zu informieren. Probier's mal bei kicad-pcb.org. Sollte Dich die Suche dort aber überfordern, dann ist dies sicher die Lösung für Dich: X4U schrieb: > ich bleib bei meinem Programm. Selbst geschrieben?
Beitrag #4944528 wurde von einem Moderator gelöscht.
Beitrag #4944550 wurde von einem Moderator gelöscht.
np r. schrieb: > so dass das > Programm feature-reicher Ich suche die Stelle, warum eine separierte Leiterbahn keinen Namen erhält, wenn die Datei wieder eingelesen wird. Der Bug ist eingestellt und irgendwo liegen die Quellen von KICAD. https://bugs.launchpad.net/kicad 1673940 Jetzt meine Frage. Wenn ich den Quellcode von KICAD näher anschauen will, wo starte ich am Besten?.
Ich würde mir im Sourcecode die Stelle suchen, wo die Netznummer in die Boarddatei geschrieben wird, also irgendwas wie "net %d" (oder "net %u") steht. Im Speicher gibt es ja die Netzinfo offensichtlich noch (es steht "GND" an den Rest-Segmenten, und du kannst sie auch wieder verbinden), aber beim Abspeichern zerstört wer diese Info, und es wird Netz 0 eingetragen. Edit: Hmm, in meiner abgespeicherten Datei (bzr 6714, nicht mehr so ganz taufrisch) steht in der Datei noch "net 1", trotzdem wird beim Einlesen die Zuordnung zu "/GND" nicht hergestellt. Scheint also zwei separate Probleme zu geben. Edit[2]: Das Schreiben der Daten scheint in pcbnew/kicad_plugin.cpp zu erfolgen. Möglicherweise ist da auch das Einlesen drin. Habe gerade keine Zeit, mir das näher anzusehen.
:
Bearbeitet durch Moderator
Für mich geht es um den Quellcode von Kicad, der verwaiste Leitungstücke
zum Net 0 Name "" beim Lesen von der Datei macht. Wie ich die Stelle im
Code finden kann. Der Fehler ist für mich eindeutig beschrieben. Es
müsste irgendeine interne Tabelle geben, wenn diese mit Werten für die
Segmente gefüllt wird, vergisst KICAD eine Möglichkeit und benennt
leider nur, wenn pads angeschlossen sind.
Zeilennummer in den Dateien so bei 144.
Beim der Leiterplatte mit den verbundenen Pads wurde das obere Stück
getrennt und dann abgespeichert.
Im File GND-nameGND.kicad_pcb steht beim ersten Abspeichern: net 1
(segment (start 50.165 44.45) (end 62.23 44.45) (width 0.25) (layer
F.Cu) (net 1))
(segment (start 62.23 44.45) (end 59.055 41.275) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD43))
(segment (start 59.055 41.275) (end 59.055 29.845) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD46))
(segment (start 59.055 29.845) (end 60.325 28.575) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD48))
(segment (start 60.325 28.575) (end 86.36 28.575) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD4A))
(segment (start 86.36 28.575) (end 84.455 30.48) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD4C))
(segment (start 84.455 30.48) (end 84.455 46.355) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD4D))
(segment (start 84.455 46.355) (end 101.6 46.355) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD4F))
(segment (start 101.6 46.355) (end 100.965 46.355) (width 0.25) (layer
F.Cu) (net 1) (tstamp 58CAFD51))
Dann wird eingelesen (NET 0 ) angezeigt beim unveränderten
Abspeichern steht im File
GND_name_none.kicad_pcb fehlerhaft net 0
(segment (start 59.055 29.845) (end 60.325 28.575) (width 0.25) (layer
F.Cu) (net 0) (tstamp 58CAFD48))
(segment (start 60.325 28.575) (end 86.36 28.575) (width 0.25) (layer
F.Cu) (net 0) (tstamp 58CAFD4A))
(segment (start 86.36 28.575) (end 84.455 30.48) (width 0.25) (layer
F.Cu) (net 0) (tstamp 58CAFD4C))
******* (net 0) Fehler beim Einlesen, das erste Abspeichern war
i.O.
Jörg W. schrieb:
> Wenn die Kette unterbrochen ist, kann es keine solche Zuordnung mehr
> geben.
Beim ersten Abspeichern bleibt die Zuordnung zu net 1 erhalten, obwohl
die Kette unterbrochen ist, auch während der normalen
Leiteplattenentwicklung, sind vom Arbeitsablauf her, beliebig viele
solcher Segmente möglich.
:
Bearbeitet durch User
Jörg W. schrieb: > Ich würde mir im Sourcecode die Stelle suchen, wo die Netznummer in > die Boarddatei geschrieben wird, also irgendwas wie "net %d" (oder > "net %u") steht. Im Speicher gibt es ja die Netzinfo offensichtlich > noch (es steht "GND" an den Rest-Segmenten, und du kannst sie auch > wieder verbinden), aber beim Abspeichern zerstört wer diese Info, > und es wird Netz 0 eingetragen Ich möchte dir nicht zu nahe treten, aber glaubst du nicht auch, dass dies die Mehrheit der Mitleser und Schreiber hier in diesem KiCAD Thread, das wenig bis gar nicht interessiert?
Wollte zeigen wie groß KICAD ist. Jörg W. schrieb: > pcbnew/kicad_plugin.cpp Danke.
:
Bearbeitet durch User
Lutz H. schrieb: > Für mich geht es um den Quellcode von Kicad, der verwaiste Leitungstücke > zum Net 0 Name "" beim Lesen von der Datei macht. Wie ich die Stelle im > Code finden kann. Der Fehler ist für mich eindeutig beschrieben. Es > müsste irgendeine interne Tabelle geben, wenn diese mit Werten für die > Segmente gefüllt wird, vergisst KICAD eine Möglichkeit und benennt > leider nur, wenn pads angeschlossen sind. Wäre es nicht für uns alle gewinnbringender, wenn du dich bei kicad-pcb.org. direkt einbringst und dort aktiv mit machst? Als das du dich hier Fachsimpeleien hingibst die für dritte wenig durchsichtig sind.
il Conte schrieb: > Jörg W. schrieb: >> Ich würde mir im Sourcecode die Stelle suchen, wo die Netznummer in >> die Boarddatei geschrieben wird, also irgendwas wie "net %d" (oder >> "net %u") steht. Im Speicher gibt es ja die Netzinfo offensichtlich >> noch (es steht "GND" an den Rest-Segmenten, und du kannst sie auch >> wieder verbinden), aber beim Abspeichern zerstört wer diese Info, >> und es wird Netz 0 eingetragen > > > Ich möchte dir nicht zu nahe treten, aber glaubst du nicht auch, > dass dies die Mehrheit der Mitleser und Schreiber hier in diesem > KiCAD Thread, das wenig bis gar nicht interessiert? Das ist nicht relevant weil ich hier in diesem Thread schon viele Sachen gelesen habe die mich nicht interessieren und wahrscheinlich die Mehrheit der Leser nicht. Allerdings halte ich Jörg für einen guten bis sehr guten Programmierer und Elektroniker und mich interessieren seine Ideen dazu schon, weil auch ich in den Sourcen herumstochere.. Gruß, Holm
Beitrag #4944991 wurde von einem Moderator gelöscht.
Beitrag #4945015 wurde von einem Moderator gelöscht.
Beitrag #4945019 wurde von einem Moderator gelöscht.
Beitrag #4945032 wurde von einem Moderator gelöscht.
Beitrag #4945037 wurde von einem Moderator gelöscht.
Beitrag #4945165 wurde von einem Moderator gelöscht.
Beitrag #4948932 wurde von einem Moderator gelöscht.
Ich habe KICAD nach dem ausprobieren auch direkt wieder deinstalliert. Warum jetzt das nachträgliche Zuordnen von Footprints vorteilhaft sein soll wurde hier zwar ausgiebig erörtert, aber für mich ist das einfach nicht sinnvoll.
Hans Wurst schrieb: > Ich habe KICAD nach dem ausprobieren auch direkt wieder deinstalliert. > > Warum jetzt das nachträgliche Zuordnen von Footprints vorteilhaft sein > soll wurde hier zwar ausgiebig erörtert, aber für mich ist das einfach > nicht sinnvoll. Muss es auch nicht sein. KiCad lässt Dir die Freiheit, es vorher oder nachher zu machen. Steht aber auch hier im Thread: Beitrag "Re: KiCAD ist im Kommen"
Hans Wurst schrieb: > Es wäre schon schön wenn den Bauteilen Standard-Footprints zugeordnet > wären Wie würde das bei dem Widerstand-Symbol genau funktionieren?
Hans Wurst schrieb: > Es wäre schon schön wenn den Bauteilen Standard-Footprints zugeordnet > wären Dann muss aber auch eine Rubrik SMD oder THT als Standard auswaehlbar sein, das fuehrt dann schnell ins Chaos. wendelsberg
Mampf F. schrieb: > Hans Wurst schrieb: >> Es wäre schon schön wenn den Bauteilen Standard-Footprints zugeordnet >> wären > > Wie würde das bei dem Widerstand-Symbol genau funktionieren? Da müssten ja dann -angefangen vom kleinsten SMD bis zum Brocken mit 1kW- sämtliche verfügbare Bauformen dranhängen. Das macht die Sache dann sehr übersichtlich ;-)
Mampf F. schrieb: > Wie würde das bei dem Widerstand-Symbol genau funktionieren? Wenn jemand den Unterschied zwischen einem einem realem Bauteil und der Darstellung als Model in eimen Computerprogramm nicht versteht ist es schwierig ohne 1:1 Verknüpfung zu arbeiten (Einkauf, Vertrieb, Management). Jedes Bauteil ( der Widerstand R42 auf der Leiterplatte) braucht manchmal eine komplette Darstellung über den kompetten Entwicklungsprozess. Für jeden Widerstand alles und nicht veränderbar vom Schaltplansymbol, PCBlayout, Spice Modell, Lieferant... .
Lutz H. schrieb: >... >... > Für jeden Widerstand alles und nicht veränderbar vom Schaltplansymbol, > PCBlayout, Spice Modell, Lieferant... . Kannst Du das auch so erklaeren, dass ein normal technisch Begabter das versteht? wendelsberg
Das Heraussuchen des passenden Footprints aus allen verfügbaren Footprints ist aber noch unübersichtlicher. Wenn dem Widerstandssymbol schon mal eine Auswahl von passenden Footprints zugewiesen wäre würde dies die Sache einfacher und schneller machen. Aber warum wird denn kein Footprint beim Atmega 1284P-PU vorgegeben, den es genau so in den KICAD-Standardlibs gibt. Eine Footprintauswahl für dieses Bauteil ist doch totaler Unfug.
Hans Wurst schrieb: > Das Heraussuchen des passenden Footprints aus allen verfügbaren > Footprints ist aber noch unübersichtlicher. Wenn dem Widerstandssymbol > schon mal eine Auswahl von passenden Footprints zugewiesen wäre würde > dies die Sache einfacher und schneller machen. Und welche wären das? Ich verwende so gut wie nie Widerstände größer SMD 1206 ... Wenn man die Zuweisung öfter mal gemacht hat, funktioniert das überaus schnell.
Mampf F. schrieb: > Hans Wurst schrieb: >> Das Heraussuchen des passenden Footprints aus allen verfügbaren >> Footprints ist aber noch unübersichtlicher. Wenn dem Widerstandssymbol >> schon mal eine Auswahl von passenden Footprints zugewiesen wäre würde >> dies die Sache einfacher und schneller machen. > > Und welche wären das? > > Ich verwende so gut wie nie Widerstände größer SMD 1206 ... > > Wenn man die Zuweisung öfter mal gemacht hat, funktioniert das überaus > schnell. Und wenn es mal doch eine andere Baugröße oder THT sein muss?
wendelsberg schrieb: > Kannst Du das auch so erklaeren, dass ein normal technisch Begabter > das versteht? Für jedes Bauteil hat Eigenschaften. Einige davon sind nirgens beschrieben oder unbekannt. Manchmal werden solche Eigenschaften unbewusst genutzt. Fehlen diese könnte es sein, dass die Funktion nicht vollständig erfüllt wird. Zum Beipiel Scheinefleich: In Deutschland wird das Fleich geschlachteter Schweine auf Trichinen untersucht und dadurch kann das Fleich gefahrlos gegessen werden. Diese Eigenschaft ist vielen Fleichkäufern ungekannt. Wenn jetzt irgendwo auf der Welt Schwinefleich gegessen wird, dass Trichinen hat, ist eine Erkrankung möglich. So sind im Produktionsprozess immer Menschen beschäftigt, die nicht die gesammten Eigenschaften eines Produktes verstehen, sondern diese nur nutzen. So werden irgendwelche spice Modelle zusammenkopiert, ohne die Kenntniss der mathematischen Eigenschaften. Deshalb kann eine 1:1 Zuordnung Ergebnisse nachvollziebar machen.
:
Bearbeitet durch User
Lutz H. schrieb: > Deshalb kann eine 1:1 Zuordnung Ergebnisse nachvollziebar machen. Diese Bibliothek musst Du dann aber - im Einklang mit Deinem Lagerverwaltungstool - von Grund auf selber zusammenstellen. Und das kann man in Kicad problemlos machen. Man muss aber nicht. Einige Footprints vorschlagen, von denen man einen auswählt - auch das kann man in Kicad. Aber auch hier: Man kann sich die vorgeschlagenen oder alle Footprints auflisten lassen.
Helmut S. schrieb: > Gibt es bestimmte Verzeichniss und/oder Registry in der ich auch "Reste" > der vorherigen KiCAD-Installation löschen sollte bevor ich es neu > installiere? Wir haben nicht mehr 1995.
Hans Wurst schrieb: > Atmega 1284P- gibt es in drei Gehaeusen: Ordering Code Package ATmega1284P-AU(2) 44A ATmega1284P-PU(2) 40P6 ATmega1284P-MU(2) 44M1 Wenn allerdings das -PU schon zum Schaltplansymbol zugeordnet ist, dann koennte theoretisch auch direkt der Footprint zugeordnet sein. Warum sollte man sich aber schon im Schaltplan festlegen? wendelsberg
Man kann bei KiCAD einem Bauteil eine Maske für passende Footprints zuordnen, ggf. auch so konkret, dass nur ein einziger passt und dadurch quasi fest zugeordnet ist. Wirklich gut gelöst ist das trotzdem nicht. Diese Zuordnung ist lediglich der Name der entsprechenden Datei und leider werden bei KiCAD von Version zu Version diese Dateien gerne einmal umbenannt. Dann fliegt einem das um die Ohren und man darf manuell korrigieren.
:
Bearbeitet durch User
Ich wage mal eine Vermutung aufgrund dessen, was ich hier lese: Was die meisten der an Eagle gewöhnten von Kicad abschreckt, ist gar nicht Kicad, sondern die Bibliotheken. Eben, z.B. dass Kicad doch Footprints vorschlagen soll, und nicht einfach alle als Option präsentieren kann. Kicad kann das. Aber es muss halt (logischerweise) auch in der Bibliothek eingepflegt sein. Die Bibliothek, die mit Kicad daherkommt, ist halt, verglichen mit Eagle (auch eine Vermutung, ich kenne es nicht) viel kleiner, und auch generischer. Aber eine Bibliothek aufbauen, die einem R eine mögliche Handvoll Footprints zuweist, oder auch eine eigene Komponente "R in 0603" - oder sogar eine eigene Komponente "R 100kOhm 0.1% in 0603, Art. Nr. xyz von Lieferant abc" - kein Problem. Kann man machen.
Detlev T. schrieb: > leider werden bei KiCAD > von Version zu Version diese Dateien gerne einmal umbenannt. Dazu muss ich gestehen, dass das wohl stimmen mag. Ich verwende halt sowieso nur sehr wenige "Standard" Bibliothekskomponenten, sondern lege immer alles was ich brauche in einer eingenen Bibliothek an. Entweder rüberkopiert (und dann gleich überprüft) oder selber gezeichnet. Bevor ich eine Komponente herausgesucht habe, die einem STM32 in genau dieser Variante in genau diesem Gehäuse entspricht, habe ich schnell aus den Angaben im Datenblatt ein Schemasymbol generiert und den passenden Footprint zugeordnet. Und bevor ich den Micro-USB Stecker des Herstellers XYZ in der liegenden Variante mit diagonal angeordneten Fixierungs-Pins herausgefunden und verifiziert habe, dass es auch wirklich der ist, habe ich ihn schnell gezeichnet. Damit lehne ich mich jetzt ein bisschen aus dem Fenster und tue vielleicht vielen Eagle-Nutzern Unrecht. Aber mich dünkt es manchmal, dass genau diese Eigenart, dass es für jede Variante von fast jedem auf der Erde existierenden Bauteil genau eine definierte Komponente gibt, oft eher einengt als hilft. Wie oft liest man hier im Forum: "Hat jemand eine Eagle-Komponente für dieses Bauteil? Ich finde leider nur eines in der leicht anderen Variante". Dass nur schon so eine Frage gestellt wird, ist doch merkwürdig. Ich weiss nicht, ob das an Kicad liegt, aber mir fällt nicht im Traum ein, irgendjemanden nach irgendeiner Komponente zu fragen, denn bevor ich die Frage formuliert habe, habe ich das Teil gezeichnet.
:
Bearbeitet durch User
Simon H. schrieb: > Was die > meisten der an Eagle gewöhnten von Kicad abschreckt, ist gar nicht > Kicad, sondern die Bibliotheken Also ich nutze Eagle seit mehr als zehn Jahren und habe mich vor kurzem in KiCAD eingearbeitet, weil ich Open Hardware Projekte damit machen will. Inzwischen komme ich damit ganz gut klar und ich kann mit KiCAD ähnlich produktiv umgehen wie mit Eagle. Deshalb erlaube ich mir einmal eine Bewertung und die lautet: Es sind auch, aber nicht nur die Bibliotheken. Die bei Eagle feste Zuordnung der Footprints zu dem Schaltplansymbol, das dann Bestandteil der Bibliotheksdatei wird, halte ich für praktikabler und sicherer. KiCAD zwingt einem eher einen bestimmten Workflow auf, das mag einem passen oder nicht. Z.B. ohne Hot-Keys kommt man bei KiCAD nicht wirklich voran. Hierachische Schaltpläne und abgestufte "Globalität" von Netznamen mag professioneller sein, verlangt aber mehr Vorausplanung und ist eine Falle für Eagle-Jünger, die davon ausgehen, gleicher Name = verbunden. Manches muss man explizit machen, was bei Eagle automatisch geht (Annotation neuer Bauteile, Backward-Annotation), muss bei KiCAD explizit gemacht werden. Wann man die Netzliste explizit importieren/exportieren muss und wann man sich das sparen kann, bin ich mir immer noch nicht sicher. Der Bauteil-Editor ist auch unübersichtlich in seiner Arbeitsweise. In der Summe sage ich trotzdem, dass man mit KiCAD produktiv arbeiten kann. In der kommerziellen Entwicklung würde ich es zur Zeit allerdings noch nicht einsetzen. Da wird noch zu viel verändert und deshalb kann man sich auf die Konsistenz noch nicht ausreichend verlassen.
wendelsberg schrieb: > Warum sollte man sich aber schon im Schaltplan festlegen? Um mögliche Verwechselungen oder Fehler durch einen Vergleich zu finden. So habe ich heute Möbelgleiter gekauft. Ich sollte lt. Möbelgleiteranleitung mit 1mm 20 tief für die Schraube vorbohren. Der Verkäufer hat sich gefreut einen 1mm Bohrer gefunden zu haben und ich kaufte diesen. Nachdem der Bohrer abgebrochen war, stellte ich fest, dass er nur eine Förderschnecke von 14mm hatte. Durch den Vergleich der 20mm mit den 14mm war der Fehler leicht gefunden. Deshalb ist eine zeitige Festlegung von Bauteileigenschaften bei der späteren Fehlersuche und Optimierung hilfreich, weil ein Referenzwert existiert.
Richtig, bei komplexen Projekten geht dann schnell mal ein Bauteil unter. Wurde z.B. in SMD-Bauform ausgelegt aber hätte eigentlich ein 10W-Zementwiderstand sein müssen. Ja man kann das immer noch ändern, aber das kannst du in anderen Tools genauso. Ich habe mir jetzt auch nochmal den Atmega 1284P-PU angeschaut. Diesem ist sogar tatsächlich ein Footprint zugewiesen, den es so aber garnicht in der Datenbank gibt.
Detlev T. schrieb: > Die bei Eagle feste Zuordnung der Footprints zu dem Schaltplansymbol, > das dann Bestandteil der Bibliotheksdatei wird, halte ich für > praktikabler und sicherer. Ich verstehe einfach nicht was alle immer für Probleme mit der Zuordnung zw. Symbol und Footprint haben. KiCad macht das gut! Gleicher Workflow wie bei Altium Designer. Diesen Bullshit bei EAGLE, dass man extra im Device die Pinzuordnung macht kann man sich sparen! Das ist verwirrend und fehleranfällig! Nur die Leute, die Layouten mit EAGLE gelernt haben verstehen das ganz simple Prinzip von KiCad und Altium Designer nicht. PS: Mentor PADS & xDxDesigner Workflow ist noch schlimmer !
Wo bitte siehst du in der Zuordnung für welchen Zweck genau das Bauteil ausgelegt sein muss?
Was ich nicht verstehe, ist, warum man sagt, einem Widerstand dürfe nicht ein 0603 ODER ein 0805 ODER ein grosses Leistungsgehäuse zugewiesen sein, weil ja ein Widerstand ein physikalisches Ding ist, das GENAU ein Gehäuse hat, und gleichzeitig man akzeptiert, dass man DEMSELBEN Widerstand entweder 100kOhm oder 1kOhm oder 0Ohm zuweisen kann. Warum sollte man das eine dürfen und das andere nicht? Falls jetzt die Antwort ist: Weil das dem Design-Tool egal sein kann, die sehen ja alle gleich aus, dann erwidere ich: Genau. Und ebenso ist es dem Schematool egal, was der Widerstand für ein Gehäuse hat. Das Argument mit der Verwechslungsgefahr zieht nicht, denn ein 0603 1kOhm sieht einem 0603 0Ohm verflucht ähnlich, und eine Verwechslung wäre meist katastrophal. Wenn man das verhindern will, muss JEDES Bauteil mit JEDEM Wert einen dedizierten Repräsentanten in der Library bekommen. Und das ist mit Kicad (und vermutlich auch mit Eagle) möglich.
:
Bearbeitet durch User
Hans Wurst schrieb: > Richtig, bei komplexen Projekten geht dann schnell mal ein Bauteil > unter. > Wurde z.B. in SMD-Bauform ausgelegt aber hätte eigentlich ein > 10W-Zementwiderstand sein müssen. Deswegen lege ich bei allen Bauteilen, die nicht Standard sind, auch direkt beim erstellen in Schaltplan den Footprint fest. Dann kann das nicht passieren...
jz23 schrieb: > Deswegen lege ich bei allen Bauteilen, die nicht Standard sind, auch > direkt beim erstellen in Schaltplan den Footprint fest. Dann kann das > nicht passieren... Da mach ich mittlerweile noch etwas mehr ... falls es mal kein Standard-Widerstand oder -Kondensator ist, hinterlege ich im Schalplan stets den Footprint UND Bestellnummer mit Distributor :) Vor ein paar Wochen hatte ich mir da mal ein Script gebaut, dass eine KiCad BOM frisst und Bestelllisten ausspuckt: - falls "footprint|value" bekannt ist, wird in die Bestellliste gleich der richtige Distributor + Bestellnummer hinterlegt Auszug aus dieser Parts-Liste:
1 | "Resistors_SMD:R_0805|3k3","RND 0805 1 3,3K","0,02","R" |
2 | "Resistors_SMD:R_0805|68","SMD-0805 68,0","0,03","R" |
3 | "TO_SOT_Packages_SMD:SOT-23|BC817-40","BC 817-40 SMD","0,04","R" |
4 | "Capacitors_SMD:C_0805|2,2µ","X5R-G0805 2,2/50","0,05","R" |
5 | "Capacitors_SMD:C_0805|2µ2","X5R-G0805 2,2/50","0,05","R" |
6 | "Capacitors_SMD:C_1206|10µ","X5R-G1206 10/35","0,09","R" |
7 | "Resistors_SMD:R_0805|10","RND 0805 1 10","0,02","R" |
8 | "Resistors_SMD:R_0805|22R","RND 0805 1 22","0,02","R" |
9 | "myfootprints:APTB1612SURKQWDF-AMT|LED_Dual_ACAC","604-APTB1612SURKQWDF","0,363","M" |
10 | "Resistors_SMD:R_0603|18R/0,5W","755-ESR03EZPJ180","0,067","M" |
11 | "Resistors_SMD:R_0603|33R/0,5W","755-ESR03EZPJ330","0,067","M" |
12 | "Resistors_SMD:R_0603|100","SMD-0603 100","0,03","R" |
- falls im Schaltplan aber die Felder BestNr und Distributor ausgefüllt wurden, wird diese Bestellnummer verwendet und in die richtige Bestellliste gepackt. Raus kommen pro Distributor mehrere Bestelllisten - die für Reichelt kann man gleich als CSV importieren^^ Falls es mal ein C ist, der zB min. 50V haben muss, wird das mit der Bestellnummer auch gleich im Schaltplan hinterlegt. Die Parts-Liste hat mittlerweile 100 Standard-Bauteile und wird kontinuierlich erweitert :)
Simon H. schrieb: > Wenn man das verhindern will, muss JEDES Bauteil mit JEDEM Wert einen > dedizierten Repräsentanten in der Library bekommen. Yep, das ist das, was wir in der Firma machen. Da steht dann nämlich auch noch die interne Lagerhaltungsnummer des Bestückers mit dabei, die in der BOM mit rausfällt. Zu Hause würde ich das aber nicht so weit übertreiben. ;-)
senior engineer schrieb: > Ich verstehe einfach nicht was alle immer für Probleme mit der Zuordnung > zw. Symbol und Footprint haben. KiCad macht das gut! Gleicher Workflow > wie bei Altium Designer. Dann erkläre ich es dir: 1. Jedes Symbol im Schaltplan, das auf ein real existierendes Bauteil hinweist, MUSS letztlich mit einer Anzahl von Pads eines Footprints verbunden sein. (Ausnahmen sind Symbole wie GND, VCC und so, die lediglich eine Netzklasse und Namen festlegen). Ist dir dieser Punkt 1 erstmal klar? 2. So, da nun feststeht, daß es immer eine Verknüpfung zwischen einem Schaltplansymbol und einem Footprint auf der Leiterplatte geben muß, erhebt sich die Frage, wann, wo und von wem diese Verknüpfung vorgenommen werden soll. Diese Frage ist also zu klären. Ist dir nun auch Punkt 2 soweit klar? 3. Hier haben wir zwei verschiedene Möglichkeiten, den Punkt 2 zu erfüllen: 3a) Lösung von Eagle: Der Bibliotheks-Autor nimmt die Verknüpfung vor, er tut dies zum Zeitpunkt der Erstellung oder Erweiterung der Bibliothek und in dieser Bibliothek. Diese ist damit unabhängig von anderen Bibliotheken, was ein gutes Stabilitätskriterium ist. Änderungen woanders können also keinen Schaden an eben dieser Bibliothek anrichten. Wenn der Bibliotheks-Autor gründlich und richtig gearbeitet hat, dann ist das Bibliotheks-Element in Ordnung und wird für alle darauf fußenden Leiterplattenprojekte zu einer richtigen, fehlerfreien Zuordnung und damit zu einer fehlerfreien Leiterplatte führen. (vorausgesetzt, der Leiterplatten-Autor hat im Stromlaufplan keinen Unsinn gemacht) 3b) Lösung von Kicad: Der Leiterplatten-Autor nimmt am Übergang vom Stromlaufplan zum Leiterplattenlayout die Zuordnung selbst vor, indem er seinen Symbolen entsprechende Footprints zuweist. Das bürdet dem Leiterplatten-Autor natürlich die Verantwortung für die richtige Zuweisung auf und da es sich bei den Symbolen und den Footprints um verschiedene Bibliotheken/Dateien handelt, zusätzlich kommt die Gefahr hoch, daß es Diskrepanzen zwischen den Bibliotheken geben kann (verschiedene Versions-Stände, Namen usw.) > Diesen Bullshit bei EAGLE, dass man extra im > Device die Pinzuordnung macht kann man sich sparen! Jetzt begreifst du hoffentlich, daß es eben kein "Bullshit" ist, die Zuordnung innerhalb der Bibliothek zu machen, denn erstens muß diese Zuordnung ja ohnehin in jedem Fall gemacht werden und zweitens ist es besser, selbige einmal und gründlich zu erledigen, anstatt sie in jedem Projekt dem Leiterplatten-Autor zuzumuten. Eagle ist hier deutlich ökonomischer, da diese Zuordnungs-Arbeit nur einmal erledigt werden muß. > Das ist verwirrend und fehleranfällig! > Nur die Leute, die Layouten mit EAGLE gelernt haben verstehen das ganz > simple Prinzip von KiCad und Altium Designer nicht. Und verwirrender oder gar fehleranfälliger ist es auch nicht. Das ist eine glatte Lüge deinerseits. Zumindest ist der Leiterplatten-Autor deutlich entlastet, da er sich eben nicht darum kümmern muß, ob die Zuweisung auch richtig ist und ob der Footprint auch wirklich für das betreffende Bauteil paßt. In einem Punkte pflichte ich dir bei: beim ganz simplen Prinzip von Kicad und Altium Designer. Mir ist das zu simpel, weswegen ich das dir unverständlich erscheinende, aber deutlich potentere Prinzip von Eagle bevorzuge. Nochwas: Das ewige Gezänke über verschiedene Ausführungen von Widerständen ist extremer Nebenschauplatz. Wer Schaltungen entwirft, plant schon vor dem Erstellen des Stromlaufplans ein, was er denn für Bauteile wofür zu verwenden gedenkt. Wer kein dickes Brett vor dem Kopfe hat, wird schon ganz am Anfang für den dicken Strom-Shunt keinen zierlichen 0603 Widerstand einplanen, sondern so einen Widerstand, der erstens technisch tatsächlich paßt und zweitens beim Distributor seiner Wahl auch erhältlich ist. All die Leute, die sich erst bei der Leiterplatte um konkrete Bauformen kümmern wollen, scheinen mir eher PSpice-Leute zu sein, die sich mental nur in theoretischen Simulationen bewegen und sich dann beim Formulieren einer tatsächlichen Hardware schwer tun. Ich kenne Leute, die bei der Simulation eben 50 Ohm beim Widerstand eingetragen haben (schreibt sich ja so schön einfach..) und später dann darauf beharren, daß der Einkäufer einen 49.9 Ohm Widerstand beschaffen muß. Ich selber hab als Hinterlassenschaft von einem gegangenen Kollegen dieser Art noch ne 5000er Rolle 49.9 Ohm in 0603 im Labor herumliegen. W.S.
senior engineer schrieb: > Detlev T. schrieb: >> Die bei Eagle feste Zuordnung der Footprints zu dem Schaltplansymbol, >> das dann Bestandteil der Bibliotheksdatei wird, halte ich für >> praktikabler und sicherer. > Ich verstehe einfach nicht was alle immer für Probleme mit der Zuordnung > zw. Symbol und Footprint haben. KiCad macht das gut! Gleicher Workflow > wie bei Altium Designer. Diesen Bullshit bei EAGLE, dass man extra im > Device die Pinzuordnung macht kann man sich sparen! > Das ist verwirrend und fehleranfällig! > Nur die Leute, die Layouten mit EAGLE gelernt haben verstehen das ganz > simple Prinzip von KiCad und Altium Designer nicht. > > PS: Mentor PADS & xDxDesigner Workflow ist noch schlimmer ! Das sind Meinungen oder Gewohnheiten. Irgendwo muss ja die Pin -> Pad Zuordnung stehen und ob das nun in der Lib oder sonstwo passiert... . Kenne beides und beides ist Mist. Das eine ist unflexibel das andere fehleranfällig und auch nicht intuitiv. Das Problem sind die bösen Hersteller die so viele verschiedene Bauteile auf den Markt bringen das da keiner hinterher kommt. Dann hauen die auch noch im gefühlt Monatsrhythmus neue Standards raus und ändern munter jedes vorhandene JEDEC Gehäuse wie Sie lustig sind. Meine Wenigkeit lässt sich für ein paar Euro die Teile machen. Da ist dann gleich ein 3D Modell mit bei. Aber da wühlt man in den Anbieterlibs konvertiert diese und wenn es das Teil da nicht gibt dauert es auch ein paar Tage.
W.S. schrieb: > Wer Schaltungen entwirft, plant schon vor dem Erstellen des > Stromlaufplans ein, was er denn für Bauteile wofür zu verwenden gedenkt. > Wer kein dickes Brett vor dem Kopfe hat, wird schon ganz am Anfang für > den dicken Strom-Shunt keinen zierlichen 0603 Widerstand einplanen, > sondern so einen Widerstand, der erstens technisch tatsächlich paßt und > zweitens beim Distributor seiner Wahl auch erhältlich ist. > > All die Leute, die sich erst bei der Leiterplatte um konkrete Bauformen > kümmern wollen, scheinen mir eher PSpice-Leute zu sein, die sich mental > nur in theoretischen Simulationen bewegen und sich dann beim Formulieren > einer tatsächlichen Hardware schwer tun. Ich habe auch mit Eagle angefangen und habe es über 15 Jahre verwendet. Mittlerweile verwende ich Eagle nur noch für kleine sehr überschaubare Projekte mit kleinsten Stückzahlen. Mein Workflow sieht so aus: 1. Ich mache mir zuerst Gedanken über die Funktion der Schaltung. 2. Danach simuliere ich das Ganze und stelle fest ob meine Überlegeungen mit der Simulation übereinstimmen. Nach diesen zwei Schritten habe ich auch z.B. bei Widerständen oder Leistungstransistoren die genauen Kennwerte, welche ich mindestens brauche. (Also die maximale Leistung usw.) 3. Jetzt kann ich den Footprint erst festlegen. Hätte ich den Footprint wie bei Eagle schon am Anfang festgelegt, fange ich jetzt an und ändere die Footprints. Damit ist Eagle nicht besonders effizient, da ich jeden zweiten Footprint mehrfach anfasse. Und wenn an dem Bauteil nicht der richtige Footprint dran hängt, dann tausche ich im Schaltplan auch noch die Teile aus. Das ist alles andere als effizient. Eagle ist dann am effizientesten, wenn es auf die Footprints nicht ankommt und ich einfach den erstbesten nehme, weil ich diese Bauform immer verwende. Aber eine Baugruppe, welche ich 1000 mal verkaufen möchte, optimiere ich für die Fertigung. Und nein, ich nehme für einen Shunt nicht irgend eine große Bauform, die auf jeden Fall passen wird, sondern die kleinste Bauform, mit der ich die Kriterien für eine einwandfreie Funktion und eine halbwegs "lange" Lebenserwartung realisieren kann. Und diese steht erst nach dem Entwurf und der erfolgreichen Simulation fest. Erst wenn die Funktion feststeht, kann man sich Gedanken über die genaue Realisierung machen. Möglicherweise muss der eine oder andere Footprint aufgrund des Gehäuses um eine Leiterplatte herum ausgewählt werden. Und über das Gehäuse mache ich mir beim funktionalen Entwurf einer Schaltung auch nur wenige Gedanken. Daher finde ich das Konzept von AltiumDesigner oder KiCad oder ... sehr gut. Und die Tatsache, dass z.B. AltiumDesigner weltweit kein Nischendasein frustet, zeigt, dass noch mehr Leute das sehr ähnlich sehen. W.S. schrieb: > Ich kenne Leute, die bei der Simulation eben 50 Ohm beim Widerstand > eingetragen haben (schreibt sich ja so schön einfach..) und später dann > darauf beharren, daß der Einkäufer einen 49.9 Ohm Widerstand beschaffen > muß. Wenn es für die einwandfreie Funktion notwendig ist, dann ist das so. Das hat aber sehr wenig mit der Zuordnung vom Symbol zum Footprint zu tun, lass mich kurz überlegen, es hat gar nichts damit zu tun.
W.S. schrieb: > Ich selber hab als Hinterlassenschaft von einem gegangenen Kollegen > dieser Art noch ne 5000er Rolle 49.9 Ohm in 0603 im Labor herumliegen. In meiner Welt ist ein 49.9 Ohm Widerstand ein engtolerierter 50 Ohmer. > All die Leute, die sich erst bei der Leiterplatte um konkrete Bauformen > kümmern wollen, scheinen mir eher PSpice-Leute zu sein, die sich mental > nur in theoretischen Simulationen bewegen und sich dann beim Formulieren > einer tatsächlichen Hardware schwer tun. Der eine kennt es so, der andere so. Mir gefällt das eagle Prinzip besser. Da sind alle Infos für das Design an einem Ort (die ich auch exportieren kann). Das ist aber eine SOHO Lösung. Wenn mehrere an einem Design arbeiten ist das eher kontraproduktiv da der workflow eingeschränkt ist. qwerty schrieb: > Erst wenn die Funktion feststeht, kann man sich Gedanken über die genaue > Realisierung machen. Das mach ich bei eagle auch so. Nur pappe ich dann über technology das Gehäuse an das Bauteil in der lib. Die erhält dann das wissen welche "es noch so gibt"
Ich benutze KiCad eigentlich schon zum Festhalten einer Schaltungsidee, ggfs. dann beim Testen auf dem Steckbrett. Zu diesem Zeitpunkt bin ich froh, dass ich mich rein auf die Funktion konzentrieren kann. Es reicht mir dabei z.B. auch wenn ich einen generischen NPN-Transistor eintragen kann. Ob das später ein BC547 oder ein 2N2222 wird, kann ich dann immer noch entscheiden. Wenn ich ein Bauteil generisch oder nicht zugewiesen habe, sehe ich das später sofort. Das ist für mich sicherer, als wenn dort ein falsches eingetragen ist und ich es übersehe.
Mir fällt auch auf wie wenig gut das editieren der Schaltplan-Verbindungen in Kicad funktioniert. Ist eine erstmal angelegt und muss doch mal verlegt werden, dann kann man sie auch gleich komplett löschen weil das schneller geht. Mich erinnert die Bedienung an Tools aus der DOS-Ära, die ohne Maus auskommen mussten. Ich sehe nicht wo diese in Kicad auch nur in einem Punkt sinnvoll eingesetzt wird.
Hans Wurst schrieb: > Mich erinnert die Bedienung an Tools aus der DOS-Ära, die ohne Maus > auskommen mussten. Ich sehe nicht wo diese in Kicad auch nur in einem > Punkt sinnvoll eingesetzt wird. Das ist ja das tolle an KiCad ... Man muss die Maus kaum verwenden und kann so schneller arbeiten. Ganz toll ist, wenn man zB bei mehreren Signalen an einem µC-Port den Namen ändern muss ... Man muss nicht wie wild mit der Maus rumsteuern, sondern kann die Cursor-Tasten verwenden und so in Windeseile von Pin zu Pin navigieren und zB den Label anpassen :) Ist halt für Produktivität optimiert und nicht für Anfänger ... Aber die können zur Not auch die Maus verwenden ;-)
:
Bearbeitet durch User
qwerty schrieb: > Daher finde ich das Konzept von AltiumDesigner oder KiCad oder ... sehr > gut. Und die Tatsache, dass z.B. AltiumDesigner weltweit kein > Nischendasein frustet, zeigt, dass noch mehr Leute das sehr ähnlich > sehen. Was ja ein Argument für eagle wäre da weiter verbreitet. Oliver R. schrieb: > Wenn ich ein Bauteil generisch oder nicht zugewiesen habe, sehe ich das > später sofort. Das ist für mich sicherer, als wenn dort ein falsches > eingetragen ist und ich es übersehe. Du kannst in eagle genau so mit generischen Symbole arbeiten. Da die libs größtenteils nur Hobbyniveau haben wäre das auch nahe liegend. Kenne aber niemanden der das so macht. Für mich hat das große Vorteile da ich beim Design Schaltplan und Board bearbeite und das auch noch interaktiv. Eagle macht das m.E. durch das grottige und widersprüchliche user interface wieder zu nichte. Ist so'n ein wenig wie damals bei Siemens Handys. Die Dinger waren technisch super aber faktisch ohne Lehrgang nicht zu bedienen. Aber wenigstens Schaltplan und Layout sind aus einem Guss. Leider ist Kicad (um mal zum Thema zurück zu kommen) da auch nicht "besser". Mampf F. schrieb: > Ganz toll ist, wenn man zB bei mehreren Signalen an einem µC-Port den > Namen ändern muss ... Man muss nicht wie wild mit der Maus rumsteuern, > sondern kann die Cursor-Tasten verwenden und so in Windeseile von Pin zu > Pin navigieren und zB den Label anpassen :) Eagle: NAME old_name new_name
X4U schrieb: > Eagle: NAME old_name new_name KiCad: Mouse an ersten Pin 'E' New_Name Enter Cursor-Down 'E' New Name Enter Cursor-Down usw^^ In meinen Eagle-Zeiten hab ich die Kommandozeile aber geliebt und exzessiv verwendet. Ich hoffe, Autodesk kommt nicht irgendwann auf die Idee, diese einzustampfen.
Mampf F. schrieb: > Das ist ja das tolle an KiCad ... Man muss die Maus kaum verwenden und > kann so schneller arbeiten. > > Ganz toll ist, wenn man zB bei mehreren Signalen an einem µC-Port den > Namen ändern muss ... Man muss nicht wie wild mit der Maus rumsteuern, > sondern kann die Cursor-Tasten verwenden und so in Windeseile von Pin zu > Pin navigieren und zB den Label anpassen :) > > Ist halt für Produktivität optimiert und nicht für Anfänger ... Aber die > können zur Not auch die Maus verwenden ;-) Stell dir vor Hotkeys und eine ordentliche Mausbedienung kann man beides in einem Programm umsetzen. Warum kann man denn elektr. Verbindungen nicht nachträglich bearbeiten, ohne dass man die Verbindung auflöst? Warum werden Netze nicht rechtwinklig am Raster ausgerichtet wenn ein Bauteil "gezogen" wird? Ich habe plötzlich Verbindungen die allen möglichen wilden Winkeln quer über den Schaltplan vom Pin zum nächsten Eckpunkt des Netzes führen. Das gleiche Spiel in PCBnew. Ich musste zwar beruflich keine Leiterplatten designen, aber die Tools, die mir in anderen Bereichen untergekommen sind, konnten das allesamt besser.
Hans Wurst schrieb: > Ich musste zwar beruflich keine > Leiterplatten designen, aber die Tools, die mir in anderen Bereichen > untergekommen sind, > konnten das allesamt besser. Jup, das ist so :) Generische-Versatzstück-Antwort: ${PROGRAMM} ist kostenlos und jeder kann Funktionen nachrüsten, wenn er programmieren kann und so die Software verbessern. Ach, wie oft hab ich diese Standard-Antwort schon gelesen, wenn ich mich in irgendeinem Forum oder Bugtracker mich über eine OpenSource Software ausgelassen habe xDDD Wobei, das ist ja auch ein Kompliment an KiCad, wenn es mittlerweile soweit gekommen ist, dass es mit kommerziellen Programmen verglichen wird / werden kann :)
:
Bearbeitet durch User
W.S. schrieb: > 3b) Lösung von Kicad: Der Leiterplatten-Autor nimmt am Übergang vom > Stromlaufplan zum Leiterplattenlayout die Zuordnung selbst vor, indem er > seinen Symbolen entsprechende Footprints zuweist. Du kennst Kicad doch gar nicht, woher nimmst du dann diese deine Weisheit?
Werbung: In dem Thread hier scheint es ja einige zu geben, denen Dinge an KiCad nicht gefallen. So ging's mir auch und das ist draus geworden: Beitrag "Horizon EDA [War: Neues, halbfertiges Elektronik-CAD-Programm]" Vielleicht werden einige damit glücklicher ;)
Mampf F. schrieb: > Das ist ja das tolle an KiCad ... Man muss die Maus kaum verwenden und > kann so schneller arbeiten. Ja, endlich. Die Antwort aus der Werbeabteilung: _it's not a bug, it's a GREAT feature_ Genau solche Beiträge hatte ich weiter oben schon bemängelt. Mampf F. schrieb: > Wobei, das ist ja auch ein Kompliment an KiCad, wenn es mittlerweile > soweit gekommen ist, dass es mit kommerziellen Programmen verglichen > wird Ach nö. Auch das ist nur Klopfen auf die eigene Schulter. Verglichen wird immer, aber das hat nix damit zu tun, ob ein Programm irgend einer Liga ebenbürtig wäre oder nicht. Mir ist durchaus klar, daß es gut für die gesamte Szene ist, wenn es eben auch unkommerzielle Alternativen gibt. Aber die müssen wenigstens einem minimalen Qualitätsanspruch genügen, sonst fallen sie durch. Und auch ich gehöre zu denjenigen, die anfangs durchaus Hoffnung hatten, daß sich Kicad gut entwickelt und Qualitäten bekommt, die es aus dem Bastler- und Wurschtler-Niveau herausbekommen. Aber das ist zu meinem argen Mißfallen eben nicht so gekommen und mittlerweile sehe ich da keine Chance auf Besserung mehr. Ich vermute, daß es mit den kommerziellen Aspekten von Eagle bei Autodesk nicht so schlimm gekommen wäre, wenn Kicad auch nur ansatzweise Eagle das Wasser hätte reichen können. Aber so hat Autodesk mangels ernstzunehmender Konkurrenz seine Sau rauslassen können. Das ist ein Verlust für die gesamte Szene. Verstehe du das mal richtig. W.S.
Hallo W.S. W.S. schrieb: >> Das ist ja das tolle an KiCad ... Man muss die Maus kaum verwenden und >> kann so schneller arbeiten. > > Ja, endlich. Die Antwort aus der Werbeabteilung: > _it's not a bug, it's a GREAT feature_ Sag mal, was ist eigentlich Dein Problem? KiCad kann Maus, Kommandozeile, Shortcuts und parametrische Eingaben. Ist Dir das zuviel und zu kompliziert? Oder hättest Du gerne eine Spracheingabe? Oder besser noch eine gute Fee, die Dir alle Wünsche von den Augen abliest? Konstruktive Kritik ist ok, aber hier passt irgendwie Stil und Tonfall nicht so recht. ;O) > Aber das ist zu meinem argen Mißfallen eben nicht so gekommen und > mittlerweile sehe ich da keine Chance auf Besserung mehr. Ich vermute, > daß es mit den kommerziellen Aspekten von Eagle bei Autodesk nicht so > schlimm gekommen wäre, wenn Kicad auch nur ansatzweise Eagle das Wasser > hätte reichen können. Aber so hat Autodesk mangels ernstzunehmender > Konkurrenz seine Sau rauslassen können. Das ist ein Verlust für die > gesamte Szene. Verstehe du das mal richtig. Na dass nenn ich ja jetzt mal ne zünftige Verschwörungstheorie. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Leute! Wer nicht in der Lage ist, einen simplen großen Button zu finden, mit dem man bei der Symbolerstellung einem Bauteil einen Footprint fix zuordnet und deswegen steif und fest über Jahre Unsinn behauptet - der ist nun wirklich keine Referenz bei der Beurteilung dieser Software. Dass Ihr Euch darüber überhaupt aufregt :-) Zu der Debatte "Fixe Zuordnung oder Zuordnung erst Später": Wenn man das so liest, meint man, dass die Leute täglich Dutzende von neuen Controllern verwenden und es eine unheimliche Arbeit ist, dafür einen vielleicht fehlenden Footprint einzutragen. Wir haben hier in den letzten 11 Jahren mit KiCad genau 34 Mikrocontroller (22 mal AVR, der Rest STM32) angelegt, die wir verwenden und die auch fixe Footprintzuordnungen haben. Wohlgemerkt: in 11 Jahren kommerzieller Verwendung. Davon abgesehen traut man, gerade wenn man damit Geld verdient, fremden Bibliotheken sowieso nicht und baut sich seine eigenen, selbst geprüften auf. Spätestens, wenn man einmal Lehrgeld bezahlt hat, gewöhnt man sich das an. Man kann auch Probleme konstruieren, wo keine sind.
W.S. schrieb: > Wer Schaltungen entwirft, plant schon vor dem Erstellen des > Stromlaufplans ein, was er denn für Bauteile wofür zu verwenden gedenkt. > Wer kein dickes Brett vor dem Kopfe hat, wird schon ganz am Anfang für > den dicken Strom-Shunt keinen zierlichen 0603 Widerstand einplanen, > sondern so einen Widerstand, der erstens technisch tatsächlich paßt und > zweitens beim Distributor seiner Wahl auch erhältlich ist. Hier hast du mal recht. Genau deshalb benutzen wir KiCad. Lieber W.S. Irgendjemand ist hier im Forum mit einem provokanten Titel aufgetaucht 'KiCad ist geil ... ' Ich möchte hier das ganze nochmal toppen: Ich finde KiCad ist endgeil ;-) KiCad hat bei uns bereits einen Paradigmenwechsel hervorgerufen! Warum ? Seit KiCad es möglich macht 3d STEP Dateien einzubinden, gibt es bei mechanischen (Vor)Untersuchungen eigentlich kein Halten mehr, zumal man 'Step Dateien' an jeder Hausecke bekommt. Althergebracht läuft es ja so: Zuerst macht man eine Skizze (Blockschaltplan) -> Schaltplan - > Platzierung/Layout -> Gerber Wir gehen inzwischen folgenden Weg: Skizze -> Platzierung -> 3d Viewer -> Schaltplan -> 3d Viewer -> Feinplatzierung -> Layout -> Gerber Damit man bereits am Anfang schon 3D-Objekte einbinden kann machen wir uns Referenz-Footprints, die es ermöglichen die in Frage kommenden Step-Files einzubinden. Diese beschriebenen Iterationen mögen zwar aufwendig erscheinen - sie sind es aber nicht. Der Unterschied zu Früher: Das Produkt reift am Bildschirm und nicht hinterher nach dem zusammenlöten mit den passendmachenden 'Pfuschaktionen'. Das meinte ich mit Paradigmenwechsel. ('Bananen Design' war gestern ;-) So gesehen ist deine Nörgelei nur Nebensache wenn es um das 'große Ganze' geht, da kann KiCad bereits richtig punkten.
Mampf F. schrieb: > Ich hoffe, Autodesk kommt nicht irgendwann auf die Idee, diese > einzustampfen. Unwahrscheinlich. Die Kommandozeile von Autocad ist sehr mächtig, aber logischer aufgebaut. Da wurde wohl das eine vom anderen "inspiriert". Mampf F. schrieb: > KiCad: > > Mouse an ersten Pin > 'E' New_Name Enter > Cursor-Down > 'E' New Name Enter > Cursor-Down > usw^^ Das ist eine gute Funktion. Hier mal ein wenig Wasser auf die Mühlen der Kicad Fans: Bei eagle läuft das so. - NAM <Enter> - Finger von der Tastatur Punkt suchen (name tippen geht nicht, wildcads? träum weiter). - Punkt mit der Maus klicken. - Wenn andere Netze in der nähe sind fragt Eagle ob dieses oder das nächste gemeint ist. Das macht er auch wenn die Netze VCC oder GND sind die man eher selten umbenennen will - Dann klickst du dich mit der rechten Maustaste so lange durch bis das richtige gehighlightet ist - Jetzt selektierst du das gewollte mit der linken Maustaste Wenn das dann passiert ist hast du die jetzt reelle Chance dein Layout völlig zu versauen. - Eagle fragt nämlich jetzt bei Teilsegmenten nach ob du: . dieses Segment . Alle Segmente auf dieser Seite . Oder Alle Segmente auf allen Seiten meinst. Natürlich ist diese Segment voreingestellt. Wenn du nur das umbenennst teilt sich dein Netz in 2 Teilnetze auf ohne das du es mitbekommst. Bei grösseren Designs irgendwo auf Seite 7 - Beim nächsten Netz geht das Spiel von vorne los. Also klicken, durchklicken, selektieren, neuen namen tippen, Segmentfrage wieder neu beantworten usw usf. Du musst aufpassen wie ein Schiesshund was du da machst und wenn du 3 Netze renamed hast weißt du nicht mehr was du damit wolltest. Das fängt dir auch kein ERC oder DRC ab, logisch ist ja alles in Butter.
il Conte schrieb: > Ich möchte hier das ganze nochmal toppen: > Ich finde KiCad ist endgeil ;-) Was mich an den Open Sourcern nervt sind diese Jubelarien über die eigen Software. Da ist immer alles SuperMegaHyperEndGeil. Wenn du wirklich mal was wissen willst und eine Frage stellst merkst du in der Regel am ignorieren oder herumschwafeln wenn diese eine evtl. doch nicht so tolle Antwort erfordert. Ein typisches Beispiel ist die F/B Annotation die Kicad nun mal nicht hat (egal warum). Da wird so lange drumrumgelabert bis zum ignorieren der Nachfrage. Das ist nicht nur bei Kicad so sondern bei fast allen open source Projekten die so kommen und gehen. Wenn mir also ein Fanbpoy was von Endgeil erzählt ... Es gehört zwar nicht hierher aber eagle (was ich schon lange nutze) kann ich in Grund und Boden kritisieren. Zur Zeit kommt dann noch das Gehabe des neuen Inhabers dazu wo ich auch harte Worte finden kann. Aber ich bemühe mich sachlich und fair zu sein, Schade das so etwas nicht jedem gegeben ist.
W.S. schrieb: > mittlerweile sehe ich da keine Chance auf Besserung mehr. Das dachte ich leider auch, als ich den Beitrag las. ;-) I
X4U schrieb: > Was mich an den Open Sourcern nervt sind diese Jubelarien über die eigen > Software. Da ist immer alles SuperMegaHyperEndGeil. Wenn du wirklich mal > was wissen willst und eine Frage stellst merkst du in der Regel am > ignorieren oder herumschwafeln wenn diese eine evtl. doch nicht so tolle > Antwort erfordert. Hast du selbst mal etwas programmiert? Jeder Programmierer ist zunächst zufrieden, wenn er sein ursprünglich gesetztes Ziel nach langer Zeit erreicht hat. Bei Opensource gibt es manchmal hierfür Helfer, wodurch sich das Ganze beschleunigt. Ob das Ergebnis in deinem Sinne gut ist oder nicht, interessiert hier niemanden. Wenn jemand wie W.S. kommt und ein global völlig unbedeutendes Tool als das Maß aller Dinge darstellt, weil er sich nicht eingestehen möchte, dass sein Altersstarrsinn ihn am Umdenken hindert, reagieren die Programmierer eher amüsiert. Ich benutze Kicad seit gut 11 Jahren und es tut, was ich will. Dass ich dabei manchmal umdenken muss, geschenkt. Morgen (nee, heute) muss ich noch Tabellen mit OpenOffice erstellen. Früher hätte ich mir ein kleines Tool mit FPC geschrieben, das mir die Daten in LaTeX umwandelt. Irgendwann gibt man halt auf!
Guido B. schrieb: > Hast du selbst mal etwas programmiert? Wobei der „Jubelperser“ hier ja vermutlich auch nichts selbst zu Kicad beigetragen hat, sondern eher eine Art Evangelist dafür ist. Solche Leute schaden der Sache aber oft mehr als sie nützen, da sie eben nur bejubeln. Ein kritischer Blick wird dabei zurückgedrängt. Den jeweiligen Entwicklern ist mit (positiver, also nicht „ist ja alles Bullshit“ wie bei W.S.) Kritik normalerweise besser geholfen.
Jörg W. schrieb: > Den jeweiligen Entwicklern ist mit (positiver, also nicht „ist ja > alles Bullshit“ wie bei W.S.) Kritik normalerweise besser geholfen. https://bugs.launchpad.net/kicad 1497 open Bugs zeigen eine aktive Arbeit zur Verbesserung. http://downloads.kicad-pcb.org/windows/nightly/
:
Bearbeitet durch User
X4U schrieb: > Wenn du wirklich mal > was wissen willst und eine Frage stellst merkst du in der Regel am > ignorieren oder herumschwafeln wenn diese eine evtl. doch nicht so tolle > Antwort erfordert. > > Ein typisches Beispiel ist die F/B Annotation die Kicad nun mal nicht > hat (egal warum). Da wird so lange drumrumgelabert bis zum ignorieren > der Nachfrage. Das ist nicht nur bei Kicad so sondern bei fast allen > open source Projekten die so kommen und gehen. Das kann man so nicht stehen lassen! Es kommt drauf an welche Fragen man stellt und wie man sie stellt und welche Vorschäge man macht. Im Übrigen haben die KiCAd - Leute 2 von uns gemachte Vorschläge (zu besseren Nutzung) innerhalb von 14 Tagen implementiert (Nightly Version). Probier das mal bei deinem CAD-Liferanten und komm dann mit der Erfolgsmeldung hier zurück! Jörg W. schrieb: > Wobei der „Jubelperser“ hier ja vermutlich auch nichts selbst zu > Kicad beigetragen hat Mehr Neutralität würde dir als MOD besser zu Gesicht stehen. Jörg W. schrieb: > Den jeweiligen Entwicklern ist mit (positiver, also nicht „ist ja > alles Bullshit“ wie bei W.S.) Kritik normalerweise besser geholfen. Du sagst es! Dazu gehört auch, dass man etwas als geil beschreiben darf wenn es zutrifft. Also mich würde sowas schmeicheln wenn jemand zu mir sagt was ich für eine 'geiles' Design hinbekommen habe :-) Hat sowas zu dir noch nie jemand gesagt ?
X4U schrieb: > Was mich an den Open Sourcern nervt sind diese Jubelarien > über die eigen Software. Ja, das verstehe ich. Bei der sachlichen und zurückhaltenden Art, die kommerzielle Software-Anbieter so an den Tag legen, ist VÖLLIG unverständlich, wieso sich ausgerechnet die FOSS-Leute immer dermaßen danebenbenehmen.
mal so nüchtern - und ohne einen Nebenkriegsschauplatz eröffnen zu wollen - in die Runde gefragt: Was wären die Beweggründe - aus funktionaler Sicht - von Eagle auf KiCad umzusteigen? Zudem würde es mich interessieren, auf welche Eagle Funktionen ich bei der Verwendung von KiCad verzichten müsste. Funktionen die KiCad hat aber Eagle nicht würden mich in erster Linie erst einmal nicht interessieren.
W.S. schrieb: >> Diesen Bullshit bei EAGLE, dass man extra im >> Device die Pinzuordnung macht kann man sich sparen! > > Jetzt begreifst du hoffentlich, Naja. Dein zur Schau gestellter Hochmut ist nicht geeignet, darüber hinwegzutäuschen, dass sich in der Fülle Deiner Falschaussagen tatsächlich ein Körnchen Wahrheit finden könnte. > daß es eben kein "Bullshit" ist, die Zuordnung innerhalb > der Bibliothek zu machen, Doch, das ist es. Zwischen Widerstandswerten und Footprints besteht in der Realität eine M:N-Beziehung, also ist es sachlich falsch, beide im selben Datensatz zu definieren. Das ist einfach von der Datenmodellierung her Quatsch. > denn erstens muß diese Zuordnung ja ohnehin in jedem Fall > gemacht werden Na super. Da sich jeder Autokäufer ohnehin auf eine konkrete Automarke festlegen muss, kann das ebensogut immer ein Trabant sein. Geil. > und zweitens ist es besser, selbige einmal und gründlich > zu erledigen, Es tut mir leid, aber es ist und bleibt sachlich falsch, wenn Dinge, die sachlich variabel sind, "einmal und gründlich" als konstant definiert werden. Das ist bei der führenden Rolle der Arbeiterklasse genauso schiefgelaufen wie beim Pi Law; die unverrückbare Zuordnung von Schaltplansymbolen und Footprints macht da keine Ausnahme. > anstatt sie in jedem Projekt dem Leiterplatten-Autor > zuzumuten. Genau. Da könnte ja auch jemand auf die Idee kommen, dem Koch die Verantwortung für korrektes Würzen zuzumuten, nicht wahr? Das geht ja GAR NICHT -- schließlich kann man vorgewürzte Steaks überall kaufen. > Eagle ist hier deutlich ökonomischer, da diese Zuordnungs- > Arbeit nur einmal erledigt werden muß. Im Gegenteil. Widerstandswert und Footprint sind unabhängige ("orthogonale") Merkmale -- also MUSS es die Möglichkeit zur freien Zuordnung geben. > Und verwirrender oder gar fehleranfälliger ist es auch nicht. > Das ist eine glatte Lüge deinerseits. Zumindest ist der > Leiterplatten-Autor deutlich entlastet, da er sich eben nicht > darum kümmern muß, ob die Zuweisung auch richtig ist und ob > der Footprint auch wirklich für das betreffende Bauteil paßt. Das ist aber eine völlig andere Sache. Es ist aus meiner Sicht VÖLLIG legitim, wenn Du erwartest, dass die EDA-Software auch DEINEN Arbeitsablauf unterstützt. (Falls das nicht klar sein sollte: Das ist kein Sarkasmus; das ist ernst gemeint.) Wenn Du im Schaltplan von vornherein nur Teile verwenden können willst, die man auch kaufen kann, und also nur Symbole mit passendem Footprint auswählen willst, muss die Software eine Möglichkeit dafür bieten. Das hat aber NICHTS mit der Datenstruktur der Bibliotheken ("Stammdaten") zu tun, sondern mit den in Deinem Arbeitsablauf anfallenden Projektdaten ("Verkehrsdaten"). Es geht um eine ZUSÄTZLICHE LEISTUNG der Software, und nicht um eine generelle EINSCHRÄNKUNG in den Bibliotheksdaten. NATÜRLICH sollte die Software so gestrickt sein, dass man z.B. Defaults für den Footprint festlegen kann, oder dass man eine Warnung bekommt, wenn man unsinnige Footprints zu Symbolen zuweist. Aber das ist eine wählbare zusätzliche Leistung der Algorithmen und keine in Stein gemeisselte Zuordnung in den Stammdaten. Typische EDA-Software gefällt sich nach meinem Eindruck darin, große Mengen relativ einfach strukturierter Daten (Symbole, Verbindungen, Footprints, Leiterzüge) effizient zu verwalten, wenn dem ein relativ einfacher Datenfluss zu Grunde liegt. Kompliziertere Daten und deren Zuordnung (Typen, Hersteller, Datenblätter, Händler, Bestellnummern, Lagerlistennummern, Spice-Modelle, Footprints, Gehäuse, ...) bleiben außen vor. Das ist aber im betrieblichen Alltag genauso wichtig. > Wer Schaltungen entwirft, plant schon vor dem Erstellen > des Stromlaufplans ein, was er denn für Bauteile wofür zu > verwenden gedenkt. Es tut mir leid -- aber DU bist nicht MAN. > Wer kein dickes Brett vor dem Kopfe hat, wird schon ganz > am Anfang für den dicken Strom-Shunt keinen zierlichen > 0603 Widerstand einplanen, sondern so einen Widerstand, > der erstens technisch tatsächlich paßt und zweitens beim > Distributor seiner Wahl auch erhältlich ist. BITTE sprich für DICH und NUR für Dich. Ich fordere Dich dringend auf, nicht ständig in meinem Namen hier aufzutreten. Wenn ich einen ersten Entwurf für einen ZF-Verstärker zeichne, dann will ich NICHT festlegen, welchen Footprint der Transistor der ersten Stufe bekommt -- der Typ steht nämlich noch gar nicht fest. > All die Leute, die sich erst bei der Leiterplatte um konkrete > Bauformen kümmern wollen, scheinen mir eher PSpice-Leute zu > sein, die sich mental nur in theoretischen Simulationen bewegen > und sich dann beim Formulieren einer tatsächlichen Hardware > schwer tun. Es tut mir leid, Dein Weltbild zu stören, aber ich bin SPICE-Verächter und möchte TROTZDEM keine Symbolbibiliothek mit Footprints. > Ich kenne Leute, die bei der Simulation eben 50 Ohm beim > Widerstand eingetragen haben (schreibt sich ja so schön > einfach..) und später dann darauf beharren, daß der Einkäufer > einen 49.9 Ohm Widerstand beschaffen muß. Nun ja -- falls es sich um den Abschlusswiderstand in einer HF-Messanordnung handelt, ist das nachzuvollziehen. Ich würde trotzdem 100 Ohm || 100 Ohm verwenden. Nicht alles ist so eindeutig, wie es auf den ersten Blick scheinen mag.
Ich kann immer noch nicht nachvollziehen was an den KiCad Bibliotheken besser sein soll als an den Eagle Libs. Ich lege mir ALLE Teile (Packages + Symbole) selbst nach Datenblatt und bei einigen Bauteilen nach Rücksprache mit unserem Bestücker an. Wenn ich einen Controller anlege der mehrere Packages mit den gleichem Pin Count habe kann ich dem Symbol alle Varianten übergeben. Ich habe in meinen Diskreten Bauteilen nur EINEN 2 Pin Widerstand (Symbol). Im Board kann ich dann bequem per "change package" die Bauform auf alle in der Lib angelegten Packages ändern (bei mir alle SMD Bauformen + ein paar THT). Seid Eagle 7 kann man einem Symbol-Pin auch mehrere Package Pins zuweisen. Das ist gut wenn man Packages mit Power-Pins oder Packages mit mehreren gleichen Pins hat (Widerstände mit 4 Pins). Das ganze wird 1x gamacht - beim anlegen der Lib. Wenn ich ein Package benötige was nicht ganz dem Standard entspricht oder es nicht vorhanden ist wird eine neue Variante angelegt. -> Was ist daran nun schlechter als bei KiCad? -> gründe für mich nicht umzusteigen sind in erster Linie fehlen F/B Annotation. Sonst hat KiCad nach meinen ersten Test schon ein paar nette Features.
_Sebastian schrieb: > -> Was ist daran nun schlechter als bei KiCad? Das muss jeder für sich selbst entscheiden. Ich war jahrelang (>10 Jahre - auch beruflich) mit Eagle zufrieden und jetzt bin ich mit KiCad zufrieden. > -> gründe für mich nicht umzusteigen sind in erster Linie fehlen F/B > Annotation. Ja, es ist halt anders ... Die ganzen Diskussionen über Eagle vs KiCad erinnern mich so bisserl an Windows vs Linux oder Android vs IOS oder Hund vs Katze. Man gewöhnt sich daran - aber in der Anfangszeit hat es mich auch gestört. > Sonst hat KiCad nach meinen ersten Test schon ein paar nette Features. Insbesondere kann man mit KiCad super mit dem Koordinatensystem arbeiten. Da hat es unglaublich tolle Features ... - Ursprung setzen, an dem das Grid beginnt - Gruppen exakt verschieben (wenn ich einen Nutzen baue, versuche ich die Platinenkanten (=Dimension oder CutOut) auf ein 0,5er Raster zu setzen. Ich muss mir nur ein Liniensegment anschauen und dann sehe ich, die Linie beginnt bei 10,23mm/17,7mm und kann die ganze Selektion dann exakt um 0,23mm nach links und 0,7mm nach oben verschieben, dann bin ich wieder im Raster Oder wenn ich ein Bauteil designe, zeichne ich eine Linie, die ungefähr da sein soll wo sie ist und kann dann die 4 Koordinaten der 2 Eckpunkte exakt eingeben. Oder ich hab ein Liniensegment gezeichnet und brauche das gleiche - nach Datenblatt des Bauteils - nochmal 20,345mm weiter unten, dann kopiere ich das Segment und verschiebe es exakt um 20,345 in Y. - Relative Koordinaten (hat Eagle auch) Das ist wirklich top gelöst und für mich ein echter Mehrwert zu Eagle (5 ?) Weiß nicht, in wie weit sich Eagle da seit V5 verbessert hat ... Man hat aber Zugriff auf alle Properties direkt und kann wirklich exakt arbeiten - und schnell vorallem. Für mich war damals der Umsteigegrund die Kosten von Eagle und mittlerweile fallen mir ständig Funktionen auf, die besser gelöst sind als bei Eagle. Achja und der OpenGL-Modus ist der Hammer ... Längenangleich differenzieller Leitungen oder der Push&Shove ist super ...
:
Bearbeitet durch User
Bülent C. schrieb: > mal so nüchtern - und ohne einen Nebenkriegsschauplatz eröffnen zu > wollen - in die Runde gefragt: > Was wären die Beweggründe - aus funktionaler Sicht - von Eagle auf KiCad > umzusteigen? Zudem würde es mich interessieren, auf welche Eagle > Funktionen ich bei der Verwendung von KiCad verzichten müsste. > Funktionen die KiCad hat aber Eagle nicht würden mich in erster Linie > erst einmal nicht interessieren. Ich bin weder Eagle- noch KiCad-Nutzer (ich arbeite mit Altium), habe aber zumindest in Eagle mal einen ganz, ganz kurzen Einblick gehabt und KiCad ist Altium in einige Dingen nicht unähnlich. Verzichten mußt du auf nichts, KiCad kann alles was Eagle auch kann, umgekehrt gilt dies allerdings nicht. Was bei KiCad (und den meisten EDA-Programmen) anders ist, ist der vorgesehene Arbeitsfluß. Manche Programme sehen da einen bestimmten, strikten Arbeitsfluß vor, andere lassen einem mehr oder weniger viel Freiraum. Beispiel FB-Annotation: Nutzer wie W.S. machen den Eindruck, das KiCad und allen anderen EDA-Programmen da eine ganz entscheidende Funktion fehlt weil sie keine FBA haben. Der Punkt ist: KiCad, Altium und andere brauchen die FBA nicht, die haben einen anderen Weg gewählt um die gleiche Funktionalität herzustellen (und dabei weniger Nachteile als FBA mitbringen). Es fehlt dir nichts-es ist nur Einiges anders.
Possetitjel schrieb: > Da sich jeder Autokäufer ohnehin auf eine konkrete Automarke > festlegen muss, kann das ebensogut immer ein Trabant sein. Leider abgekuendigt. Und nun? wendelsberg
_Sebastian schrieb: > Ich kann immer noch nicht nachvollziehen was an den KiCad Bibliotheken > besser sein soll als an den Eagle Libs. Sie sind es nicht. Erst mal muss man zwischen dem Tool und der Bibliothek unterscheiden. Ich glaube durchaus, dass die Eagle-Bibliothek noch viel umfangreicher ist als die Kicad Bibliothek. Wenn wir aber von der Art sprechen, wie mit den Bibliotheken gearbeitet wird, ist diese Frage, wie schon soooo viele Male zuvor mit einer Gegenfrage zu beantworten: Wenn ein Tool Nur Weg A zum Ziel kennt, ein anderes Tool jedoch neben Weg A auch Weg B und Weg C, warum sollte das schlechter sein? Kicad kann sich bezüglich der Zuordnung zwischen Schemasymbolen und Footprints genau gleich verhalten wie Eagle. Aber es kann auch anders. Interessanterweise wird diese Alternative von Kicad-Nutzern gern genutzt. Und die Tatsache, dass das zusätzlich möglich ist, wird nun als ganz grosser Nachteil von Kicad gesehen. Wenn ich eine Lötstation kaufe, mit der ich alles machen kann, was ich brauche, dann ist es mir egal, wenn sie auch noch ein Heissluftgebläse hat, welches ich nicht brauche. Ich werde dann nicht sagen: "Och schade, diese Station wäre perfekt für mich... aber ich will kein Heissluftgebläse haben. Jetzt muss ich halt weitersuchen."
Mampf F. schrieb: > Weiß nicht, in wie weit sich Eagle da seit V5 verbessert hat ... Nichts, weil alles was du beschrieben hast auch mit eagle geht. > > Man hat aber Zugriff auf alle Properties direkt und kann wirklich exakt > arbeiten - und schnell vorallem. dito > Oder ich hab ein Liniensegment gezeichnet und brauche das gleiche - nach > Datenblatt des Bauteils - nochmal 20,345mm weiter unten, dann kopiere > ich das Segment und verschiebe es exakt um 20,345 in Y. > Oder ich hab ein Liniensegment gezeichnet und brauche das gleiche - nach > Datenblatt des Bauteils - nochmal 20,345mm weiter unten, dann kopiere > ich das Segment und verschiebe es exakt um 20,345 in Y. Mache ich in eagle auch öfter, aber da es keine Fangpunkte hat und die Koordinateneingabe etwas umständlich ist nehme ich gleich Autocad und importiere das dxf. > > Für mich war damals der Umsteigegrund die Kosten von Eagle und > mittlerweile fallen mir ständig Funktionen auf, die besser gelöst sind > als bei Eagle. Das kann ich mir gut vorstellen. Eagle hat einige imho sehr gute Konzepte die aber eher benutzerfeindlich umgesetzt sind. > Push&Shove Wäre für mich ein guter Grund umzusteigen. Wie sieht es eigentlich bei Kicad mit Bestückung aus? Eagle hat da mit den mount... ulp's eine sehr gute Hilfe. Was ist mit Nutzenerstellung? (Die von Eagle halte ich für unbrauchbar)
Simon H. schrieb: > Und die Tatsache, dass das zusätzlich möglich ist, wird nun > als ganz grosser Nachteil von Kicad gesehen. wer sollte das so sehen? Bibliotheken haben imho die Eigenschaft das alle Teile da sind, außer die welche du gerade brauchst. Die zweite Eigenschaft: Wenn vorhanden dann veraltet und die dritte dass die erstellten Teile für einen Lötprozess erstellt wurden den du nicht anwendest. Es ist für mich also wichtiger Teile schnell und ohne große Klimmzüge erstellen zu können. Da kriege ich bei eagle jedes mal die Krätze weil es das mMn mieseste Benutzerinterface zur Lib Erstellung hat das man sich ausdenken kann. Das sage ich als Nutzer seit V 2.x
il Conte schrieb: > Das kann man so nicht stehen lassen! Warum nicht? Es ist eine Meinung unter vielen. Zufällig meine. > Es kommt drauf an welche Fragen man stellt und wie man sie stellt > und welche Vorschäge man macht. Wenn ich die Möglichkeit hätte welche Fragestellungen in welcher Form und welche Vorschläge zulässig sind fände ich die Welt ein wenig eintönig ;-) > > Im Übrigen haben die KiCAd - Leute 2 von uns gemachte Vorschläge > (zu besseren Nutzung) innerhalb von 14 Tagen implementiert > (Nightly Version). Probier das mal bei deinem CAD-Liferanten > und komm dann mit der Erfolgsmeldung hier zurück! Hat Cadsoft bei einigen Fehlern innerhalb von 24 Stunden geschafft. Und nu? Wem ist damit geholfen wenn der nächste Fehler kommt? Lass mal die Kirche im Dorf, bei Kicad sitzen gute Leute und bei Cadsoft auch, ebenso bei allen anderen Herstellern wo die Software aktiv gepflegt wird. Open Source hat den Nachteil das die Menschen die sich dafür einsetzen keine Entlohnung erhalten. Hab selber einiges in dem Bereich gemacht und in der Regel hast du irgendwann die Nase voll von der Anspruchshaltung der wenigen die nichts Beitragen aber immer mehr haben wollen. Da wirst du heute durch Bugtrackingsysteme etwas von abgeschirmt, aber das Prinzip ändert sich dadurch nicht. Wenn dann nicht (teil)kommerzialisiert wird (wie bei Linux oder OO) oder die Autoren in öffentlichen Instituten arbeiten ist es irgendwann Essig mit der Weiterentwicklung.
X4U schrieb: > Open Source hat den Nachteil das die Menschen die sich dafür einsetzen > keine Entlohnung erhalten. Hab selber einiges in dem Bereich gemacht und > in der Regel hast du irgendwann die Nase voll von der Anspruchshaltung > der wenigen die nichts Beitragen aber immer mehr haben wollen. Da wirst > du heute durch Bugtrackingsysteme etwas von abgeschirmt, aber das > Prinzip ändert sich dadurch nicht. Ohne Anspruchshaltung geht es nicht. Das gilt für JEDE SW, egal ob kommerziell oder OS. Das Gegenteil wäre nämlich sich mit kruder Bedienweise, Bugs, mangelnden Funktionen usw. einfach zufrieden zu geben. Damit wird aber jede SW früher oder später vom Anwender einfach links liegen gelassen, spätestens wenn bessere Alternativen auftauchen. Das Problem mit der Entlohnung sehe ich auch. Das ist ein inhärentes Problem bei OS. Das könnte man durchbrechen, indem man beispielsweise eine Art Mitbestimmung bei der Entwicklung (Wünsche zur GUI-Gestaltung, Bedienbarkeit, Funktionsumfang) gegen einen freiwilligen Kleinbetrag z.B. 5 oder 10 Euro pro Monat ein Jahr lang als Spende an den/die Entwickler bezahlt. Das wäre dann ein Motivationsschub an die Entwicklung auch am Ball zu bleiben. Es wird endlich Zeit mal diesen Teufelskreis "es ist immer alles Umsonst, deswegen lieber Anwender halt's Maul und stell keine Ansprüche an deine OS" zu durchbrechen. Implizit geschieht das z.B. bereits durch Firmen, die ihre bezahlten Entwickler mit an OS-Projekten arbeiten lassen, wovon die Community letztlich dann auch profitiert (KiCAD wäre ein Beispiel dafür). Die Frage ist halt immer, WER bezahlt letztlich dafür. Nur der/die Entwickler, die ihre Freizeit opfern oder eine Firma, die aus Eigeninteresse die Entwicklung einer OS-SW vorantreibt oder auch mal der Endanwender, der dann auch ein Stück weit die Entwicklung der SW selber mitbestimmen dürfen können soll(te) (vorsichtig formuliert ;)). > Wenn dann nicht (teil)kommerzialisiert wird (wie bei Linux oder OO) oder > die Autoren in öffentlichen Instituten arbeiten ist es irgendwann Essig > mit der Weiterentwicklung. Deswegen macht es auch keinen wirklichen Sinn, wenn sich ein Einzelner daran versucht sich sein "besseres KiCAD" (als unbezahltes Hobbyprojekt) von Grund auf neu zu schreiben, anstatt lieber gleich bei KiCAD seine Programmierfähigkeiten mit einzubringen, um dort die SW zu verbessern. Die OS Szene hat schon genug halbgare Tools, die dann jahrelang brach liegen.
Hallo Brille. Brille schrieb: > Ohne Anspruchshaltung geht es nicht. Das gilt für JEDE SW, egal ob > kommerziell oder OS. Das Gegenteil wäre nämlich sich mit kruder > Bedienweise, Bugs, mangelnden Funktionen usw. einfach zufrieden zu > geben. Damit wird aber jede SW früher oder später vom Anwender einfach > links liegen gelassen, spätestens wenn bessere Alternativen auftauchen. Du übersiehst, dass oft eine der Hauptmotive von Open source Entwicklungen gerade ist, eine SW zu schreiben, die anders funktioniert als der handelsübliche Kram. Sei es, weil kommerzielle Software so gestaltet ist, dass der Entscheider, der den Vertrag unterschreibt und das Geld zahlt, meint, die SW ist brauchbar, aber der tatsächliche Anwender dann große Probleme damit hat.... Oder weil der jeweilige Open Source Entwickler ein persönliches Problem aus welchem Grunde auch immer mit einer Software hat. die für einen Massenmarkt geschrieben wurde. Nicht umsonst gibt es ja auch z.B. orthopädische Schuhe, um mal ein Beispiel aus einer anderen Branche zu nehmen. solche SW muss man notgedrungen selber oder in kleinen Gruppen selber schreiben, und nimmt dann auch in einigen Bereichen Unzulänglichkeiten der SW in Kauf. > Es wird endlich Zeit mal diesen Teufelskreis "es ist immer alles > Umsonst, deswegen lieber Anwender halt's Maul und stell keine Ansprüche > an deine OS" zu durchbrechen. Das wird nur den Anwendern so gesagt, die die SW nur verwenden, weil sie umsonst zu haben ist, und dann rumpatzen. ;O) Konstruktive Kritik ist ok. Aber vergiss nicht, dass OS meist nicht eine "für lau Kopie" kommerzieller Software sein will, sondern eben auch Ansprüche abdecken will, die eine kommerzielle Software nicht abdecken kann, weil zu exotisch und der Markt zu klein. Insofern passt Dein marktwirtschftlicher Ansatz dabei wenig, weil in einer solchen Situation der "Markt" halt nicht so funktioniert wie gewünscht, und diese Leute machen sich dann halt einen eigenen Markt nach eigenen Regeln auf. Und jetzt kommst Du von aussen vom "grossen" Markt, siehst dass und sagst "ist ja alles Mist, das kann man ja nicht verkaufen" ;O) Lass die Leute mal selber machen und halt Dich da einfach raus, wenn es Dir nur darum geht, das Produkt "Massenmarkttauglich" zu machen. Insofern verstehe ich Deine Intention dabei auch nicht: Du kritisierst, dass die Sonderanfertigung von orthopädischem Schuh nicht in Massen kopiert und auf dem Markt geworfen werden kann, weil sie halt nur für den passt, für den es die Sonderanfertigung ist.....aber das erwartet ja auch keiner. Und wenn die Sonderanfertigungen so teuer sind, und das Laufen mit normalen Schuhen so weh tut, nun, dann werden die Schuhe halt selbst gemacht. Wo ist nun konkret Dein Problem? Wenn Dir die Schuhe nicht passen, dann zieh sie halt nicht an. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
_Sebastian schrieb: > Ich kann immer noch nicht nachvollziehen was an den > KiCad Bibliotheken besser sein soll als an den Eagle Libs. Man kann (soweit ich das verstanden habe) die Zuordnung von Schaltplansymbol und Footprint viel leichter verändern. > Ich lege mir ALLE Teile (Packages + Symbole) selbst nach > Datenblatt und bei einigen Bauteilen nach Rücksprache mit > unserem Bestücker an. Das klappt nach meinem Verständnis nur, wenn Du den genauen Typ immer schon kennst. Was machst Du, wenn nur feststeht: "Hier kommt ein npn-HF-Transistor im SOT223 hin"? > -> Was ist daran nun schlechter als bei KiCad? Der Zwang, einen bestimmten Footprint nur über den Umweg eines konkreten Typs wählen zu können, ist Scheisse. Der Fall, dass man den Footprint schon kennt, den Typ aber noch nicht, kommt halt praktisch auch vor.
Wühlhase schrieb: > Was bei KiCad (und den meisten EDA-Programmen) anders ist, > ist der vorgesehene Arbeitsfluß. Manche Programme sehen da > einen bestimmten, strikten Arbeitsfluß vor, andere lassen > einem mehr oder weniger viel Freiraum. Das Dumme ist, dass das ziemlich weitreichende Konsequenzen für den betrieblichen Einsatz solcher Software hat. Im Hobbybereich mit Ein-Mann-Projekten fällt das nicht auf, aber was ist, wenn mein Vorgänger Programm X verwendet hat, ich nur mit Programm Y klarkomme und mein neuer Kollege, der ein Jahr später eingestellt wird, Programm Z bevorzugt? Wenn die Dateiformate kompatibel wären, wäre das kein Problem. Sind sie aber meines Wissens nicht. > Beispiel FB-Annotation: Nutzer wie W.S. machen den Eindruck, > das KiCad und allen anderen EDA-Programmen da eine ganz > entscheidende Funktion fehlt weil sie keine FBA haben. > Der Punkt ist: KiCad, Altium und andere brauchen die FBA > nicht, die haben einen anderen Weg gewählt um die gleiche > Funktionalität herzustellen (und dabei weniger Nachteile als > FBA mitbringen). Magst Du den Punkt bitte genauer erklären? Ich habe nur kleinere Sachen mit Target gemacht und FBA weder verwendet noch vermisst.
Hallo Brille. Brille schrieb: > Deswegen macht es auch keinen wirklichen Sinn, wenn sich ein Einzelner > daran versucht sich sein "besseres KiCAD" (als unbezahltes Hobbyprojekt) > von Grund auf neu zu schreiben, anstatt lieber gleich bei KiCAD seine > Programmierfähigkeiten mit einzubringen, um dort die SW zu verbessern. > Die OS Szene hat schon genug halbgare Tools, die dann jahrelang brach > liegen. Hier im Forum wird von einigen Leuten beklagt, dass KiCad viel zu kompliziert sei, und für ganz einfache Hobbyanfänger Projekte total überkandidelt sei. Nun, wenn diese sich nun hinsetzten, und so ein einfachst Programm z.B. im Stile von [[https://www.mikrocontroller.net/articles/Schaltplaneditoren#KISSCAD|Kisscad]] schreiben, das aber im Bibliotheken- und Schematic/Layoutformat z.B. mit KiCad kompatibel wäre, so hätten sie ein sehr einfaces Schaltplan und Platinenmalprogramm, das aber mit KiCAD in den Dateien kompatibel ist. Projekte könnten ausgetauscht werden, und ein Bibliotheksstamm existiert auch. Gerber export und drucken könnte man sich schon schenken, denn dafür könnte man das Projekt in kiCad importieren und lediglich den Gerber Export oder das Drucken in kiCad durchführen. Die Bedienung des Programmes bzw. der Suite könnte einfach gehalten sein, so wie Paint einfach gegenüber Gimp ist. Ein solches Kleinprojekt könnte von einer einzelnen Person schon gestemmt werden, und würde nur gelegentliche Wartung erfordern. Nur so als Gedankenspiel......;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Oder weil der jeweilige Open Source Entwickler ein > persönliches Problem aus welchem Grunde auch immer > mit einer Software hat. die für einen Massenmarkt > geschrieben wurde. Hier liegt ein wesentlicher Teil des Problems: Für EDA-Software GIBT es schlicht keinen Massenmarkt. Die Masse der Hobbyisten bildet keinen Markt, denn für viele wären 50 Euro immer noch zu teuer (zumindest hat man den Eindruck). Der Markt der kommerziellen Anwender dagegen ist klein. Ich erinnere mich noch deutlich, wie sehr O. Bartels vor vielen Jahren geklagt hat. Es gibt also -- um in Deinem Bilde zu bleiben -- NUR Handwerker, die orthopädische Schuhe anfertigen.
Nachtrag: Bernd W. schrieb: Ich bin etwas unkonzentriert. > Nun, wenn diese sich nun hinsetzten, und so ein einfachst Programm z.B. > im Stile von > [[https://www.mikrocontroller.net/articles/Schaltplaneditoren#KISSCAD|Kisscad]] Der Link sollte auf KISSCAD gehen: https://www.mikrocontroller.net/articles/Schaltplaneditoren#KISSCAD Eigentlich sollte und würde ich jetzt lieber Schlafen, aber meine Nackenprobleme halten mich wach....:( Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Hier im Forum wird von einigen Leuten beklagt, dass KiCad viel zu > kompliziert sei, und für ganz einfache Hobbyanfänger Projekte total > überkandidelt sei. Ist es auch. So wie viele andere auch. Obwohl ich EAGLE schätze, wäre ich für eine Kombination von S-Plan und Sprint . Natürlich mit Backannotation. Auf einem Stand von vor zehn Jahren. Ohne Bauteilliste. Ohne Gerber. Kostenlos. Kein 3D. ... Den ganzen Schnulli braucht man doch nicht. Mit meinem EAGLE 3.55 von 1999 in der Version von Euro von vor 25 Jahren reicht mir meist völlig. Nur neuere Biblio kann ich nicht einpflegen :-(.
Bernd W. schrieb: > Nun, wenn diese sich nun hinsetzten, [...] Einige dieser Leute sitzen schon. > und so ein einfachst Programm [...] schreiben, das aber im > Bibliotheken- und Schematic/Layoutformat z.B. mit KiCad > kompatibel wäre, so hätten sie ein sehr einfaces Schaltplan > und Platinenmalprogramm, das aber mit KiCAD in den Dateien > kompatibel ist. Gibt es doch (in modifizierter Form) schon. Frag mal Stefan S. > [...] > Die Bedienung des Programmes bzw. der Suite könnte einfach > gehalten sein, so wie Paint einfach gegenüber Gimp ist. Genau. Mein Reden seit dem Bauernkrieg. > Ein solches Kleinprojekt könnte von einer einzelnen Person > schon gestemmt werden, und würde nur gelegentliche Wartung > erfordern. Nee. Einspruch. Ich gebe Dir Recht in der Vermutung, dass der größte Teil des Codes sicher erstmal von einem Einzelnen erstellt werden könnte. ABER: 1. Die Projektgruppe müsste mittelfristig auf mindestens 5 bis 10 Leute anwachsen, damit kontinuierliche Arbeit gesichert werden kann, ohne dass einzelne Leute unter Druck geraten. 2. Das Wichtigste ist nachhaltige, kontinuierliche Arbeit -- damit das Projekt von potenziellen Anwendern überhaupt ernstgenommen wird. Das geht nur mit guter Kommunikation untereinander und nach Außen. 3. Es müsste ein ECHTES Alleinstellungsmerkmal geben, das für potenzielle Anwender interessant ist. Als ein solches würde ich z.B. ansehen, wenn der Schaltplaneditor Schaltpläne für gEDA, KiCAD, Eagle, Target und BAE erzeugen könnte. Einfache Bedienbarkeit, gute Ergonomie setze ich voraus. > Nur so als Gedankenspiel......;O) Ich habe Dich schon verstanden :) Das Kernproblem liegt mMn auf der menschlichen Ebene: 1. Für begeisterte Programmierer ist diese Arbeit nicht attraktiv genug; solche kleinkarierte Fleissarbeit ist keine Herausforderung und bringt weder Ruhm noch Ehre. 2. Weniger ambitionierte Programmierer trauen sich an die Sache nicht heran, weil sie keine Erfolgschance sehen. Ich bin inzwischen der Meinung, dass die Aufgabe rein programmiertechnisch gar keine überirdischen Fähigkeiten verlangt; die Hürden liegen in der relativ komplexen Anwendungslogik. Eher (unter-)durchschnittliche Programmierer könnten das mMn ohne weiteres schaffen, wenn sie gut miteinander reden könnten und projektmethodisch geschickt vorgehen würden. Das Ganze ist mehr als die Summe der Einzelteile -- aber dieses Ganze muss sich erstmal zusammenfinden.
Bernd W. schrieb: > Ein solches Kleinprojekt könnte von einer einzelnen Person schon > gestemmt werden, und würde nur gelegentliche Wartung erfordern. Da würde ich meine Zeit eher in Tutorials und man pages für Kicad stecken bevor ich das Rad zum X-ten mal neu erfinde.
X4U schrieb: > Bernd W. schrieb: >> Ein solches Kleinprojekt könnte von einer einzelnen Person >> schon gestemmt werden, und würde nur gelegentliche Wartung >> erfordern. > > Da würde ich meine Zeit eher in Tutorials und man pages > für Kicad stecken bevor ich das Rad zum X-ten mal neu > erfinde. Ach so?! Wenn das alles schon zum X-ten Male erfunden wurde, kannst Du sicherlich 10 Schaltplaneditoren aufzählen, die - quelloffen, - portabel, - interoperabel sowie - leicht zu bedienen (=ergonomisch) sind. Target, Eagle, Altium, BAE fallen wegen fehlender Quelloffenheit heraus. Kisscad und Diptrace sind nicht portabel. gschem und KiCAD sind meiner bescheidenen Meinung nach bedientechnisch eine mittlere Katastrophe (wobei ich gschem minimal besser finde als den KiCAD- Schaltplaneditor). Bleibt Fritzing als Kandidat :)
michael_ schrieb: > Mit meinem EAGLE 3.55 von 1999 in der Version von Euro von vor 25 Jahren > reicht mir meist völlig. Ich hatte mal einen Chef, der hat alles mit PIC Controller gemacht, weil das das einzige war, was er kannte ... Zu der damaligen Zeit - vor 15 Jahren - hatte ich ihm schon von ARM-Controllern vorgeschwärmt ... Bei neuen Projekten hatte ich ihn damals in Grund und Boden diskutiert, aber er wollte sich nicht auf die ARM einlassen. Weil, es kennt sich ja niemand damit aus und alles neu - stattdessen wollte er dann PIC32 verwenden (verwendet einen Mach Kern) ... Seufz xD Gegen meine Argumentation (alles fertig was er braucht, praktische Erfahrung mit den Controllern usw) hat er sich gleich komplett dagegen entschieden und hat sich von Code Mercenaries diese sonderbaren HID-USB-Teile besorgt. Damit hat er dann eine SPS-Maschinensteuerung gebastelt ... seufz (*edit*: USB-HID garantiert nicht, dass die Daten ankommen ... für industrielle Maschinensteuerungen natürlich genau das richtige ;-) Jahre später kam er dann - ich arbeitete schon garnicht mehr dort - und meinte ganz erstaunt, dass ARM 85% Martkanteil im Embedded-Bereich hat ... Ich hab dazu dann nichts mehr gesagt. Mit Eagle 3.55 hab ich auch viel gearbeitet - es schadet aber nicht sich auch mal neue Sachen anzuschauen. Eagle 4 zB, das konnte immerhin schon Bauteile drehen ;-) Seh ich aber immer wieder - und ich bin da keine Ausnahme -, dass man lieber konservativ ist und das verwendet, was man schon kennt, obwohl es bessere Alternativen gibt. Der Mensch ist ein Gewöhnungstier und wenn man beruflich etwas machen muss, hat man meist eh keine Zeit, sich in neue Dinge einzuarbeiten. Klar, KiCad ist anfangs weder benutzerfreundlich noch intuitiv, wenn man sich aber mal reingebissen hat (oder wie andere meinen "verhirnt" hat) kann man damit gut und teilweise besser arbeiten als zB mit Eagle.
:
Bearbeitet durch User
Possetitjel schrieb: >> Ich lege mir ALLE Teile (Packages + Symbole) selbst nach >> Datenblatt und bei einigen Bauteilen nach Rücksprache mit >> unserem Bestücker an. > > Das klappt nach meinem Verständnis nur, wenn Du den genauen > Typ immer schon kennst. Was machst Du, wenn nur feststeht: > "Hier kommt ein npn-HF-Transistor im SOT223 hin"? Wenn ich erst ein Sot23 gewählt habe (weil der Typ noch nicht fest stand) meist hat man ja beim Schaltplandesign schon eine Vorahnung in welcher Größenordnung das Package ist. -> Dann ist man am fein planen und selektieren (Layout ist schon mal so sortiert das es sinn macht), dann klicke ich im Layout das Bauteil an "change package" und wähle das richtige aus. Dann habe ich im Layout UND im Schaltplan das richtige Teil. Im Schaltplan wird dann noch der Hersteller und Wert eingetragen. Und wenn ein Package nicht vorhanden ist, wird es NEU angelegt und als Variante dem Bauteil (NPN-Transistor) hinzugefügt. Kann man so oder mit einer Ähnlichen Strategie in KiCad arbeiten? Das vermeidet enorm viele Fehler.
_Sebastian schrieb: > Kann man so oder mit einer Ähnlichen Strategie in KiCad arbeiten? Da es keine Backannotation gibt, würdesst du dort das Package an einer anderen Stelle ändern (als Attribut im Schaltplan), aber im Prinzip funktioniert das auch. Nur: schon beim Austausch des SOT-23 durch ein SOT-223 hast du doch das Problem, dass du ein dreibeiniges Bauteil durch ein vierbeiniges ersetzt. Wie machst du das, ohne den Schaltplan anzufassen?
Jörg W. schrieb: > Wie machst du das, ohne den Schaltplan anzufassen? Wenn das Symbol im Schaltplan gleicht bleibt kann man einfach nur das Package tauschen. Da ist es egal wie viele Pins das Package hat. Man kann einem Pin vom Symbol mehrere Pins im Package zuweisen (die sind dann per Airwire verbunden).
_Sebastian schrieb: > Wenn das Symbol im Schaltplan gleicht bleibt kann man einfach nur das > Package tauschen. Yep, aber nur dann. Im Prinzip ist so ein SOT-223 jedoch kein dreipoliges Bauteil, denn eigentlich kann man Pin 2 und 4 auch als Lötbrücke benutzen. Dafür bedürfte es aber einer Bauteildefinition, die sie als „intern verbunden“ darstellen kann. Bin mir gerade nicht sicher, aber ich glaube, Kicad kann das nicht. Ich habe jahrelang mit BAE gearbeitet, welches durchaus eine Backannotation und Bauformtausch im Layout beherrscht hat, aber ich habe dieses Feature eigentlich nie benötigt. Der einzig wirkliche Nutzen von deren Backannotation war es, dass man Pin-/Gate-Swap und im Layout durchgeführte Umnummerierung von Bauteilen (damit man sie auf der Platine systematisch anordnen kann) in den Schaltplan zurück transformiert.
Jörg W. schrieb: > Im Prinzip ist so ein SOT-223 jedoch kein dreipoliges Bauteil, denn > eigentlich kann man Pin 2 und 4 auch als Lötbrücke benutzen. Dafür > bedürfte es aber einer Bauteildefinition, die sie als „intern > verbunden“ darstellen kann. > > Bin mir gerade nicht sicher, aber ich glaube, Kicad kann das nicht. Jein, so direkt kann das KiCad nicht. Man könnte aber tatsächlich die "Net-Tie"-Funktionalität (eigentlich ein ekliger Hack, der bei den Entwicklern bekannt ist, aber toleriert wird) verwenden. Und zwar kann man im Footprint von einem SMD-Pad zum anderen SMD-Pad eine Kupferlinie zeichnen. Im Gerber und in der Ansicht ist es dann verbunden, rein logisch aber nicht. Das eklige daran ist, dass diese Kupferlinie vom DRC ignoriert wird, d.h. man könnte beim Routen diese Linie kreuzen und dem DRC würde es nicht auffallen. Also besser nicht machen... Aber zum Verbinden von GND und AGND ist es super ... Da liegen die Pads normal eh so dicht aneinander, dass da nichts anderes durchgeroutet werden könnte. Aber trotzdem, KiCad würde niemals wissen, dass zB Pin2 und Pin4 Äquivalent sind, d.h. nur einer von beiden angeschlossen werden muss, weil der andere intern mitverbunden ist.
:
Bearbeitet durch User
FBA habe ich auch nie vermisst. Hierzu muss ich nun aber zugeben, dass ich jetzt der Konservative bin. Wenn es gut gelöst wäre, wäre das sicher eine feine Sache, gerade für Pin-Swapping etc. Aber generell bin ich da einfach sehr skeptisch. In meinem Weltbild ist das Schema der Chef, resp. der, der das Schema zeichnet. Das Layout, resp. der, der dieses erstellt (das wäre in meinem Fall auch ich) soll sich gefälligst danach richten. Und die Gerberdaten sollen das zeigen, was das Layout will. Klare Hierarchie. Wenn ich nach dem Compilieren sehe, dass ich mich in einem String vertippt habe, würde ich nie erwarten, dass ich im Hex-Editor diesen String ändern und dann eine FB-Annotation zum Source-Code machen kann. Und wenn ich es könnte, würde ich es nicht wollen. Anderes Beispiel: Codegenerierung über UML vs generierter Source-Code. Wobei das hier wohl geht, man aber auch hier sehr gut aufpassen muss. Bezüglich dem Bauteil, das im Schema drei, im Layout aber vier Anschlüsse hat: Auch hier bin ich halt konservativ und finde, dass jeder Anschluss explizit im Schema präsent sein muss. Eben, das Schema ist der Chef. Aber ich gebe zu, das sind Gewohnheiten meinerseits.
Hallo Mampf. Mampf F. schrieb: > Das eklige daran ist, dass diese Kupferlinie vom DRC ignoriert wird, > d.h. man könnte beim Routen diese Linie kreuzen und dem DRC würde es > nicht auffallen. > > Also besser nicht machen... Aber zum Verbinden von GND und AGND ist es > super ... Da liegen die Pads normal eh so dicht aneinander, dass da > nichts anderes durchgeroutet werden könnte. Richtig. Das Kupfer zwischen den Pads ist "Niemandsland", d.h. es würde von Polygonen überschrieben bzw. Mindestabstandsverletzungen würden im DRC nicht entdeckt, wenn Du die Pads nicht so Dicht beisammen machst, dass das Kupfer dazwischen unter die Aegis der Isolationsabstände der Pads gerät. d.h. die Pads sollten so dicht beisammenliegen, dass ihre Isolationsabstände sich so eben nicht überlappen. Die Leiterbahn dazwischen wird vom DRC nicht entdeckt und nicht geschützt, aber es kann auch nichts anderes hindurchgeroutet werden, weil es immer den Isolationsabstand des einen oder anderen Pads verletzten würde. Trotzdem, ein übler Hack. Hat aber schon jemand probiert, ob es in den aktuellen Versionen besser ist? Siehe: Beitrag "Re: Neues bei KiCAD Nightly-Builds ab 2017 Okt." Weitere Infos zu Netties in KiCad und im allgemeinen finden sich hier: Beitrag "Re: Kicad Leiterbahn im Footprint möglich?" Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Oh, da tut sich derzeit ja einiges ... Hmm, den Eagle-Importer muss ich mal testen :) Die Contributions der Cern-Leute treiben KiCad echt ganz schön voran - auf deren Konto ging ja auch der Push & Shove :)
:
Bearbeitet durch User
Simon H. schrieb: > FBA habe ich auch nie vermisst. Hierzu muss ich nun aber zugeben, dass > ich jetzt der Konservative bin. Wenn es gut gelöst wäre, wäre das > sicher eine feine Sache, gerade für Pin-Swapping etc. Aber generell bin > ich da einfach sehr skeptisch. In meinem Weltbild ist das Schema der > Chef, resp. der, der das Schema zeichnet. Das Layout, resp. der, der > dieses erstellt (das wäre in meinem Fall auch ich) soll sich gefälligst > danach richten. Und die Gerberdaten sollen das zeigen, was das Layout > will. Klare Hierarchie. Eagle hat das imho sehr gut gelöst. Damit ist so flüssig zu arbeiten das man sich Änderungen mit undo/redo fast wie einen Film ansehen kann. Jeder wie er will und mag. Es ist schon sehr angenehm das Design interaktiv zu entwickeln. Wenn Bauteile im Schaltplan selektiert werden sind Sie im Layout auch "gehighlightet" und umgekehrt. Wer damit mal gearbeitet hat (Zweischirm Systeme sind ja heute eher die Regel als die Ausnahme) wird da nicht von weg wollen. Auch nicht beim testen und reparieren. Kicad wird das vermutlich nicht können und auch viele andere nicht. Gerber hab ich mir bei eagle eher selten angeschaut. Seitdem ich den zofc 3D viewer (hat mit eagle nichts zu tun) entdeckt habe ist es aber ein fester Bestandteil. Ein super tool das Netzlisten Bestückungsdruck und Platzhalter für Bauteile in 3D zeigt. Da findet man oft noch einiges was man verbessern kann. Mampf F. schrieb: > Jörg W. schrieb: > Man könnte aber tatsächlich die "Net-Tie"-Funktionalität (eigentlich ein > ekliger Hack, der bei den Entwicklern bekannt ist, aber toleriert wird) > verwenden. Die ganze Diskussion um "tauschbare footprints" halte ich für müßig. Die Info wo welcher Anschluss im Symbol denn am footprint liegt ist vom verwendeten Programm unabhängig. Irgendwo muss man es eingeben. Ob man da nun replaced oder netlisted ist gehupft wie gesprungen.
X4U schrieb: > Kicad wird das vermutlich nicht können und auch viele andere nicht. Wobei, wenn man mal gesehen hat, wie ein LaTeX-Editor in der Lage ist, zwischen LaTeX-Quelle und generiertem PDF Querbeziehungen zu bauen, sollte man wohl hier nie „nie“ sagen. ;-)
Jörg W. schrieb: > Wobei, wenn man mal gesehen hat, wie ein LaTeX-Editor in der Lage > ist, zwischen LaTeX-Quelle und generiertem PDF Querbeziehungen zu > bauen, sollte man wohl hier nie „nie“ sagen. ;-) Bei aller Liebe von nie war nie die Rede. Aber coming soon hat die Open Source Szene genau so drauf wie Microsoft. Bei eagle warte ich z.B. auch schon 20 Jahre auf ne brauchbare lib Erstellung.
Die Community um Kicad ist derart kritiklos, da wäre es ein Wunder wenn die Macher merken würden, dass da etwas fehlt.
Hans Wurst schrieb: > Die Community um Kicad ist derart kritiklos, da wäre es ein Wunder wenn > die Macher merken würden, dass da etwas fehlt. Das halte ich für Polemik und übergriffig ist es auch. Man kann weder in andere hinein schauen noch kennt man interne Diskussionen. Warum dann sinnlose um Worte streiten wenn es um technische Eigenschaften geht?
Hans Wurst schrieb: > Die Community um Kicad ist derart kritiklos, da wäre es ein Wunder wenn > die Macher merken würden, dass da etwas fehlt. Sollten sie etwa auf das unfundierte Genöle eines jeden Hanswurst hören? Wenn du es „gleich wieder deinstalliert“ hast, dann verstehe ich gar nicht, warum du hier eigentlich so genervt weiter diskutierst. Keiner schreibt doch irgendjemandem vor, ein bestimmtes Tool zu benutzen, oder klingeln die Kicad-Jünger täglich bei dir an der Tür und nerven dich, es dann doch nochmal zu probieren? X4U schrieb: > Bei aller Liebe von nie war nie die Rede. War ja auch'n Smiley dahinter. Besagter LaTeX-Editor hat mir schon ein wenig Verwunderung abgerungen, denn eine solche Funktionalität hätte ich dort einfach nicht erwartet. Schließlich weiß man ja, auf welchem Wege aus einem LaTeX-Quelldokument das PDF gebaut wird.
Jörg W. schrieb: > Keiner schreibt doch irgendjemandem vor, ein bestimmtes Tool zu > benutzen, oder klingeln die Kicad-Jünger täglich bei dir an der Tür > und nerven dich, es dann doch nochmal zu probieren? Also mir sind die Kicad Leute tausendmal lieber als z.B. die Apple Jünger. Die stehen für mich für eine Idee, das es nämlich möglich ist etwas gemeinschaftlich aufzubauen. Ein viel sympathischeres Konzept als das Hosianna auf einen stalinistischen Konzernapparat zu singen und die eigene Leistung max. darin besteht in einen Laden zu rennen.
Hans Wurst schrieb: > Die Community um Kicad ist derart kritiklos, da wäre es ein Wunder wenn > die Macher merken würden, dass da etwas fehlt. Weils halt nichts zum kritisieren gibt ;-) Mal im Ernst: die Features die KiCad heute zu bieten hat, reicht weit über den Hobby und Kleinfirmen Horizont hinaus! Ich (als Evangelist ;-) bin überzeugt, dass KiCad bereits am Image von Altium kratzt!
Jörg W. schrieb: > Keiner schreibt doch irgendjemandem vor, ein bestimmtes Tool zu > benutzen, oder klingeln die Kicad-Jünger täglich bei dir an der Tür > und nerven dich, es dann doch nochmal zu probieren? JA ich ;-)
X4U schrieb: > Jeder wie er will und mag. Es ist schon sehr angenehm das Design > interaktiv zu entwickeln. Wenn Bauteile im Schaltplan selektiert werden > sind Sie im Layout auch "gehighlightet" und umgekehrt. > > Wer damit mal gearbeitet hat (Zweischirm Systeme sind ja heute eher die > Regel als die Ausnahme) wird da nicht von weg wollen. Auch nicht beim > testen und reparieren. Kicad wird das vermutlich nicht können und auch > viele andere nicht. Wenn man auf einen Footprint klickt, springt das Schematool zum entsprechenden Schemasymbol und umgekehrt, und das selbe bei Pins/Pads. Das ist schon sehr praktisch, v.a. mit zwei Bildschirmen. Highlighting macht es so jetzt noch nicht. Das ist aber m.W. in der Queue.
il Conte schrieb: > Ich (als Evangelist ;-) bin überzeugt, dass KiCad bereits am Image von > Altium kratzt! Da dürfte noch einiges an „Luft“ sein bis dorthin. Nein, ich bin kein Evangelist für Altium, aber man darf neidlos anerkennen, dass sie nicht ganz umsonst in diesem Bereich eine Art de-facto-Standard in vielen Firmen sind.
Jörg W. schrieb: > Nein, ich bin kein Evangelist für Altium, aber man darf neidlos > anerkennen, dass sie nicht ganz umsonst in diesem Bereich eine Art > de-facto-Standard in vielen Firmen sind. Das war ORCAD auch mal :-(
Simon H. schrieb: > Wenn man auf einen Footprint klickt, springt das Schematool zum > entsprechenden Schemasymbol und umgekehrt, und das selbe bei Pins/Pads. > Das ist schon sehr praktisch, v.a. mit zwei Bildschirmen. Ja voll ultra ... Besonders, wenn KiCad dann zwischen mehreren Schaltplanseiten der Schaltplan-Hierarchie wild rum springt und dann immer der Schaltplan offen ist, den man gerade nicht haben wollte - nur weil man mal auf das falsche Bauteil geklickt hat ;-)
:
Bearbeitet durch User
Wenn ich mich mit dem Schema beschäftige, kommt es relativ selten vor, dass ich mit der Maus derart abrutsche, dass ich auf den zweiten Bildschirm gelange und dort aus Versehen einen Footprint anklicke. Und umgekehrt auch recht selten. Wenn ich aber tatsächlich auf dem Layouttool auf ein Pad clicke und dann auf den Schemaeditor schaue, möchte ich in 99% der Fälle wissen, was denn das für ein Pad ist. Ich denke mal, das ist nicht nur bei mir so. Wenn man aber tatsächlich mal diese Springerei nicht haben möchte, kann man sie natürlich auch abschalten.
:
Bearbeitet durch User
Jörg W. schrieb: > Nein, ich bin kein Evangelist für Altium, aber man darf neidlos > anerkennen, dass sie nicht ganz umsonst in diesem Bereich eine Art > de-facto-Standard in vielen Firmen sind. Das ist Microsoft auch und SAP, Lotos Notes und all das andere Zeugs das "topmost" im "worlds worst software programs" ranking ist. Willst du dein Programm damit wirklich auf eine Stufe stellen ;-) ?
X4U schrieb: > Willst du dein Programm damit wirklich auf eine Stufe stellen ;-) ? Die anderen sind das teilweise nur durch Marketing geworden, oder durch Wegfall von Konkurrenz (SAP). ;) Aber wir wollten ja eher über Kicad reden …
Jörg W. schrieb: > Aber wir wollten ja eher über Kicad reden … Ganz mein Ansinnen! Aber manchmal fühlt man sich ganz schön ausgebremst, da bräuchte es halt öfters mal die schützende Hand des MODs ;-) (Der einem bei der Missionierung die Andersgläubigen vom Leibe hält, damit man sich besser den Haiden zuwenden kann ;-)
X4U schrieb: > Jörg W. schrieb: >> Nein, ich bin kein Evangelist für Altium, aber man darf neidlos >> anerkennen, dass sie nicht ganz umsonst in diesem Bereich eine Art >> de-facto-Standard in vielen Firmen sind. > > Das ist Microsoft auch und SAP, Lotos Notes und all das andere Zeugs das > "topmost" im "worlds worst software programs" ranking ist. > > Willst du dein Programm damit wirklich auf eine Stufe stellen ;-) ? Fairerweise muß ich aber sagen, daß MS Office schon sehr klasse ist (auch wenn ich mich gerade mit Lyx vertraut mache). Auch Win10 ist gar nicht so übel. Wenn nur die verdammte Telemetrie, One-Drive-Mist usw. nicht wären... Possetitjel schrieb: > Wühlhase schrieb: > >> Was bei KiCad (und den meisten EDA-Programmen) anders ist, >> ist der vorgesehene Arbeitsfluß. Manche Programme sehen da >> einen bestimmten, strikten Arbeitsfluß vor, andere lassen >> einem mehr oder weniger viel Freiraum. > > Das Dumme ist, dass das ziemlich weitreichende Konsequenzen > für den betrieblichen Einsatz solcher Software hat. > > Im Hobbybereich mit Ein-Mann-Projekten fällt das nicht auf, > aber was ist, wenn mein Vorgänger Programm X verwendet hat, > ich nur mit Programm Y klarkomme und mein neuer Kollege, der > ein Jahr später eingestellt wird, Programm Z bevorzugt? > > Wenn die Dateiformate kompatibel wären, wäre das kein Problem. > Sind sie aber meines Wissens nicht. Ich kenne es eigentlich eher so, daß sich der Mitarbeiter mit den Werkzeugen der Firma vertraut macht und nicht jeder sein Eigenes mitbringt. Aber du hast Recht, es ist Mist wenn die Software die betrieblichen Prozesse unterstützt. Da lob ich mir Programme, die sich bequem zurechtschnitzen lassen. Ja, das macht am Anfang Arbeit, zahlt sich aber rasch aus. Leider leiden viele Firmen lieber viele Jahre unter ihrem Herumgewurschtel anstatt sich ein oder zwei Wochen Zeit zu nehmen sich die Arbeit einfacher zu machen. Possetitjel schrieb: >> Beispiel FB-Annotation: Nutzer wie W.S. machen den Eindruck, >> das KiCad und allen anderen EDA-Programmen da eine ganz >> entscheidende Funktion fehlt weil sie keine FBA haben. >> Der Punkt ist: KiCad, Altium und andere brauchen die FBA >> nicht, die haben einen anderen Weg gewählt um die gleiche >> Funktionalität herzustellen (und dabei weniger Nachteile als >> FBA mitbringen). > > Magst Du den Punkt bitte genauer erklären? > > Ich habe nur kleinere Sachen mit Target gemacht und FBA weder > verwendet noch vermisst. Wenn du in Altium Änderungen aus deinem Schaltplan in die Leiterplatte übernehmen willst, müssen sie manuell importiert werden. Das heißt Design > Import from Schematic (kann man im Menü klicken, oder zwei Hotkeys drücken), dann kommt ein Fenster mit allen Änderungen, die Altium machen kann. Netze´/Bauteile/Verbindungen/usw. ergänzen/löschen/editieren/usw. steht alles in dem Fenster drin. Wenn du willst kannst du hier einige Änderungen selektieren oder alle oder...was du eben willst. Oder gleich sofort mit Enter übernehmen. Wenn Altium keine Änderungen machen kann, sind Schaltplan und Layout synchron. Andersrum (z.B. Pin-Swapping in den Schaltplan rüberbringen) gehen auch. Der Vorteil ist, das Altium z.B. nicht dein ganzes Layout zerhaut, wenn du ein Bauteil (möglicherweise z.B. den ernsthaften IC mit den vielen Pins) änderst. Eagle entfernt gnadenlos alles was du im Schaltplan löschst wenn du nicht aufpasst, und sei es nur für ganz kurz. In Altium siehst du vorher was geändert wird, kannst es notfalls auslassen, und wenn alles ok ist einfach mit Enter skippen. Und sowas wie ein Bauteil in der Leiterkarte anklicken und auch im Schaltplan selektieren geht natürlich genauso. Nur braucht man das nicht ganz so oft, da Altium den Netznamen auf die Leiterbahn schreibt, und wenn man im Schaltplan nicht mit Netlabels spart, dann kann man gleich sehen welchem Zweck die Leiterbahn dient. Das sieht dann auch im Schaltplan besser aus. Ansonsten kann man auch schon im Schaltplan Designrules festlegen. Wenn du willst daß deine 230V-Leiterbahn einen Mindestabstand/breite/was-du-auch-immer-willst einen definierten Wert nicht über/unterschreitet (und nur die 230V-Leiterbahn, nicht etwa gleichzeitig die Versorgungsleitung des galv. getrennten µCs), dann kannst du das dort festlegen wo du es am Besten überblickst: im Schaltplan. Und da Altium schon während des Routens darüber wacht daß du zumindest die wichtigsten Designrules einhälst (und nicht am Ende vor einer Reparatur-Orgie stehst wo du dachtest du seist endlich fertig), es ist sehr angenehm und beruhigend zu wissen, das man an sowas nicht mehr im Hinterkopf behalten muß (und am Ende eh vergisst). michael_ schrieb: > Bernd W. schrieb: >> Hier im Forum wird von einigen Leuten beklagt, dass KiCad viel zu >> kompliziert sei, und für ganz einfache Hobbyanfänger Projekte total >> überkandidelt sei. > > Ist es auch. > So wie viele andere auch. > Obwohl ich EAGLE schätze, wäre ich für eine Kombination von S-Plan und > Sprint . > Natürlich mit Backannotation. > > Auf einem Stand von vor zehn Jahren. > Ohne Bauteilliste. > Ohne Gerber. > Kostenlos. > Kein 3D. > ... > > Den ganzen Schnulli braucht man doch nicht. Wenn du keine Ansprüche an deine Arbeit hast, das sei dir nicht genommen. Ich arbeite aber gerne professionell-auch in meiner Freizeit. Und ja, da sind die vielen Werkzeuge sehr hilfreich und ich bin froh, daß es heute so tolle Möglichkeiten gibt. Nur weil es ein Hobbyprojekt ist heißt es ja nicht, das es frei von Komplexität oder einfach wäre.
Guido B. schrieb: > Hast du selbst mal etwas programmiert? Jeder Programmierer ist zunächst > zufrieden, wenn er sein ursprünglich gesetztes Ziel nach langer Zeit > erreicht hat. Bei Opensource gibt es manchmal hierfür Helfer, wodurch > sich das Ganze beschleunigt. Ob das Ergebnis in deinem Sinne gut ist > oder nicht, interessiert hier niemanden. Genau! Du hast den Punkt getroffen. Der Knackpunkt ist immer wieder, daß "wenn jemand was programmiert" er die ganze Sache aus dem Blickwinkel des Programmierers sieht - und eben nicht aus dem Blickwinkel der eventuellen Anwender, die logischermaßen bislang mit anderen etablierten Programmen arbeiten. Natürlich ist dann der Programmierer stolz auf sich - kann er auch, schließlich hat er ja was geschaffen - und das sogar offengelegt und alles ohne Bezahlung. Ich kann den Stolz des Programmierers sehr wohl verstehen. Aber die zwei Schlußfolgerungen daraus, daß erstens das Programm sich mit etablierten Programmen messen kann und diese übertrifft - und zweitens daß sich die Benutzer des Programmes gefälligst an das Programm zu gewöhnen haben, damit sie es genauso obermegageil finden wie der Programmierer selbst, treffen eben nicht immer zu. Also meckern dann diese an was etabliertes gewöhnten Leute über's Programm, was aber den Programmierer und seine Umgebung nicht interessiert: "Ob das Ergebnis in deinem Sinne gut ist oder nicht, interessiert hier niemanden" Eben, eben. W.S.
Wühlhase schrieb: >> Willst du dein Programm damit wirklich auf eine Stufe stellen ;-) ? > Fairerweise muß ich aber sagen, daß MS Office schon sehr klasse ist Ich komme übrigens damit gar nicht klar. > Ansonsten kann man auch schon im Schaltplan Designrules festlegen. Wenn > du willst daß deine 230V-Leiterbahn einen > Mindestabstand/breite/was-du-auch-immer-willst einen definierten Wert > nicht über/unterschreitet (und nur die 230V-Leiterbahn, nicht etwa > gleichzeitig die Versorgungsleitung des galv. getrennten µCs), dann > kannst du das dort festlegen wo du es am Besten überblickst: im > Schaltplan. Das kenne ich von BAE auch so, und ich denke, dass das über Netzklasen in Kicad ebenfalls so geht.
Wühlhase schrieb: > Beispiel FB-Annotation: Nutzer wie W.S. machen den Eindruck, das KiCad > und allen anderen EDA-Programmen da eine ganz entscheidende Funktion > fehlt weil sie keine FBA haben. > Der Punkt ist: KiCad, Altium und andere brauchen die FBA nicht Also, Luft zum atmen, was zum essen und die biologische Fortpflanzung brauchen wir, um zu überleben. Alles andere ist eher fakultativ. Soviel zum Brauchen. Eine V/R-Annotation, wie man sie seit Jahren bei Eagle kennengelernt hat, ist ein ganz erheblicher Komfort bei der Arbeit, den man schätzen sollte - und viele Eagle-Anwender schätzen eben diesen Komfort sehr hoch. Nun ist Kicad verhältnismäßig neu und es wäre dessen Autoren durchaus möglich gewesen, solchen Komfort auch bei ihrem Programm vorzusehen. Aber dazu hätte das richtige Fundament gelegt werden müssen. Hier eben in einer Art interner Datenbank, wo der Schematics-Editor und der Layout-Editor (und auch der Bibliotheks-Editor) nur unterschiedliche Frontends derselben Datenbank sind. Aber mit einer strikten Trennung zwischen diesen, die nur durch Dateiaustausch (Netzlisten usw.) überbrückt wird, geht sowas nicht. Das liegt dann schlußendlich nicht an den Leuten, die das eine oder andere Programm bepflegen, sondern es liegt am Grundentwurf, also an den Fundamenten. Genau das ist es, worauf ich seit langem hinweise. Kicad ist so neu, daß man derartiges hätte mit einplanen sollen, doch es wurde versäumt. Ob nun aus dem Willen, alles ganz anders zu machen oder der Wahl des falschen Vorbildes, ist am Ende egal. W.S.
Wühlhase schrieb: > > Und sowas wie ein Bauteil in der Leiterkarte anklicken und auch im > Schaltplan selektieren geht natürlich genauso. Nur braucht man das nicht > ganz so oft, da Altium den Netznamen auf die Leiterbahn schreibt, und > wenn man im Schaltplan nicht mit Netlabels spart, dann kann man gleich > sehen welchem Zweck die Leiterbahn dient. Das sieht dann auch im > Schaltplan besser aus. Das ist bei Kicad genau so. Bei Eagle ja wohl auch, oder? > Ansonsten kann man auch schon im Schaltplan Designrules festlegen. Wenn > du willst daß deine 230V-Leiterbahn einen > Mindestabstand/breite/was-du-auch-immer-willst einen definierten Wert > nicht über/unterschreitet (und nur die 230V-Leiterbahn, nicht etwa > gleichzeitig die Versorgungsleitung des galv. getrennten µCs), dann > kannst du das dort festlegen wo du es am Besten überblickst: im > Schaltplan. Bei Kicad muss das im Layouttool geschehen. Aber ich meine, dass sich da was in Arbeit ist... > Und da Altium schon während des Routens darüber wacht daß du zumindest > die wichtigsten Designrules einhälst (und nicht am Ende vor einer > Reparatur-Orgie stehst wo du dachtest du seist endlich fertig), es ist > sehr angenehm und beruhigend zu wissen, das man an sowas nicht mehr im > Hinterkopf behalten muß (und am Ende eh vergisst). Genau so bei Kicad. Und das halte ich nicht für ein Feature, sondern schlicht für eine Mindestanforderung.
Dieser Faden war für mich der Anlass, mich seit Langem, mal wieder mit KiCad zu befassen. Zur Vorgeschichte: bin langjähriger Target-Benutzer, wichtig für mich war immer, das die Wege für meine Fräse (als HPGL) rauspurzeln. Da das Programm auch prima unter WINE läuft, hat es auch den Betriebssystemwechsel, bei mir, als einziges proprietäres Programm überlebt. Vor 2 Tagen habe ich also mal wieder KiCad installiert, und erstmal angefangen, die "erste Schritte Anleitung" ganz langsam durchzuarbeiten, mit Schwerpunkt auf die Bibliotheksverwaltung und dem Erstellen eigener Symbole und Footprints. Jetzt stelle ich doch so ganz nebenbei so fest, das die Plotausgabe in DXF, genau das macht, was ich für meine Fräse benötige, den DXF-Konverter hab ich schon fertig, da ich Frontplatten u.Ä. schon seit Langem mit LibreCad mache. Stelle also fest, das KiCad und ich bestimmt Freunde werden und möchte die Gelegenheit nutzen, mich schonmal bei den Machern, Übersetzern und Unterstützern, auch hier im Forum zu bedanken!
Wühlhase schrieb: >> Das Dumme ist, dass das ziemlich weitreichende Konsequenzen >> für den betrieblichen Einsatz solcher Software hat. >> >> Im Hobbybereich mit Ein-Mann-Projekten fällt das nicht auf, >> aber was ist, wenn mein Vorgänger Programm X verwendet hat, >> ich nur mit Programm Y klarkomme und mein neuer Kollege, der >> ein Jahr später eingestellt wird, Programm Z bevorzugt? >> >> Wenn die Dateiformate kompatibel wären, wäre das kein Problem. >> Sind sie aber meines Wissens nicht. > > Ich kenne es eigentlich eher so, daß sich der Mitarbeiter mit > den Werkzeugen der Firma vertraut macht und nicht jeder sein > Eigenes mitbringt. Ja: Weil der Chef vor 10 Jahren, als er noch selbst entwickelt hat, mal Target3001 gewählt hat, müssen jetzt alle anderen auch bei Target bleiben :) Nein, im Ernst, Du hast schon Recht: Üblicherweise wird das vorgegeben, welche Software zu benutzen ist. Ist aber auch nicht wirklich schön für die Entwickler. Gerade in Kleinunternehmen HÄTTE man häufig die Möglichkeit, sich auf andere Software zu einigen, wenn sich die Daten einfach migrieren ließen. Bei einer früheren Firma haben mit mir fast zeitgleich noch zwei andere Entwickler angefangen. Das vorhandene, gecrackte OrCAD einfach weiterzubenutzen kam nicht in Frage. Meine neuen Kollegen wollten Eagle benutzen -- also wurde ich überstimmt. > Da lob ich mir Programme, die sich bequem zurechtschnitzen > lassen. Ja, das macht am Anfang Arbeit, zahlt sich aber > rasch aus. Ja. > Leider leiden viele Firmen lieber viele Jahre unter ihrem > Herumgewurschtel anstatt sich ein oder zwei Wochen Zeit zu > nehmen sich die Arbeit einfacher zu machen. Naja... dieses Urteil ist etwas ungerecht. Es ist i.d.R. nicht akzeptabel, das Geschäft einfach für einen Monat anzuhalten und alles umzustellen; das muss schrittweise gehen. Gerade das macht einem die Software aber häufig nicht gerade leicht. > Possetitjel schrieb: >>> Beispiel FB-Annotation: [...] >> >> Magst Du den Punkt bitte genauer erklären? >> >> Ich habe nur kleinere Sachen mit Target gemacht und FBA >> weder verwendet noch vermisst. > > Wenn du in Altium Änderungen aus deinem Schaltplan in die > Leiterplatte übernehmen willst, müssen sie manuell importiert > werden. [...] > Der Vorteil ist, das Altium z.B. nicht dein ganzes Layout > zerhaut, wenn du ein Bauteil (möglicherweise z.B. den > ernsthaften IC mit den vielen Pins) änderst. Eagle entfernt > gnadenlos alles was du im Schaltplan löschst wenn du nicht > aufpasst, und sei es nur für ganz kurz. [...] Danke für die ausführliche Erklärung. > Nur weil es ein Hobbyprojekt ist heißt es ja nicht, das es > frei von Komplexität oder einfach wäre. Ja. Das gilt aber auch umgekehrt: Nur, weil es ein professionelles Projekt ist, heißt das nicht, dass man zwingend 16 Lagen und impedanzkontrollierte Leitungen braucht. Aber eine Software, bei der man nicht alle halbe Stunde einen Wutanfall bekommt, DIE braucht man auf jeden Fall.
Simon H. schrieb: > Bei Kicad muss das im Layouttool geschehen. Ah ja, stimmt. Im Schaltplan kann man nur den Netznamen vergeben; Bildung der Netzklassen erfolgt dann im Layouttool.
X4U schrieb: > Die ganze Diskussion um "tauschbare footprints" halte ich > für müßig. Hmm. Ich eigentlich nicht. > Die Info wo welcher Anschluss im Symbol denn am footprint > liegt ist vom verwendeten Programm unabhängig. Die INFORMATION ist unabhängig -- ihre konkrete KODIERUNG ist leider programmspezifisch. Oder kann gEDA mit KiCAD- Symbolen arbeiten? Eagle mit Altium-Footprints? > Irgendwo muss man es eingeben. Ja. Aber warum muss ich die für jedes Programm neu eingeben, wenn es doch genau dieselbe Information wie vorher ist? Davon abgesehen ging es (mir) ursprünglich um was anderes: Es ist Scheisse, wenn das Programm eine bestimmte Arbeits- reihenfolge erzwingt, die sachlich gar nicht notwendig wäre. Wenn ich im Schaltplan einen generischen npn-Transistor platziere und einen Footprint zuweise, aber keine Typangabe, dann hat die Software das hinzunehmen und mit den gegebenen Daten weiterzuarbeiten. Sie soll mich beim Erstellen der Stückliste warnen, dass die Angaben nicht vollständig sind -- aber es gibt keinen Grund, mit den unvollständigen Angaben kein Layout entwerfen zu können.
Possetitjel schrieb: > Wenn ich im Schaltplan einen generischen npn-Transistor > platziere und einen Footprint zuweise, aber keine Typangabe, > dann hat die Software das hinzunehmen und mit den gegebenen > Daten weiterzuarbeiten. > Sie soll mich beim Erstellen der Stückliste warnen, dass die > Angaben nicht vollständig sind -- aber es gibt keinen Grund, > mit den unvollständigen Angaben kein Layout entwerfen zu > können. Wenn im Schaltplan einfach nur das Symbol für den npn-Transistor verwendet wird, dann ist doch eigentlich ersteinmal alle gesagt - Du willst einen npn-Transistor verwendet - fertig! Wenn es dann im nächsten Schritt ans Layouten geht, legtst du vielleicht fest, was es für ein Transitor werden soll, SMD, THT oder vielleicht auch nur drei Pins, weil der Transistor über Kabel angeschlossen wird.... Wenn dir aber schon klar ist beim Zeichnen des Schaltplanes, das es ein "dickes Ding" von Transistor werden muss, dann kannst du den passenden Footprint (z.B. TO-3) gleich den Transistor-Symbol zuweisen... Beide Wege sind mit KiCad möglich, ich bevorzuge den ersten - letztere Methode wenn es eine "Sonderlocke" werden soll...
W.S. schrieb: > Eine V/R-Annotation, wie man sie seit Jahren bei Eagle kennengelernt > hat, ist ein ganz erheblicher Komfort bei der Arbeit, den man schätzen > sollte - und viele Eagle-Anwender schätzen eben diesen Komfort sehr > hoch. > Naja, es gibt global vermutlich nicht allzuviele Eagleanwender und nur wenige davon schätzen diese Programmeigenschaft. > Nun ist Kicad verhältnismäßig neu und es wäre dessen Autoren durchaus > möglich gewesen, solchen Komfort auch bei ihrem Programm vorzusehen. > Aber dazu hätte das richtige Fundament gelegt werden müssen. Nicht trivial! Schaltplan und Layout sind zunächst (ähm fundamental) getrennte Arbeitsbereiche. Man kann diese miteinander koppeln, wie es Eagle zeigt. Das ist aber nicht trivial, letztendlich läuft das auf eine Datenbank heraus, auf die beide Programme zugreifen. Und jetzt wird es programmtechnisch richtig interessant. Eine neue Datenbank zu programmieren macht sicherlich keinen Sinn. Auf eine existierende zuzugreifen geht aber auch nicht, da nicht jeder User dieselbe verwendet (wenn überhaupt). Sowas muss also in der Programmentwicklung weit zurückstehen, es sei denn es wird konkret gesponsert und man findet hierzu Entwickler (gibt es Programmierer, die sich sowohl mit Platinenlayout, als auch mit Datenbanken auskennen?).
W.S. schrieb: > Kicad ist so neu, daß man derartiges hätte mit einplanen sollen, doch es > wurde versäumt. Ob nun aus dem Willen, alles ganz anders zu machen oder > der Wahl des falschen Vorbildes, ist am Ende egal. Altium: 1986 Eagle: 1988 KiCad: 1992 In der Tat: KiCad ist wirklich neu.
Wühlhase schrieb: > michael_ schrieb: >> Bernd W. schrieb: >>> Hier im Forum wird von einigen Leuten beklagt, dass KiCad viel zu >>> kompliziert sei, und für ganz einfache Hobbyanfänger Projekte total >>> überkandidelt sei. >> >> Ist es auch. >> So wie viele andere auch. >> Obwohl ich EAGLE schätze, wäre ich für eine Kombination von S-Plan und >> Sprint . >> Natürlich mit Backannotation. >> >> Auf einem Stand von vor zehn Jahren. >> Ohne Bauteilliste. >> Ohne Gerber. >> Kostenlos. >> Kein 3D. >> ... >> >> Den ganzen Schnulli braucht man doch nicht. > Wenn du keine Ansprüche an deine Arbeit hast, das sei dir nicht > genommen. Ich arbeite aber gerne professionell-auch in meiner Freizeit. Aber lesen kannst du doch! Was Bernd Wiebus mit "ganz einfache Hobbyanfänger Projekte" gemeint hat. Man sollte sich auch mal in die Lage eines blutigen Anfängers hineinversetzen können. Ich selbst habe mich immer in die geforderten Ansprüche einarbeiten können. Und professionell in der Freizeit zu basteln ist schon ein Witz für sich. Nochmal, den meisten Schnulli, mit dem hier viele Profi-Anwender angeben, braucht der Anfänger nicht. Und schreckt ihn ab. Mampf F. schrieb: > Mit Eagle 3.55 hab ich auch viel gearbeitet - es schadet aber nicht sich > auch mal neue Sachen anzuschauen. Eagle 4 zB, das konnte immerhin schon > Bauteile drehen ;-) Hä, dann hattest du da keine Ahnung. Warum sollte 3.55 das nicht können?
Skyper schrieb: > Beide Wege sind mit KiCad möglich, Mag sein. -- Der Ausgangspunkt war, dass mit Eagle NICHT beide Wege möglich sind. So, wie ich das verstanden habe, geht Eagle IMMER von einem bestimmten Transistortyp aus und ordet diesem Typ ein Symbol und einen Footprint zu.
Guido B. schrieb: > Das ist aber nicht trivial, letztendlich läuft das auf > eine Datenbank heraus, auf die beide Programme zugreifen. Ja. > Und jetzt wird es programmtechnisch richtig interessant. Ja :) > Eine neue Datenbank zu programmieren macht sicherlich keinen > Sinn. Auf eine existierende zuzugreifen geht aber auch nicht, > da nicht jeder User dieselbe verwendet (wenn überhaupt). Naja, die Datenbank wird eine separate Komponente mit definierten Schnittstellen sein müssen. Anders kann es nicht gehen. > Sowas muss also in der Programmentwicklung weit zurückstehen, Im Gegenteil; das müsste man mit strategischer Weitsicht vorher bedenken. > es sei denn es wird konkret gesponsert und man findet hierzu > Entwickler (gibt es Programmierer, die sich sowohl mit > Platinenlayout, als auch mit Datenbanken auskennen?). Offensichtlich gibt es die -- nebenan laufen zwei Fäden, in denen es um Bauteildatenbanken geht. Bauelemente, Schaltplansymbole und Schaltpläne verhalten sich genauso zueinander wie Zeichen, Glyphen und Texte. Wieso funktioniert (inzwischen) bei Texten das, was bei Schaltplänen seit Jahrzehnten ein Ding der Unmöglichkeit ist? Wieso sind ausgerechnet FOSS-Programmierer dermaßen desinteressiert daran, über ihr eigenes Projekt hinauszudenken?
Possetitjel schrieb: > So, wie ich das verstanden habe, geht Eagle IMMER von einem > bestimmten Transistortyp aus und ordet diesem Typ ein Symbol > und einen Footprint zu. Du hast ja eine glorreiche Erkenntniss! Warum sollte das anders sein? Das macht doch jedes Programm. Selbst wenn du den Schaltplan mit Bleistift malst, mußt du irgendwann ein konkretes Bauteil zuordnen. Du redest wie ein Blinder von der Farbe. Lass es lieber.
michael_ schrieb: > Was Bernd Wiebus mit "ganz einfache Hobbyanfänger Projekte" > gemeint hat. Man sollte sich auch mal in die Lage eines > blutigen Anfängers hineinversetzen können. [...] > Nochmal, den meisten Schnulli, mit dem hier viele > Profi-Anwender angeben, braucht der Anfänger nicht. > Und schreckt ihn ab. Du schüttest das Kind mit dem Bade aus. Es geht überhaupt gar nicht um die nackte Anzahl an Features. Es geht um 1. Austauschbarkeit der Daten (ALLER Arten von Daten), 2. gute Bedienerführung und 3. flexible Unterstützung verschiedener Arbeitsabläufe.
michael_ schrieb: > Possetitjel schrieb: >> So, wie ich das verstanden habe, geht Eagle IMMER von einem >> bestimmten Transistortyp aus und ordet diesem Typ ein Symbol >> und einen Footprint zu. > > Du hast ja eine glorreiche Erkenntniss! Das ist keine Erkenntnis, das ist eine Vermutung. Ich verwende Eagle nämlich nicht. > Warum sollte das anders sein? <Gebetsmühle> Weil es für das Erstellen des Schaltplanes ausreichend ist, ein SCHALTPLANSYMBOL -- UND NUR DAS SYMBOL -- auszuwählen. Weder Typ noch Footprint sind dafür erforderlich. </Gebetsmühle> > Das macht doch jedes Programm. Nein, das ist falsch. Mit gEDA kann ich einen generischen Transistor im Schaltplan platzieren; dem ist weder (zwingend) eine Typenbezeichnung noch ein Footprint zugeordnet. > Selbst wenn du den Schaltplan mit Bleistift malst, mußt du > irgendwann ein konkretes Bauteil zuordnen. Es geht nicht darum, dass man das IRGENDWANN machen muss, sondern darum, dass diese Zuordnung bei Eagle FEST IN DER BAUTEILBIBLIOTHEK VERANKERT ist. Und genau das ist vom Datenfluss her falsch. > Du redest wie ein Blinder von der Farbe. > Lass es lieber. Vielleicht überdenkst Du das doch nochmal und findest wieder auf die Sachebene.
michael_ schrieb: > Du schnallst es nicht! Mag sein. Dann sind wir schon zwei. > Es ging um "ganz einfache Hobbyanfänger Projekte". Nicht nur. Beschissen bedienbare Software ist für ALLE beschissen bedienbar. Der Profi schluckt seinen Ärger nur herunter (meistens) und kassiert monatlich Schweigegeld. Einem Anfänger oder Umsteiger dagegen fallen die Mängel einfach viel stärker auf. Der Profi ist nicht WEGEN der beschissenen Eigenarten der Software produktiv, sondern TROTZDEM.
Possetitjel schrieb: > Das ist keine Erkenntnis, das ist eine Vermutung. Ich > verwende Eagle nämlich nicht. Eigentlich eine Frechheit, wenn du dazu mitdiskutierst! Dann lerne es! Possetitjel schrieb: > Weil es für das Erstellen des Schaltplanes ausreichend ist, > ein SCHALTPLANSYMBOL -- UND NUR DAS SYMBOL -- auszuwählen. > > Weder Typ noch Footprint sind dafür erforderlich. Richtig. Possetitjel schrieb: > Mit gEDA kann ich einen generischen Transistor im Schaltplan > platzieren; dem ist weder (zwingend) eine Typenbezeichnung > noch ein Footprint zugeordnet. Richtig. Possetitjel schrieb: > Es geht nicht darum, dass man das IRGENDWANN machen muss, > sondern darum, dass diese Zuordnung bei Eagle FEST IN DER > BAUTEILBIBLIOTHEK VERANKERT ist. Und genau das ist vom > Datenfluss her falsch. Wo und wann das passiert, hast du doch nicht zu bestimmen! Beschäftige dich bitte intensiv mit EAGLE und komme dann wieder, eher nicht.
michael_ schrieb: > Possetitjel schrieb: >> Das ist keine Erkenntnis, das ist eine Vermutung. >> Ich verwende Eagle nämlich nicht. > > Eigentlich eine Frechheit, wenn du dazu > mitdiskutierst! Vielleicht solltest Du lieber zum Kickboxen gehen, wenn Du Deine Aggressionen abreagieren musst. Ich diskutiere mit, weil mir Diskussionen wie diese Mittel zum Erkenntnisgewinn sind. Wie ich schon dreimal geschrieben habe: In unserer alten Firma tauchten auf Schaltplänen plötzlich völlig abstruse Typenbezeichnungen auf. Als ich den Kollegen fragte, der diese Schaltpläne mit Eagle erstellt hat, kam als Antwort: "Ach soooo... nee... das hat nix zu sagen. Ich habe mir nur irgendwelche Transistoren gesucht, die den richtigen Footprint hatten." Also kann man ganz offensichtlich mit Eagle nicht so einfach NUR den Footprint ändern (und alles andere lassen, wie es ist), oder -- alternativ dazu -- nur ein Symbol MIT Footprint, aber OHNE Typenbezeichnung platzieren. > Possetitjel schrieb: >> Es geht nicht darum, dass man das IRGENDWANN machen muss, >> sondern darum, dass diese Zuordnung bei Eagle FEST IN DER >> BAUTEILBIBLIOTHEK VERANKERT ist. Und genau das ist vom >> Datenfluss her falsch. > > Wo und wann das passiert, hast du doch nicht zu bestimmen! Aber selbstverständlich habe ich das zu bestimmen. Wenn Eagle eine Zuordnung fest in der Bauteilbibliothek verankert, die in der betrieblichen Praxis variabel sein muss, dann ist Eagle für die betriebliche Praxis nicht geeignet. Ende. Wenn jemand von Datenmodellen NOCH weniger Ahnung hat als ich und daher nicht erkennt, dass diese Zuordnung an dieser Stelle datentechnisch falsch ist, dann ist das nicht mein Problem. > Beschäftige dich bitte intensiv mit EAGLE Warum sollte ich? Ich habe Eagle vor vielen Jahren mal angetestet und als für mich untauglich verworfen. Warum sollte ich mir diesen Murx erneut antun? Gibt keinen vernünftigen Grund. > und komme dann wieder, eher nicht.
W.S. schrieb: > Aber dazu hätte das richtige Fundament gelegt werden > müssen. > > Hier eben in einer Art interner Datenbank, wo der > Schematics-Editor und der Layout-Editor (und auch der > Bibliotheks-Editor) nur unterschiedliche Frontends > derselben Datenbank sind. > > Aber mit einer strikten Trennung zwischen diesen, die > nur durch Dateiaustausch (Netzlisten usw.) überbrückt > wird, geht sowas nicht. Das stimmt erstmal. > Das liegt dann schlußendlich nicht an den Leuten, die > das eine oder andere Programm bepflegen, sondern es liegt > am Grundentwurf, also an den Fundamenten. Auch richtig. > Genau das ist es, worauf ich seit langem hinweise. > > Kicad ist so neu, daß man derartiges hätte mit einplanen > sollen, doch es wurde versäumt. Nein. Einspruch. Modularisierung und Datenfluss von KiCad sind Ergebnis von Entwurfsentscheidungen. Für Deine Behauptung, es "wurde versäumt", fehlt jeder Beleg. Ich finde es sehr nachvollziehbar, das KiCad (ebenso wie gEDA z.B.) auf eine zentrale Datenbank verzichtet und auf separate Programme setzt, die primär über Dateien die Daten austauschen. Eine zentrale Datenbank hat zwar große Vorteile, aber auch den großen Nachteil, dass mit ihrem Funktionieren alles steht und fällt. > Ob nun aus dem Willen, alles ganz anders zu machen Naja. gEDA macht es auch so. Ich weiss also nicht, wer wen kopiert hat. > oder der Wahl des falschen Vorbildes, [...] Sicher nicht.
Hallo michael_ michael_ schrieb: > Ist es auch. > So wie viele andere auch. > Obwohl ich EAGLE schätze, wäre ich für eine Kombination von S-Plan und > Sprint . > Natürlich mit Backannotation. > > Auf einem Stand von vor zehn Jahren. > Ohne Bauteilliste. > Ohne Gerber. > Kostenlos. > Kein 3D. Aehm....wenn Du Backannotation möchtest, wirst Du vermutlich auch zumindest intern im Programm eine Bauteilliste benötigen. Dann kannst Du die auch zugänglich machen, für irgendwelche Sonderfälle. Auf Gerber würde ich aber auch als Anfänger nicht verzichten wollen, weil das wird irgendwann wichtig, wenn Du Platinen anfertigen lassen möchtest. Es gibt auch Anfänger, die nicht selber ätzen. Gerber ist ein wichtiges Austauschformat. Aber umgekehrt könnte man dann als Board Format direkt Gerber verwenden....Gerber ist übrigens das einfachste und primitivste Grafik Format, dass ich kenne. Nur Bitmaps sind noch primitiver aber dann leider nicht mehr einfach zu Handhaben. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
michael_ schrieb: > Eigentlich eine Frechheit, wenn du dazu mitdiskutierst! Michael, bitte etwas mehr Besonnenheit. Bei dem genannten Aspekt von Eagle (starre Zuordnung eines Footprints zum Symbol bereits im Schaltplan) genügt es wohl in der Tat, wenn man das x-Mal von Leuten wie W.S. als Feature angepriesen bekommt, als dass man diese Tatsache als gegeben hinnehmen darf, auch ohne das Programm zu benutzen. Über andere Aspekte hat Possetitjel nicht geredet. Das hier ist auch kein Eagle-Thread, insofern braucht man hier auch nicht über alle Details, Vorzüge, Lizenzärger etc. von Eagle zu diskutieren. Possetitjel schrieb: >> Eine neue Datenbank zu programmieren macht sicherlich keinen Sinn. Auf >> eine existierende zuzugreifen geht aber auch nicht, da nicht jeder User >> dieselbe verwendet (wenn überhaupt). > > Naja, die Datenbank wird eine separate Komponente mit definierten > Schnittstellen sein müssen. sqlite ist schon erfunden. Wenn man das möchte, ließe sich das vermutlich dort einbauen. Man könnte dann für den Anfang mit einem generischen sqlite-Editor arbeiten oder eben ein Tool bauen, das konkret für das EDA-Werkzeug zugeschnitten ist. Scheint aber als Designentscheidung keiner so gewollt zu haben. Da blieben nun zwei Wege: 1) mit dem derzeitigen Design leben, 2) es selbst implementieren und dem Kicad-Projekt anbieten. ;-)
Jörg W. schrieb: > Bei dem genannten Aspekt von Eagle (starre Zuordnung eines Footprints > zum Symbol bereits im Schaltplan) genügt es wohl in der Tat, wenn man > das x-Mal von Leuten wie W.S. als Feature angepriesen bekommt, als > dass man diese Tatsache als gegeben hinnehmen darf, auch ohne das > Programm zu benutzen. Natürlich lässt sich das Footprint nachträglich austauschen. Geht ganz einfach. Aber es muß vorbereitet sein. Man muß aber das Programm kennen. Sinnlos aber für Leute, die es nicht kennen und auch nicht kennenlernen wollen. Ich streite doch auch nicht auf einem Gebiet, wo ich keine Ahnung habe. Bernd W. schrieb: > Auf Gerber würde ich aber auch als Anfänger nicht verzichten wollen, > weil das wird irgendwann wichtig, wenn Du Platinen anfertigen lassen > möchtest. Es gibt auch Anfänger, die nicht selber ätzen. Gerber ist ein > wichtiges Austauschformat. Gerber braucht es nicht unbedingt. Schau mal Print-Layout, welche Hersteller direkt seine Dateien annehmen. Mindestens zehn.
michael_ schrieb: > Schau mal Print-Layout, welche Hersteller direkt seine Dateien annehmen. > Mindestens zehn. Von wievielen? Ausserdem wage ich mal zu vermuten, dass die das nur anbieten können, weil sie selber Sprint haben, mit welchem sie dann den Gerber-Export machen. Irgendjemand muss ja die Maskendaten erstellen. Entweder der Kunde oder der Lieferant. Wenn also ein Tool keinen Gerber-Export anbietet, wird auch kein Leiterplattenhersteller die Daten dieses Tools annehmen.
Beitrag #5209464 wurde vom Autor gelöscht.
Beitrag #5209471 wurde von einem Moderator gelöscht.
michael_ schrieb: > Gerber braucht es nicht unbedingt. O DOCH !! da bin ich derselben Meinung wie Bernd. Der riesen Vorteil ist bei einem Gerberviewer dass man die Lagen einzeln anschauen und inspizieren kann. Gegeben falls kann man es im Layout noch korrigieren. Bei uns gilt: Kein 'Tapeout' ohne Gerberviewer! Man kennt doch den Spruch: 'Vor lauter Wald sieht man die Bäume nicht' Beim Gerberviewer ist es so, dass der Wald ausgeblendet wird.
Hallo Simon. Simon H. schrieb: >> Schau mal Print-Layout, welche Hersteller direkt seine Dateien annehmen. >> Mindestens zehn. > > Von wievielen? Ausserdem wage ich mal zu vermuten, dass die das nur > anbieten können, weil sie selber Sprint haben, mit welchem sie dann den > Gerber-Export machen. Irgendjemand muss ja die Maskendaten erstellen. > Entweder der Kunde oder der Lieferant. Richtig. Da ich selber mal in Leiterplattenfabriken gearbeitet habe, kann ich das so bestätigen. Es gibt zwar auch zu Gerber Alternativen, aber die sind proprietär bzw. als exotisch zu bezeichnen. > Wenn also ein Tool keinen > Gerber-Export anbietet, wird auch kein Leiterplattenhersteller die Daten > dieses Tools annehmen. Er wird dann vor den Daten des Programmes stehen, und nicht wissen, wie er weiterkommt, weil irgendwie muss er ja auf ein Maskendatenformat kommen. Es gibt zwar Tools, die auch aus Bildformaten oder PDF Gerber machen können, aber alles mit Bauchschmerzen, weil nirgendwo explizite Angaben über Masse, Koordinatenursprung, positiv oder negativ oder vergleichbar stehen, und alles sehr aufwändig und umständlich. Es besteht darum eine große Wahrscheinlichkeit einen Fehler zu machen. Darum würde der Hersteller die von ihm selber produzierten Gerberdaten an den Einsender zur Gegenkontrolle zurückschicken, und ein Einsender, der sich überfordert fühlt, Gerber zu erzeugen, würde mit dieser Anforderung in Verzweiflung versinken. Gerber ist ein Muss. Es ginge im Zweifel sogar nur mit Gerber, aber keinesfalls ohne. ;O) Ohne Gerber ginge nur für Leute, die auch selber ätzen, und für die dann ein ganz normaler Ausdruck langt. Und wenn die Probleme mit der Größe des Ausdrucks oder Verzerrungen haben, ist halt der Drucker der Schuldige. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Wühlhase schrieb: Danke erstmal für die ausführliche Erklärung. > Der Vorteil ist, das Altium z.B. nicht dein ganzes Layout zerhaut, wenn > du ein Bauteil (möglicherweise z.B. den ernsthaften IC mit den vielen > Pins) änderst. Eagle entfernt gnadenlos alles was du im Schaltplan > löschst wenn du nicht aufpasst, und sei es nur für ganz kurz. > In Altium siehst du vorher was geändert wird, kannst es notfalls > auslassen, und wenn alles ok ist einfach mit Enter skippen. Das ergibt sich in Altium über den Workflow. In Eagle setzt du beide Teile parallel und änderst dann. Das ergibt sich eben aus der F/B Annotation. Durch redo undo (das schneller reagiert als du tippen kannst) kannst du die Änderungen sogar als eine Art Film ablaufen lassen. > > Und sowas wie ein Bauteil in der Leiterkarte anklicken und auch im > Schaltplan selektieren geht natürlich genauso. Gute Info, danke > Nur braucht man das nicht > ganz so oft, da Altium den Netznamen auf die Leiterbahn schreibt, und > wenn man im Schaltplan nicht mit Netlabels spart, dann kann man gleich > sehen welchem Zweck die Leiterbahn dient. Das sieht dann auch im > Schaltplan besser aus. Macht eagle tataaa ob 7x ebenso, Labels im Schaltplan gibt es natürlich schon ewig. > > Ansonsten kann man auch schon im Schaltplan Designrules festlegen. Wenn > du willst daß deine 230V-Leiterbahn einen Wird in eagle über Netzklassen festgelegt. Die kannst du importieren, exportieren und im Schaltplan oder Layout editieren. durch die F/B Annotation ist auch da alles sofort synchron.
Brille schrieb: > X4U schrieb: >> Open Source hat den Nachteil das die Menschen die sich dafür einsetzen >> keine Entlohnung erhalten. Gerade das halte ich nicht zuletzt aufgrund meiner Erfahrung sowohl in der kommerziellen, als auch in der OSS-Entwicklung, für einen großen Vorteil. >> Hab selber einiges in dem Bereich gemacht und >> in der Regel hast du irgendwann die Nase voll von der Anspruchshaltung >> der wenigen die nichts Beitragen aber immer mehr haben wollen. [...] > > Ohne Anspruchshaltung geht es nicht. Das Problem sind meistens weniger die Ansprüche selbst, sondern die Art und Weise, wie sie formuliert werden. Es ist der Ton, der die Musik macht. > Das Problem mit der Entlohnung sehe ich auch. Das sehe ich nicht, wo soll das sein? > Das ist ein inhärentes > Problem bei OS. Das könnte man durchbrechen, indem man beispielsweise > eine Art Mitbestimmung bei der Entwicklung (Wünsche zur GUI-Gestaltung, > Bedienbarkeit, Funktionsumfang) gegen einen freiwilligen Kleinbetrag > z.B. 5 oder 10 Euro pro Monat ein Jahr lang als Spende an den/die > Entwickler bezahlt. Das wäre dann ein Motivationsschub an die > Entwicklung auch am Ball zu bleiben. Für Kleinstbeträge startet kein Entwickler seinen Editor, schon gar nicht, wenn es um Nischensoftware geht, bei der sich die Kleinbeträge nicht durch Akkumulation zu einem motivierenden Betrag summieren. Diese Denkweise geht davon aus, daß Menschen nur durch ökonomischen Nutzen motiviert werden, das ist ein kommerzielles Denkmodell, welches dem OpenSource-Gedanken inhärent und diametral entgegensteht (und, ganz am Rande bemerkt auch ein ziemlich trauriges Welt- und Menschenbild offenbart, IMHO). Es ist viel einfacher und bedarf gar keiner finanziellen oder sonstigen Transaktionen, um Einfluß auf die Entwicklung von OpenSource zu nehmen. Nämlich, indem man sich an dem Projekt beteiligt -- und das muß nicht nur Coding, sondern kann auch die Erstellung von Dokumentation, Übersetzungen, oder einfach nur die vernünftige, freundliche und begründete Formulierung der eigenen Wünsche und Ansprüche sein. > Es wird endlich Zeit mal diesen Teufelskreis "es ist immer alles > Umsonst, deswegen lieber Anwender halt's Maul und stell keine Ansprüche > an deine OS" zu durchbrechen. Es gibt keinen solchen Kreis, und schon gar keinen, der sich durch die Spende von ein paar Brosamen an die Entwickler durchbrechen ließe. Wer sich über solche Dinge beschwert, tut das in der Regel nur deswegen, weil er als OSS-Autor mit zu vielen unverschämten Anspruchstellern konfrontiert war -- oder als unverschämter Anspruchsteller die passende Antwort bekommen hat. Selbstverständlich sind meine Erfahrungen nicht repräsentativ, aber in den deutlich über zwanzig Jahren, in denen ich als Entwickler und Anwender von OpenSource-Software unterwegs bin, habe ich es noch nicht ein einziges Mal erlebt, daß jemand, der freundlich und vernünftig gefragt oder gar einen sinnvollen Verbesserungsvorschlag gemacht hat, eine Antwort wie die von Dir behauptete bekommen hätte. Noch nie. >> Wenn dann nicht (teil)kommerzialisiert wird (wie bei Linux oder OO) oder >> die Autoren in öffentlichen Instituten arbeiten ist es irgendwann Essig >> mit der Weiterentwicklung. Ja, und wenn der ökonomische Erfolg ausbleibt, ist der kommerzielle Hersteller pleite oder muß so viele Entwickler entlassen, daß die SW eingestellt werden muß, oder sie wird verkauft und reüssiert mit neuen "speziellen" Lizenzbedingungen... kommt das jemandem bekannt vor? ;-) > Deswegen macht es auch keinen wirklichen Sinn, wenn sich ein Einzelner > daran versucht sich sein "besseres KiCAD" (als unbezahltes Hobbyprojekt) > von Grund auf neu zu schreiben, anstatt lieber gleich bei KiCAD seine > Programmierfähigkeiten mit einzubringen, um dort die SW zu verbessern. > Die OS Szene hat schon genug halbgare Tools, die dann jahrelang brach > liegen. Entschuldige, aber wer so etwas schreibt, hat offensichtlich das ganze Entwicklungsmodell von OpenSource nicht verstanden. Und solange es ein funktionierendes Werkzeug für die Aufgabe gibt, spielen die halbgaren, zurecht brach liegenden Versuche keine Rolle.
Jörg W. schrieb: > Bei dem genannten Aspekt von Eagle (starre Zuordnung eines Footprints > zum Symbol bereits im Schaltplan) genügt es wohl in der Tat, wenn man > das x-Mal von Leuten wie W.S. als Feature angepriesen bekommt, als > dass man diese Tatsache als gegeben hinnehmen darf, auch ohne das > Programm zu benutzen. Es gibt bei eagle keine starre Zuordnung. So wenig wie Sie in andern Programmen existiert weil du das footprint nun mal manchmal tauchen muss. Es ist nur anders gelöst da eagle ein Bauteil ab Schaltplan komplett verwaltet kann. Das ist auch nichts besonderes und die meisten anderen Programme werden es ebenso können. Es bildet schlicht die Realität ab. Bei eagle kannst du das Teil replacen oder als sog "Technologie" (was schlicht die Bauform meint) in die lib packen. Dann wird später beliebig zwischen den Bauformen - footprint in Kicad notation- im Design hin und hergeschaltet ohne sich um irgendwas kümmern zu müssen oder auch nur ein Netz zu verlieren oder ändern zu müssen. Das ergibt sich alles aus dem Workflow und der F/B Annotation. Du kannst auch Symbole ohne Case (footprint) bauen und umgekehrt. Du kannst dir auch sämtliche Symbole in eine lib exportieren, da alle footprints die du brauchst zuordnen und diese sogar über den lib editor per drag and drop aus anderen libs reinziehen. Oder du macht dir für jedes Symbol eine lib und macht die footprints dann. Der workflow von Kicad macht in eagle einfach keinen Sinn weil du dann die F/B verlierst.
W.S. schrieb: > Genau das ist es, worauf ich seit langem hinweise. ...und alle Anderen liegen völlig falsch. > > Kicad ist so neu, daß man derartiges hätte mit einplanen sollen, doch es > wurde versäumt. Ob nun aus dem Willen, alles ganz anders zu machen oder > der Wahl des falschen Vorbildes, ist am Ende egal. > > W.S. Wieder Unfug. Wo ist das prinzipielle Problem die Datenquelle "file mit ASCII Inhalt" gegen "Tabelle aus der Datenbank mit ASCII Inhalt" auszutauschen? Laß Dir bitte empfehlen das Du Deine Aufborschtelei über KiCad besser einstellen solltest, sie führt nicht dazu das sich potentielle oder gestandene KiCad User angeekelt davon abwenden, sondern das Du Dich unglaubwürdig und unmöglich machst. Dieser Seifensieder sollte Dir langsam mal aufgehen. Die sei Deine Meinung zu KiCad und Eagle von ganzem Herzen gegönnt, aber sie bleibt bitteschön Deine Meinung. Vergleiche doch einfach mal die Mannjahre die in Eagle stecken und die finanzielle Power die da heute dahinter steht mit den Leistungen und kosten die die beiden Programme für einen User bringen. Du kannst Dich auf den Kopf stellen und mit dem Arsch fliegen fangen, aber KiCad ist effizienter gemessen an den Kosten (wir reden hier nicht von "50x80x2"). Das KiCad zum jetzigen Zeitpunkt Funktionen fehlen (aus Deiner Sicht) oder das die dahinter stehende Philosophie anders ist als Du es Dir wünschst, mag sein, aber Du hast diese Sachen auch nicht bezahlt. Jetzt tue uns bitte allen einen Gefallen: Halte Dich zurück mit Deiner Meinung über KiCad, denn die gehört mittlerweile zum Allgemeinwissen eines Elektronikers in Deutschland. Gruß, Holm
Sheeva P. schrieb: >> Es wird endlich Zeit mal diesen Teufelskreis "es ist >> immer alles Umsonst, deswegen lieber Anwender halt's Maul >> und stell keine Ansprüche an deine OS" zu durchbrechen. > > Es gibt keinen solchen Kreis, [...] Da bin ich nicht ganz so sicher. Programmierer neigen meiner Beobachtung nach dazu, programmiertechnischen Fragen eine Bedeutung zuzumessen, die ihnen aus Anwendersicht nicht zukommt (--> "Betriebsblindheit"). Andererseits ist es ja gerade die Lust am Programmieren, die sie dazu bringt, ihre Kraft überhaupt für das Projekt einzusetzen! Sie wollen etwas schaffen, was ihren eigenen (vorwiegend technisch orientierten) Maßstäben nach begeisterungswürdig ist. Die nicht-technischen Maßstäbe und Wünsche der Nur-Anwender sind orthogonal dazu; die schaden nicht, sind aber auch nicht missionskritisch. Der FOSS-Programmierer kommt auch gut ohne externe Anwender aus.
Ist eine bald weiter stabile Version von Kicad geplant? Ein paar Tester für die Importfunionen werden zur Zeit sicherlich gebraucht.
Jörg W. schrieb: > Possetitjel schrieb: >>> Eine neue Datenbank zu programmieren macht sicherlich >>> keinen Sinn. Auf eine existierende zuzugreifen geht >>> aber auch nicht, da nicht jeder User dieselbe verwendet >>> (wenn überhaupt). >> >> Naja, die Datenbank wird eine separate Komponente mit >> definierten Schnittstellen sein müssen. > > sqlite ist schon erfunden. Wenn man das möchte, ließe > sich das vermutlich dort einbauen. Man könnte dann für > den Anfang mit einem generischen sqlite-Editor arbeiten > oder eben ein Tool bauen, das konkret für das EDA-Werkzeug > zugeschnitten ist. Naja, ich fürchte, das ist weniger eine Frage des Werkzeuges als vielmehr der Vision, was man damit anstellen sollte. Dein Spott von neulicht trifft schon den Kern: Es gibt schätzungsweise deutlich mehr FOSS-Programmierer, die in ihrer Freizeit programmieren, als solche, die sich in ihrer Freizeit den Kopf über Datenmodelle zerbrechen. > Scheint aber als Designentscheidung keiner so gewollt > zu haben. Ich hoffe, der Grund ist ein anderer: Mit dem Thema lädt man sich viel Ärger auf und hat wenig Ruhm zu gewinnen :) > Da blieben nun zwei Wege: 1) mit dem derzeitigen Design > leben, 2) es selbst implementieren und dem Kicad-Projekt > anbieten. ;-) Naja, "nur KiCad" würde ich nicht wollen; es sollte nach Möglichkeit schon von der konkreten EDA-Software unabhängig sein. Die (aus meiner Sicht) kleinere Baustelle ist die Bauteil- bibliothek. Die gute Nachricht ist, dass gEDA, KiCad (und wohl auch andere) die Bibliothek einfach als Files im File- system halten; diese Schnittstelle ist also hinreichend einfach. Ich bastele seit einer Weile an einem Mini- (... ach was, eher Nano-...) Tool zur lokalen Verwaltung und Suche von Datenblättern; Koexistenz mit Office-Software (LOCalc) bzw. einer Datenbank ist strategisch geplant. Dort könnte man Schaltplansymbole und Footprints anbinden, aber ich habe in dieser Richtung noch nichts bedacht. Auch ein generisches Austauschformat für Schaltplansymbole, das sich leicht in die jeweiligen projekteigenen Formate konvertieren lässt, scheint mir machbar. Das deutlich dickere Brett sind die Schaltpläne. Notwendig wäre ein projektübergreifend taugliches Austauschformat; in der Richtung habe ich aber noch nichts bedacht.
Possetitjel schrieb: > Sheeva P. schrieb: >>> Es wird endlich Zeit mal diesen Teufelskreis "es ist >>> immer alles Umsonst, deswegen lieber Anwender halt's Maul >>> und stell keine Ansprüche an deine OS" zu durchbrechen. >> >> Es gibt keinen solchen Kreis, [...] > > Da bin ich nicht ganz so sicher. Ich schon. ;-) > Programmierer neigen meiner Beobachtung nach dazu, > programmiertechnischen Fragen eine Bedeutung zuzumessen, die > ihnen aus Anwendersicht nicht zukommt (--> "Betriebsblindheit"). Ja, natürlich. Etliche Dinge können Anwender nämlich gar nicht beurteilen, weil ihnen die dazu notwendige Kompetenz und Erfahrung fehlen. Das hat mit dem oben Besprochenen aber nichts zu tun. Worum es oben ging, sind keine technischen Fragen, sondern soziale; es ging um Respekt, Kommunikation, und die Formulierung seiner Ansprüche. Schau Dir nur an, wie W.S. seine Ansprüche formuliert: er sucht nur einen kostenlosen Ersatz für seine Software, ist aber weder bereit, seinen Workflow an eine vorhandene Alternative anzupassen, noch, einen vernünftigen Featurerequest zu formulieren -- stattdessen kommt nur arrogantes Gepöbel in einem Forum, in dem vermutlich kaum ein Kicad-Entwickler mitliest. Hälst Du das etwa für ein konstruktives, lösungsorientiertes Vorgehen? Zumal gegenüber Menschen, an die er seinen Anspruch stellt, daß sie ihm ihre Software und ihre darin investierte Arbeit und Energie schenken? Es hat also nichts mit technischen Fragen oder Betriebsblindheit zu tun, solchen Leuten zu sagen: hau ab, ich bin nicht Dein Leibeigener. Du läßt Dich doch sicher auch nicht von jedem Pöbler herumkommandieren, oder? > Andererseits ist es ja gerade die Lust am Programmieren, > die sie dazu bringt, ihre Kraft überhaupt für das Projekt > einzusetzen! > Sie wollen etwas schaffen, was ihren eigenen (vorwiegend > technisch orientierten) Maßstäben nach begeisterungswürdig > ist. Da kann ich nur für mich sprechen: mir reicht es, wenn ich ein Problem so gelöst habe, daß es meine Kriterien an Funktion, Stabilität, Sicherheit, Wart- und Wiederverwendbarkeit erfüllt. Wenn andere Techies meine Lösung gut finden, freut mich das natürlich, aber das ist nicht das Ziel. > Die nicht-technischen Maßstäbe und Wünsche der Nur-Anwender > sind orthogonal dazu; die schaden nicht, sind aber auch > nicht missionskritisch. Der FOSS-Programmierer kommt auch > gut ohne externe Anwender aus. Beides bezweifle ich zwar, aber das ist ja nicht das Thema.
Possetitjel schrieb: > Dein Spott von neulicht trifft schon den Kern: Es gibt > schätzungsweise deutlich mehr FOSS-Programmierer, die in > ihrer Freizeit programmieren, als solche, die sich in > ihrer Freizeit den Kopf über Datenmodelle zerbrechen. Das halte ich für ein Gerücht, keine Software ohne Datenmodell. ;-) > Die (aus meiner Sicht) kleinere Baustelle ist die Bauteil- > bibliothek. Die gute Nachricht ist, dass gEDA, KiCad (und > wohl auch andere) die Bibliothek einfach als Files im File- > system halten; diese Schnittstelle ist also hinreichend > einfach. > Ich bastele seit einer Weile an einem Mini- (... ach was, > eher Nano-...) Tool zur lokalen Verwaltung und Suche von > Datenblättern; Koexistenz mit Office-Software (LOCalc) > bzw. einer Datenbank ist strategisch geplant. > Dort könnte man Schaltplansymbole und Footprints anbinden, > aber ich habe in dieser Richtung noch nichts bedacht. Auch > ein generisches Austauschformat für Schaltplansymbole, das > sich leicht in die jeweiligen projekteigenen Formate > konvertieren lässt, scheint mir machbar. Ich weiß zwar nicht genau, was Du vorhast, aber vermutlich wäre LOBase da wesentlich besser geeignet... Ich persönlich würde sowas jedoch eher mit einer Volltext-Suchmaschine wie Elasticsearch probieren. ;-)
Possetitjel schrieb: > Das deutlich dickere Brett sind die Schaltpläne. Notwendig > wäre ein projektübergreifend taugliches Austauschformat; > in der Richtung habe ich aber noch nichts bedacht. Irgendwer schrieb mal, daß einem da das Problem im Weg steht, daß jeder Software-Hersteller da einen eigenen Weg geht. Die grafischen Symbole werden zwar gehen, aber es wird sicher vieles geben was man schlicht nicht konvertieren kann. In Altium beispielsweise kann man ein Bauteil nicht nur als einfaches Standardbauteil eintragen, sondern z.B. als reines BOM-Element, als Net-Tie (ein Bauteil das einfach nur ein Netz durchschleift, gut z,B. für Drahtbrücken), wobei es noch zwei verschiedene Typen für Net-Ties gibt, und noch mindestens eine weitere Variante. Ein solches Bauteil in ein anderes Programm zu importieren das eine solche Eigenschaft schlicht nicht unterstützt-was willst du damit machen? Und was ist, wenn ganz wesentliche Funktionen davon abhängen? Oder Designrules-in Altium kannst du praktisch unbegrenzt viele Designrules reinhämmern, wobei es da nicht nur allgemein viele Rules gibt, sondern auch viele Arten von Rules, also z.B. Abstände (in Altium nicht einfach nur 'Abstand', sondern Abstand Lötauge<>Leiterbahn, Abstand Lötauge<>Lötauge, Abstand Leiterbahn<>Polygon, usw), Lochdurchmesser, Leiterbahnbreiten, Maße für Lötstopp und Pastemaske, Diff'Paar, diverse Polygon-Rules, usw. In Eagle ist das weitaus übersichtlicher, auch wenn es Schnittmengen gibt, alles kriegt man da nie importiert. Gilt für andere Programme sicherlich auch. Oder solche Sachen wie radiale Grids...kann das jede EDA-Software?
Sheeva P. schrieb: >> Programmierer neigen meiner Beobachtung nach >> dazu, programmiertechnischen Fragen eine Bedeutung >> zuzumessen, die ihnen aus Anwendersicht nicht zukommt >> (--> "Betriebsblindheit"). > > Ja, natürlich. Wieso "natürlich"? Das erstellte Programm ist doch (oder sollte wenigstens sein) ein Hilfsmittel, um ein konkretes Problem zu lösen. Bei EDA-Software also: Erstellen von Schaltplänen und Layouts. Also sollte doch die Frage im Vordergrund stehen, welche Klippen typischerweise in diesem Arbeitsprozess auftreten und wie man sie umschifft, und nicht die Frage, ob nun MesaGL, Wayland oder GTK verwendet wird. > Etliche Dinge können Anwender nämlich gar nicht beurteilen, > weil ihnen die dazu notwendige Kompetenz und Erfahrung > fehlen. Das ist richtig, aber... > Das hat mit dem oben Besprochenen aber nichts zu tun. ... eben! Denn das allerwichtigste -- nämlich den Arbeitsablauf, wie er beim Anwender auftritt -- KANN der Anwender beurteilen! > Worum es oben ging, sind keine technischen Fragen, sondern > soziale; es ging um Respekt, Kommunikation, "Kommunikation". Gutes Stichwort. Das betrifft nicht nur die Anwender, sondern auch die Programmierer. > und die Formulierung seiner Ansprüche. > Schau Dir nur an, wie W.S. seine Ansprüche formuliert: [...] Ja... das sind wir einer Meinung, aber darum geht's mir gar nicht. Ich möchte gar nicht mal von "Ansprüchen" reden, sondern eher von den Zielen, die man sich vornimmt. Konkretes Beispiel: Bauteilbibliothek. Von Seiten der Anwender höre ich immer wieder zwei Dinge: - Die Wünsche und Vorstellungen sind individuell SEHR verschieden. - Wer Wert auf Fehlerfreiheit legt, erstellt seine Bauteile selbst. Natürlich bringt JEDE Software -- kommerzielle wie freie -- ihre eigene Bibliothek mit; natürlich hat JEDE Software ihr eigenes Datenformat, das zu nichts anderem kompatibel ist; natürlich hat JEDES Softwarepaket seinen eigenen Symboleditor mit seinen eigenen Macken. Folge für den Anwender: Man muss sich ZUERST auf ein Programmpaket festlegen. Mit diesem arbeitet man; je länger man das tut, desto mehr Bauteile erstellt man, und desto schwerer fällt der Wechsel, weil die ganze Arbeit dann verloren ist (--> "vendor lock-in"). Interesse der FOSS-Leute an diesem Problem: Null. Warum die Kommerziellen das machen, ist mir klar -- aber warum machen die FOSS-Leute diesen Scheiss mit?! Das ist ganz ausdrücklich eine Sache, die NICHT innerhalb eines bestimmten Projektes gelöst werden kann, weil es ja eben um die Austauschbarkeit der Daten ZWISCHEN unterschiedlichen Projekten geht. Notwendig wäre also ein unabhängiges, externes "EDA Compatibility Project (EDACoP" :) (Dasselbe gilt im Prinzip auch für die Schaltpläne.) Anderes Beispiel: Schaltplaneditor. Das ist eigentlich eine gut abtrennbare Komponente mit relativ klar definierten Schnittstellen. Meine eigenen Spielereien nicht gerechnet weiss ich von mindestens zwei Versuchen allein hier im Forum, einen gut bedienbaren Schaltplaneditor zu schaffen. Das Java-Programm (HobbyCi) vereint äußerliche Schlichtheit mit cleveren Ideen zur Programmlogik und ermöglicht daher die einfache Arbeitsweise, die ich mir vorstelle. Als Prinzipstudie sehr vielversprechend -- aber: kein Zugriff auf exerne Libraries (gEDA, KiCad), keine kompatiblen Schaltpläne; Projekt ist offenbar verhungert, also auch kein Quelltext, keine schriftliche Dokumentation, keine Lizenz. Nur Java-Bytecode. Stefans ruby-Editor bedient sich clevererweise aus dem Symbolvorrat von gEDA und soll gEDA-taugliche Schaltpläne erzeugen -- aber der lässt sich auf meiner Kiste gar nicht starten bzw. schmiert bei der ersten Aktion ab. Unnötig zu erwähnen, dass auch gEDA und KiCad meines Wissens keine zueinander kompatiblen Schaltpläne erzeugen können. Was soll denn das? Es geht doch überhaupt nicht um ultrakomplizierte, mega- aufwändige Features INNERHALB einer Software -- es geht nur um die Basics des Datenaustausches nach Außen! > Es hat also nichts mit technischen Fragen oder > Betriebsblindheit zu tun, solchen Leuten zu sagen: hau > ab, ich bin nicht Dein Leibeigener. Doch, hat es. Dass der Ton der Kritik nicht akzeptabel ist, steht außer Frage. Dass die konkrete Forderung (aus technischer Sicht) vielleicht unsinnig ist, gestehe ich auch noch zu. Aber: Einer Forderung, die ein Anwender formuliert hat, liegt irgend ein Bedürfnis dieses Anwenders zu Grunde. Man braucht nun wahrlich nicht besonders viel tiefen- psychologisches Geheimwissen, um aus "Niemand braucht diesen Schnulli!" die Kernaussage "Aha. Diesem Anwender ist die Software zu kompliziert zu bedienen" zu extrahieren. Gute Software sollte einfache Dinge einfach und komplizierte Dinge möglich machen. An diesem Kriterium gemessen gibt es keine gute (freie) EDA-Software. > Du läßt Dich doch sicher auch nicht von jedem Pöbler > herumkommandieren, oder? Nein, natürlich nicht. Ich bemühe mich aber, den sachlichen Kern einer Kritik selbst dann zu verstehen, wenn ihr Ton nicht angemessen war.
Sheeva P. schrieb: > Possetitjel schrieb: >> Dein Spott von neulicht trifft schon den Kern: Es gibt >> schätzungsweise deutlich mehr FOSS-Programmierer, die in >> ihrer Freizeit programmieren, als solche, die sich in >> ihrer Freizeit den Kopf über Datenmodelle zerbrechen. > > Das halte ich für ein Gerücht, keine Software ohne > Datenmodell. ;-) Das ist kein Widerspruch: Dass die SOFTWARE ein Datenmodell enthält, bedeutet ja nicht, dass der Programmierer auch darüber NACHGEDACHT hat -- und selbst wenn, muss es ihm noch lange keinen Spaß gemacht haben :) >> Ich bastele seit einer Weile an einem Mini- (... ach was, >> eher Nano-...) Tool zur lokalen Verwaltung und Suche von >> Datenblättern; Koexistenz mit Office-Software (LOCalc) >> bzw. einer Datenbank ist strategisch geplant. [...] > > Ich weiß zwar nicht genau, was Du vorhast, aber vermutlich > wäre LOBase da wesentlich besser geeignet... Das waren meine ersten Versuche. > Ich persönlich würde sowas jedoch eher mit einer Volltext- > Suchmaschine wie Elasticsearch probieren. ;-) Wenn Interesse besteht, kann ich außerhalb dieses Fadens etwas dazu schreiben.
Wühlhase schrieb: > Possetitjel schrieb: >> Das deutlich dickere Brett sind die Schaltpläne. Notwendig >> wäre ein projektübergreifend taugliches Austauschformat; >> in der Richtung habe ich aber noch nichts bedacht. > > Irgendwer schrieb mal, daß einem da das Problem im Weg steht, > daß jeder Software-Hersteller da einen eigenen Weg geht. Klar. Es wäre schon ein Erfolg, wenn man im ersten Angriff zunächst die freien Programme und die "üblichen" kleinen kommerziellen erwischt, also fritzing, gEDA, KiCad, Eagle, Target. Zusätzlich vielleicht noch BAE. > Die grafischen Symbole werden zwar gehen, aber es wird > sicher vieles geben was man schlicht nicht konvertieren > kann. Sicher. Ich schätze, man müsste unterschiedliche Kompatibilitätsschichten definieren. Erstmal mit dem einfachen Zeug anfangen und sehen, inwieweit man das in einem passenden Meta-Format repräsentieren und verlustfrei konvertieren kann.
Possetitjel schrieb: > Sheeva P. schrieb: > Wieso "natürlich"? Weil Softwareentwickler ganz genau dieselbe Art von Fachidioten sind wie Schaltplanentwickler, Layouter, und Betriebswirte. Und weil die Anwender dazu neigen, Funktionalität für wichtiger zu halten als das Datenmodell einer Applikation. > Das erstellte Programm ist doch (oder sollte wenigstens > sein) ein Hilfsmittel, um ein konkretes Problem zu lösen. > Bei EDA-Software also: Erstellen von Schaltplänen und > Layouts. > Also sollte doch die Frage im Vordergrund stehen, welche > Klippen typischerweise in diesem Arbeitsprozess auftreten > und wie man sie umschifft, und nicht die Frage, ob nun > MesaGL, Wayland oder GTK verwendet wird. Genau. Und viele Aufgabe kann man auf sehr unterschiedliche Weise und ihre Teilaufgaben in sehr unterschiedlichen Reihenfolgen lösen. Die Aufgabe des Entwicklers ist es dann, eine Designentscheidung zu treffen, nicht selten eine, die sich erheblich auf das Datenmodell und damit auf das Fundament, nämlich die Funktionalität und Workflows der Software auswirkt. > Denn das allerwichtigste -- nämlich den Arbeitsablauf, wie > er beim Anwender auftritt -- KANN der Anwender beurteilen! Nach vielen Jahren in diesem Bereich muß ich der Aussage leider vehement widersprechen. Die meisten Anwender können höchstens einen ihnen bereits bekannten Arbeitsablauf beurteilen. Daß nicht wenige Entwickler sich noch nie mit Usability oder gar mal einen Styleguide beschäftigt haben, ist allerdings, zugegeben, leider auch wahr. Aber in den meisten erfolgreichen OSS-Projekten taucht früher oder später jemand auf, der das Thema vernünftig, freundlich und sachlich anspricht, und dadurch für signifikante Verbesserungen sorgt. Aber egal, wie gut und sinnvoll diese Verbesserungen sind: immer finden sich Anwender, die diese Verbesserungen ablehnen. >> Worum es oben ging, sind keine technischen Fragen, sondern >> soziale; es ging um Respekt, Kommunikation, > > "Kommunikation". Gutes Stichwort. > Das betrifft nicht nur die Anwender, sondern auch die > Programmierer. Ja, natürlich. Aber es sind ja üblicherweise zunächst die Anwender, welche die Kommunikation eröffnen, indem sie Forderungen stellen, die leider oft irgendwo zwischen "bescheuert" und "unmöglich" liegen. Ich bau doch nicht mein Datenmodell, mein Programm und dessen Workflow um, nur weil ein paar wenige Anwender sich nicht von ihren Angewohnheiten trennen wollen. > Ich möchte gar nicht mal von "Ansprüchen" reden, sondern eher > von den Zielen, die man sich vornimmt. > > Konkretes Beispiel: Bauteilbibliothek. Gutes Beispiel, das. Denn schon bei dessen Datenmodell im Programm fallen mir etwa zehn klassische und zwei oder drei etwas modernere Datenmodelle ein, wie man das abbilden kann -- und bei jedem einzelnen davon kann ich bereits jetzt vorhersagen, daß eine bestimmte Klientel sich daran stoßen wird -- und manchmal sogar, welche und weswegen. Strukturierte Flatfiles sind da der herkömmliche Weg, den die überwiegende Mehrzahl der mir bekannten Programme nutzt. Da mosern die Profis, die mit mehreren Leuten zusammenarbeiten, auf aktuelle Daten angewiesen sind und zwar wissen, daß man die in einem SCM ablegen kann, aber keine Lust haben, ihr lokales SCM zu pflegen. Natürlich ginge auch eine SQL-Datenbank, allerdings fallen mir da bereits etliche Möglichkeiten zur normalisierten Strukturierung ein, und an jeder wird eine bestimmte Anwendergruppe etwas auszusetzen haben. Eine Gruppe findet Flatfile-Datenbanken wie sqlite verständlicherweise doof, darunter die vorgenannten Profis. Eine andere Gruppe wird sich beschweren, daß sie keine Lust hat, extra eine Datenbank wie PostgreSQL zu installieren und zu betreiben, und diverse andere Gruppen werden sich darüber beschweren, wie die Daten abgebildet und normalisiert sind. Ich ganz persönlich würde eine moderne, schemafreie NoSQL-Datenbank wie Elasticsearch bevorzugen, weil man da nicht nur die Bauteildaten selbst, sondern auch die Datenblätter hinterlegen und im Volltext durchsuchen kann, aber dann wird wieder eine Gruppe mosern, daß man sich mit diesem modernen Zeug nicht auskennt und auch nicht auskennen will. Und, wohl gemerkt: bis hierher habe ich nur über verschiedene Methoden der strukturierten Speicherung gesprochen, und nicht einmal über die möglichen Datenmodelle. Von denen ist aber der Workflow in der Software, über den in diesem Thread so intensiv diskutiert wurde, inhärent abhängig. Hinzu kommt wohl, daß OSS-Entwickler, die sich mit EDA-Software beschäftigen, eher zu traditionellen Lösungen neigen. Schemafreie NoSQL-Datenbanken? PostgreSQL mit hstore? So neumodischen Schietkrom kommt mi nich int Hus! > Interesse der FOSS-Leute an diesem Problem: Null. > > Warum die Kommerziellen das machen, ist mir klar -- aber > warum machen die FOSS-Leute diesen Scheiss mit?! Weil es vollkommen sinnlos ist. Das Datenmodell der Libraries ist eng mit dem nötigen Workflow verknüpft, und deswegen wird immer einer meckern, der diesen Workflow nicht mag, weil er einen anderen gewohnt ist. Also lege ich mich als Entwickler auf den Weg des geringsten Widerstandes fest, und baue meine Datenmodelle und Workflows so, daß erstens mein Programm gut damit umgehen kann, ich zweitens selbst möglichst gut damit umgehen kann, sowie drittens möglichst wenig Leute meckern. Letzten Endes ist das jedoch der kleinste Teil in der Entwicklung einer komplexen Suite von GUI-Programmen, die korrekt zusammenarbeiten müssen. Nur: daß dieser Teil klein ist, macht ihn nicht zwangsläufig einfacher. > Es geht doch überhaupt nicht um ultrakomplizierte, mega- > aufwändige Features INNERHALB einer Software Es geht darum, daß die Features der Software, ihre Datenmodelle und ihre Workflows gerade bei hochkomplexen Arbeitsabläufen wie jenem von der Idee zu Platine, Maschine oder Haus inhärent mit einander verbunden sind und deswesen kaum getrennt betrachtet werden können. Ein Schaltplaneditor, ein Layouteditor, ein Autorouter und die Bauteile-Bibliothek sind Teil einer Suite, die idealerweise in Funktionalität und Workflow fein auf einander abgestimmt ist. > Aber: Einer Forderung, die ein Anwender formuliert hat, > liegt irgend ein Bedürfnis dieses Anwenders zu Grunde. Ja. Es bleibt aber SEIN Bedürfnis, nicht das meine. Vielleicht mache ich es zu meinem, wenn er nett ist oder eine Gegenleistung anbietet, aber wenn nicht... tja, dann hat er eben Pech gehabt. > Gute Software sollte einfache Dinge einfach und komplizierte > Dinge möglich machen. An diesem Kriterium gemessen gibt es > keine gute (freie) EDA-Software. Richtig, aber es gibt eben auch keine gute kommerzielle EDA-Software. Um genau zu sein, kenne ich überhaupt keine gute CAD-Software, das ist nicht auf EDA beschränkt. Und ausgerechnet die OSS-Welt mit ihrem verschwindend geringen Marktanteil hat derzeit keine Chance, daran etwas zu ändern.
Possetitjel schrieb: > Das ist kein Widerspruch: Dass die SOFTWARE ein Datenmodell > enthält, bedeutet ja nicht, dass der Programmierer auch > darüber NACHGEDACHT hat -- und selbst wenn, muss es ihm > noch lange keinen Spaß gemacht haben :) Man kann keine funktionierende EDA-Suite bauen, ohne sich zuvor intensive Gedanken über deren Datenmodell zu machen. >> Ich persönlich würde sowas jedoch eher mit einer Volltext- >> Suchmaschine wie Elasticsearch probieren. ;-) > > Wenn Interesse besteht, kann ich außerhalb dieses Fadens > etwas dazu schreiben. Sehr gerne, ich habe derweil etwas mit ESearch herumgespielt und für den Anfang überraschend gute Ergebnisse erzielt.
Sheeva P. schrieb: > Und viele Aufgabe kann man auf sehr unterschiedliche > Weise und ihre Teilaufgaben in sehr unterschiedlichen > Reihenfolgen lösen. Ja. > Die Aufgabe des Entwicklers ist es dann, eine > Designentscheidung zu treffen, Jein. Die Aufgabe wäre erstmal, die Varianten (für die gewünschten Abläufe) zu erfassen und daraufhin abzuklopfen, welche Varianten wieviel Aufwand erfordern und welche wie miteinander verträglich sind. DANN kann man eine Entscheidung treffen. > nicht selten eine, die sich erheblich auf das Datenmodell > und damit auf das Fundament, nämlich die Funktionalität > und Workflows der Software auswirkt. Das kann passieren, ja. Das wird aber keineswegs immer passieren. Wie heisst es: "Wer will, findet Wege. Wer nicht will, findet Gründe." > Aber es sind ja üblicherweise zunächst die Anwender, > welche die Kommunikation eröffnen, Naja, boshaft gesagt: Genau das ist ja das Problem. Die Programmierer programmieren drauflos, was ihnen in die Rübe kommt :) Kommunikation ist optional. > Ich bau doch nicht mein Datenmodell, mein Programm und > dessen Workflow um, nur weil ein paar wenige Anwender > sich nicht von ihren Angewohnheiten trennen wollen. Warum nicht? Wenn die Programmänderung nicht zu einer Verschlechterung der Architektur führt, kann man doch auch den paar wenigen Anwendern entgegenkommen. Welcher Zacken fällt einem aus der Krone? Klar -- es gibt wirklich Fälle, da geht das nicht. Dann geht es eben wirklich nicht. > Strukturierte Flatfiles sind da der herkömmliche Weg, > den die überwiegende Mehrzahl der mir bekannten Programme > nutzt. Da mosern die Profis, die mit mehreren Leuten > zusammenarbeiten, auf aktuelle Daten angewiesen sind und > zwar wissen, daß man die in einem SCM ablegen kann, aber > keine Lust haben, ihr lokales SCM zu pflegen. Naja, "Argument" und "gutes Argument" ist noch ein Unterschied; da brauchen wir nicht streiten. Irgendwer meckert immer. > Natürlich ginge auch eine SQL-Datenbank, allerdings fallen > mir da bereits etliche Möglichkeiten zur normalisierten > Strukturierung ein, und an jeder wird eine bestimmte > Anwendergruppe etwas auszusetzen haben. Eine Gruppe findet > Flatfile-Datenbanken wie sqlite verständlicherweise doof, > darunter die vorgenannten Profis. Eine andere Gruppe wird > sich beschweren, daß sie keine Lust hat, extra eine Datenbank > wie PostgreSQL zu installieren und zu betreiben, und diverse > andere Gruppen werden sich darüber beschweren, wie die Daten > abgebildet und normalisiert sind. Fällt Dir etwas auf? Alle Punkte, die Du oben anführst, haben damit zu tun, WIE etwas TECHNISCH realisiert wird. Genau das ist aber die Sorte unsinniger Streitereien, die ich kritisiere. Maßgebend sollte sein, welche ARBEITSABLÄUFE die Software ermöglicht, und dann wird die von der Architektur her am besten passende Lösung für diese Arbeitsabläufe gewählt. (Viele Lösungen schließen sich gegenseitig auch gar nicht zwingend aus.) GENAU das ist der Kritikpunkt: Es wird SOFORT über Implementierungsdetails gestritten, statt sich erstmal mit dem Pflichtenheft zu befassen! >> Warum die Kommerziellen das machen, ist mir klar -- >> aber warum machen die FOSS-Leute diesen Scheiss mit?! > > Weil es vollkommen sinnlos ist. Das Datenmodell der > Libraries ist eng mit dem nötigen Workflow verknüpft, Den Punkt sehe ich nicht. > Also lege ich mich als Entwickler auf den Weg des > geringsten Widerstandes fest, [...] Ja -- genauso sieht das auch aus: Das Brett an der dünnsten Stelle gebohrt. > Es geht darum, daß die Features der Software, ihre > Datenmodelle und ihre Workflows gerade bei hochkomplexen > Arbeitsabläufen Hochkomplexe Arbeitsabläufe: Ja, gehe ich mit. > inhärent mit einander verbunden sind und deswesen kaum > getrennt betrachtet werden können. Naja, jede Schnittstellenfestlegung ist eine "Trennung". Software-Architektur funktioniert aber nur so. >> Aber: Einer Forderung, die ein Anwender formuliert hat, >> liegt irgend ein Bedürfnis dieses Anwenders zu Grunde. > > Ja. Es bleibt aber SEIN Bedürfnis, nicht das meine. Ja. > Vielleicht mache ich es zu meinem, wenn er nett ist oder > eine Gegenleistung anbietet, aber wenn nicht... tja, dann > hat er eben Pech gehabt. Genau das ist der Knackpunkt bei FOSS: Es mangelt an konkludentem Handeln. Wozu werden "Profi-Funktionen" in das Programm eingebaut, wenn das Programm letztlich nicht für professionelle Anwender tauglich ist? Es geht nicht primär um die funktionale Seite des Programmes, sondern um das Verhalten des gesamten Projektes. Ich rede nicht von juristischen Dingen, die sind klar; ich rede von der Kommunikation, der Außenwirkung. Das ist so "trivialer" Kram wie - stabiles Projektteam (mit deutlich mehr als einem Mitglied), - aussagekräftige Dokumentation, - Hintergrundinformation über Ziele, getroffene Entscheidungen und die Entscheidungsgründe. >> Gute Software sollte einfache Dinge einfach und komplizierte >> Dinge möglich machen. An diesem Kriterium gemessen gibt es >> keine gute (freie) EDA-Software. > > Richtig, aber es gibt eben auch keine gute kommerzielle > EDA-Software. Das kann sein, aber das kann ich nicht beurteilen. Altium habe ich z.B. nie aus der Nähe gesehen, BAE auch nicht. > Und ausgerechnet die OSS-Welt mit ihrem verschwindend > geringen Marktanteil hat derzeit keine Chance, daran > etwas zu ändern. Jaja, ich weiss: "Linux is obsolete" :) Ich glaube, zumindest einige der Probleme der FOSS-Leute sind hausgemacht und wären lösbar.
Hallo, Sheeva P. schrieb: > Man kann keine funktionierende EDA-Suite bauen, ohne zu machen. Und bevor man sich intensive Gedanken über ein Datenmodell macht, sollte man sich noch viel intensivere Gedanken um die Funktionalität und den Arbeitsablauf einer Software machen. rhf
Hallo Possetitjel. Possetitjel schrieb: > Die nicht-technischen Maßstäbe und Wünsche der Nur-Anwender > sind orthogonal dazu; die schaden nicht, sind aber auch > nicht missionskritisch. Der FOSS-Programmierer kommt auch > gut ohne externe Anwender aus. Aehm....bei sehr vielen open Source Projekten sind Anwender und Entwickler ein und dieselben. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Das ist genau das Problem. Jetzt muss der Entwickler noch eine ganz altertümliche Auffassung von guter Bedienung haben und fertig ist Kicad.
Hallo Hans Wurst. Hans Wurst schrieb: > Das ist genau das Problem. Jetzt muss der Entwickler noch eine ganz > altertümliche Auffassung von guter Bedienung haben und fertig ist Kicad. Da kann man mal sehen, wie die Ansichten auseinandergehen. ;O) Die einen kritisieren an Open Source, dass Programierer zu weit vom Anwender weg sind, und programmiert wird, ohne auf Anwender Rücksicht zu nehmen, und die anderen kritisieren, dass durch die enge Verbindung von Programmierer und Anwender mögliche Innovationen unterbleiben. ;O) > Jetzt muss der Entwickler noch eine ganz > altertümliche Auffassung von guter Bedienung haben und fertig ist Kicad. Glücklicherweise schreiben an KiCad mehrere hundert Entwickler....vom Studenten, über Leute, die sowohl als Programmierer und/oder Anwender voll im Beruf stehen bis hin zu Pensionären. Bisher haben die sich immer auf Brauchbares zusammengerauft. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Bisher haben die sich immer > auf Brauchbares zusammengerauft. Für wahr, das merkt man auch daran das es bereits einen TO gibt der KiCad geil findet ;-) Gefühlt sind die in zunehmen. (Ich meine natürlich die Umsteiger oder die sich das neu aneignen)
Bernd W. schrieb: > Glücklicherweise schreiben an KiCad mehrere hundert Entwickler....vom > Studenten, über Leute, die sowohl als Programmierer und/oder Anwender > voll im Beruf stehen bis hin zu Pensionären. Bisher haben die sich immer > auf Brauchbares zusammengerauft. ;O) Da fällt mir ein, ich wollte mal so einen Group-Selector bauen wie die Gruppen, die man in Eagle aufziehen kann ... Das ist das einzige, was ich bisher immer vermisst hab ... Dass ich ein Polygon aufziehen kann, um die Bauteile zu selektieren, die ich verschieben möchte. Mit dem Polygon ging das ja Widerstandsgenau^^
Possetitjel schrieb: > Sheeva P. schrieb: >> Die Aufgabe des Entwicklers ist es dann, eine >> Designentscheidung zu treffen, > > Jein. > Die Aufgabe wäre erstmal, die Varianten (für die gewünschten > Abläufe) zu erfassen und daraufhin abzuklopfen, welche > Varianten wieviel Aufwand erfordern und welche wie miteinander > verträglich sind. Ja, und das haben die Kicad-Entwickler ja offensichtlich getan -- denn sonst würde es keine Bauteilebibliothek geben. Die Entwicker haben also keineswegs "munter drauflos programmiert", sondern sich Gedanken über den Anwendungsfall, dessen Umsetzung in einen Workflow, ein diesen Workflow unterstützendes Datenmodell und ein dafür geeignetes Datenformat gemacht, und zwar bevor sie die erste Zeile Code dafür geschrieben haben. Anders kann man GUI-Software nämlich nicht entwickeln, schon gar keine Suite von mehreren Programmen, die mit einander kooperieren und dabei auf dieselben Bibliotheken und Daten zugreifen müssen. Die Kicad-Entwickler haben sich bei ihrer Designentscheidung nun für einen Workflow entschieden, der ihnen sinnvoll erscheint und -- wenn ich Jörgs Ausführungen dazu richtig verstanden habe -- in ähnlicher Form auch beim verbreitetsten Industrie-Pseudostandard Altium Designer genutzt wird. Wie Du jetzt auf die Unterstellung kommst, daß die Entwickler bei den nötigen Vorüberlegungen geschludert hätten, erschließt sich mir daher nicht. >> Aber es sind ja üblicherweise zunächst die Anwender, >> welche die Kommunikation eröffnen, > > Naja, boshaft gesagt: Genau das ist ja das Problem. > Die Programmierer programmieren drauflos, was ihnen in > die Rübe kommt :) Kommunikation ist optional. Daß Entwickler sich vor dem Coden Gedanken über den Anwendungsfall, einen passenden Workflow und dabei natürlich auch darüber machen, mit welchen Datenmodellen und -Formaten dieser optimal unterstützt werden kann, ist eine Selbstverständlichkeit. Ohne solche Fundamente bekommt man kein noch so einfaches Programm hin. Die Anwender kommen erst ins Spiel, wenn die Software so weit entwickelt ist, daß ihre Funktionalitäten und Workflows von den Anwendern ausprobiert werden können. Sobald die Anwender etwas zum Ausprobieren haben, liefern sie manchmal vernünftigen Input, manchmal nicht. Und manchmal kommt dabei auch nur Gefasel oder gar Gepöbel, das ist dann gar kein Input. >> Ich bau doch nicht mein Datenmodell, mein Programm und >> dessen Workflow um, nur weil ein paar wenige Anwender >> sich nicht von ihren Angewohnheiten trennen wollen. > > Warum nicht? Weil die überwiegende Mehrheit der Anwender offensichtlich gut mit den vorhandenen Workflows arbeiten kann und will. > Wenn die Programmänderung nicht zu einer Verschlechterung > der Architektur führt, kann man doch auch den paar wenigen > Anwendern entgegenkommen. Welcher Zacken fällt einem aus > der Krone? Die Ressourcen in Softwareprojekten unterliegen gewissen personellen und zeitlichen Beschränkungen, da ist OpenSource keine Ausnahme. Jede Stunde, die ich dafür einsetze, um auch den letzten Meckerer zufrieden zu stellen, fehlt mir bei anderen Aufgaben, mit deren Lösung ich mehr Anwender oder vielleicht sogar mich selbst glücklich machen kann. Bei Leuten wie dem, der hier so herumpöbelt, habe ich allerdings auch gar keine Lust und keine Motivation, ihm entgegen zu kommen. Das ist nämlich einer der schönsten Unterschiede zwischen meiner bezahlten Arbeit und OSS: bei meinem Engagement im OpenSource-Bereich kann ich selbst frei und ohne irgendeinen Zwang entscheiden, was ich mache, und wessen Bedürfnisse ich berücksichtigen will oder nicht. > Fällt Dir etwas auf? Ja, wir reden an einander vorbei. > Alle Punkte, die Du oben anführst, haben damit zu tun, > WIE etwas TECHNISCH realisiert wird. Genau das ist aber > die Sorte unsinniger Streitereien, die ich kritisiere. > Maßgebend sollte sein, welche ARBEITSABLÄUFE die Software > ermöglicht, und dann wird die von der Architektur her am > besten passende Lösung für diese Arbeitsabläufe gewählt. Wo ich hier angesetzt habe, sind die Arbeitsabläufe längst geklärt, und es geht vielmehr um die technische Realisation. Dabei wollte ich vornehmlich auf Dein Thema einer Bauelemente-Datenbank eingehen: das WAS und das WARUM sind klar -- wir brauchen eine Bibliothek mit strukturierten Daten --, und jetzt geht es vielmehr um das WIE. > (Viele Lösungen schließen sich gegenseitig auch gar nicht > zwingend aus.) "Zwingend" ist dabei meistens nicht das Kriterium, sondern es geht vielmehr um Eigenschaften wie Aufwand (s.o.: Ressourcenallokation) und Wartbarkeit. > GENAU das ist der Kritikpunkt: Es wird SOFORT über > Implementierungsdetails gestritten, statt sich erstmal mit > dem Pflichtenheft zu befassen! Entschuldige bitte, aber das ist falsch. In jedem Projekt, an dem ich bis heute teilgenommen habe, egal ob kommerziell oder OSS, wurde zuerst immer ein Konsens erzielt, was umgesetzt werden sollte. Häufig war der Konsens schon im Anfangsstadium des Projekts sehr detailliert und ausgereift, in anderen Fällen wurde er mit verschiedenen Methoden verfeinert und hin und wieder mußte er sogar verworfen und ein neuer Konsens erarbeitet werden, weil sich der vorherige als impraktikabel oder technisch nicht umsetzbar erwiesen hatte. Erst danach ging es um Details der technischen Umsetzung. Und immer, wenn eine technische Umsetzung zur Zufriedenheit funktioniert hat, wurden neue Ziele gesucht, ein Konsens dazu erarbeitet, und danach wiederum über dessen technische Umsetzung diskutiert. So funktioniert Softwareentwicklung in Teams, das geht auch nicht anders. Schließlich ist es schlicht unmöglich, über die Implementierung von etwas Unbekanntem zu diskutieren. >> Also lege ich mich als Entwickler auf den Weg des >> geringsten Widerstandes fest, [...] > > Ja -- genauso sieht das auch aus: Das Brett an der > dünnsten Stelle gebohrt. Sowas kommt zwar leider vor, aber in der Regel modellieren OSS-Entwickler ihre Arbeitsabläufe so, daß sie für die Mehrheit ihrer Anwender und / oder sie selbst möglichst optimal funktionieren. Im OSS-Umfeld ist es nämlich so, daß die Entwickler gleichzeitig meist auch Nutzer ihrer Software sind -- und natürlich keine Lust haben, ihre eigenen Arbeitsabläufe aufwändiger oder komplizierter zu machen als unbedingt nötig. >> Es geht darum, daß die Features der Software, ihre >> Datenmodelle und ihre Workflows gerade bei hochkomplexen >> Arbeitsabläufen >> inhärent mit einander verbunden sind und deswesen kaum >> getrennt betrachtet werden können. > > Naja, jede Schnittstellenfestlegung ist eine "Trennung". > Software-Architektur funktioniert aber nur so. Ja, aber wenn Schaltplaneditor, Layouteditor und Bibliotheksverwaltung auf dieselbe Bibliothek zugreifen müssen und dabei jeweils unterschiedliche Bedürfnisse und Arbeitsabläufe abdecken müssen, dann muß ich mir zuerst schon einige Gedanken darüber machen, welche Informationen die Bibliothek enthalten und über welche Schnittstellen sie den jeweiligen Programmen zugänglich gemacht werden können. Erschwerend kommt hinzu, daß Änderungen an der Bibliothek wiederum Änderungen an den Schnittstellen und den darauf zugreifenden Programmen nach sich ziehen, und an dieser Stelle sind wir schon wieder bei der erwähnten Ressourcenallokation. >> Vielleicht mache ich es zu meinem, wenn er nett ist oder >> eine Gegenleistung anbietet, aber wenn nicht... tja, dann >> hat er eben Pech gehabt. > > Genau das ist der Knackpunkt bei FOSS: Es mangelt an > konkludentem Handeln. Ich finde mein Handeln, mich an den Bedürfnissen der Mehrheit meiner Anwender zu orientieren und die wenigen Pöbler zu ignorieren, äußerst konkludent und obendrein sehr vernünftig. > Wozu werden "Profi-Funktionen" in das Programm eingebaut, > wenn das Programm letztlich nicht für professionelle > Anwender tauglich ist? Im Falle von Kicad ist es wohl so, daß es zum Beispiel am CERN durchaus professionell genutzt wird und seine Tauglichkeit für den professionellen Einsatz offensichtlich unbestreitbar ist. > Es geht nicht primär um die funktionale Seite des Programmes, > sondern um das Verhalten des gesamten Projektes. Ich rede > nicht von juristischen Dingen, die sind klar; ich rede von > der Kommunikation, der Außenwirkung. > > Das ist so "trivialer" Kram wie > - stabiles Projektteam (mit deutlich mehr als einem Mitglied), > - aussagekräftige Dokumentation, > - Hintergrundinformation über Ziele, getroffene Entscheidungen > und die Entscheidungsgründe. Tatsächlich bietet fast jedes OSS-Projekt Informationen an, in denen jeder, der will, die Ziele, Entscheidungen und deren Gründe nachlesen kann. In Mailinglisten und Newsgroups kann man oft sogar die Diskussionen und die Argumente nachlesen, die zu den Entscheidungen geführt haben, und viele Projekte unterhalten zudem Webseiten, Wikis und Weblogs, in denen solche Informationen stehen. In den meisten mir bekannten OSS-Projekten gibt es das alles, nur: mit Ausnahme der Entwickler liest das keiner. Und wenn man Anwender darauf verweist, wird einem regelmäßig erklärt, daß man die Software doch nur benutzen wolle und keine Zeit habe, sich mit der Dokumentation oder noch weitergehenden Hintergrundinformationen zu beschäftigen, zumal sich die Hintergrundinformationen dann auch noch häufig mit Themen beschäftigen, welche Anwender mangels Vorkenntnissen ohnehin nicht verstehen. Im Gegensatz zu den meisten kommerziellen Herstellern sind die OSS-Leute auch sehr kontakt- und auskunftsfreudig, durch freundliches Nachfragen bekommst Du in der Regel alle Informationen, die Du haben willst -- oft sogar noch viel mehr. Aber auch dazu sind viele Anwender zu faul, "ich möchte die Software doch nur benutzen" -- und am Ende beschweren sie sich über das Fehlen von Informationen, um die sie sich nie bemüht haben. > Ich glaube, zumindest einige der Probleme der FOSS-Leute sind > hausgemacht und wären lösbar. Das ist zwar leider nicht ganz falsch, aber diese Probleme sind nicht die, welche Du ausgemacht haben willst.
Hallo, Roland F. schrieb: > Sheeva P. schrieb: >> Man kann keine funktionierende EDA-Suite bauen, ohne zu machen. > > Und bevor man sich intensive Gedanken über ein Datenmodell macht, sollte > man sich noch viel intensivere Gedanken um die Funktionalität und den > Arbeitsablauf einer Software machen. Es ging hier um die Bauteilebibliothek, da muß ich mir jetzt nicht allzu viele Gedanken über die Funktionalität machen: da müssen Daten strukturiert gespeichert und zum Abruf vorgehalten werden.
Sheeva P. schrieb: > Es ging hier um die Bauteilebibliothek, da muß ich mir jetzt nicht allzu > viele Gedanken über die Funktionalität machen: da müssen Daten > strukturiert gespeichert und zum Abruf vorgehalten werden. Lese ich daraus (auch aus deinem Beitrag vorher) das du bei KiCad aktiv am proggen bist ?
Bernd W. schrieb: > Hallo Hans Wurst. > > Hans Wurst schrieb: > >> Das ist genau das Problem. Jetzt muss der Entwickler noch eine ganz >> altertümliche Auffassung von guter Bedienung haben und fertig ist Kicad. > > Da kann man mal sehen, wie die Ansichten auseinandergehen. ;O) > > Die einen kritisieren an Open Source, dass Programierer zu weit vom > Anwender weg sind, und programmiert wird, ohne auf Anwender Rücksicht zu > nehmen, und die anderen kritisieren, dass durch die enge Verbindung von > Programmierer und Anwender mögliche Innovationen unterbleiben. ;O) Ich habe nichts gegen Open Source, ich habe auch nichts gegen Kicad an sich, mich stört nur, dass bis heute niemand das Bedienkonzept ins Jahr 2017 gebracht hat.
Du glaubst doch nicht wirklich an diese Vorstellung, oder? Sowas ist festgemeiselt. Soll keine Kritik an irgendeiner Software sein. Ich kenn nur eine Firma, die ständig irgendwas über den Haufen wirft: Kurioserweise Microsoft
Wäre schon schön wenn Kicad zumindest im Jahr 1995 ankommt. - Das Highlighten selektierter Elemente - selektieren von Bauteilgruppen mit der Maus - Ziehen als Standard und Verschieben über Hotkey - Komplette Überarbeitung der Funktionen zum Erstellen und editieren von Verbindungen und Traces. - Automatische rechtwinklige Ausrichtung der Verbindungen am Raster -> keine Luftlinienverbindungen. - Selektieren von Leiterbahnen und Verbindungen nicht nur in den Eckpunkten - Kein Rumgehopse des Maus-Cursors beim öffnen eines Menüs. usw.
Sheeva P. schrieb: > Im Gegensatz zu den meisten kommerziellen Herstellern sind die OSS-Leute > auch sehr kontakt- und auskunftsfreudig, durch freundliches Nachfragen > bekommst Du in der Regel alle Informationen, die Du haben willst -- oft > sogar noch viel mehr. Aber auch dazu sind viele Anwender zu faul, "ich > möchte die Software doch nur benutzen" -- und am Ende beschweren sie > sich über das Fehlen von Informationen, um die sie sich nie bemüht > haben. Sheeva, meiner einer findet OSS Klasse und ich bin auch selber in dem Bereich aktiv. Aber ein Tag hat nur 24 Stunden und ein Anwender der diese Software nur benutzt ist selten willens sich mit internas der Erstellung zu beschäftigen. Das fehlen von Informationen weil jemand das Handbuch nicht gelesen hat ist auch nicht OSS spezifisch. Es kommt noch hinzu das ich nach dem Kauf einer Software keine Verpflichtung gegenüber dem Anbieter habe. In der Regel ist er aber interessiert sein Produkt weiter zu entwickeln und Fehler zu beheben. Da ist es mir häufig lieber diesen klaren weg zu gehen statt in diesem latent offenen Schuldverhältnis gegenüber einer Community zu stehen. Die ist ja in der Regel sehr nett und freut sich über jeden der das Programm benutzt. Bei Rückfragen wird auch oft sehr hilfsbereit reagiert (sofern man die einfachen Mindeststandards der Netikette einhält) aber das ändert das Prinzip nicht. Hans Wurst schrieb: > Wäre schon schön wenn Kicad zumindest im Jahr 1995 ankommt. > > - Das Highlighten selektierter Elemente > - selektieren von Bauteilgruppen mit der Maus > - Ziehen als Standard und Verschieben über Hotkey > - Komplette Überarbeitung der Funktionen zum Erstellen und editieren von > Verbindungen und Traces. > - Automatische rechtwinklige Ausrichtung der Verbindungen am Raster -> > keine Luftlinienverbindungen. > - Selektieren von Leiterbahnen und Verbindungen nicht nur in den > Eckpunkten > - Kein Rumgehopse des Maus-Cursors beim öffnen eines Menüs. > usw. Ist das wirklich so?
X4U schrieb: > Ist das wirklich so? Vielleicht wenn man den OpenGL-Modus nicht nutzt, der deutlich neueren Datums ist^^ Nicht nur die Anzeige ist anders - die Bedienung ist auch komplett anders und hat mit dem Legacy-Mode nicht mehr viel gemeinsam. Gut, ein ganz anderes Programm ist es dann trotzdem nicht, aber deutlich komfortabler.
:
Bearbeitet durch User
Oha, wenn dem so ist wird das heute direkt ausprobiert. Vielleicht werden KiCad und ich doch noch Freunde.
Abdul K. schrieb: > Ich kenn nur eine Firma, die ständig irgendwas über den Haufen wirft: > Kurioserweise Microsoft und Firefox' Mozilla. Update auf v57 und schon funktionieren Add-ons wie NoScript nicht mehr. Auf einmal sind auch die Tabs wieder rechteckig (wie sie mal waren) und alles soll natürlich unglaublich viel schneller sein. Das Rad ist damit zum x-ten mal wieder neu erfunden. Browsen bisher? Browsen jetzt? Wieder runter mit dem Teil und alles ist gut ..
Hans Wurst schrieb: > Oha, wenn dem so ist wird das heute direkt ausprobiert. Vielleicht > werden KiCad und ich doch noch Freunde. Ob bei dir KiCad die Freundschaft erwiedert wage ich zu bezweifeln :-) KiCad sucht sich seine Freunde aus, so wie mich ;-)
Opengl Canvas ist schon deutlich besser. Allerdings in EEschema kann ich nichts dergleichen aktivieren.
Hallo, Abdul K. schrieb: > Ich kenn nur eine Firma, die ständig irgendwas über den Haufen wirft: > Kurioserweise Microsoft Und hier haben wir meiner Meinung nach das Paradebeispiel dafür, das "ständiges über den Haufen werfen" auch nach hinten los gehen kann. Dauernde Änderungen an einer Benutzerschnittstelle sind im produktiven Einsatz Produktivitätskiller und kosten Unmengen an Geld. Im privaten Bereich verschwenden sie meine Lebenszeit. rhf
:
Bearbeitet durch User
Roland F. schrieb: > Hallo, > > Abdul K. schrieb: >> Ich kenn nur eine Firma, die ständig irgendwas über den Haufen wirft: >> Kurioserweise Microsoft > > Und hier haben wir meiner Meinung nach das Paradebeispiel dafür, das > "ständiges über den Haufen werfen" auch nach hinten los gehen kann. > Dauernde Änderungen an einer Benutzerschnittstelle sind im produktiven > Einsatz Produktivitätskiller und kosten Unmengen an Geld. Im privaten > Bereich verschwenden sie meine Lebenszeit. > > rhf Ja, dann hol doch den C64 raus und erstelle deine Layouts mit einem Joystick. Dafür wurde EEschema ja optimiert.
il Conte schrieb: > Ob bei dir KiCad die Freundschaft erwiedert wage ich zu bezweifeln :-) > KiCad sucht sich seine Freunde aus, so wie mich ;-) und wenn ich die Freundschaftsanfrage ablehne, ist KiCad dann sauer auf mich? Mampf F. schrieb: >> Wäre schon schön wenn Kicad zumindest im Jahr 1995 ankommt. >> >> - Das Highlighten selektierter Elemente >> - selektieren von Bauteilgruppen mit der Maus >> - Ziehen als Standard und Verschieben über Hotkey >> - Komplette Überarbeitung der Funktionen zum Erstellen und editieren von >> Verbindungen und Traces. >> - Automatische rechtwinklige Ausrichtung der Verbindungen am Raster -> >> keine Luftlinienverbindungen. >> - Selektieren von Leiterbahnen und Verbindungen nicht nur in den >> Eckpunkten >> - Kein Rumgehopse des Maus-Cursors beim öffnen eines Menüs. >> usw. > Gut, ein ganz anderes Programm ist es dann trotzdem nicht, aber > deutlich komfortabler. Ist also alles veraltet und daher grundlos?
Hallo X4U. X4U schrieb: > und wenn ich die Freundschaftsanfrage ablehne, ist KiCad dann sauer auf > mich? Bestimmt nicht. Das Programm ist relativ robust. > >> Gut, ein ganz anderes Programm ist es dann trotzdem nicht, aber >> deutlich komfortabler. > > Ist also alles veraltet und daher grundlos? Etliches dürfte sowieso nach der aktuellen Umstellung der Datenformate für Schaltplan und Symbole überholt sein, bzw. innerhalb der nächsten Monate veralten. Und dann kommt KiCad halt einigen Arbeitsstilen besser entgegen als anderen. Mir lag KiCad damals 2009 auf Anhieb, aber es gibt wohl auch Fälle wo das anders ist. Einiges muss man schlicht wissen. Es gibt z.B. selten Programme, wo man mehrere komplett unterschiedliche Canvasse zur Auswahl hat, die sich auch entsprechend anders verhalten. Demzufolge lassen das die meisten beim Ausprobieren liegen. Einige fühlen sich sogar veräppelt. Der openGL Canvas verlangt aber auch eine gute openGL Unterstützung. Die ist nicht überall gegeben (z.B. auf meinem uralt Netbook). Es gibt dann Mesa um eine openGL Unterstützung zu emulieren, aber daaaan wiiiieerd aaaales gaaaanz laaangsaaam. Wo das aber eine openGL Unterstützung gut funktioniert, ist KiCad sehr geschmeidig. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Etliches dürfte sowieso nach der aktuellen Umstellung der Datenformate > für Schaltplan und Symbole überholt sein, bzw. innerhalb der nächsten > Monate veralten. Das "liebe" ich so an der Open Source Szene. Man stellt konkrete Fragen und bekommt ein neblige Antwort mit Verweis auf die glorreiche Zukunft. Gegen Kicad habe ich überhaupt nichts, würde sogar von heute auf morgen wechseln wenn es was taugt. Das scheitert aber immer wieder schon im Vorfeld an den Antworten der Nutzer. Die imho hirnlose Diskussion über den Austausch von Footprints weiter oben spricht da Bände. Eagle kann beides. Das ist aber sinnlos weil wie die Trennung von Schaltplan und Board eben ein anderes Arbeitskonzept ist. Wie oft kommt das dann noch vor? In der Regel nimmt man gleich ein anderes Bauteil weil sonst keiner mehr durchblickt und der "Pfleger" sich auch erstmal an einem Flohzirkus probieren sollte. > > Und dann kommt KiCad halt einigen Arbeitsstilen besser entgegen als > anderen. Mir lag KiCad damals 2009 auf Anhieb, aber es gibt wohl auch > Fälle wo das anders ist. Eben und das gute alte Zeichenbrett und Letraset in 4:1 ist haptisch auch durch nichts zu ersetzen. Das sind für mich Nullaussagen. Ich muss auch C++ Grundlagen lernen weil eagle nun mal anders nicht zu proggen ist. Mach ich das halt, wenn Autodesk zu dreist wird lerne ich Kicad oder irgendwas anderes. Mir doch egal.
Ok X4U, für dich gehe ich das halt nochmal durch. Eigentlich wurde das schon etliche Male besprochen, aber dann kommt wieder ein Hans Wurst mit falschen Behauptungen. Hans Wurst schrieb: > - Das Highlighten selektierter Elemente Wozu? Selektiert wird durch das Aufziehen eines Rechtecks, alles was drin ist wird (auf Nachfrage wo nötig) selektiert. > - selektieren von Bauteilgruppen mit der Maus Womit denn sonst? > - Ziehen als Standard und Verschieben über Hotkey Hat er nie probiert, Move oder Drag wird über das Kontextmenü oder den Anfangsbuchstabe mittels Tastatur gewählt. Wie kann es da eine Priorität geben? > - Komplette Überarbeitung der Funktionen zum Erstellen und editieren von > Verbindungen und Traces. Aha! > - Automatische rechtwinklige Ausrichtung der Verbindungen am Raster -> > keine Luftlinienverbindungen. Natürlich, wie denn sonst. Achso diagonal geht auch, ist das zuviel? > - Selektieren von Leiterbahnen und Verbindungen nicht nur in den > Eckpunkten Wozu sollten diese selektiert werden? > - Kein Rumgehopse des Maus-Cursors beim öffnen eines Menüs. Das gibt es nicht. > usw. Aha.
Guido B. schrieb: > Hans Wurst schrieb: >> - Das Highlighten selektierter Elemente > Wozu? Selektiert wird durch das Aufziehen eines Rechtecks, alles was > drin ist wird (auf Nachfrage wo nötig) selektiert. Uff! Du hast nicht begriffen, was damit gemeint ist. Highlighten und Selektieren ist unterschiedlich. Habe mir für WIN die 4.0.7 runtergeladen. Aber die 700MB sind schon der Hammer. Was ist da alles drin? Wenn ich lange Weile habe, installiere ich das mal. Vielleicht kriege ich da ein Platinchen zustande analog "Hallo World". Bei der V.4.0.6. war ich zu doof dafür.
Das "hello world"-pendant als pcb-layout - könnte sein 1 LED, 1 Vorwiderstand 1 Schalter und eine 2-polige Anschlussklemme für die Spannungsversorgung.
michael_ schrieb: > Uff! > Du hast nicht begriffen, was damit gemeint ist. > Highlighten und Selektieren ist unterschiedlich. Gut möglich. Wenn ich etwas selektiere, wird es in Eeschema blasser dargestellt. Highlighting wäre vermutlich andersrum?
Guido B. schrieb: >> - Selektieren von Leiterbahnen und Verbindungen nicht nur in den >> Eckpunkten > Wozu sollten diese selektiert werden? Z.B. um eine LB anschließend im eingestellten Raster mit den Cursortasten zu verschieben. Diptrace kann das.
Hallo X4U. X4U schrieb: > Wie oft kommt das dann noch vor? In der Regel nimmt man gleich ein > anderes Bauteil weil sonst keiner mehr durchblickt und der "Pfleger" > sich auch erstmal an einem Flohzirkus probieren sollte. In der Praxis pflegt man seine EIGENE Bibliothek, und schaut sich in der offiziellen Bibliothek nur um, wenn man etwas neues braucht. Wie eigentlich bei jeder anderen Layout Software auch. Den Austausch von Footprints empfinde ich nicht so als große Schwierigkeit. ;O) > >> >> Und dann kommt KiCad halt einigen Arbeitsstilen besser entgegen als >> anderen. Mir lag KiCad damals 2009 auf Anhieb, aber es gibt wohl auch >> Fälle wo das anders ist. > > Eben und das gute alte Zeichenbrett und Letraset in 4:1 ist haptisch > auch durch nichts zu ersetzen. Das sind für mich Nullaussagen. Tut mir leid für Dich, aber das wird Dir dann halt auch niemand sagen können. Ob das Deinem Arbeitsstil entspricht, must du selber ausprobieren. das kann niemand anderes für Dich tun. Falls du erwartest, dass solche Vorhersagen für Dich funktionieren, wird KiCad wohl eher nichts für Dich sein. Du erwartest eben ein "Schema F" wie in management Kursen gepredigt, und das bietet "real live" und pen Source eben immer nur bedingt. Du solltest schon eine gewisse Begabung und auch Spass daran haben, neben der Spur zu denken, sonst wird das nichts. Lass es also besser, Du bist zu unflexibel. Das kann ich gut verstehen, geht mir im Prinzip ja auch so. Ich bin auch ein alter Mann. > Ich muss auch C++ Grundlagen lernen weil eagle nun mal anders nicht zu > proggen ist. Mach ich das halt, wenn Autodesk zu dreist wird lerne ich > Kicad oder irgendwas anderes. Mir doch egal. Ich glaube nicht, dass Dir das wirklich egal ist. Sonst würdest Du hier nicht fragen sondern selber probieren bzw. konkreter fragen, wenn Du beim Probieren vor irgendein Problem gelaufen bist. Aber vermutlich kann Autodesk sehr dreist werden, bevor Du wirklich die Konsequenzen ziehst. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
mark space schrieb: > Das "hello world"-pendant als pcb-layout - könnte sein 1 LED, 1 > Vorwiderstand 1 Schalter und eine 2-polige Anschlussklemme für die > Spannungsversorgung. Ich hatte zwar etwas ähnliches im Sinn, es kann aber der Standard sein. Wenn man das bis zum Gerber durchzieht, schafft man auch den Rest. Im TV gibt es ja genug Wett-Kochen. Könnte man da nicht auch mal Wett-Layout machen? Gut, ich sehe es ein, es wäre nicht sehr attraktiv.
Ich habe inzwischen einige Programme in den letzten 30 Jahren getestet oder sogar mit gearbeitet. Caddy, Autocad, Orcad, Beckercad, Target, ... Meine eindrücke der letzten Jahre (günstige Software): EAGLE (< Ver 7 ): Ist super einfach und für 90% der Fälle ausreichend. KiCAD: Sehr gewöhnungsbedürftige Arbeitsweise, aber auch nicht schlecht wenn man sich mühsam eingearbeitet hat. Horizon: Könnte der neue TOP Opensource CAD Killer sein. Macht bis jetzt auf mich einen besseren Eindruck wie KiCAD, dabei ist das Teil noch kein Jahr alt. Wenn das so weiter geht dann redet in einem weiteren Jahr keiner mehr über die anderen Programme, weil zu schlecht.
Hallo guido. Guido B. schrieb: > Ok X4U, für dich gehe ich das halt nochmal durch. Eigentlich wurde das > schon etliche Male besprochen, aber dann kommt wieder ein Hans Wurst > mit falschen Behauptungen. Das hat System: https://de.wikipedia.org/wiki/Postfaktische_Politik >> - Automatische rechtwinklige Ausrichtung der Verbindungen am Raster -> >> keine Luftlinienverbindungen. > Natürlich, wie denn sonst. Achso diagonal geht auch, ist das zuviel? Ihn stört, dass man im Schaltplan beim "drag" die Linien schräg werden, statt in rechtwinkliger Anordnung zu bleiben. Ich habe sowas schonmal gesehen. Vorteil: Es spart ein wenig Zeit, wenn man die Verbindungen nicht neu rechtwinklig geraderücken muss. Das ist aber auch nur ein halber Vorteil, weil meistens ist sowieso mehr neu anzuordnen, um die Übersichtlichkeit zu waren, und nicht nur damit es für den Cheff professionell aussieht. > >> - Selektieren von Leiterbahnen und Verbindungen nicht nur in den >> Eckpunkten > Wozu sollten diese selektiert werden? Man kann die Leiterbahnsegmente überall "fassen". Es langt, sie rechts anzuklicken und dann gegebenenfalls näher aus einer Liste zu wählen. Die "move" und "drag" Optionen betreffen immer das komplette Segment. Parametrisch lassen sich aber auch einzelne endpunkte versetzten. Im "legacy Canvas" hat man mit "break track" auch noch eine Möglichkeit, neue "Endpunkte" für Tracks einzusetzten. Im "openGL canvas" arbeitet man sowieso ganz anders.......;O) "selektieren" macht durchaus Sinn, wenn man komplett fertiggeroutete Blöcke auf eine andere Position bringen will. Bei mehreren gleichartigen Blöcken macht auch ein Kopieren des selektierten Blocks Sinn.....allerdings sollte man in diesem Fall die neuen Referenzbezeichner von Hand vergeben. Allerdings funktioniert das selektieren recht gut "legacy Canvas". Im "openGL canvas" ist das komplizierter. Ein Linksklick selektiert sofort das nächstgelegene Objekt. Eine gruppe lässt sich nur selektieren, wenn man weit genug von allen Objekten eine Box aufzieht....es macht also Sinn, je nach Anwendungsfall zwischen den canvassen zu wechseln. >> - Kein Rumgehopse des Maus-Cursors beim öffnen eines Menüs. > Das gibt es nicht. Richtig. Das muss ein vorübergehendes Problem vom Anfang dieses Jahrzehnts gewesen sein. Siehe oben den Hinweis auf "postfaktisch" Meine Ausführungen bereffen ein kicad Version: (2017-06-16 revision dab73e1)-master, release build. Es gibt aber viel aktuellere...... Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Klaus schrieb: > Horizon: > Könnte der neue TOP Opensource CAD Killer sein. > Macht bis jetzt auf mich einen besseren Eindruck wie KiCAD, dabei ist > das Teil noch kein Jahr alt. Wenn das so weiter geht dann redet in einem > weiteren Jahr keiner mehr über die anderen Programme, weil zu schlecht. Da lehnst du dich ganz schön übers Geländer :-( Die Werbetrommel rühren ist ja gut und recht, dick auftragen geht ja auch noch aber es sollte glaubwürdig rüber kommen. So wird es höchstens ein Festschmaus für die Trolle.
Bernd W. schrieb: > Ich bin auch ein alter Mann. Na, na - andere Männer in deinem Alter konnen noch einen ganzen Harem 'betreuen' ;-)
Bernd W. schrieb: > Ihn stört, dass man im Schaltplan beim "drag" die Linien > schräg werden, statt in rechtwinkliger Anordnung zu bleiben. Das ist ja auch bekloppt. Zumindest in den (häufigen) Fällen, in denen es der Computer selbsttätig besser machen kann, könnte er es doch auch tun. Wenn dann noch ein paar übrigbleiben, in denen das nicht geht, dann ist das eben so. Noch schlimmer ist die Eigenart von gschem, Netze auseinander- zureissen. Da kann ich ja gleich CorelDraw nehmen, um den Schaltplan zu malen. > Vorteil: Es spart ein wenig Zeit, wenn man die Verbindungen > nicht neu rechtwinklig geraderücken muss. Nicht nur das. Ich sehe einen eindeutigen Zusammenhang zwischen der unter- irdischen Qualität vieler Schaltpläne, die hier so veröffentlicht werden, und der Qualität der Schaltplaneditoren. Wenn die Gefahr besteht, dass man beim Verschönern wieder neue Fehler in den Schaltplan hineinbringt, dann unterlässt man das Verschönern eben -- und so sehen die Pläne dann auch aus. > Das ist aber auch nur ein halber Vorteil, weil meistens ist > sowieso mehr neu anzuordnen, um die Übersichtlichkeit zu > waren, und nicht nur damit es für den Cheff professionell > aussieht. Merkwürdiges Argument. Auch eine kleine Steigerung des Bediencomforts ist es doch wert, implementiert zu werden.
Klaus schrieb: > [horizon] Könnte der neue TOP Opensource CAD Killer sein. > Macht bis jetzt auf mich einen besseren Eindruck wie KiCAD, > dabei ist das Teil noch kein Jahr alt. Wenn das so weiter > geht dann redet in einem weiteren Jahr keiner mehr über > die anderen Programme, weil zu schlecht. Softwarequalität hat mehr Aspekte als nur die Funktionalität.
Bernd W. schrieb: > Wo das aber eine openGL Unterstützung gut funktioniert, ist KiCad sehr > geschmeidig. Jup, wesentlich performanter als der Uralt-Modus ... Insbesondere wenn man große Baugruppen rumschieben muss. Die Selektion im OpenGL-Modus ist auch wesentlich besser ... Man kann nicht nur ein Rechteck aufziehen wie im alten Modus schon, sondern kann mit dem üblichen STRG+Click auch noch zusätzlich zur Selektion noch weitere einzelne Bauteile selektieren. Man kann Liniensegmente anklicken und besser bearbeiten - das war im alten Modus der Horror. Die Bauteile und Liniensegmente rasten schön am Grid ein und man kann die Eckpunkte mit der Maus ziehen usw ... Wenn man den Layer wechselt wird der aktuelle Layer über den anderen angezeigt ... Den Push&Shove zB gibt es nur im neuen Modus und den Längenausgleich oder differentielles Routing auch. Viele viele Verbesserungen :) Seh ich aber auch so, dass KiCad sich keinen großen Gefallen tut, erstmal per default den alten Modus anzubieten.
:
Bearbeitet durch User
Hallo Possetitjel. Possetitjel schrieb: >> Ihn stört, dass man im Schaltplan beim "drag" die Linien >> schräg werden, statt in rechtwinkliger Anordnung zu bleiben. > > Das ist ja auch bekloppt. > Zumindest in den (häufigen) Fällen, in denen es der Computer > selbsttätig besser machen kann, könnte er es doch auch tun. > Wenn dann noch ein paar übrigbleiben, in denen das nicht geht, > dann ist das eben so. Schlimmer finde ich bei Modi, wo die Linien rechtwinklig bleiben die Fälle, wo verschobene Linien dann direkt übereinander liegen. Das wird schnell übersehen und dann nicht berichtigt. Und als Servicetechniker, der später in einen Ausdruck schaut, habe ich dann ein Problem, den Matsch zu entschlüsseln. Dann lieber schräg. Das fällt wenigstens auf. ;O) > > Noch schlimmer ist die Eigenart von gschem, Netze auseinander- > zureissen. Da kann ich ja gleich CorelDraw nehmen, um den > Schaltplan zu malen. Du verwechselst move und drag. Bei "move" ist ja das Abreissen intentionell, bei "drag" nicht. >> Das ist aber auch nur ein halber Vorteil, weil meistens ist >> sowieso mehr neu anzuordnen, um die Übersichtlichkeit zu >> waren, und nicht nur damit es für den Cheff professionell >> aussieht. > > Merkwürdiges Argument. > Auch eine kleine Steigerung des Bediencomforts ist es doch > wert, implementiert zu werden. In dem Falle ist das aber sehr wenig. Und wenn man übersieht, das Linien übereinanderliegen...siehe oben. Es gab wohl Orcad Varianten, wo das notorisch war. Wenn man es also einführt, sollte man es optional auch abschalten können. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Warum benutzt Kicad denn OpenGL erst neuerdings? Das gabs doch schon zu Win98 Zeiten und ist vermutlich programmatisch einfacher zu bedienen als ältere Grafikschnittstellen.
Abdul K. schrieb: > Warum benutzt Kicad denn OpenGL erst neuerdings? Ach erstaunlich ... In den Release-Notes von Nov 2015 (Version 4.0.0) hies es: > New graphics rendering backend GAL (OpenGL and Cairo) [currently pcbnew > only and does not yet support all legacy tools] Wusste nicht, dass der Modus so neu ist :)
:
Bearbeitet durch User
Zwei Jahre sind nun auch nicht so lang. Konkretisiert müßte man ja sagen, ist Kicad aus dem Jahr 1998 ?
Abdul K. schrieb: > Warum benutzt Kicad denn OpenGL erst neuerdings? Das gabs doch schon zu > Win98 Zeiten und ist vermutlich programmatisch einfacher zu bedienen als > ältere Grafikschnittstellen. Seit wann unterstützt Eagle dieses? Scheint doch nicht so einfach zu sein. Bernd W. schrieb: > Schlimmer finde ich bei Modi, wo die Linien rechtwinklig bleiben die > Fälle, wo verschobene Linien dann direkt übereinander liegen. Eben, man bräuchte ja für sowas einen Autorouter für den Schaltplan. Kann man sich natürlich wünschen, ist aber nicht ganz trivial.
Possetitjel schrieb: > Noch schlimmer ist die Eigenart von gschem, Netze auseinander- > zureissen. Da kann ich ja gleich CorelDraw nehmen, um den > Schaltplan zu malen. Machen !! Possetitjel schrieb: > Nicht nur das. > Ich sehe einen eindeutigen Zusammenhang zwischen der unter- > irdischen Qualität vieler Schaltpläne, die hier so veröffentlicht > werden, und der Qualität der Schaltplaneditoren. Schwachsinn hoch 3. Das hat was mit Handschrift, struktuierten Denken, Origanisation zu tun aber nicht mit den Editoren ! Mann o Mann deine Probleme möchte ich haben. Ich frage mich schon die ganze Zeit bist du dem W.S. sein Bruder :-(
Guido B. schrieb: > Abdul K. schrieb: >> Warum benutzt Kicad denn OpenGL erst neuerdings? Das gabs doch schon zu >> Win98 Zeiten und ist vermutlich programmatisch einfacher zu bedienen als >> ältere Grafikschnittstellen. > > Seit wann unterstützt Eagle dieses? Scheint doch nicht so einfach zu > sein. > Es geht um Kicad. Wieso fängst du mit Eagle an? Eagle ist uralt. Deutlich älter als Win98 (Wo laut Wiki OpenGL von MS eingeführt wurde). Ich habe das grauselige Eagle so ca. 1992 mal verwenden müssen. Da lief es noch als DOS-Programm und ich kam vom Mac. Also Kulturschock. > Bernd W. schrieb: >> Schlimmer finde ich bei Modi, wo die Linien rechtwinklig bleiben die >> Fälle, wo verschobene Linien dann direkt übereinander liegen. > > Eben, man bräuchte ja für sowas einen Autorouter für den Schaltplan. > Kann man sich natürlich wünschen, ist aber nicht ganz trivial. Das ist ne interessante Idee!! Wirklich, bravo! Wieso kam noch nie jemand auf die Idee. So 30 Adressleitungen routen äh schemen ist doch nix anderes.
@il Conte & @Klaus Auf der einen Seite finde ich auch das Horizon noch nicht soweit ist um es ernsthaft einzusetzen und das Klaus etwas zu früh die Werbetrommel schlägt. ABER ich habe es auch getestet und muss auch sagen das da viel potenzial drin steckt und das in der kürze der Zeit was tolles entstanden ist. Und vielleicht werden wir alle noch überrascht und selbst Klaus hat zu tief gestappelt, warten wir mal ab. Wenn es da so weiter geht dann werde ich es mal für ein kleines Projekt benutzen, aber bis dahin bleibe ich bei KiCAD. VG, Uli
Moin, Erstaunlich, dass die Punkte, die mir derzeit an KiCad negativ auffallen, hier so gut wie keine Erwaehnung finden. Das aender ich jetzt mal: * Busse : Fuer mich grad ein Totalausfall. Durch die Benamungsvorschriften (alle Mitglieder muessen gleich heissen und duerfen sich nur durch die Nummer am Ende unterscheiden) sind in der Praxis unschoene Hacks zu erwarten, bzw. es ist komplett unmoeglich, Busse mit differentiellen Signalen zu haben. * Einzelne Durchkontaktierungen - Stichwort: Via-Stitching. Geht zwar irgendwie mit Haengen und Wuergen, und vieel Geklicke. Aber schoen ist anders. Vias, die auf Innenlagen keine Pads haben sollen, gehen hoechstens, wenn man mit einem Texteditor in den entsprechenden Files editiert und dann jaa nicht mehr mit dem Footprinteditor anfasst. * Unterlagen fuer die Fertigung/Serviceunterlagen: OK, Gerber kommt raus. Schon mal sehr schoen. Aber wie kriegt man denn ein Position-File nur fuer die THT Komponenten? Bei den Footprint properties nur die drei Moeglichkeiten sind schon bissl - hm - willkuerlich. Virtual ist zwar schon ganz toll fuer z.B. Testpads. Die tauchen aber natuerlich trotzdem in der BOM (aus eeschem) als eigene Bauteile auf und duerfen dann haendisch wieder rausgepopelt werden. Wie kriegt man Bestueckungsplaene als pdf, die man auch schwarzweiss ausgedruckt lesen kann? In denen verschiedene Kicadlayer in verschiedenen Grautoenen erscheinen (z.b. die Pads in ziemlich hellgrau, die Schriften komplett Schwarz) ohne dafuer extra an den Darstellungen auf m Bildschirm rumpopeln zu muessen (und nach dem Ausdruck wieder retour)? Oder gar Bestueckungsplaene getrennt nach SMD und THT? Fuer was ist das BOM-File ausm PCBNew gut? Da taucht dann jedes (Stitching)Via drinnen auf, jeder Testpunkt, obwohl der Footprint als "Virtual" gekennzeichnet ist. Dafuer keine weiteren Infos mehr zu Bestellnummern, o.ae, was in in EESchema noch vorliegt. Kann man die Erstellung des BOM-Files auch irgendwie beeinflussen, so wie die BOM in EESchema? Hab' nicht gefunden wo/wie. So, erstmal genug genoergelt. Mahlzeit ;-) Gruss WK
Guido B. schrieb: > Hans Wurst schrieb: >> - Das Highlighten selektierter Elemente > Wozu? Selektiert wird durch das Aufziehen eines Rechtecks, alles was > drin ist wird (auf Nachfrage wo nötig) selektiert. ... Danke für die Antworten, lese ich so das die Einwände übertrieben sind. Bernd W. schrieb: > Den Austausch von Footprints empfinde ich nicht so als große > Schwierigkeit. ;O) Hallo erstmal und danke für die Stellungnahme. Mit Footprints sehe ich die Probleme eben auch nicht. Bernd W. schrieb: > Tut mir leid für Dich, aber das wird Dir dann halt auch niemand sagen > können. Ob das Deinem Arbeitsstil entspricht, must du selber > ausprobieren. das kann niemand anderes für Dich tun. Schon klar, schwer zu delegieren ;-). > > Falls du erwartest, dass solche Vorhersagen für Dich funktionieren, wird > KiCad wohl eher nichts für Dich sein. Du erwartest eben ein "Schema F" Nein ich schaue mich um und Nutze solche Diskussionen um einen Eindruck zu bekommen. Ich kann nicht alle Produkte durchtesten ob Sie mir passen. Bernd W. schrieb: > Du erwartest eben ein "Schema F" > wie in management Kursen gepredigt, und das bietet "real live" und pen > Source eben immer nur bedingt. Du solltest schon eine gewisse Begabung > und auch Spass daran haben, neben der Spur zu denken, sonst wird das > nichts. Daraus entnehme ich das KiCad mehr voraussetzt als z.B. Diptrace (was ja out of the Box funzt). > Das kann ich gut > verstehen, geht mir im Prinzip ja auch so. Ich bin auch ein alter Mann. Meine Zeit ist begrenzt und die EDA Welt läuft für mich nebenbei. PCB Layout ist ein Werkzeug wie ein Hammer oder Mcad oder meinetwegen auch ein Textprogramm. Mir ist es einfach egal welches ich nutze und von den KiCad Leuten war ich auch noch mit keinem ein Bier trinken ( da gibt es übrigens auch sonst niemanden der das Wort Leiterplatten kennt). Bernd W. schrieb: > Aber vermutlich kann Autodesk sehr dreist werden, bevor Du wirklich die > Konsequenzen ziehst. Natürlich, warum sollte ich wechseln nur weil die auf einmal eine Miete haben wollen? Das finde ich eher fair und ich habe jetzt schlicht mehr Möglichkeiten als vorher. Das Sie darauf umgestellt haben und nur dafür auch noch Geld haben wollten ist die Dreistigkeit die mich veranlasst andere Programme anzuschauen. Aber Kicad ist nicht allein auf der Welt. Angenommen alle Programme die ich mir angeschaut habe würden den Preis von Eagle kosten. Altium und Cadstar würde ich sofort eagle evtl und KiCad und Diptrace nicht kaufen. So sieht es aus.
Dergute W. schrieb: > Erstaunlich, dass die Punkte, die mir derzeit an KiCad negativ > auffallen, hier so gut wie keine Erwaehnung finden. Dem würde ich übrigens weitgehend zustimmen. Bei den Vias behelfe ich mir damit, dass ich sie im Schaltplan als tatsächliche Bauteile anlege, ist für Hobby sicher OK, aber in einer BOM wird man die nicht haben wollen. :) Das Bus-Konzept finde ich einfach ärgerlich. Hab' mich aber auch noch nicht aufraffen können, mal zu schauen, wieviel Aufwand es bräuchte, das vom Kopf auf die Füße zu stellen.
Abdul K. schrieb: > Ich habe das grauselige Eagle so ca. 1992 mal verwenden müssen. Da lief > es noch als DOS-Programm und ich kam vom Mac. Also Kulturschock. Na wenn das dein letzter Stand ist dann bist du ja ein "kompetenter Gesprächspartner" ;-).
Uli schrieb: > Und vielleicht werden wir alle noch überrascht und selbst Klaus hat zu > tief gestappelt, warten wir mal ab. Du sagt es! Wie viel Leute machen am 'Horizon' Projekt eigentlich mit? Damit das was wird müssen da gefühlt 100 Leute ran, des Weiteren braucht es einen 'potenten' Sponsor (alla CERN) Und am wichtigsten es muss über Features besitzen die den Nutzen des Anwenders wesentlich steigern . Objektiv betrachtet wird es so laufen dass ab einen Projektstaus von ca.. 80% bis 90% Reife der Enthusiasmus nachlässt weil es dann steinig und mühselig wird. Das Projekt wird zwar nicht beerdigt aber es wird versanden Das liegt auch daran dass die Konkurrenz nicht schläft, immer besser wird und dadurch die Hürden für einem selber höher werden.
Jörg W. schrieb: > Dem würde ich übrigens weitgehend zustimmen. Bei den Vias behelfe > ich mir damit, dass ich sie im Schaltplan als tatsächliche Bauteile > anlege, ist für Hobby sicher OK, aber in einer BOM wird man die nicht > haben wollen. :) Man benötigt nur einen Via-Footprint ... Den platziert man einmal im Layout und edit den Netznamen auf GND (geht über Edit Pin) Dann dupliziert man es so oft, wie man es haben möchte und verschiebt sie dort hin, wo sie sitzen sollen. Einziges kleines Manko ... Man sollte überschüssige Bauteile beim Netzliste einlesen nicht löschen ... Aber in der Regel stitcht man ja eh ganz zum Schluss.
:
Bearbeitet durch User
Ich habe genug Ärger mit Eagle damals gehabt, bin dann auf RUN-EDS umgestiege mit BAE drin. Das kostete halt auch Faktor 10 oder so mehr. Die Firma hat das bezahlt. In Anbetracht der Arbeitszeitkosten ist der Preis des Programms auch eher sekundär. Hier sieht man ein Layout mit diesem Programm: Beitrag "Re: Gibt es brauchbare, freie/billige Software um PCB zu erstellen?" Aktuell sichte ich die Lage, da ich umsteigen möchte.
il Conte schrieb: > Damit das was wird müssen da gefühlt 100 Leute ran, > des Weiteren braucht es einen 'potenten' Sponsor (alla CERN) sagt wer? > Und am wichtigsten es muss über Features besitzen die den Nutzen des > Anwenders wesentlich steigern . Ich habe den Eindruck, dass das bereits jetzt der Fall ist, da es noch lange nicht fertig ist.
Ich denke er hat bei Horizon sich ne elegante Struktur ausgedacht. Umso effektiver man das macht, umso wenige muß man coden. Schlechte Struktur heißt, daß man überall Ausnahmen abfangen muß aka Zeit verschwendet. Das ist der wesentliche Unterschied zwischen guter und schlechter Software. Also momentan ist es schon erstaunlich. Oder vielleicht nur ein Werbeprospekt für seinen nächsten Arbeitgeber?
Dergute W. schrieb: > Moin, > > Erstaunlich, dass die Punkte, die mir derzeit an KiCad negativ > auffallen, hier so gut wie keine Erwaehnung finden. Das aender ich jetzt > mal: Du nörgelst hier rum - wieso eigentlich? Irgendwie kommt es mir vor als ob du dir kein CADENCE leisten kannst, verlangst aber nun, dass ein OS KiCad dass alles können muss. Deine 'Sternchen' Aufzählungen ist alles nur Wirbel um nichts! Mit etwas Kreativität kann man das alles leicht umschiffen.
Jörg W. schrieb: > Ich habe den Eindruck, dass das bereits jetzt der Fall ist, da es > noch lange nicht fertig ist. Dann zähle es bitte mal auf. (das interessiert bestimmt nicht nur mich) Aber wie gesagt es muss einem vom Hocker reisen! Behaupten kann jeder :-(
Abdul K. schrieb: > Ich habe genug Ärger mit Eagle damals gehabt, bin dann auf RUN-EDS > umgestiege mit BAE drin. Das kostete halt auch Faktor 10 oder so mehr. Wenn du in der Liga gearbeitet hast dann wird die Luft unter der Altium Cadstar (evtl. noch OrCad) .. Liga dünne. Abdul K. schrieb: > Hier sieht man ein Layout mit diesem Programm: So ein Layout würde ich mit eagle nur machen wenn es nicht anders geht. Obwohl oder gerade weil ich damit so lange arbeite. Braucht einfach zu lange. Wer das mit KiCad probiert ... . Mein Eindruck ist das es da auch eher nicht das Tool für ist. Jörg W. schrieb: > Dergute W. schrieb: >> Erstaunlich, dass die Punkte, die mir derzeit an KiCad negativ >> auffallen, hier so gut wie keine Erwaehnung finden. > > Dem würde ich übrigens weitgehend zustimmen. Ok, das ist doch mal ne Aussage. Nichts gegen KiCad, eine tolle Sache. Ein OSS Projekt ist auch nicht dazu da das die Crew ein Produkt erstellt was im Produktiveinsatz mit gekaufter Software konkurrieren soll. Aber solche Aussagen sind einfach ehrlich und man kann einen Eindruck bekommen ohne das ganze wochenlang zu testen. il Conte schrieb: > Du nörgelst hier rum - wieso eigentlich? Gegenfrage: Warum wirst du persönlich wenn andere sachliche Einwände bringen?
Ich glaube Horizon ist eine 1 Man Show, bis jetzt. Was daraus wird mussen wir abwarten. VG, Uli
X4U schrieb: > il Conte schrieb: >> Du nörgelst hier rum - wieso eigentlich? > > Gegenfrage: Warum wirst du persönlich wenn andere sachliche Einwände > bringen? deshalb : Dergute W. schrieb: > So, erstmal genug genoergelt. Mahlzeit ;-)
Uli schrieb: > Ich glaube Horizon ist eine 1 Man Show, bis jetzt. Das ist genau meine Einschätzung. Nochmals ich habe nichts gegen diesen Mann; im Gegenteil ich bewundere dem seine Energie, Ausdauer und Enthusiasmus. Meine persönliche Meinung dazu ist: Man kann sowas viel 'gewinnbringender' einsetzen als hier, um nicht am Ende dann desillusioniert zu werden.
il Conte schrieb: > Jörg W. schrieb: >> Ich habe den Eindruck, dass das bereits jetzt der Fall ist, da es >> noch lange nicht fertig ist. > > Dann zähle es bitte mal auf. Nein, schau doch einfach im Nachbarthread vorbei. Der hier ist für Kicad da. Btw., du warst es, der Behauptungen in die Runde geworfen hat … X4U schrieb: > Ein OSS Projekt ist auch nicht dazu da das die Crew ein Produkt erstellt > was im Produktiveinsatz mit gekaufter Software konkurrieren soll. Sehe ich anders, aber auch bei gekaufter Software ist nicht immer alles so toll.
X4U schrieb: > So ein Layout würde ich mit eagle nur machen wenn es nicht anders geht. > Obwohl oder gerade weil ich damit so lange arbeite. Braucht einfach zu > lange. > > Wer das mit KiCad probiert ... . Mein Eindruck ist das es da auch eher > nicht das Tool für ist. Hast du das schon mal probiert? Ich denke nicht. Das hier angesprochene Layout (vemutlich mit 6 Lagen) stellt mit den heutigen Möglichkeiten von KiCad ( P&S )absulut kein Problem dar.
4 Signallagen und 2 Powerplanes. Die Frage ist doch, wie lange brauch man? Wenn ich mich recht erinnere, waren es 250h fürs Layout. Den PCMCIA-Controller mit dem PCMCIA-Slot zu verbinden war einfach abartig kompliziert. Meine Meinung zu PCMCIA ist deswegen, der Steckverbinder ist großer Mist. Und dann war ich ja ein junger Hüpfer. Man beachte die Details, wie die vergrößerten Leiterbahnen an den Steckern. Heute würde ich das Projekt ganz anders aufziehen. Hach, da war ja damals das Erdbeben. Die Tür schwangte auf einmal nachts. gruselig. Tagsüber Studium, nachts Layout. Technisch sehe ich kein Problem das mit einem aktuellen Layoutprogramm zu realisieren.
Abdul K. schrieb: > Heute würde ich das Projekt ganz anders aufziehen. Wahrscheinlich 2 Lagen mehr spendieren und in der Hälfte der Zeit damit fertig werden.
Abdul K. schrieb: > Man beachte die Details, wie die vergrößerten Leiterbahnen an den > Steckern. Spätere BAE-Versionen hätten dir die “teardrops” automatisch erzeugen können. ;-) Hat Kicad eigentlich einen Teardrop-Automatismus (um mal wieder auf das Thema des Threads zurückzukommen)?
Nur der Autorouter war von Bartels. RUN-EDS starb so ca. 2001. Der Autorouter hatte hier versagt ;-) Ja, die Lagen, also es war schon ein Akt zu sagen es werden 6 Lagen. 8 hätte mich das Projekt gekostet. Den Job nicht, hatte noch andere Aufgaben.
Gibts eigentlich ne große Übersicht über Features der aktuellen Programme in eine halbwegs aktuellen Aufstellung? Damit mich Jörg nicht löscht.
Jörg W. schrieb: > Hat Kicad eigentlich einen Teardrop-Automatismus (um mal wieder auf > das Thema des Threads zurückzukommen)? KiCad ist was worüber man sich freut und nicht weint, dass einem die 'Teardrops' kommen ;-) Mal ne Gegenfrage: Wird eigentlich BAE noch weiter gepflegt und ist es auf dem Stand der Zeit?
il Conte schrieb: >> Hat Kicad eigentlich einen Teardrop-Automatismus (um mal wieder auf >> das Thema des Threads zurückzukommen)? > > KiCad ist was worüber man sich freut und nicht weint, > dass einem die 'Teardrops' kommen ;-) Hilft mir unwahrscheinlich weiter … > Mal ne Gegenfrage: > Wird eigentlich BAE noch weiter gepflegt und ist es auf dem Stand der > Zeit? Scheint nicht so, aber hier soll's ja um Kicad gehen. Ich benutze BAE praktisch mittlerweile nicht mehr, wenngleich ich dem Autorouter schon hinterher trauere. Am liebsten würde ich ihn als Backend in andere Programme integrieren, schließlich habe ich ja 'ne Lizenz dafür. Den gibt es sogar es separates Binary ("neurrut"), aber man müsste dann BAE-Dokumente (deren eigenes SQL-Format) erzeugen und lesen können, denn darauf setzt neurrut auf.
Mampf F. schrieb: > Jörg W. schrieb: >> Dem würde ich übrigens weitgehend zustimmen. Bei den Vias behelfe >> ich mir damit, dass ich sie im Schaltplan als tatsächliche Bauteile >> anlege, ist für Hobby sicher OK, aber in einer BOM wird man die nicht >> haben wollen. :) > > Man benötigt nur einen Via-Footprint ... Den platziert man einmal im > Layout und edit den Netznamen auf GND (geht über Edit Pin) > > Dann dupliziert man es so oft, wie man es haben möchte und verschiebt > sie dort hin, wo sie sitzen sollen. > > Einziges kleines Manko ... Man sollte überschüssige Bauteile beim > Netzliste einlesen nicht löschen ... Aber in der Regel stitcht man ja eh > ganz zum Schluss. 1. Du klickst auf "Leiterbahnen und DuKos hinzufügen". 2. Du startest die Leiterbahn da, wo du deine DuKo haben willst. 3. Du drückst "v". 4. Du klickst nochmal auf den selben Startpunkt. 5. ??? 6. Du hast eine DuKo, wo du sie haben wolltest. mfg
Ich weiß, dass es Krücken gibt, das zu machen, aber wie schon geschrieben worden ist: schön wäre was anderes.
Jörg W. schrieb: > Hat Kicad eigentlich einen Teardrop-Automatismus (um mal wieder auf > das Thema des Threads zurückzukommen)? So viel ich weiß nicht, aber ehrlich ich vermisse es auch nicht. Mir ist noch keine PCB untergekommen die wegen fehlenden Teardrops nicht funktioniert hat. Wenn ich mich richtig entsinne hat das was mit Unteräzung bei der Herstellung zu tun. Die Fertiger haben das heute doch alle im Griff und bestimmt auch die Chinesen. Ich denke mal dass das eher ein Thema für die 'Küchenätzer' ist
il Conte schrieb: > Wenn ich mich richtig entsinne hat das was mit Unteräzung bei der > Herstellung zu tun. Durchaus auch was mit mechanischer Festigkeit. Wenn ich ein massives Bauteil (wie einen Steckverbinder) an die heute üblichen dünnen Leiterbahnen (125 µm gibt's ja inzwischen „von der Stange“) hänge, dann ergibt sich da schnell eine Sollbruchstelle. Der Teardrop verhindert das. https://en.wikipedia.org/wiki/Teardrop_(electronics)
Abdul K. schrieb: >> Bernd W. schrieb: >>> Schlimmer finde ich bei Modi, wo die Linien rechtwinklig bleiben die >>> Fälle, wo verschobene Linien dann direkt übereinander liegen. >> >> Eben, man bräuchte ja für sowas einen Autorouter für den Schaltplan. >> Kann man sich natürlich wünschen, ist aber nicht ganz trivial. > > Das ist ne interessante Idee!! Wirklich, bravo! Wieso kam noch nie > jemand auf die Idee. So 30 Adressleitungen routen äh schemen ist doch > nix anderes. Warum noch niemand auf die Idee kam einen Autorouter für Schaltplaneditoren zu schreiben? Du meinst vermutlich ein Tool, dass einem die lästige Arbeit der sinnvollen Anordnung aller Schaltplanzeichen mitsamt des Verbindens derselben untereinander abnimmt? Vermutlich weil so ein vom "Robot" gerouteter Schaltplan dann alles andere als schön und lesbar wäre, sondern eher so wie beim Layout, nämlich optimiert auf dicht gepackt, um (Platinen-) Platz zu sparen. Genau das will man aber nicht haben als (generell) jemand, der aus dem Schaltplan auch die Funktion der Schaltung schnell begreifen möchte. Abgesehen davon müsste man dazu die Verbindungen bereits als Netzliste vorliegen haben. OK, könnte man z.B. von LTSpice übernehmen. Nur hat LTSpice wiederum nicht alle Informationen, die der spätere Schaltplan beinhaltet, z.B. Klemmen o.ä. Wäre es allgemein nicht besser, bevor man solche vermeintlich tollen Features anpreist, sich der wirklich verbesserungswürdigen Details zu widmen? Wir sollten uns man von dem Gedanken trennen, dass Entwickler-Kapazität bzw. -Zeit grundsätzlich in beliebiger Höhe verfügbar ist, sondern generell eher eng begrenzt ist. Beispielsweise ist die aktuelle Version von Sprint Layout nun schon 7 Jahre alt. Zwar werden immer wieder kleinere Updates vorgenommen und wohl auch Kleinigkeiten durch Hinzufügen verbessert, aber dennoch ist die SW versionsmäßig selber schon vergleichsweise alt und Abacom ist keine Hobbyfirma, die SW nebenbei in ihrer Freizeit entwickelt im Gegensatz zu Horizon. Es braucht also erfahrungsgemäß eher Jahre, bis eine EDA Software überhaupt soweit ist als halbwegs angenehm und brauchbar eingeschätzt UND AUCH vom Benutzer AKZEPTIERT zu werden. Bei eagle war bzw. ist das ähnlich. Es ist kaum wirklich Neues hinzugekommen über die letzten Jahre bei eagle.
Felix F. schrieb: > 1. Du klickst auf "Leiterbahnen und DuKos hinzufügen". > 2. Du startest die Leiterbahn da, wo du deine DuKo haben willst. > 3. Du drückst "v". > 4. Du klickst nochmal auf den selben Startpunkt. > 5. ??? > 6. Du hast eine DuKo, wo du sie haben wolltest. Tut mir leid, das genügt meinen ästhetischen Ansprüchen nicht ... Wenn ich die Massefüllung ausschalte sieht das ja gottfürchterlich aus ... Das kann ich mit mir nicht vereinbaren :)
Entweder der Hersteller verliert die Lust oder es wird sogar irgendwann fertig. Ja, fertig. Soll es geben, also alle sinnvollen Features drin und praktisch alle Bugs raus. Ich sehe keinen fundamentalen Unterschied zwischen Schaltplan und Layout. Für beides könnte man Automatismen der gehobenen Art realisieren. Ein Schnittstelle z.B. zu LTspice ist nett, aber man macht sich dadurch abhängig vom Austauschformat und muß eventuell sogar zugeben, daß andere gute oder gar bessere Programme schreiben. Typischerweise sind die Projekte in SPICE auch keine vollständigen Schaltpläne. Soweit sind wir noch nicht. Vielleicht in 30 Jahren.
Abdul K. schrieb: > Typischerweise sind die Projekte in SPICE auch keine vollständigen > Schaltpläne. Soweit sind wir noch nicht. Vielleicht in 30 Jahren. Nö. Wir haben uns in den letzten Jahren eher davon weg bewegt, da praktisch jedes Stück Elektronik, welches komplexer ist als eine LED-Taschenlampe, irgendeine Form programmierbarer Logik enthält (Controller). Diese wiederum kannst du nur mit erheblichem Aufwand simulieren.
Jörg W. schrieb: > Der Teardrop Ich hab mir das im Wiki durchgelesen. Ich denke mal bei der heutigen Prozessicherheit der Hersteller ist das ganze eigentlich gegessen. Wenn ich beim Design mechanische Belastungen vermutet, muss man dem anders begegenen. Jörg W. schrieb: > Wenn ich ein massives > Bauteil (wie einen Steckverbinder) an die heute üblichen dünnen > Leiterbahnen (125 µm gibt's ja inzwischen „von der Stange“) hänge, > dann ergibt sich da schnell eine Sollbruchstelle. Sowas wird doch mechanisch vom durchkontaktierten Loch abgefangen. Bei SMD sind es die relativ grossen PADs. Da gibt es keine 'Sollbruchstellen'.
Abdul K. schrieb: > Ich sehe keinen fundamentalen Unterschied zwischen Schaltplan und > Layout. Für beides könnte man Automatismen der gehobenen Art > realisieren. Ja genau ... Neue pseudointelligente Algorithmen, die alles falsch machen ... Super Idee!
Kann uns doch egal sein, wir beide erleben es eh nicht mehr.
Teardrop ist schon nett, wenn man mal per Hand was tauschen will. Ich hatte die damals glaube ich eingebaut, weil der Leiterplattenhersteller oft an Anschlüssen unterbrochene Leiterbahnen lieferte. Naja, die Qualität war eh mau. Bin halt Perfektionist. So sind die Jumper auf obigen Board auch alle schön in einer Reihe am Platinenrand. Das Routen dieser Leitungen durchs Board ist natürlich schwierig. Kann ja mal ein Foto des Boards machen. Habe noch eines da.
Abdul K. schrieb: > Ich sehe keinen fundamentalen Unterschied zwischen Schaltplan und > Layout. Für beides könnte man Automatismen der gehobenen Art > realisieren. Ich sehe da schon einen fundamentalen Unterschied: (Autorouter erstelltes) Layout: dicht gepackt, auf Platz optimiert (manuell erstellter) Schaltplan: optisch ansprechend, auf Verständnis bzw. schnellen Überblick optimiert
il Conte schrieb: > Dergute W. schrieb: >> Moin, >> >> Erstaunlich, dass die Punkte, die mir derzeit an KiCad negativ >> auffallen, hier so gut wie keine Erwaehnung finden. Das aender ich jetzt >> mal: > > Du nörgelst hier rum - wieso eigentlich? > Irgendwie kommt es mir vor als ob du dir kein CADENCE leisten kannst, > verlangst aber nun, dass ein OS KiCad dass alles können muss. > > Deine 'Sternchen' Aufzählungen ist alles nur Wirbel um nichts! > Mit etwas Kreativität kann man das alles leicht umschiffen. Nö, er hat Recht, aber deswegen ist KiCad noch lange keine schlechte Sache (was er ja auch nicht behauptet hat). Kommt Zeit, kommt Rat, ich baue KiCad öfter mal neu und verschlechtert hat es sich IMHO nicht im Laufe der Zeit. Gruß, Holm
Abdul K. schrieb: > Ein Schnittstelle z.B. zu LTspice ist nett, aber wie gut muss das integriert sein um es effektiv zu nutzen? Das von mir verwendete Tool kann LTspice schon seit Jahren vorwärts und rückwärts. Nach meiner Erfahrung bringt das eher wenig. Das gesamte Design kannst du nicht simulieren (z.B. den Controller) und die Teile die gehen haben dann meist irgendwelche Bauteile die LTspice nicht kennt. Da hast du dann die nächste Baustelle die Teile parallel zu pflegen. Unabhängig voneinander geht das nach meiner Erfahrung schneller und ist flexibler. > Teardrop ist schon nett, wenn man mal per Hand was tauschen will. Danke für den Tip, für Steckverbinder scheint mir das eine gute Sache zu sein.
il Conte schrieb: > Ich denke mal bei der heutigen Prozessicherheit der Hersteller > ist das ganze eigentlich gegessen. bei der Herstellung sehe ich das auch so. Aber z.B Steckverbinder werden oft mechanisch belastet. Da macht es schon Sinn mehr Kupfer um das Lötauge zu bauen.
Ich habe nicht vor LTspice mit irgendwas zu verheiraten. Die Idee war nicht von mir. Ich könnte mir aber vorstellen, daß das in Jahrzehnten Standard sein wird. Ich mach lieber alles KISS.
X4U schrieb: > Da macht es schon Sinn mehr Kupfer um das > Lötauge zu bauen. Wenn du von einer einseitigen Platine redest mit nicht verkupferten Löchern redest, so wie bei den 'Küchenätzern' üblich ist, mag das stimmen. Ich rede eigentlich nicht vom Hobbybereich. Ich gehe von 2 lagigen durchkontaktierten Platinen aus, das ist heute Standard. Im Übrigen, wenn du heute einseitige Platinen bei einem Hersteller bestellst dann ist es meistens so dass die als doppelseitig produziert werden wobei eine Seite eben nicht belegt ist.
Du musst das jetzt nicht schön-evangelisieren. Das Feature fehlt, man kann nun entweder sehen, ob man's irgendwie eingebaut bekommt, oder muss damit leben. Du kannst aber aufhören, die Notwendigkeit für sowas wegdiskutieren zu wollen. Das ist doch sonst wie bei Microsoft: „Wir wissen schon, was für Sie gut ist.“
Jörg W. schrieb: > Du musst das jetzt nicht schön-evangelisieren. Das Feature fehlt, > man kann nun entweder sehen, ob man's irgendwie eingebaut bekommt, > oder muss damit leben. Du kannst aber aufhören, die Notwendigkeit > für sowas wegdiskutieren zu wollen. Das ist doch sonst wie bei > Microsoft: „Wir wissen schon, was für Sie gut ist.“ Mit Verlaub das ist nichts anders als eine Killerfloskel, wenn einem die sachlichen Gegenargumente ausgehen :-(( Sehr schnell zu durchschauen. Eine schärfere Retorik verkneif ich mir jetzt, um dich nicht in Wallung zu bringen :-)
il Conte schrieb: > die sachlichen Gegenargumente Solche akzeptierst du doch sowieso nicht – zumindest so lange nicht, bis Kicad ein solches Feature vielleicht mal hat. Danach würden sie jedoch für dich zum k.o.-Kriterium für Kicad werden. Sorry, sowas in der Art ist zumindest leider mein Eindruck, den ich von dir bekommen habe. Ich schrieb nirgends, dass mir die Teardrops besonders wichtig wären, sondern habe nur gefragt, ob Kicad das hat. Deine gesamte Reaktion darauf ist jedoch, sich 1) lustig drüber zu machen und 2) zu argumentieren, dass man das sowieso nie brauchen würde. Du glaubst gar nicht, wie sehr das einem auf den Keks gehen kann, sorry. (Das sage ich dir jetzt als Kicad-Nutzer, der ich de facto bin.)
Jörg W. schrieb: > Das Feature fehlt, > man kann nun entweder sehen, ob man's irgendwie eingebaut bekommt, Eagle macht das über ein ulp (user language program) indem es die Leiterbahn auffächert. Zwar nur eine Krücke aber es geht. Gibt es so etwas (ulp) auch in KiCad?
Ich glaube, bei BAE war das auch mit einem ULC gemacht. Bei BAE ist gefühlt die Hälfte der Funktionalität als ULCs implementiert (und dadurch auch vom Benutzer änderbar). Da das compilierte Programm(teil)e sind, ist das trotzdem schnell. Meines Wissens hat Kicad nichts vergleichbares. Wäre ja vielleicht mal eine nützliche Ergänzung. Scriptsprachen, die man einbetten kann, gibt's ja mittlerweile einige.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ich schrieb nirgends, dass mir die Teardrops besonders wichtig wären, > sondern habe nur gefragt, ob Kicad das hat. Und dann dieses Statment: Jörg W. schrieb: > Das sage ich dir jetzt als Kicad-Nutzer, der ich de facto bin Als KiCad Nutzet weiss man ob Teartrops gehen oder nicht !! Mach dich nicht lächerlich. Was sein wird, ist, dass du deinen BAE nachtrauerst, und hier Trauerhilfe suchst :) Jörg W. schrieb: > Deine gesamte Reaktion > darauf ist jedoch, sich 1) lustig drüber zu machen ... Sorry, du machst es aber auch einem sehr leicht.
Jörg W. schrieb: > da praktisch jedes Stück Elektronik, welches komplexer ist als eine > LED-Taschenlampe, irgendeine Form programmierbarer Logik enthält ..also meine letzten LED-Taschenlampen enthielten eigentlich alle auch schon eine "Form programmierbarer Logik", z.B. einen Attiny oder STM8. Das Ding muss ja schliesslich SOS morsen können... ;-)
il Conte schrieb: > Als KiCad Nutzet weiss man ob Teartrops gehen oder nicht !! Wenn man mal was nicht weiß, darf man fragen, oder? Aber ich werde in Zukunft deine Evangelismen einfach ignorieren. Du solltest jedoch wissen, dass du Kicad mit deinem nervigen Evangelismus keinen Gefallen tust. > Was sein wird, ist, dass du deinen BAE nachtrauerst Schrieb ich nicht deutlich genug, dass ich da lediglich dem Autorouter nachtrauere? (Ansonsten: das BAE habe ich noch, es ist lauffähig, es ist keine Mietsoftware – ich könnte es also weiterhin nutzen, wenn ich so sehr dran hängen würde, wie du hier unterstellst.)
X4U schrieb: >> Teardrop ist schon nett, wenn man mal per Hand was tauschen will. > Danke für den Tip, für Steckverbinder scheint mir das eine gute Sache zu > sein. Jörg W. schrieb: >Ich schrieb nirgends, dass mir die Teardrops besonders wichtig wären, >sondern habe nur gefragt, ob Kicad das hat. Keine Ahnung ob KiCAD Teardrops unterstützt. Einen Bedarf oder Wunsch dafür scheint es zumindest auch in anderen EDA Softwaren zu geben. Ich zitiere mal kurz aus der Wunschliste der Konkurrenz ;) " What we are working on: 1. .. 2. .. 3. .. 4. .. 5. .. 6. .. 7. Also some smaller features .. ,tear-drops, etc. Regards, Your DipTrace Team! " Es läuft doch. ;-)
Jörg W. schrieb: > Wenn man mal was nicht weiß, darf man fragen, oder? Jörg W. schrieb: > il Conte schrieb: >> Als KiCad Nutzet weiss man ob Teartrops gehen oder nicht !! > > Wenn man mal was nicht weiß, darf man fragen, oder? Oder man probiert es aus ob es geht oder nicht, wie es die meisten machen. Anscheinend bist du noch ziemlich am Anfag mit deinen KiCad Wissen, tust aber so als ob du der Guru bist. Sorry sowas geht mir auf dem Keks :-(
Brille schrieb: > " What we are working on: > 1. .. > 2. .. > 3. .. > 4. .. > 5. .. > 6. .. > 7. Also some smaller features .. ,tear-drops, etc. Ungefähr an dieser Position der Wunschliste würde ich es auch haben wollen. ;-)
Angehängte Dateien:
-
Poor_Mans_TearDrops.png
6,8 KB
Brille schrieb: > Einen Bedarf oder Wunsch > dafür scheint es zumindest auch in anderen EDA Softwaren zu geben. Wobei es wohl in jeder Software als Workaround möglich ist Teilsegmente mit unterschiedlichen Breiten zu verwenden.
Das ist ja letztlich das, was Abdul damals auch getan hat. Schöner ist es aber natürlich, wenn es sich automatisieren lässt. Andere Dinge wären aber in der Priorität weiter oben, beispielsweise ordentliche Busse im Schaltplan / Netzliste oder Via stitching ohne Krücken.
Brille schrieb: > Warum noch niemand auf die Idee kam einen Autorouter > für Schaltplaneditoren zu schreiben? Das stimmt doch gar nicht. Ich habe über die Jahre mehrere Schaltplaneditoren angetestet; fast jeder hat mindestens eine Halbautomatik zum Verlegen von Verbindungen. > Du meinst vermutlich ein Tool, dass einem die lästige > Arbeit der sinnvollen Anordnung aller Schaltplanzeichen > mitsamt des Verbindens derselben untereinander abnimmt? Nö, müsste gar nicht. Es würde genügen, wenn bei Neu-Platzierung der Schaltplan- symbole der Verlauf der Verbindungen nach Möglichkeit vereinfacht würde, ohne existierende Verbindungen zu trennen. > Vermutlich weil so ein vom "Robot" gerouteter Schaltplan > dann alles andere als schön und lesbar wäre, sondern eher > so wie beim Layout, nämlich optimiert auf dicht gepackt, > um (Platinen-) Platz zu sparen. Man kann einem Programm unterschiedliche Regeln für unterschiedliche Zwecke beibringen. :) > Abgesehen davon müsste man dazu die Verbindungen bereits > als Netzliste vorliegen haben. Naja... das lässt sich ja einrichten. > Wäre es allgemein nicht besser, bevor man solche > vermeintlich tollen Features anpreist, sich der wirklich > verbesserungswürdigen Details zu widmen? Das SIND wirklich verbesserungswürdige Details. (Zumindest für mich.) > Wir sollten uns man von dem Gedanken trennen, dass > Entwickler-Kapazität bzw. -Zeit grundsätzlich in beliebiger > Höhe verfügbar ist, sondern generell eher eng begrenzt ist. In Anbetracht dessen, dass es allein hier im Forum in den letzten Jahren drei Anläufe gab, EDA-Software zu schaffen, finde ich diese Aussage etwas... abenteuerlich. Programmierer wollen aber programmieren -- und nicht mit anderen Programmierern, die genauso zickig sind wie sie selbst, zusammenarbeiten. Die Software ist genauso kommunikativ wie die Leute, die sie erschaffen.
Angehängte Dateien:
-
DT_Teardrops.gif
37 KB
X4U schrieb: > Brille schrieb: >> Einen Bedarf oder Wunsch >> dafür scheint es zumindest auch in anderen EDA Softwaren zu geben. > > Wobei es wohl in jeder Software als Workaround möglich ist Teilsegmente > mit unterschiedlichen Breiten zu verwenden. Ja, Workarounds gibt es. Unter den Examples in Diptrace findet sich ebenfalls ein Beispiel dazu. Ist halt nur die Frage, ob man diesen Aufwand "per Hand" selber wirklich betreiben will. Da muss man sich dann schon Zeit für nehmen wollen (siehe Anhang).
Hai Bernd! Bernd W. schrieb: > Schlimmer finde ich bei Modi, wo die Linien rechtwinklig > bleiben die Fälle, wo verschobene Linien dann direkt > übereinander liegen. Ja. Zwei Varianten desselben Problems: Der Schaltplaneditor darf die Struktur der Verbindungen nicht eigenmächtig ändern (z.B. Netze auseinanderreissen). Er darf auch keine Output erzeugen, der dem Nutzer eine andere Schaltungsstruktur vorspiegelt, als programmintern vorhanden ist (elektrisch unabhängige Verbindungen übereinander zeichnen). > Du verwechselst move und drag. Kann sein; ich habe mich nicht um die Namen geschert. > Bei "move" ist ja das Abreissen intentionell, bei "drag" > nicht. Naja, also wenn ich 1. zwei Bauelemente einfüge, 2. eine Verbindung herstelle, 3. das eine Bauteil anpacke und bewege, dann erwarte ich natürlich, dass die eben hergestellte Verbindung erhalten bleibt. Bei gschem passiert das in bestimmten Fällen, in anderen nicht -- mir erschließt sich nicht, wann warum der eine oder der andere Fall eintritt. > In dem Falle ist das aber sehr wenig. Und wenn man > übersieht, das Linien übereinanderliegen...siehe oben. Hmm, ja, guter Punkt. -- Man braucht auch einen Design Rule Check für Schaltpläne: - keine Segmente unterschiedlicher Netze übereinander, - Abzweigungen im selben Netz IMMER nur mit Verbindungspunkt, - keine Netzsegmente unter/über Symbolen. > Wenn man es also einführt, sollte man es optional auch > abschalten können. Ja, auf jeden Fall. Ich wüsste auch keinen technischen Grund, warum nicht mehrere Schaltplaneditoren im selben Projekt koexistieren können sollten. Die Bedienphilosophien können ja komplett unterschiedlich sein; solange die Schnittstellen zu den anderen Komponenten passen, spielt das doch keine Rolle. Man MUSS ja nicht alles in ein einziges Programm quetschen.
Moin, il Conte schrieb: > > Du nörgelst hier rum - wieso eigentlich? Aus dem gleichen Grund, warum du hier schreibst: Weil ich's kann. > Irgendwie kommt es mir vor als ob du dir kein CADENCE leisten kannst, > verlangst aber nun, dass ein OS KiCad dass alles können muss. Leisten koennen koennt' ich mir's wahrscheinlich schon. Nur am Wollen wird's hapern. Ich koennt' mir auch ein Microsoft Windows leisten, tu's aber nicht... > verlangst aber nun, dass ein OS KiCad dass alles können muss. Aha - wo verlang' ich das denn? Ich schrub, was mir negativ auffiel. Ich schrub mitnichten, dass alle Entwickler sofort alles fallenlassen zu haben und meinen Scheiss gefaelligst nach meiner Prioritaetenliste sofort abzuarbeiten haben - oder wo liest du das? > > Deine 'Sternchen' Aufzählungen ist alles nur Wirbel um nichts! > Mit etwas Kreativität kann man das alles leicht umschiffen. Mit etwas Kreativitaet und einem Bleistift und einem Karoblock kann man KiCad komplett "leicht umschiffen". Hab' ich aber garnicht vor. Klar geht das alles irgendwie mit Bauteilen, die nur aus Kupferrohren bestehen und lustigen Batch- und Scriptdateien in nicht minder lustigen Sprachen. Aber genauso klar kann ich Defizite, die mir auffallen auch benennen. X4U schrieb: > Nichts gegen KiCad, eine tolle Sache. > Ein OSS Projekt ist auch nicht dazu da das die Crew ein Produkt erstellt > was im Produktiveinsatz mit gekaufter Software konkurrieren soll. Naja Opensrc schliesst Professionalitaet sicher nicht aus. il Conte schrieb: > deshalb : > > Dergute W. schrieb: >> So, erstmal genug genoergelt. Mahlzeit ;-) Hmmmkay - In meinem Kulturkreis ist "Mahlzeit" an Wochentagen um die Mittagszeit herum eine durchaus uebliche Floskel. Warum triggert dich das so? Naja, ok ich seh' schon, dich triggert ja vieles. Holm T. schrieb: > Nö, er hat Recht, aber deswegen ist KiCad noch lange keine schlechte > Sache (was er ja auch nicht behauptet hat). Kommt Zeit, kommt Rat, ich > baue KiCad öfter mal neu und verschlechtert hat es sich IMHO nicht im > Laufe der Zeit. Exakt so seh' ich das (auch). Die Selberbaubarkeit von KiCad hat auch in der Vergangenheit tatsaechlich zugenommen. Allerdings Ist KiCad halt fuer die meisten "nur" das Werkzeug. Ich bau' mir auch nicht jeden Tag einen Hammer, auch wenn ein neuer Werkzeugstahl 'rauskommt. Gruss WK
Beitrag #5213562 wurde von einem Moderator gelöscht.
Possetitjel schrieb: > Nö, müsste gar nicht. Die Leitungen im Schaltplan werden verbunden, in dem einfach Namen an die Leitungen geschrieben werden. Auf diese Art werden 90% der Schaltpläne gezeichnet. Die analoge Welt, als die Funktion in den Drähten lag, wurde kleiner. Deshalb sind Routingfunktionen im Schaltplan nicht so wichtig.
Dergute W. schrieb: > il Conte schrieb: >> deshalb : >> >> Dergute W. schrieb: >>> So, erstmal genug genoergelt. Mahlzeit ;-) > Hmmmkay - In meinem Kulturkreis ist "Mahlzeit" an Wochentagen um die > Mittagszeit herum eine durchaus uebliche Floskel. Warum triggert dich > das so? > Naja, ok ich seh' schon, dich triggert ja vieles. Irgendwie bringst du da ein bisschen was durcheinander. Der ganze Context ging so: il Conte schrieb: > X4U schrieb: >> il Conte schrieb: >>> Du nörgelst hier rum - wieso eigentlich? >> >> Gegenfrage: Warum wirst du persönlich wenn andere sachliche Einwände >> bringen? > > deshalb : > > Dergute W. schrieb: >> So, erstmal genug genoergelt. Mahlzeit ;-) Dem X4U hat es wohl nicht gefallen dass ich dich 'angenörgelt' habe. Warauf ich dich zitiert habe, weil ich eben davon ausging das du deinen Beitrag (richtigerweise ;-) als Nörglerei einstufst ;-) Da triggert gar nichts.
Lutz H. schrieb: > Die Leitungen im Schaltplan werden verbunden, in dem einfach Namen an > die Leitungen geschrieben werden. Auf diese Art werden 90% der > Schaltpläne > gezeichnet. Die analoge Welt, als die Funktion in den Drähten lag, wurde > kleiner. Deshalb sind Routingfunktionen im Schaltplan nicht so wichtig. Exakt so ist es! Bei unseren Schaltplänen sind parktisch alle Signalleitungen als Stummel ausgeführt (mit Netznamen) und enden im blauem Bus-Kanal um am anderen Ende wieder aufgedröselt zu werden. Eine Ausnahme bilden GND und PWR Leitungen. (meistens) Das ist übersichtlich und eignet sich bestens für das hierarchische Design.
il Conte schrieb: > Dem X4U hat es wohl nicht gefallen dass ich dich ... und bereits bereut das nicht einfach ignoriert zu haben was ich hiermit nachhole. il Conte schrieb: > Bei unseren Schaltplänen sind parktisch alle Signalleitungen > als Stummel ausgeführt (mit Netznamen) und enden im blauem Bus-Kanal Bei Bussen ist das auch sinnvoll. Bei analogen- und Power-Schaltungen geht der Zusammenhang verloren und die Schaltung wird schwer lesbar.
Lutz H. schrieb: > Die Leitungen im Schaltplan werden verbunden, in dem > einfach Namen an die Leitungen geschrieben werden. Auf > diese Art werden 90% der Schaltpläne gezeichnet. Diese Schaltpläne sehen ja auch entsprechend aus. Suchbild: "Wer findet das Label?" Davon abgesehen: Ich glaube, Du vergisst die Schaltpläne z.B. im Schaltschrankbau. Die sind sehr wohl "verbindungs- programmiert". > Die analoge Welt, als die Funktion in den Drähten > lag, wurde kleiner. Das ist richtig, und das ist mir klar. > Deshalb sind Routingfunktionen im Schaltplan nicht so > wichtig. Da ich eher ein Analogmensch bin, sind sie mir sehr wohl wichtig. Du kommst doch auch nicht auf die Idee zu sagen: "Rollstühle sind nicht wichtig", nur weil es anteilig relativ wenig Rollstuhlfahrer unter den Menschen gibt.
Hans Wurst schrieb im Beitrag #5213562: > -Wie kann ich einzelne Bauelemente oder Verbindungsabschnitte > selektieren ohne gleich alle mit die im Bereich des Rechtecks sind? Garnicht, aber wozu soll das gut sein. Habe ich noch nie vermisst. > -Wozu bewegt sich der selektierte Wust mit dem Mauszeiger wenn das > Programm noch nicht weiß was ich damit anstellen will? Der bewegt sich nicht, nur sein Bild. Drücke ESC und Alles ist wie es war. Wähle ein Untermenü und es geht wieder am Ausgangspunkt weiter. > -Warum wird der selektierte Bereich an die Mausposition verschoben, wo > ich das Ziehen(grab) als Standardfunktion erwarten würde? Dito, was beim verschieben von Gruppen als Standard gesetzt ist, ist doch Wurst. Hans Wurst schrieb im Beitrag #5213562: > Klar gebe ich morgen meinem Chef so und sage ihm das gleiche. > Eeschema kann Eckknoten nicht selbstständig verwalten. Selbst wenn du > zwei Abschnitt im Raster auf eine Linie ziehst verbleibt der Knoten, > obwohl > die Verbindung optisch eine einzige Linie bildet. Verstehe ich nicht, die Knoten sind graphische Symbole und können ggf. gelöscht werden. Hans Wurst schrieb im Beitrag #5213562: >>> - Selektieren von Leiterbahnen und Verbindungen nicht nur in den >>> Eckpunkten >> Wozu sollten diese selektiert werden? > > Um sie zu Verschieben (ohne Verbindungen aufzutrennen). Dazu müssen sie nicht selektiert werden. "Segment ziehen, Steigung beibehalten" aus dem Kontextmenü ist dein Freund. dabei bleiben die Verbindungen erhalten, die Längen werden automatisch angepasst. [...]
:
Bearbeitet durch Moderator
X4U schrieb: > Bei analogen- und Power-Schaltungen > geht der Zusammenhang verloren und die Schaltung wird schwer lesbar. Das stimmt auch wiederum, das macht z.B. bei einer OPV-Beschaltung wenig Sinn. Für die Signale die wegführen (OUT PIN) oder zugeführt werden, kann es aber trotzdem Sinn machen wie oben beschrieben. Eigentlich muss dass jeder für sich entscheiden was für ihn noch lesbar ist oder nicht. Im Prinzip hat Lutz aber recht.
Beitrag #5213678 wurde vom Autor gelöscht.
il Conte schrieb: > Sheeva P. schrieb: >> Es ging hier um die Bauteilebibliothek, da muß ich mir jetzt nicht allzu >> viele Gedanken über die Funktionalität machen: da müssen Daten >> strukturiert gespeichert und zum Abruf vorgehalten werden. > > Lese ich daraus (auch aus deinem Beitrag vorher) das du bei KiCad > aktiv am proggen bist ? Nein, aber ich war an ähnlichen Projekten beteiligt.
Hans Wurst schrieb: > Ich habe nichts gegen Open Source, ich habe auch nichts gegen Kicad an > sich, Deine bisherigen Aussagen lesen sich irgendwie anders. > mich stört nur, dass bis heute niemand das Bedienkonzept ins Jahr > 2017 gebracht hat. Das Programm ist etwa 25 Jahre alt und hat eine breite Benutzerbasis, die an die vorhandenen Bedienkonzepte gewöhnt sind. Diese Bedienkonzepte zu ändern würde einerseits große Ressourcen verbrauchen -- um dafür andererseits eine Benutzerbasis zu verprellen, die sich an diese Bedienung gewöhnt hat. Ansonsten steht es Dir natürlich frei, Deinen Vorstellungen entsprechende Bedienkonzepte zu entwickeln und dem Kicad-Projekt vorzuschlagen. Das wäre wesentlich sinnvoller als Deine destruktive Trollerei in diesem Forum. Ansonsten verstehe ich Dein Problem nicht. Wenn Dich die Bedienung stört, such' Dir doch einfach ein anderes Programm, dessen Bedienung Dir besser gefällt. Oder zwingt Dich irgendjemand dazu, Kicad zu benutzen?
X4U schrieb: > Sheeva, meiner einer findet OSS Klasse und ich bin auch selber in dem > Bereich aktiv. Aber ein Tag hat nur 24 Stunden und ein Anwender der > diese Software nur benutzt ist selten willens sich mit internas der > Erstellung zu beschäftigen. Ja, natürlich, aber das verlangt ja auch niemand. > Das fehlen von Informationen weil jemand das > Handbuch nicht gelesen hat ist auch nicht OSS spezifisch. Deswegen bieten diverse Unternehmen kostenpflichtigen Support an, sowohl für kommerzielle Software als auch für OSS. Aber im OSS-Bereich scheinen einige Anwender zu glauben, auch der Support müsse kostenlos sein -- die fallen mit ihren Ansprüchen dann eben auf die Nase, na und? > Es kommt noch hinzu das ich nach dem Kauf einer Software keine > Verpflichtung gegenüber dem Anbieter habe. In der Regel ist er aber > interessiert sein Produkt weiter zu entwickeln und Fehler zu beheben. Auch OpenSource-Projekte haben ein Interesse an der Verbesserung ihrer Software und an der Behebung von Fehlern darin -- meistens ist dieser Prozeß sogar viel offener und wesentlich einfacher zugänglich als bei kommerziellen Herstellern. > Da ist es mir häufig lieber diesen klaren weg zu gehen statt in diesem > latent offenen Schuldverhältnis gegenüber einer Community zu stehen. Die > ist ja in der Regel sehr nett und freut sich über jeden der das Programm > benutzt. Bei Rückfragen wird auch oft sehr hilfsbereit reagiert (sofern > man die einfachen Mindeststandards der Netikette einhält) aber das > ändert das Prinzip nicht. Natürlich hast Du vollkommen Recht, aber OpenSource lebt nicht von reinen Anwendern, sondern von Mitmachern -- und das Schuldverhältnis entsteht nur aus dem Anspruchsdenken von Anwendern, die zwar nicht mitmachen, aber ihre Vorstellungen realisiert sehen wollen, und zwar gefälligst zackig. So kann das aber nicht funktionieren, und die meisten mir bekannten Projekte haben auch keine Lust auf diese Art von Anwendern. Den wesentlichen Punkt hast Du genannt: die Mindeststandards der Netikette sind einzuhalten, im Kontakt mit OSS-Entwicklern noch mehr als im Kontakt mit kommerziellen Herstellern und bezahlten Supportern.
Possetitjel schrieb: > Noch schlimmer ist die Eigenart von gschem, Netze auseinander- > zureissen. Da kann ich ja gleich CorelDraw nehmen, um den > Schaltplan zu malen. Du weißt aber schon, daß gschem nicht zu Kicad gehört? > Auch eine kleine Steigerung des Bediencomforts ist es doch > wert, implementiert zu werden. Das kommt immer auf den Einzelfall an, mithin: um die Relation zwischen Aufwand und Nutzen. In diesem Punkt unterscheiden sich kommerzielle und OpenSource-Software nicht im Geringsten -- allerdings hast Du bei OSS natürlich immer die Möglichkeit, Deine Verbesserungswünsche selbst zu implementieren oder jemanden dafür zu bezahlen, daß er es tut.
@ Sheeva Plug Ich sehe da gerade du hast der Reihe nach alle abgefertigt, hast du auch keinen ausgelassen ;-)
Sheeva P. schrieb: > allerdings hast Du bei OSS > natürlich immer die Möglichkeit, Deine Verbesserungswünsche selbst zu > implementieren oder jemanden dafür zu bezahlen, daß er es tut. Sie mal an. Nun kommt die Bezahlung ja doch mal ins Spiel. Wie war das noch gleich von dir: ich: >> Das Problem mit der Entlohnung sehe ich auch. du: > Das sehe ich nicht, wo soll das sein? > Für Kleinstbeträge startet kein Entwickler seinen Editor, schon gar > nicht, wenn es um Nischensoftware geht, bei der sich die Kleinbeträge > nicht durch Akkumulation zu einem motivierenden Betrag summieren. Diese > Denkweise geht davon aus, daß Menschen nur durch ökonomischen Nutzen > motiviert werden, das ist ein kommerzielles Denkmodell, welches dem > OpenSource-Gedanken inhärent und diametral entgegensteht (und, ganz am > Rande bemerkt auch ein ziemlich trauriges Welt- und Menschenbild > offenbart, IMHO). Offenbar hängt die "Motivation" früher oder später eben doch am Geld. Nämlich spätestens dann, wenn der oder die Entwickler ihre Phase der Euphorie (SW ist zu ca. 80 Prozent fertig) hinter sich haben und die Lust noch weitere Zeit darin zu investieren sich langsam dem Ende neigt. Falls die SW bis dahin das Pech hatte keine größere Gruppe von Entwicklern an sich binden zu können, ist der Drops gelutscht und gerade diejenigen Anwender, die sich bis dato auf so eine Software ENRSTHAFT eingelassen haben, stehen dann im Regen und können sich wieder neu orientieren. Letzteres ist dann sehr ärgerlich. Beispiel gefällig: http://www.icsharpcode.net/OpenSource/SD/Default.aspx Lies dazu https://github.com/icsharpcode/SharpDevelop/issues/799 Was ist denn übrigens bei dir "Nischensoftware"? Etwa alles was nicht den Bekanntheitsgrad von OpenOffice, Blender, FreeCAD hat (drei willkürlich gewählte Beispiele)? Ist SharpDevelop etwa eine solche "Nische"? 149,830 users have contributed to 39,511 threads and 43,961 posts. Fast 150 Tausend Nutzer sind für mich keine Nische, sondern eine breite Fangemeinde. Das Beispiel zeigt auch gleichzeitig die Unsinnigkeit des Arguments, man könne ja einfach "mitproggen" und so die Software "verbessern". Auf wieviel Prozent der Nutzer trifft das real wirklich zu? Anscheinend auf weniger als 10 von 150.000 Nutzer wohl aus den unterschiedlichsten Gründen (zu wenig Ahnung, Zeit, Lust etc.). Für eine brauchbare EDA-Software bundesweit auch nur 1000 Anwender zusammenzubekommen, die bereit wären monatlich 5 Euro zu zahlen sollte doch genügend Motivation für zumindest einen Entwickler sein, so ein Projekt fortzuführen. Gerade dann, wenn angeblich (nach deiner Lesart) das Eigeninteresse gegenüber dem Monetären sowieso deutlich überwiegt. 5000 Tacken jeden Monat fürs Codieren als Zweitjob. Soviel verdienen viele (auch vor Steuern) nicht mal mit ihrer Vollzeitarbeit im ganzen Monat. Wo also ist das Problem? Sind die Herren sich etwa zu fein Geld fürs OSS Proggen zu nehmen? Steht ihnen womöglich eine (ihre) Ideologie dabei im weg? Ich erwähnte es bereits weiter oben. KiCAD ist erst durch die Beteiligung der Leute vom CERN (mit dem Push and Shove Router) so richtig bekannt geworden. Diese Leute beim CERN sind BEZAHLTE Entwickler. Im Endeffekt spielt es keine Rolle, ob eine Firma die SW-Entwicklung bezahlt oder eine Community mit akkumulierten Kleinbeträgen. Wichtig ist, die SW bleibt dabei frei benutzbar (der OSS-Gedanke) für jeden und ALLE haben was von (Ja, auch der oder die Entwickler). Dazu muss man natürlich bereit sein mal seine (möglicherweise vorhandenen) ideologischen Scheuklappen abzulegen und sich neuen Modellen der OSS-Erstellung zu öffnen, nämlich dort, wo ein OSS-Projekt ansonsten einfach keine oder eine zu langsame Weiterentwicklung erfahren würde. Derlei Beispiele gibt es zuhauf und für viele ist es einfach nur Schade, dass sie sang- und klanglos in Vergessenheit geraten. Die Entwicklung von KICAD scheint aktuell auch so zu laufen. Um noch ein Beispiel zu nennen, denkbar wäre auch gewesen z.B. CADSOFT Eagle über ein Crowdfunding Projekt natürlich rechtzeitig aufzukaufen (solche Verkäufe kommen meistens nicht aus heiterem Himmel, sondern bahnen sich seit längerem an, wenn auch zumeist unbemerkt von der Öffentlichkeit) und zu einer OSS zu transformieren, anstatt sich jetzt über das unrühmliche neue Lizenz Modell des Aufkäufers zu beklagen.
il Conte schrieb: > @ Sheeva Plug > > Ich sehe da gerade du hast der Reihe nach alle abgefertigt, > hast du auch keinen ausgelassen ;-) Da scheine ich etwas verpaßt zu haben: ich habe weder die Absicht, noch das Bedürfnis, jemanden "abzufertigen" -- und wenn meine Beiträge bei den darin Angesprochenen so angekommen sein sollten, bitte ich um Verzeihung.
Hallo Jörg, Graf, Brille und Possetitjel. Jörg W. schrieb: > Hat Kicad eigentlich einen Teardrop-Automatismus (um mal wieder auf > das Thema des Threads zurückzukommen)? Im Sommer 2017 definitiv nicht. Ich muss mir aber unbedingt jetzt irgendwann die Zeit nehmen, und mir ein aktuelles KiCad (in einem aktuellen Debian) compilieren, weil ich zu neugierig auf die Veränderungen bin. Allerdings denke ich, das Teardrops nicht dazu gehören, weil sie zu weit unten auf der ToDo Liste stehen. il Conte schrieb: >> Der Teardrop > > Ich hab mir das im Wiki durchgelesen. > Ich denke mal bei der heutigen Prozessicherheit der Hersteller > ist das ganze eigentlich gegessen. > Wenn ich beim Design mechanische Belastungen vermutet, muss man > dem anders begegenen. Das Wichtigste wird im fraglichen Wikipedia Artikel nur kurz angerissen: "by misalignment during drilling, so that too much copper may be removed by the drill hole in the area where a trace connects to the pad or via. An extra advantage is the enlarging of manufacturing tolerances, making manufacturing easier and cheaper." Es geht um die Bohrtoleranzen. Selbst wenn Du normalerweise die Bohrtoleranzen gut halten kannst, nehmen sie zu, wenn Du im Stapel bohrst, weil Du Kosten reduzieren willst. Und dann werden Teardrops wieder eine Nummer. Da allerdings in den hiesigen Firmen Layouts meistens nur für Sonderlösungen mit geringen Stückzahlen gemacht werden, die für eine chinesische (Massen)produktion (noch) zu uninterressant sind, spielen hierzulande Teardrops aber keine so große Rolle. Ein weiterer Punkt ist Flex/Starrflex. Dort werden nicht nur Teardrops an Bohrungen verwendet, sondern auch an Verzweigungen der Leiterbahnen und dergleichen werden Teardropähnliche Strukturen verwendet, um Kerbeffekte zu vermeiden. Eine einfacher umzusetztende Alternative zu Teardrops (für Bohrtoleranzen) sind Schneemänner. Allerdings sind die nicht so platzsparend. Brille schrieb: > (Autorouter erstelltes) Layout: dicht gepackt, auf Platz optimiert > (manuell erstellter) Schaltplan: optisch ansprechend, auf Verständnis > bzw. schnellen Überblick optimiert Die paar Autorouter, die ich bisher kennengelernt habe, waren eher schnell als platzsparend. Nach einem Durchlauf manuell die Positionierung optimieren und den Router neu laufen lassen. Im steten Wechsel zwischen Autorouter und manuellem Routen bekam man dann halbwegs schnell ein sehr dichtes Layout. Wenn es denn auf High-Speed, HF, EMV Hochspannung, Hochstrom und mechanische Absonderlichkeiten nicht ankommt. Was Autorouter überhaupt nicht können, sind solche Randbedingungen aus HF-Technik, EMV, Hochspannung und Hochstrom, Wärmemanagement..... Auf Aestehtik kann ich gut verzichten. Verständnis und schneller Überblick sind interessant für den Service (wenn man den im Design berücksichtigt). Unter Sicherheitsaspekten ist Überblick aber eigentlich essenziell. Possetitjel schrieb: >> Du verwechselst move und drag. > > Kann sein; ich habe mich nicht um die Namen geschert. Nunja. Es sind halt zwei unterschiedliche Funktionen mit unterschiedlichem Namen und halt auch unterschiedlichem Verhalten. ;O) > >> Bei "move" ist ja das Abreissen intentionell, bei "drag" >> nicht. > > Naja, also wenn ich > > 1. zwei Bauelemente einfüge, > 2. eine Verbindung herstelle, > 3. das eine Bauteil anpacke und bewege, > > dann erwarte ich natürlich, dass die eben hergestellte > Verbindung erhalten bleibt. Bei gschem passiert das in > bestimmten Fällen, in anderen nicht -- mir erschließt > sich nicht, wann warum der eine oder der andere Fall > eintritt. Bei Deinem Beispiel würde man "drag" verwenden. Dann bleiben die Verbindungen erhalten. Möchte man aber jetzt ein Objekt oder eine Gruppe aus dem Schaltungsverbund entfernen, ohne sie aber zu löschen, weil man damit z.B. noch irgendetwas anderes vorhat, dann verwendet man "move". Dann werden die Verbindungen getrennt, und das Bewegte ist komplett selbstständig. Sprachlich ist das vieleicht etwas doof, weil das was bei anderen Programmen oft "move" macht, heisst in KiCad "drag". Auf der anderen Seite bedeutet "move" "bewegen", und genau das wird ja auch gemacht, und "drag" bedeutet Ziehen, und beim Ziehen werden die Verbindungen mitgezogen. So gesehen ist das auch wieder konsistent. Ich finde es übrigens ausgesprochen bequem, zwischen den beiden Funktionen je nach Situation direkt wählen zu können. Bei irgendeinem anderen Programm (Genesys???) z.b. bekam man nach dem Wählen der "move" Funktion noch eine Auswahlbox um das Verhalten wählen zu können. Das fand ich umständlicher. >> In dem Falle ist das aber sehr wenig. Und wenn man >> übersieht, das Linien übereinanderliegen...siehe oben. Der ERC würde viele abfangen. Allerdings würde der ERC die nicht Abfangen, die so dicht paralell liegen, dass sie für den ERC getrennt sind, aber für einen humanen Betrachter bei unpassender Vergrößerung (Bei einem Ausdruck schnell passiert) schlecht zu trennen sind. ;O) > Ich wüsste auch keinen technischen Grund, warum nicht > mehrere Schaltplaneditoren im selben Projekt koexistieren > können sollten. Die Bedienphilosophien können ja komplett > unterschiedlich sein; solange die Schnittstellen zu den > anderen Komponenten passen, spielt das doch keine Rolle. > Man MUSS ja nicht alles in ein einziges Programm quetschen. Immerhin sind für gEDA, KiCad und Horizon die Formate offen. Da könnte man sich Adapterskripte erstellen. PCBnew in KiCad kann schon nativ gEDA und Eagle Footprints verwenden. Ob das gut funktioniert, habe ich aber nie getestet. gEDA Schaltplandateien habe ich mir heute noch angesehen. Da gEDA nicht wirklich zwischen Schaltplan und Symbol trennt, ist das nicht ganz so trivial wie zuerst gedacht......oder mir fehlt noch die zündende Idee. Symbole selber gingen.....weil bei ihnen klar ist, das sie Symbole sind. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Sheeva. Sheeva P. schrieb: >> Noch schlimmer ist die Eigenart von gschem, Netze auseinander- >> zureissen. Da kann ich ja gleich CorelDraw nehmen, um den >> Schaltplan zu malen. > > Du weißt aber schon, daß gschem nicht zu Kicad gehört? Er meint vermutlich schon Eeschema. Die Verwechslung "move" und "drag" tritt dort bei Unkundigen halt recht häufig auf. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Beitrag #5213870 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > Possetitjel schrieb: >> >> Die Aufgabe wäre erstmal, die Varianten (für die gewünschten >> Abläufe) zu erfassen und daraufhin abzuklopfen, welche >> Varianten wieviel Aufwand erfordern und welche wie miteinander >> verträglich sind. > > Ja, und das haben die Kicad-Entwickler ja offensichtlich > getan -- denn sonst würde es keine Bauteilebibliothek geben. Unzulässige Folgerung. Um etwas implementieren zu können, das brauchbar funktioniert, muss man erstmal nur DIE EINE Varianten durchdenken, die man implementiert. Ob es andere, bessere Möglichkeiten gibt, und ob die bedacht worden sind, weiss man von außen nicht. > Wie Du jetzt auf die Unterstellung kommst, daß die > Entwickler bei den nötigen Vorüberlegungen geschludert > hätten, erschließt sich mir daher nicht. Nicht geschludert. Es funktioniert ja. Es ist akzeptabel -- aber "wirklich gut" ist anders. > Die Anwender kommen erst ins Spiel, wenn die Software > so weit entwickelt ist, daß ihre Funktionalitäten und > Workflows von den Anwendern ausprobiert werden können. In der kommerziellen Softwareentwicklung lernt man gerade, dass das zu spät ist. >>> Ich bau doch nicht mein Datenmodell, mein Programm und >>> dessen Workflow um, nur weil ein paar wenige Anwender >>> sich nicht von ihren Angewohnheiten trennen wollen. >> >> Warum nicht? > > Weil die überwiegende Mehrheit der Anwender offensichtlich > gut mit den vorhandenen Workflows arbeiten kann und will. Falsche Bezugsmenge. Es sind nicht nur die interessant, die es schon verwenden (die sind sicherlich einigermaßen zufrieden, sonst würden sie nicht dabei bleiben), sondern auch die, die es ganz gern verwenden würden, aber aus irgendwelchen Gründen davon abgeschreckt werden. >> Wenn die Programmänderung nicht zu einer Verschlechterung >> der Architektur führt, kann man doch auch den paar wenigen >> Anwendern entgegenkommen. Welcher Zacken fällt einem aus >> der Krone? > > Die Ressourcen in Softwareprojekten unterliegen gewissen > personellen und zeitlichen Beschränkungen, da ist OpenSource > keine Ausnahme. Jede Stunde, die ich dafür einsetze, um auch > den letzten Meckerer zufrieden zu stellen, fehlt mir bei > anderen Aufgaben, mit deren Lösung ich mehr Anwender oder > vielleicht sogar mich selbst glücklich machen kann. Das ist zwar für sich genommen richtig -- ich glaube aber nicht, dass das der wahre Grund ist. Irgendeine Suchfunktion bequemer zu machen ist halt viel weniger lukrativ als das ganze Programm auf eine andere Graphikschnittstelle umzustricken, weil man bei der Such- funktion im Verhältnis viel mehr grübeln muss und am Ende viel weniger Code entsteht. Das will halt niemand machen. >> GENAU das ist der Kritikpunkt: Es wird SOFORT über >> Implementierungsdetails gestritten, statt sich erstmal mit >> dem Pflichtenheft zu befassen! > > Entschuldige bitte, aber das ist falsch. Stattgegeben. Wie INNERHALB etablierter Projekte diskutiert wird, kann ich gar nicht beurteilen; ich bin ja nicht dabei. Ich bekomme im wesentlichen nur die Diskussionen mit, die außerhalb von Projekten ablaufen. > In jedem Projekt, an dem ich bis heute teilgenommen habe, [...] > > So funktioniert Softwareentwicklung in Teams, das geht auch nicht > anders. Nimm es mir nicht übel, aber das klingt zu schön, um allgemein wahr zu sein. SELBSTVERSTÄNDLICH geht es anders -- anders und beliebig viel schlechter. > Schließlich ist es schlicht unmöglich, über die Implementierung > von etwas Unbekanntem zu diskutieren. Im Gegenteil, das ist leider in der Praxis ganz einfach und funktioniert so: Jeder hat eine klare und selbstverständliche Vorstellung davon, wie es funktionieren soll -- nur sind die Vorstellungen der Leute alle unterschiedlich. Da das niemandem auffällt -- "wozu denn ewig über Trivialitäten diskutieren, die sowieso klar sind!" -- arbeitet jeder mit Energie an seinem Modul, der am Ende nicht mit dem zusammenspielt, was der andere gemacht hat... > Im OSS-Umfeld ist es nämlich so, daß die Entwickler > gleichzeitig meist auch Nutzer ihrer Software sind -- und > natürlich keine Lust haben, ihre eigenen Arbeitsabläufe > aufwändiger oder komplizierter zu machen als unbedingt > nötig. Mein Reden: Die Leute, die KEINE Scheuklappen aufhaben, werden erst gehört, wenn schon alle Messen gelesen sind. MEINE Auffassung von "kompliziert" ist vielleicht ETWAS verschieden von der des C++-Cracks, der die Software programmiert hat! >> Wozu werden "Profi-Funktionen" in das Programm eingebaut, >> wenn das Programm letztlich nicht für professionelle >> Anwender tauglich ist? > > Im Falle von Kicad ist es wohl so, daß es zum Beispiel > am CERN durchaus professionell genutzt wird und seine > Tauglichkeit für den professionellen Einsatz offensichtlich > unbestreitbar ist. Missverständnis. Das CERN ist quasi eine Behörde. Unter "professionellem Einsatz" habe ich verstanden "Unternehmen, das mit Gewinnerzielungsabsicht Schaltungen entwickelt". Das tut das CERN sicher nicht. Aus meiner Sicht hat für den Einsatz in Kleinunternehmen die Kompatibilität der Datenformate oberste Priorität. Dass diese nicht einmal bei den freien EDA-Systemen gegeben ist, ist nicht hinnehmbar. Das Argument, bei den kommerziellen Systemen sei es ja auch nicht anders, das zählt nicht: GENAU DESHALB will ich ja KEIN kommerzielles Programm einsetzen. GENAU DESHALB suche ich ja eine freie Alternative! > Tatsächlich bietet fast jedes OSS-Projekt Informationen an, > [...] > In den meisten mir bekannten OSS-Projekten gibt es das alles, > nur: mit Ausnahme der Entwickler liest das keiner. [...] Okay, das ist ein Problem. > Im Gegensatz zu den meisten kommerziellen Herstellern sind > die OSS-Leute auch sehr kontakt- und auskunftsfreudig, > durch freundliches Nachfragen bekommst Du in der Regel > alle Informationen, die Du haben willst -- oft sogar noch viel > mehr. Aber auch dazu sind viele Anwender zu faul, [...] Ja, das Problem haben die Kommerziellen aber auch. Es ist im Einzelfall sehr schwierig zu entscheiden, wer Recht hat. Teilweise reden Software-Anbieter und Kunde auch aneinander vorbei. >> Ich glaube, zumindest einige der Probleme der FOSS-Leute sind >> hausgemacht und wären lösbar. > > Das ist zwar leider nicht ganz falsch, aber diese Probleme > sind nicht die, welche Du ausgemacht haben willst. Ich bin noch nicht ganz überzeugt :)
Sheeva P. schrieb: > Possetitjel schrieb: >> Noch schlimmer ist die Eigenart von gschem, Netze >> auseinanderzureissen. Da kann ich ja gleich CorelDraw >> nehmen, um den Schaltplan zu malen. > > Du weißt aber schon, daß gschem nicht zu Kicad gehört? Ja, selbstverständlich weiss ich das. Ich meinte auch tatsächlich gschem (von gEDA). Es ging ja nur darum, dass ich gar nicht von irgendwelchen Super-Automatiken rede, sondern dass in den Programmen ganz elementare Dinge fehlen. Ein Schaltplaneditor darf (meiner Meinung nach) die Schaltung NUR dann auseinanderreissen, wenn ich ihm das EXPLIZIT sage. Sonst nicht. Welchen Regeln gschem gehorcht, verstehe ich nicht. >> Auch eine kleine Steigerung des Bediencomforts ist es >> doch wert, implementiert zu werden. > > Das kommt immer auf den Einzelfall an, mithin: um die > Relation zwischen Aufwand und Nutzen. Ja. -- Noch schlimmer: Gefühlte Relation aus Aufwand und Nutzen. Man geht ja ein Problem häufig erst dann an, wenn man schon irgend eine Lösungsidee hat. Solange die fehlt, muss man sich halt weiterärgern. Mir ist das erst so deutlich klargeworden, als ich die andere Antwort auf Deinen älteren Beitrag verfasst habe: Ich experimentiere ja im Moment auch gerade mit einer Suchfunktion ( -- allerdings für Datenblätter, nicht für Schaltplansymbole. Ich denke aber, das ist hinreichend ähnlich.) Meine Erfahrung ist, dass ein irrsinniges Missverhältnis besteht zwischen dem Zeitaufwand für die Vorüberlegungen und die Planung auf der einen und die tatsächliche Codierung auf der anderen Seite. Die entstehende Codemenge ist lächerlich winzig im Vergleich zu dem Zeitaufwand. Ich mache das aber, weil es ein Problem ist, das mich schon seit 20 Jahren ärgert -- und ich vor ein paar Wochen zufällig über eine Lösungsidee gestolpert bin. Wäre dieser Anstoß nicht gewesen, würde ich mich weiter ärgern.
Bernd W. schrieb: > Possetitjel schrieb: > >>> Du verwechselst move und drag. >> >> Kann sein; ich habe mich nicht um die Namen geschert. > > Nunja. Es sind halt zwei unterschiedliche Funktionen mit > unterschiedlichem Namen und halt auch unterschiedlichem > Verhalten. ;O) Hihi...! Missverständnis. Ich hatte nicht mitbekommen, dass Du von KiCad redest, wo es diese beiden Funktionen gibt. Ich war tatsächlich bei gschem (gEDA); dort kann man die Bauteile ohne Modus-Umschaltung einfach mit der Maus bewegen. Das Problem: Verbindungen, die an Bauteilen enden, werden mitgeführt, aber Verbindungen, die irgendwo auf anderen Verbindung enden, werden abgerissen. Völlig idiotisch. Das hier... >> Naja, also wenn ich >> >> 1. zwei Bauelemente einfüge, >> 2. eine Verbindung herstelle, >> 3. das eine Bauteil anpacke und bewege, >> >> dann erwarte ich natürlich, dass die eben hergestellte >> Verbindung erhalten bleibt. Bei gschem passiert das in >> bestimmten Fällen, in anderen nicht -- mir erschließt >> sich nicht, wann warum der eine oder der andere Fall >> eintritt. ... kann somit als geklärt betrachtet werden. Jetzt wirklich zu KiCad: > Möchte man aber jetzt ein Objekt oder eine Gruppe aus dem > Schaltungsverbund entfernen, ohne sie aber zu löschen, > weil man damit z.B. noch irgendetwas anderes vorhat, dann > verwendet man "move". Dann werden die Verbindungen getrennt, > und das Bewegte ist komplett selbstständig. Gerade probiert: Funktioniert. Finde ich trotzdem ungünstig: Für meinen Arbeitsablauf sollte "drag" Standardverhalten sein; wenn ich wirklich "move" will, kann ich auch explizit "move" wählen. > Sprachlich ist das vieleicht etwas doof, weil das was bei > anderen Programmen oft "move" macht, heisst in KiCad "drag". > Auf der anderen Seite bedeutet "move" "bewegen", und genau > das wird ja auch gemacht, und "drag" bedeutet Ziehen, und > beim Ziehen werden die Verbindungen mitgezogen. So gesehen > ist das auch wieder konsistent. Nene... die Bezeichnungen passen schon. Ich finde nur die Art und Weise der Maussteuerung unschön; das ist sehr hakelig. >>> In dem Falle ist das aber sehr wenig. Und wenn man >>> übersieht, das Linien übereinanderliegen...siehe oben. > > Der ERC würde viele abfangen. Allerdings würde der ERC die > nicht Abfangen, die so dicht paralell liegen, dass sie für > den ERC getrennt sind, aber für einen humanen Betrachter > bei unpassender Vergrößerung (Bei einem Ausdruck schnell > passiert) schlecht zu trennen sind. ;O) Nee... ich meine schon einen DRC speziell für das Schaltplan- design. Warum denn nicht? >> Ich wüsste auch keinen technischen Grund, warum nicht >> mehrere Schaltplaneditoren im selben Projekt koexistieren >> können sollten. Die Bedienphilosophien können ja komplett >> unterschiedlich sein; solange die Schnittstellen zu den >> anderen Komponenten passen, spielt das doch keine Rolle. >> Man MUSS ja nicht alles in ein einziges Programm quetschen. > > Immerhin sind für gEDA, KiCad und Horizon die Formate offen. Ja, das ist der einzige Lichtblick. > Da könnte man sich Adapterskripte erstellen. PCBnew in KiCad > kann schon nativ gEDA und Eagle Footprints verwenden. Oh. Super. Wusste ich nicht. Irgendwo im pcb-rnd-Umfeld (gEDA) habe ich gelesen, dass verbesserte KiCad-Kompatibilität erklärtes Projektziel ist. Das lässt hoffen. > gEDA Schaltplandateien habe ich mir heute noch angesehen. Da > gEDA nicht wirklich zwischen Schaltplan und Symbol trennt, ist > das nicht ganz so trivial wie zuerst gedacht......oder mir > fehlt noch die zündende Idee. Ja. Das Problem ist grundsätzlicher Natur: Der Schaltplan ist ja "nur" eine Vektorgraphik zur Visualisierung der Struktur der Schaltung. Gleichzeitig ist aber in den Anschlusspins und den Segmenten der Verbindungen die Netzliste codiert. Es ist eigentlich vom Datenmodell her Scheisse, dass man die Netzliste aus dem Koordinatenwust der Vektorgraphik heraus- fieseln muss. Es müsste umgekehrt funktionieren -- die Netzliste müsste die primäre Autorität sein, und der Rest vom Schaltplan enthält "nur" Hinweise, wie die Netzliste hübsch gezeichnet werden soll. Ich müsste mal einen Schaltplan mit eingebetteten Symbolen herstellen und dann sehen, ob man mit den Koordinaten der Verbindungspunkte und der Netzsegmente etwas anfangen kann.
Brille schrieb: > Sheeva P. schrieb: >> allerdings hast Du bei OSS >> natürlich immer die Möglichkeit, Deine Verbesserungswünsche selbst zu >> implementieren oder jemanden dafür zu bezahlen, daß er es tut. > > Sie mal an. Nun kommt die Bezahlung ja doch mal ins Spiel. Wie war das > noch gleich von dir: > > ich: >>> Das Problem mit der Entlohnung sehe ich auch. > > du: > [...] Vielen Dank für den Hinweis, aber ich weiß, was ich geschrieben habe. > Offenbar hängt die "Motivation" früher oder später eben doch am Geld. Nö, denn der von mir erwähnte "jemand" ist nicht zwangsläufig ein OSS-Entwickler und / oder an dem Projekt beteiligt. Freie Entwickler gibt es wie Sand am Meer, und wenn Du denen genug Geld auf den Tisch legst, dann entwicken die Deine Verbesserungswünsche sicher gerne. > Nämlich spätestens dann, wenn der oder die Entwickler ihre Phase der > Euphorie (SW ist zu ca. 80 Prozent fertig) hinter sich haben und die > Lust noch weitere Zeit darin zu investieren sich langsam dem Ende neigt. Genau, und deswegen ist alle OSS-Software nur zu 80% fertig -- ist aber mit Ausnahme des Desktop-Marktes trotzdem nahezu überall Marktführer. ;-) > Falls die SW bis dahin das Pech hatte keine größere Gruppe von > Entwicklern an sich binden zu können, ist der Drops gelutscht und gerade > diejenigen Anwender, die sich bis dato auf so eine Software ENRSTHAFT > eingelassen haben, stehen dann im Regen und können sich wieder neu > orientieren. Letzteres ist dann sehr ärgerlich. Tja, so ist das Leben. Dasselbe Problem haben Anwender, die sich auf eine kommerzielle Software eingelassen haben, deren Hersteller das Produkt einstellt oder in die Insolvenz geht. > Beispiel gefällig: Nö. Aber 150000 User, die nicht einmal 40000 Threads mit 43000 Postings geschafft haben? Nee, ist klar. > Für eine brauchbare EDA-Software bundesweit auch nur 1000 Anwender > zusammenzubekommen, die bereit wären monatlich 5 Euro zu zahlen sollte > doch genügend Motivation für zumindest einen Entwickler sein, so ein > Projekt fortzuführen. Gerade dann, wenn angeblich (nach deiner Lesart) > das Eigeninteresse gegenüber dem Monetären sowieso deutlich überwiegt. > 5000 Tacken jeden Monat fürs Codieren als Zweitjob. Soviel verdienen > viele (auch vor Steuern) nicht mal mit ihrer Vollzeitarbeit im ganzen > Monat. Fähige Entwickler verdienen mehr, und wenn Du Deine 1000 Leute zusammen bringst, von denen jeder 5 Euro pro Monat beiträgt, dann mach das doch einfach und engagiere einen dafür... Viel Erfolg! ;-) > Wo also ist das Problem? Das Problem ist, daß wir nicht Deine Befehlsempfänger sind. Wenn Du einen Befehlsempfänger haben willst, der Software so baut wie Du das für richtig hälst, dann bezahl' eben jemanden dafür. > Sind die Herren sich etwa zu fein Geld fürs OSS Proggen zu nehmen? Da kann ich nicht für irgendwelche "Herren" sprechen, sonder nur für mich. Und ja, für meine OSS-Arbeit will ich kein Geld, das mache ich alleine aus Spaß und für mein ganz persönliches Vergnügen. Ich verdiene genug, da muß ich mich nicht von Typen mit Deinem Tonfall herumkommandieren lassen. Tut mir ja auch leid, aber da haste eben Pech gehabt. > Ich erwähnte es bereits weiter oben. KiCAD ist erst durch die > Beteiligung der Leute vom CERN (mit dem Push and Shove Router) so > richtig bekannt geworden. Kicad war schon vorher bekannt und wäre nicht das Werkzeug der Wahl beim CERN geworden, wenn nicht die nötigen professionellen Eigenschaften für den Einsatz dort gehabt hätte. Henne, Ei...
Possetitjel schrieb: > Um etwas implementieren zu können, das brauchbar funktioniert, > muss man erstmal nur DIE EINE Varianten durchdenken, die man > implementiert. Ob es andere, bessere Möglichkeiten gibt, und > ob die bedacht worden sind, weiss man von außen nicht. Solange es eine funktionierende Lösung gibt, ist der Rest irrelevant. Die Entwickler haben sich für diese Lösung entschieden, und wenn sie Dir nicht paßt, dann schlag' eine bessere vor oder such' Dir eine andere Software. > Nicht geschludert. Es funktioniert ja. Das ist der springende Punkt: es funktioniert. Und zwar nicht nur für die Entwickler, sondern auch für die vorhandene Nutzerbasis. > Es ist akzeptabel -- aber "wirklich gut" ist anders. Das ist Deine Geschmacksfrage. Etlichen anderen Anwendern scheint es hingegen mindestens gut genug zu sein, sonst würden sie die Software nämlich nicht benutzen. >> Weil die überwiegende Mehrheit der Anwender offensichtlich >> gut mit den vorhandenen Workflows arbeiten kann und will. > > Falsche Bezugsmenge. > > Es sind nicht nur die interessant, die es schon verwenden > (die sind sicherlich einigermaßen zufrieden, sonst würden > sie nicht dabei bleiben), sondern auch die, die es ganz gern > verwenden würden, aber aus irgendwelchen Gründen davon > abgeschreckt werden. Richtige Bezugsmenge. Dein Denkfehler ist, daß die Kriterien, die für kommerzielle Software gelten -- nämlich möglichst viele und immer neue bezahlende Benutzer zu gewinnen-- für OSS-Projekte nicht gelten. > Das ist zwar für sich genommen richtig -- ich glaube aber > nicht, dass das der wahre Grund ist. Du darfst natürlich gerne glauben halt, was Du willst. ;-) > Es ist im Einzelfall sehr schwierig zu entscheiden, wer Recht > hat. Aus OSS-Sicht nicht. Wir machen Dir ein Angebot, das Du benutzen darfst, wenn es Dir gefällt. Wenn es Dir nicht gefällt, dann nutz' es halt nicht, das ist ganz alleine Deine eigene Entscheidung.
Beitrag #5213897 wurde von einem Moderator gelöscht.
Possetitjel schrieb: > Es müsste umgekehrt funktionieren -- die Netzliste müsste die > primäre Autorität sein, und der Rest vom Schaltplan enthält > "nur" Hinweise, wie die Netzliste hübsch gezeichnet werden > soll. So eine Netzliste könnte die Darstellung für die Simulationsprogramme sein. Meine Fantasie reicht aber nicht aus, wie von einer solchen Darstellung ein künstlerisch wertvoller, harmonischer, übersichtlicher und hübscher Schaltplan entstehen kann. Das Dranschreiben der Netznamen an die Anschlüsse wäre möglich, die Positionierung der Schaltzeichen wird schwieriger.
:
Bearbeitet durch User
Possetitjel schrieb: > Sheeva P. schrieb: > Es ging ja nur darum, dass ich gar nicht von irgendwelchen > Super-Automatiken rede, sondern dass in den Programmen ganz > elementare Dinge fehlen. Von welcher Suite reden wir den jetzt, von gEDA oder Kicad? > Man geht ja ein Problem häufig erst dann an, wenn man > schon irgend eine Lösungsidee hat. Solange die fehlt, > muss man sich halt weiterärgern. Flashce Reihenfolge: erst der Ärger führt dazu, daß sich jemand Gedanken über mögliche oder bessere Lösungen macht. > Mir ist das erst so deutlich klargeworden, als ich die > andere Antwort auf Deinen älteren Beitrag verfasst habe: > Ich experimentiere ja im Moment auch gerade mit einer > Suchfunktion ( -- allerdings für Datenblätter, nicht für > Schaltplansymbole. Ich denke aber, das ist hinreichend > ähnlich.) Für mich liegt die Sache auf der Hand: Datenblätter sind Textdokumente und gehören daher natürlich in eine Volltext-Suchmaschine wie Elasticsearch, Solr, Splunk oder ähnliche.
Volker Radon schrieb im Beitrag #5213897: > Sheeva P. schrieb: >> Das Problem ist > > ... daß waschechte Technokraten wie Du grundsätzlich erwarten, daß sich > der Anwender gefälligst nach der ihm vorgesetzten Software zu richten > habe und nicht umgekehrt Software nach Bedürfnissen der Anwender > auszurichten sei. Nö. Ich erwarte, daß Anwender sich eine Software heraussuchen, die zu ihren Bedürfnissen und Wünschen paßt, oder ihre Verbesserungsvorschläge wenistens halbwegs vernünfig vortragen. Mehr erwarte ich gar nicht, und das kann doch wohl nicht zu viel verlangt sein.
Beitrag #5213911 wurde von einem Moderator gelöscht.
Possetitjel schrieb: > Es müsste umgekehrt funktionieren -- die Netzliste müsste die > primäre Autorität sein, und der Rest vom Schaltplan enthält > "nur" Hinweise, wie die Netzliste hübsch gezeichnet werden > soll. Genau so funktioniert's bei horizon...
Sheeva P. schrieb: > Kicad war schon vorher bekannt und wäre nicht das Werkzeug der Wahl beim > CERN geworden, wenn nicht die nötigen professionellen Eigenschaften für > den Einsatz dort gehabt hätte. Henne, Ei... Darf ich kurz einwenden das hier kaum jemand die Bedürfnisse eines nicht kommerziellen Großforschungsinstitutes mit Projektlaufzeiten im Jahrzehntebereich hat oder ist das blasphemisch?
X4U schrieb: > Sheeva P. schrieb: >> Kicad war schon vorher bekannt und wäre nicht das Werkzeug der Wahl beim >> CERN geworden, wenn nicht die nötigen professionellen Eigenschaften für >> den Einsatz dort gehabt hätte. Henne, Ei... > > Darf ich kurz einwenden das hier kaum jemand die Bedürfnisse eines nicht > kommerziellen Großforschungsinstitutes mit Projektlaufzeiten im > Jahrzehntebereich hat oder ist das blasphemisch? Darfst Du :-) Sheeva wollte vermutlich nur darauf hinweisen, dass man unter KiCad durchaus auch komplexere Mehrlagen-Designs erstellen kann. Aber davon ab erfüllt es bspw. auch bei uns schon seit 2006 die professionellen Bedürfnisse zufriedenstellend. Wir verdienen unter anderem mit KiCad unsere Brötchen. Und unsere Projekte liegen nicht im Jahrzehntebereich ;-)
:
Bearbeitet durch Moderator
Possetitjel schrieb: > Es müsste umgekehrt funktionieren -- die ... Diese Ansätze sind für mich zu sehr auf die Technik focussiert, ein EDA Programm (oder eine Toolchain wie KiCad) ist aber im Grunde eine Mensch-Maschinen Schnittstelle. Das wesentliche an einem PCB Layout sind nicht Netzlisten oder Bauteile sondern schiere endlose Einzelheiten. "Meine" Software würde auf ein Versionkontrollsystem (VCS) aufsetzen. Grundbausteine sind templates, so wie es in libs schon heute realisiert ist. Editoren (für SCH/Board/und LIB) würden nur Änderungen bearbeiten. So wie bei Diff in Git und mercurial. Dann kann mit einer beliebigen Anzahl an Benutzern am Design gearbeitet werden und jede noch so kleine Änderung kann separat eingepflegt werden, ist rückverfolgbar und jederzeit zu ändern. VCS Systeme sind seit Jahrzehnten etabliert und in der Softwareentwicklung standard. Sie sind zudem ausgereift, stabil und open source. Setzt aber ein lesbares Protokoll voraus wie z.B. xml ;-).
X4U schrieb: > "Meine" Software würde auf ein Versionkontrollsystem (VCS) aufsetzen. > Grundbausteine sind templates, so wie es in libs schon heute realisiert > ist. Editoren (für SCH/Board/und LIB) würden nur Änderungen bearbeiten. > So wie bei Diff in Git und mercurial. Dann geht dasselbe Gemoser doch schon wieder los: die einen mögen lieber den zentralisierten Ansatz von SVN, andere bevorzugen den dezentralen Ansatz von Git, wieder andere hätten lieber gerne Hg statt Git und die Traditionalisten trauern ihrem CVS hinterher. Das ist einer der Hauptpunkte, über die ich die ganze Zeit rede: als Entwickler mußt Du Designentscheidungen treffen und sie durchhalten, denn irgendjemand meckert ohnehin immer. Das Einzige, was unser Entwickler tun kann, ist die Entscheidung so zu treffen, daß möglichst viele der vorhandenen Benutzer damit leben können.
wegen "Horizon": Abdul K. schrieb: > Ich denke er hat bei Horizon sich ne elegante Struktur ausgedacht. Nun, ich hoffe dies. Bin mir aber nicht sicher. Nach seinen Worten hat er sich gar kein fertiges Konzept ausgearbeitet, weil ihm dies zu 'statisch' ist, d.h. es veraltet ihm zu schnell und ihm fallen allzeit neue Dinge ein, die er dann programmiert. OK, vielleicht ist er ein bislang unerkanntes Genie und so ganz in seinem Inneren wächst das Konzept auf die richtige Weise. Wer weiß? Wir werden ja sehen, wie es sich denn so entwickelt. W.S.
W.S. schrieb: > OK, vielleicht ist er ein bislang unerkanntes Genie Du bist ja auch so ein Genie ;-) Bring dich bei ihm ein - zum wohle aller 'CAD FUNDIS' ;-)
Abdul K. schrieb: > Ich sehe keinen fundamentalen Unterschied zwischen Schaltplan und > Layout. Für beides könnte man Automatismen der gehobenen Art > realisieren. Und wozu? Überlappungen sind im Schaltplan was Übliches, Abstandsregeln braucht es auch nicht, das Einzige, was zählt, ist die Lesbarkeit. Und die gehorcht nicht technischen Regeln (DRC), sondern dem optischen Empfinden des Betrachters. Aber die grundsätzliche Sache mit der Netzliste ist schon in Ordnung. Netze sollen sich zwischen den Anschlüssen von Bauteilen erstrecken und es darf für das Produkt (LP) keinen Einfluß haben, ob sie sich auf dem Schaltplan berühren, kreuzen, treffen oder so. Viele Schaltplan-Editoren verletzen dieses Prinzip gröblichst. Man denke an die "Editoren" von diversen Spice-Versionen oder den Schematics-Editor von Xilinx's ISE. Die arbeiten schlichtweg koordinatenorientiert und das ist für den Benutzer eine Zumutung, denn man handelt sich unversehens Kurzschlüsse aller Art damit ein, die obendrein auch noch eklig zu beseitigen sind. Also, anstelle irgendwelcher Schaltplan-Autorouter bevorzuge ich ganz deutlich eine elegante und leistungsfähige manuelle Editierbarkeit im Schematics. Als Negativbeispiel fällt mir da Diptrace ein, wo man z.B. an ein GND-Symbol partout NICHT seitwärts herangehen kann. Wenn man das tut, macht das Programm daraus einen Mäander, versperrt damit den nächsten Raster und es sieht beschissen aus. Was die Autoren sich dabei gedacht haben, ist mir schleierhaft... __ | | --- | === So etwa. W.S.
Dergute W. schrieb: > Einzelne Durchkontaktierungen - Stichwort: Via-Stitching. Ach.. das kann das Kicad also auch nicht? W.S.
W.S. schrieb: > Also, anstelle irgendwelcher Schaltplan-Autorouter bevorzuge ich ganz > deutlich eine elegante und leistungsfähige manuelle Editierbarkeit im > Schematics. Als Negativbeispiel fällt mir da Diptrace ein, wo man z.B. > an ein GND-Symbol partout NICHT seitwärts herangehen kann. Wenn man das > tut, macht das Programm daraus einen Mäander, versperrt damit den > nächsten Raster und es sieht beschissen aus. Was die Autoren sich dabei > gedacht haben, ist mir schleierhaft... Ach was. Der automatische Route Mode in Schematic lässt sich durch Druck auf 'M' (= manuell) jederzeit abschalten (oder halt übers Kontextmenü). Aber selbst das brauchst du nicht zwangsläufig. Schiebst halt nach dem Anschluss einfach nochmal kurz den Wire so hin, wie du ihn haben willst. Das ist in unter einer Sekunde getan. Der automatische Route Mode ist in den meisten Fällen eine sehr angenehme Hilfe. Aber niemand wird bei DT gezwungen ihn auch zu benutzen.
Sheeva P. schrieb: >> Nämlich spätestens dann, wenn der oder die Entwickler ihre Phase der >> Euphorie (SW ist zu ca. 80 Prozent fertig) hinter sich haben und die >> Lust noch weitere Zeit darin zu investieren sich langsam dem Ende neigt. > > Genau, und deswegen ist alle OSS-Software nur zu 80% fertig -- ist aber > mit Ausnahme des Desktop-Marktes trotzdem nahezu überall Marktführer. > ;-) Der war gut. Den merke ich mir. "Mit Ausnahme des Desktop-Marktes überall Marktführer". :))) Klingt so wie E-Autos sind überall Marktführer (in den Entwicklungslabors von Hightech-Firmen, bei Finanzinvestoren, bei Google, Facebook uns Konsorten, natürlich bei den Grünen - mit Ausnahme des Straßenverkehrs. Über was Diskutieren wir hier nochmal gerade? EDA-Software oder? Worauf läuft EDA Zeugs nochmals gerade? Auf dem Desktop. Aber Danke für dein Statement. So schätze ich dich auch ein. Deine restlichen Antworten sprechen auch für sich. Danke fürs (sinnlose) Gespräch.
Abdul K. schrieb: > Hm, also auf dem Laptop sollt es auch gehen. Klar, Laptop ist der portable Desktop. ;) Nur Abdul, ich weiß nicht wie groß dein Läppi ist? Mein NB hat einen Screen von rund 15 Zoll. Das ist für Schaltplan und Platinenlayout nicht so wirklich komfortabel. Beim Desktop habe ich (mittlerweile) auf 27 Zoll aufgerüstet und die CPU rennt dort auch schneller. Das macht es um einiges angenehmer. Gruß
Brille schrieb: > Beim > Desktop habe ich (mittlerweile) auf 27 Zoll aufgerüstet und die CPU > rennt dort auch schneller. Das macht es um einiges angenehmer. Ellapetsch ich hab den 'Grösseren' :-) - 35" ;-) Ich meine natürliche 35" Monitor curved. Ihr mit euren Spielzeug PCs :-) bei diesem Monitor gehts Schaltplanzeichnen ganz von selber ;-) NB: Damits auch jeder versteht: Das ganze ist nicht so ernst gemeint bis auf die 35"
il Conte schrieb: > Ellapetsch ich hab den 'Grösseren' :-) - 35" ;-) > > Ich meine natürliche 35" Monitor curved. Curved hatte ich mir auch überlegt, aber Office Dokumente auf Curved war dann doch nicht so mein Fall und alles was größer als 27" ist war mir bei FHD nicht mehr geheuer und QHD war mir zu teuer (hihi, reimt sich).
Chris D. schrieb: > Aber davon ab erfüllt es bspw. auch bei uns schon seit 2006 die > professionellen Bedürfnisse zufriedenstellend. Wir verdienen unter > anderem mit KiCad unsere Brötchen. Und unsere Projekte liegen nicht im > Jahrzehntebereich ;-) und deine Beiträge sind für mich auch bisher eine der wenigen mit denen ich was anfangen kann. Schlicht aus der Praxis, wir arbeiten damit und es funktioniert. > Sheeva wollte vermutlich nur darauf hinweisen, dass man unter KiCad > durchaus auch komplexere Mehrlagen-Designs erstellen kann. Sollte da ähnlich gearbeitet wird wie bei der Großforschungsanlage mit 4 Buchstaben bei mir um die Ecke wäre das nicht gerade ein Pluspunkt ;-).
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.