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
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.