Tag zusammen. Ich falle einfach mal mit der Tür ins Haus: Es geht mir in erster Linie um die Entwicklung einer Alternative zu EAGLE, KiCAD, gEDA & Co. unter Nutzung aktueller Technologien und Bedienkonzepte. Meine persönlichen Beweggründe sind u.A. die Unzufriedenheit mit der Bedienbarkeit, Stabilität, Kompatibilität der o.g. Programme. Zudem erhoffe ich mir eine lehrreiche Ergänzung zu meinem Studium. Hier ein paar Eckdaten: - Als Plattform habe ich Eclipse vorgesehen. Z.B. als Perspektive oder als eigene RCP-Anwendung. Das Projekt wird also als reine Java-Lösung umgesetzt werden. - Für die Visualisierung soll OpenGL eingesetzt werden, welches mittlerweile von nahezu allen Grafikkarten unterstützt wird und für eine performante sowie hochwertige Darstellung auch bei komplexen Layouts herhalten soll. - Für das Bedienkonzept halte ich Poseidon for UML von Gentleware für richtungsweisend. Die Erstellung von Schaltplänen dürfte damit sehr schnell von der Hand gehen. - Bauteile können als eigene Java-Klassen implementiert werden, was generische Footprints, Packages, etc. ermöglicht. Daneben existiert natürlich auch die Variante mit dem "selber malen". - Für eine konkrete Lizenz habe ich mich noch nicht entschieden. Die Software soll quelloffen und kostenfrei werden. Es soll die Möglichkeit geben kommerzielle Plug-Ins zu erstellen. Mir ist klar, dass es sich dabei um kein Projekt handelt, was innerhalb eines Jahres einen vollwertigen Ersatz für die derzeitigen Platzhirsche bietet. Auch setze ich es mir nicht als explizites Ziel zeitnah in der Profiliga mitzuspielen - eine große Akzeptanz im Hobbybereich und an den (Hoch-)Schulen wären da realistischer. Wunschdenken: ein paar Erweiterungen, für die ich zumindest die Schnittstellen bereitstellen möchte: - Simulation der Schaltung mit wählbaren Ersatzschaltungen für die einzelnen Komponenten - Import von Komponenten oder ganzen Schaltplänen anderer Produkte - Werkzeuge zur Unterstützung für Reverse Engineering bestehender Platinen und Gerber-Daten - Eine integrierte Online-Bauteile-Datenbank mit Suchfunktionen (Webservice o.ä.) - Echtzeit 3D-Ansicht der Bauteile und Platinen - Einbettung von Mikroprozessoremulationen in die Simulation - Anbindung von JTAG an die Simulation - Autorouter, Autoplacer Die endgültige Entscheidung für oder gegen das Projekt hängt davon ab, ob sich genug Leute finden, die Interesse an einem solchen Produkt haben und die Zeit finden konstruktiv daran mitzuarbeiten. Was haltet ihr von dieser Idee, was würdet ihr euch wünschen? Wenn ich mir die anderen Threads (EAGLE vs. KiCAD vs. den Rest der Welt) so ansehe, rechne ich mit vielen Rückmeldungen ;) Schöne Grüße und danke, Kai
Interesanntes Vorhaben. Setz mal nen Prototypen auf. Ich schaus mir dann gerne an.
Ehrlich gesagt, ich halte so ein Projekt schlicht für unrealisierbar. Allein um Fehler auszumerzen braucht es Jahre. Vergleiche doch mal mit KiCAD. Wie lange hat es gebraucht um die SW auf den Stand von heute zu bringen? Wie lange wird KiCAD noch brauchen um eagle ernsthafte Konkurrenz zu bieten? Vermutlich noch ein paar Jahre. Oder vergleichen wir mal mit Abacom. Deren SW ist ja nun wirklich nicht der letzte Schrei, aber da müsste man erst mal hinkommen und wie lange hat Abacom gebraucht um überhaupt mal eine Gummiband Funktion in ihren Schaltplan Editor einzubauen? In Version 6.0 wurde das realisiert. Ich glaube so etwas wird ähnlich verlaufen wie Linux Geeks Platine (man hört und sieht nichts mehr davon). Viel Euphorie am Anfang und dann stetig Berg ab. Aber die Idee an sich ist schon toll ..
Kai Giebeler schrieb: > Tag zusammen. > > Ich falle einfach mal mit der Tür ins Haus: Es geht mir in erster Linie > um die Entwicklung einer Alternative zu EAGLE, KiCAD, gEDA & Co. unter > Nutzung aktueller Technologien und Bedienkonzepte. > > Meine persönlichen Beweggründe sind u.A. die Unzufriedenheit mit der > Bedienbarkeit, Stabilität, Kompatibilität der o.g. Programme. Zudem > erhoffe ich mir eine lehrreiche Ergänzung zu meinem Studium. Also einfach mal ganz direkt und ohne Vorbehalte aus meiner Hobbyisten-Sicht (nicht pauschal, sondern einfach so, wie das bei mir gerade aussehen würde): > Hier ein paar Eckdaten: > - Als Plattform habe ich Eclipse vorgesehen. Z.B. als Perspektive oder > als eigene RCP-Anwendung. Das Projekt wird also als reine Java-Lösung > umgesetzt werden. Eclipse läuft bei mir zu lahm da einfach zu fett geworden; die Idee mit Java ist aber sicher nicht verkehrt, damit erschlägt man einige Probleme auf einmal. Andererseits hätte C/C++ immer noch eindeutig Performance-Vorteile, vorallem für diejenigen, die nicht mit topmoderner Hardware unterwegs sind. > - Für die Visualisierung soll OpenGL eingesetzt werden, welches > mittlerweile von nahezu allen Grafikkarten unterstützt wird und für eine > performante sowie hochwertige Darstellung auch bei komplexen Layouts > herhalten soll. Vorallem 3D-Ansicht der Bauteilumrisse etc. wäre hübsch. Evtl. wäre später mal ein Povray-Export denkbar, das gäbe dann als Abschluss sogar photorealistische Bilder für den Kunden :-) > - Für das Bedienkonzept halte ich Poseidon for UML von Gentleware für > richtungsweisend. Die Erstellung von Schaltplänen dürfte damit sehr > schnell von der Hand gehen. Ich kenn das Programm leider nicht. Ich kann allerdings sagen, dass ich das Bedienkonzept von Eagle recht effizient finde. Schön wärs da, wenn man die Funktionen auf einzelne Buchstaben verlegen könnte, etwa wie in Target, aber dann dennoch auf ellenlange Menüstrukturen und etliche Kontextmenüs verzichten könnte. Unterm Strich wäre mir ein 'Erst-Werkzeug-dann-Bauteil'-Konzept immer noch am liebsten, auch wenn das schon steinalt ist. > - Bauteile können als eigene Java-Klassen implementiert werden, was > generische Footprints, Packages, etc. ermöglicht. Daneben existiert > natürlich auch die Variante mit dem "selber malen". Vorallem ist eine gutes Import/Export-Schnittstelle lebenswichtig, denn mit den Java-Klassen kann niemand sonst was anfangen. Grad für Footprints als DXF oder so, da wäre das wichtig. Könnte man ja eigentlich ratzfatz als XML-Format realisieren. > - Für eine konkrete Lizenz habe ich mich noch nicht entschieden. Die > Software soll quelloffen und kostenfrei werden. Es soll die Möglichkeit > geben kommerzielle Plug-Ins zu erstellen. > Wunschdenken: ein paar Erweiterungen, für die ich zumindest die > Schnittstellen bereitstellen möchte: > - Simulation der Schaltung mit wählbaren Ersatzschaltungen für die > einzelnen Komponenten Über die Simulation selbst würde ich mir nicht den Kopf drüber zerbrechen, das haben schon genug andre getan, ich würde auch da eine gute Schnittstelle erstellen, mit der dann irgendein Spice gefüttert wird. > - Import von Komponenten oder ganzen Schaltplänen anderer Produkte Wichtig, keine Frage. > - Werkzeuge zur Unterstützung für Reverse Engineering bestehender > Platinen und Gerber-Daten Meinethalben. Da wäre z.B. eine Funktion hübsch, die aus Bildern schonmal Netze einlesen kann (also z.B. als Schwarzweißbild erfassen und dann per Klick ein Netz hervorheben, so ähnlich, wie die 'Füllen'-Funktion in einigen Bildbearbeitungsprogrammen). > - Eine integrierte Online-Bauteile-Datenbank mit Suchfunktionen > (Webservice o.ä.) Hm, wichtiger wäre, eine sehr gute lokale Bibliothek. Wer ernsthaft arbeitet, baut sich sowieso seine eigene Bibliothek auf. Aber als Quelle für Bauteilvorlagen sicher nicht verkehrt. > - Echtzeit 3D-Ansicht der Bauteile und Platinen > - Einbettung von Mikroprozessoremulationen in die Simulation > - Anbindung von JTAG an die Simulation Auch hier: Schreib gute Schnittstellen und benutz dann ausgereifte Werkzeuge dahinter. Die Unix-Kommandozeilendinger (avrsim, ghdl, gspice...) lassen sich recht problem- und nahtlos im Backend verbauen. > - Autorouter, Autoplacer Mach dir da keine allzu große Mühe. Wichtiger wären Online-DRC/ERC und so Dinger wie Impedanzüberwachung. > Was haltet ihr von dieser Idee, was würdet ihr euch wünschen? Wenn ich > mir die anderen Threads (EAGLE vs. KiCAD vs. den Rest der Welt) so > ansehe, rechne ich mit vielen Rückmeldungen ;) Die Idee ist nicht schlecht, aber da ist viel zu tun. Überleg doch einfach mal, aus KiCAD zu forken, also den Projektstamm zu übernehmen, aufzuräumen und z.B. die Einzelprogramme bei KiCAD (Schaltplan, Layout, Zuordnung etc.) sinnvoll und ergonomisch zusammenzufügen. Wenn das mal solide steht, haste ne gute Basis. Will sagen: Erfind nicht zum 100. Mal das Rad neu (Target, Eagle, KiCAD, PCB, gEDA...), sondern nimm eines der bisherigen und verbessere es grundlegend :-)
Sven P. schrieb: >> - Für die Visualisierung soll OpenGL eingesetzt werden, welches >> mittlerweile von nahezu allen Grafikkarten unterstützt wird und für eine >> performante sowie hochwertige Darstellung auch bei komplexen Layouts >> herhalten soll. > Vorallem 3D-Ansicht der Bauteilumrisse etc. wäre hübsch. Evtl. wäre > später mal ein Povray-Export denkbar, das gäbe dann als Abschluss sogar > photorealistische Bilder für den Kunden :-) Das gibbet bei KiCAD bereits - Povray-Export sollte kein großes Problem darstellen :-) > Auch hier: Schreib gute Schnittstellen und benutz dann ausgereifte > Werkzeuge dahinter. Die Unix-Kommandozeilendinger (avrsim, ghdl, > gspice...) lassen sich recht problem- und nahtlos im Backend verbauen. > ... > Überleg doch einfach mal, aus KiCAD zu forken, also den Projektstamm zu > übernehmen, aufzuräumen und z.B. die Einzelprogramme bei KiCAD > (Schaltplan, Layout, Zuordnung etc.) sinnvoll und ergonomisch > zusammenzufügen. > Wenn das mal solide steht, haste ne gute Basis. Will sagen: Erfind nicht > zum 100. Mal das Rad neu (Target, Eagle, KiCAD, PCB, gEDA...), sondern > nimm eines der bisherigen und verbessere es grundlegend :-) Ja, so sehe ich das auch. Es ist wesentlich effizienter (und auch effektiver, wenn man davon ausgehen muss, dass der Hauptentwickler nach ein paar Monaten/Jahren keine Lust mehr hat - wie es so oft der Fall ist), Bestehendes zu verbessern. Vieles vom Gewünschten bringt KiCAD schon rudimentär mit. Wenn man sich daran beteiligt, hilft das wesentlich mehr, als PCB-Programm 1297453 aufzulegen. Chris D.
Als Einseitig-Handaetzer faende ich eine Semi-Autorouting-Funktion, die einen Befehl der Art "Nimm diese 8 Leitungen und fuehr sie unter U666 durch, dann diese 5 zwischen den Pins von U0815 aber halt dich rechts, dann die HC574 ala Loch Ness, diese da bitte parallel, und da nimm Null-Ohm-Widerstaende, und gehe notfalls auf 8/8 Regeln von 12/10 runter wenn es nicht anders geht..." verstehen kann, schon toll...;)
> Eclipse läuft bei mir zu lahm da einfach zu fett geworden; die Idee mit > Java ist aber sicher nicht verkehrt, damit erschlägt man einige Probleme > auf einmal. > Andererseits hätte C/C++ immer noch eindeutig Performance-Vorteile, > vorallem für diejenigen, die nicht mit topmoderner Hardware unterwegs > sind. Ich halte die Flexibilität und Erweiterbarkeit von Eclipse für einen sinnvollen Resourceneinsatz. Diejenigen Geräte, die nicht genügend Performance aufweisen können sind mit den bestehenden Lösungen (KiCAD, ...) vermutlich besser bedient. Ich habe aber in letzter Zeit kaum noch mit Rechnern gearbeitet, auf denen Eclipse unerträglich langsam lief. > Vorallem 3D-Ansicht der Bauteilumrisse etc. wäre hübsch. Evtl. wäre > später mal ein Povray-Export denkbar, das gäbe dann als Abschluss sogar > photorealistische Bilder für den Kunden :-) Ich möchte das auf jeden Fall mit anbieten. Wenn die Modelle einmal da sind, ist der POVRAY-Export eine Kleinigkeit. > >> - Für das Bedienkonzept halte ich Poseidon for UML von Gentleware für >> richtungsweisend. Die Erstellung von Schaltplänen dürfte damit sehr >> schnell von der Hand gehen. > Ich kenn das Programm leider nicht. Beim "Überfahren" des Bauteils mit der Maus werden alle typischen Funktionen direkt beim Bauteil angeboten (z.B. Leiterbahn ziehen, mit Masse verbinden) - muss halt noch ausgearbeitet werden. http://www.gentleware.com/fileadmin/media/viewlets/text/CreateClassesShort.viewlet/CreateClassesShort_viewlet_swf.html > Ich kann allerdings sagen, dass ich > das Bedienkonzept von Eagle recht effizient finde. Schön wärs da, wenn > man die Funktionen auf einzelne Buchstaben verlegen könnte, etwa wie in > Target, aber dann dennoch auf ellenlange Menüstrukturen und etliche > Kontextmenüs verzichten könnte. > Unterm Strich wäre mir ein 'Erst-Werkzeug-dann-Bauteil'-Konzept immer > noch am liebsten, auch wenn das schon steinalt ist. Ich denke, dass es hier den größten Diskussionsbedarf geben wird. Als Photoshop/GIMP-Benutzer bin ich auch ein großer Freund von Tastenkürzeln als Alternative zu Werkzeugleisten und Untermenüs. Eclipse bietet mit den Views eine äußerst effektive Möglichkeit auf Popups und Untermenüs zu verzichten - diese muss nur sinnvoll genutzt werden. > Vorallem ist eine gutes Import/Export-Schnittstelle lebenswichtig, denn > mit den Java-Klassen kann niemand sonst was anfangen. Grad für > Footprints als DXF oder so, da wäre das wichtig. Könnte man ja > eigentlich ratzfatz als XML-Format realisieren. Bei den Klassen werden auch diverse generische Ansätze dabei sein, die externe Bibliotheken/Dateien transparent in die Anwendung einblenden. Die Behandlung einer nachträglichen Änderung externer Beschreibungen wird ein eigenes komplexes Thema werden. >> Wunschdenken: ein paar Erweiterungen, für die ich zumindest die >> Schnittstellen bereitstellen möchte: >> - Simulation der Schaltung mit wählbaren Ersatzschaltungen für die >> einzelnen Komponenten > Über die Simulation selbst würde ich mir nicht den Kopf drüber > zerbrechen, das haben schon genug andre getan, ich würde auch da eine > gute Schnittstelle erstellen, mit der dann irgendein Spice gefüttert > wird. So war der Plan ;) >> - Werkzeuge zur Unterstützung für Reverse Engineering bestehender >> Platinen und Gerber-Daten > Meinethalben. Da wäre z.B. eine Funktion hübsch, die aus Bildern > schonmal Netze einlesen kann (also z.B. als Schwarzweißbild erfassen und > dann per Klick ein Netz hervorheben, so ähnlich, wie die > 'Füllen'-Funktion in einigen Bildbearbeitungsprogrammen). Ich hatte vorerst die Darstellung als Hintergrundbild (Wasserzeichen) überlegt, welches man dann nachzeichnen kann - simpel aber manchmal hilfreich. Die automatische Vektorisierung wäre dann der nächste Schritt. > Hm, wichtiger wäre, eine sehr gute lokale Bibliothek. Wer ernsthaft > arbeitet, baut sich sowieso seine eigene Bibliothek auf. Aber als Quelle > für Bauteilvorlagen sicher nicht verkehrt. In der Oberfläche wird nicht zu erkennen sein, ob die Bibliothek lokal oder remote ist. Beides ist aber auf jeden Fall möglich. >> - Echtzeit 3D-Ansicht der Bauteile und Platinen >> - Einbettung von Mikroprozessoremulationen in die Simulation >> - Anbindung von JTAG an die Simulation > Auch hier: Schreib gute Schnittstellen und benutz dann ausgereifte > Werkzeuge dahinter. Die Unix-Kommandozeilendinger (avrsim, ghdl, > gspice...) lassen sich recht problem- und nahtlos im Backend verbauen. Daher hatte ich ja geschrieben, dass ich vorerst nur die Schnittstellen bereitstellen will. >> - Autorouter, Autoplacer > Mach dir da keine allzu große Mühe. Wichtiger wären Online-DRC/ERC und > so Dinger wie Impedanzüberwachung. Danke, DRC/ERC hatte ich vergessen zu erwähnen! > Die Idee ist nicht schlecht, aber da ist viel zu tun. Ich weiß - in der Komplexität sehe ich weniger das Problem. Die politischen Probleme machen mir da mehr Sorgen. Ebenso der lange Zeitraum. > Überleg doch einfach mal, aus KiCAD zu forken, also den Projektstamm zu > übernehmen, aufzuräumen und z.B. die Einzelprogramme bei KiCAD > (Schaltplan, Layout, Zuordnung etc.) sinnvoll und ergonomisch > zusammenzufügen. > Wenn das mal solide steht, haste ne gute Basis. Will sagen: Erfind nicht > zum 100. Mal das Rad neu (Target, Eagle, KiCAD, PCB, gEDA...), sondern > nimm eines der bisherigen und verbessere es grundlegend :-) Ich hatte seinerzeit beim KiCAD-Entwickler nachgefragt aber keine Rückmeldung bekommen. Der Quelltext ist für meine Begriffe eine einzige Katastrophe. Ich habe die letzten 8 Jahre von berufswegen Altlasten-Software am Leben erhalten oder wiederbelebt. Am Ende kam immer dasselbe raus: Neuentwicklung wäre billiger gewesen. Meine Idealvorstellung von der Software geht in eine andere Richtung als KiCAD, EAGLE & Co. Mir geht es gezielt um die Integration in Eclipse/Java und die damit verbundenen Vorteile. Ich kann von den bestehenden Projekten daher leider nicht viel nutzen. Das Argument mit dem durchhalten sehe ich ein. Auch wenn so ein Projekt theoretisch von einer Person gestemmt werden kann, so bedarf es in der Praxis doch immer der Motivation durch andere. Danke für das Feedback soweit, Kai
So, mal Abo, will ja mitbekommen, in wievielen Tagen hier aufgegeben wird :P
Kai Giebeler schrieb:
> Nach habe ich offiziell nicht angefangen ;)
Ich denke das wird sich als das eigentliche Problem herausstellen.
Hier im Forum hast Du schnell einen Haufen leute, die alles besser
wissen und Dir jedes Projekt madig machen, aber Du wirst kaum jemand
finden, der mit anpackt.
Am besten Du setzt Dich hin und baust nen Prototypen. Wenn mal das
Grundgerüßt steht, dann kann man auch mal dran gehen, die Aufgaben zu
verteilen.
Viel Glück,
ich beobachte den Thread weiter und falls es sich ergibt kann ich Dich
auch bei der Entwicklung unterstützen.
>Ich denke das wird sich als das eigentliche Problem herausstellen. >Hier im Forum hast Du schnell einen Haufen leute, die alles besser >wissen und Dir jedes Projekt madig machen, aber Du wirst kaum jemand >finden, der mit anpackt. Damit hatte ich aber gerechnet - habe lange überlegt, ob ich vor Projektbeginn hier reinhorchen soll. Bisher bin ich mit den Rückmeldungen aber recht zufrieden. >Viel Glück, >ich beobachte den Thread weiter und falls es sich ergibt kann ich Dich >auch bei der Entwicklung unterstützen. Danke!
Abo! Und ich würde das Projekt auch auf jeden Fall im Rahmen meiner zeitlichen Möglichkeiten unterstützen! Klingt sehr interessant.
@Kai Giebeler >Ich falle einfach mal mit der Tür ins Haus: Es geht mir in erster Linie >um die Entwicklung einer Alternative zu EAGLE, KiCAD, gEDA & Co. unter >Nutzung aktueller Technologien und Bedienkonzepte. Hallo Kai, ich habe lediglich die drei obigen Zeilen gelesen, aber... Dir sollte klar sein, dass so eine Entwicklung sehr, sehr viel Aufwand ist. Bis man etwas halbwegs brauchbares hat vielleicht 5k Stunden harte Arbeit, dann mag es von der Funktionalität vielleicht in etwa gEDA oder Kicad entsprechen, mit einem etwas moderneren Look. Und von den Leuten hier kannst Du sicher keine Hilfe Erwarten, allenfalls Wünsche und Meckerei. Was vielleicht realistischer ist: Beteilige Dich an gEDA (oder KiCad). Da kann man vieles machen. Etwa eine völlig neue graphische Oberfläche. Einsatz von OpenGL ist ja in den Entwicklerversionen schon vorhanden. Der neue topologische Autorouter ist sehr beeindruckend.
Also wie gesagt, den Java-Ansatz find ich nicht verkehrt, aber Eclipse muss es mit meinem Willen nicht sein -- darum gehts aber natürlich nicht :-) Ich gestehe aber offen: Das letzte Mal habe ich Eclipse vor zwei Jahren probiert und da waren 512MB Arbeitsspeicher nicht genug -- es hat diese und dazu die Swap-Partition vollgeknallt und ist dann abgestürzt. Das kann natürlich auch ein (Konfigurations-)Fehler gewesen sein, ich habs out-of-the-box gestartet. Wenn sich das WESENTLICH gebessert hat, probier ichs gerne nochmal aus :-)
Sven P. schrieb: > Wenn sich das WESENTLICH gebessert hat, probier ichs gerne nochmal aus > :-) Eclipse ist hier bei uns das täglich Brot, ohne Eclipse könnt ich mir eine effiziente Softwareentwicklung schon nicht mehr vorstellen ;-). Man darf natürlich nicht geizig sein was die zugeteilten Resourcen angeht (eclipse.ini anpassen) ... Wir entwickeln unter anderem auch Eclipse-Plugins und das Konzept ist da schon sehr durchdacht. Ich könnte mir also sehr gut vorstellen so ein Tool auf die Beine zu stellen, klar, mit 2 Wochenend-Programmierern wird das nicht in einem Jahr fertig ...
Jens Krause schrieb: > Sven P. schrieb: >> Wenn sich das WESENTLICH gebessert hat, probier ichs gerne nochmal aus >> :-) > > Eclipse ist hier bei uns das täglich Brot, ohne Eclipse könnt ich mir > eine effiziente Softwareentwicklung schon nicht mehr vorstellen ;-). Ich kann mich dem nur anschließen und ich arbeite bereits seit min. 8 Jahren damit.
Vielleicht erst mal sowas wie tinycad erstellen? Das ist schon aufwendig genug. ;)
Nette Idee, aber man muß auch davon leben können. Als Hobby verliert es wahrscheinlich irgendwann seinen Reiz. Vorstellen kann ich mir so etwas wie beim Opensource-Browser Firefox den man mit zusätzlichen Plug-Ins, Add-ons/blogs oder so selbst zusammenstellen kann. Die Community müßte dann schon Weltweit dafür tätig sein und Normen müßten dann auch eingehalten werden. Viele Spaß beim Erstellen eines Lastenheftes. Als Tester bin ich gern dabei.
>Autor: Schwups... (Gast) >Datum: 29.07.2009 18:23 >Nette Idee, aber man muß auch davon leben können. Naja, vom Dummschwätzen können wir auch nicht leben -- trotzdem tun wir es mit Begeisterung...
>Vielleicht erst mal sowas wie tinycad erstellen? Das ist schon aufwendig >genug. ;) Hatte ich mir als erste Stufe auch überlegt. Ist ein guter Meilenstein.
Kai Giebeler (Firma: SettleBack GbR) (runtimeterror) wrote: >>Vielleicht erst mal sowas wie tinycad erstellen? Das ist schon aufwendig >>genug. ;) > Hatte ich mir als erste Stufe auch überlegt. Ist ein guter Meilenstein. Der Editor reicht zwar gefühlsmäßig nicht an eagle heran, aber das Ding funktioniert ganz gut. Ist gerade von der alten Codebasis auf VS 2008 portiert worden (Express ging wohl nicht wegen der fehlenden MFC). http://tinycad.svn.sourceforge.net/viewvc/tinycad/TinyCAD/trunk/src/ aktuell jetzt Latest Stable Build TinyCAD Version 2.70.00 Build 248 Beta Release file released: TinyCAD_2.70.00.248_Beta_Setup.exe
Wobei der MFC-Blödsinn natürlich jegliche Portabilität wieder abknallt :-/
Sven P. (haku) wrote: > Wobei der MFC-Blödsinn natürlich jegliche Portabilität wieder abknallt > :-/ Na ja, der ursprüngliche Code war halt mit Hilfe der MCF und wohl VC 6.0 geschrieben und die Hilfe verwendet den MS HTML Help Workshop. Ist also alles "en wenig" MS lastig ;). So wie ich das in den Build Anweisungen gelesen habe gibt es theoretisch auch die Möglichkeit mit gcc und dem "Microsoft toolset" (was immer das ist) zu compilieren, wozu er aber um Hilfe bat bzw. nachtragt, ob das jemandem gelungen ist. Er hat halt bug fixes unternommen und will wohl weiter an TinyCad arbeiten.
Sven P. schrieb: > Wobei der MFC-Blödsinn natürlich jegliche Portabilität wieder abknallt > :-/ Das Projekt kann man anscheinend sowieso nicht unter Linux/Unix kompilieren, da Groß/Kleinschreibung der Dateinamen bei den #includes ignoriert wurde.
Wie auch immer, bis auf das MFC sind das wohl minimale Hürden :-)
also ICH fände deine idee geil, beim lesen hab ich zwar auch gedacht "hmm wieso nimmst du nich kicad und baust das weiter auf" aber du hast ja anscheinend gute gründe das nich zu tun. wenn du das hobbymäßig machen möchtest wärs viell. ne gute idee einfach mal anzufangen und schauen ob es nach ein paar monaten noch spass macht und man weit kommt.. im schlimmsten fall hast du dann wie gesagt ein paar WE's vergeudet;) wenn du es kommerziell machen willst, dann kann ich dazu nix sagen.. ich hoffe du lässt dich nich entmutigen und es finden sich leute die die fähigkeiten und lust haben die zu helfen (mir fehlt es eindeutig an ersterem) ;)
>ich hoffe du lässt dich nich entmutigen und es finden sich leute die die >fähigkeiten und lust haben die zu helfen (mir fehlt es eindeutig an >ersterem) ;) Am Anfang sind erstmal gute Ideen und Anregungen gefragt - das ist zwar auch nicht jedermanns Sache, aber filtern kann man ja immer noch ;) Beim technischen Teil werde ich wohl erstmal in Vorkasse gehen (-> Prototyp) und dann mal die Resonanz abwarten. Entgegen dem obigen Post ist das Lastenheft nicht allein meine Aufgabe sondern die der späteren potenziellen Nutzer (wozu ich mich natürlich auch zähle).
Habe auch so was in der Schublade, basierend auf FreePCB. Mein Plan ist, in FreePCB eine VM einzubauen, und dann darauf aufzubauen. Derzeit bin ich fast fertig, das Programm auf eine Plattformunabhängige Programmierumgebung zu portieren. Vorteil, recht gut aufgebaut, offenes Format sowie Biblotheken.
Hi chris, hört sich ja interessant an. >Mein Plan ist, in FreePCB eine VM einzubauen, und dann darauf >aufzubauen. Wie habe ich mir das vorzustellen? Was soll die VM leisten?
Die VM soll skripte sowie Funktionalität im Stil von BAE sowie EAGLE erlauben, wobei es eher an BAE als an Eagle angelehnt sein wird. Als VM ist die von Quake v3 vorgesehen. Vorteil ist, viele Funktionen lassens sich unabhängig von der Core ändern, ohne die Core-Funktionalität zu ändern. Beispiele sollten z.B. die grafische Anzeige der ungerouteten Netze auf der Platine, wie bei BAE sein, oder der Autoplacer, usw. Es erlaubt viel Flexibilität.
> VM von Quake v3
Nimm doch gleich die komplette Engine, dann kann ich auch in First
Person Perspektive mit ner Wumme über die Platine laufen und DRC Errors
abknallen! ;)
SCNR
> Nimm doch gleich die komplette Engine, dann kann ich auch in First > Person Perspektive mit ner Wumme über die Platine laufen und DRC Errors > abknallen! ;) Ich schmeiß mich weg! Als Waffe gibt's nen Lötkolben mit passender Munition. Ich sag nur "Via has been planted!" oder "Double drill!"
Kai Giebeler schrieb: >> Nimm doch gleich die komplette Engine, dann kann ich auch in First >> Person Perspektive mit ner Wumme über die Platine laufen und DRC Errors >> abknallen! ;) > > Ich schmeiß mich weg! > Als Waffe gibt's nen Lötkolben mit passender Munition. > Ich sag nur "Via has been planted!" oder "Double drill!" M-m-m-m-monster-Drill!
Es ist nur die VM, eine komplette, die wenn der code gut ist, dann kann man den im C-compiler compilieren, und er läuft schneller. Die VM ist besser und performanter als andere VM´s.
Ich finde die Idee es mit Java zu machen sehr gut. Es gibt doch schon paar fertige CADs in Java wie z.B.: http://sourceforge.net/search/?type_of_search=soft&words=java+cad Ich schlage vor alles was zu gebrauchen ist nehmen und daraus ein PCB CAD bauen. Bei einem Interface zu Boundary-Scan bin ich bereit mit zu arbeiten. mfg Johann
> M-m-m-m-monster-Drill!
Oberlehrer:
Nein DAS war bei Unreal Tournament :-> :P ;)
Quad-Dam... ääh Layer ;)
Kai Giebeler schrieb: > - Als Plattform habe ich Eclipse vorgesehen. > als eigene RCP-Anwendung. Schon scheiße. Du kannst natürlich versuchen jegliches Schlagwort der letzten paar Jahre irgendwie unterzubringen, das ergibt dann eine große, langsame Anwendung, die in ein paar Jahren vergammelt. Dann nämlich, wenn die Informatiker mit neuen Hirnfürzen gekommen sind und RCP als falsch, uncool und veraltet gilt und dir niemand mehr deine Plattform wartet. Abgesehen davon, was soll ein Framework taugen, das, nur um Schlagwort-Kompatibel zu sein, aus einem ziemlich verwursteten Framework für eine IDE hervorgegangen ist, von der schon lange keiner mehr weiß wie alle Einzelteile funktionieren und korrekt zu verwenden sind? > Das Projekt wird also als reine Java-Lösung > umgesetzt werden. Grade jetzt ebenfalls nicht die beste Entscheidung. Sun wird gerade an Orcale verkauft und niemand weiß, was Oracle von Sun übrig lässt oder wegwirft. Hinzu kommt, dass ein paar durchgeknallte Bunti-Bunti-Fetischisten bei Sun es geschaft haben, dass das für gewöhnliche Anwendungen halbwegs brauchbare Swing GUI-Toolkit nicht mehr gepflegt wird. Statt dessen haben sie einen ein Deck der sich JavaFX nennt, und nur was für Kiffer in Werbeagenturen ist, durchgedrückt. Zu Eclipse eigenem Müll sag ich nichts. > - Für die Visualisierung soll OpenGL eingesetzt werden, welches > mittlerweile von nahezu allen Grafikkarten unterstützt wird und für eine > performante sowie hochwertige Darstellung auch bei komplexen Layouts > herhalten soll. Dein Problem ist nur, dass Java's OpenGL-Binding nicht Teil von Standard-Java ist (JSR 231) und du damit auf den guten Willen von Platform-Portierern angewiesen bist, ob du das Binding auf einer Platform zur Verfügung hast. Ob das alles dann in Eclipse passt ist noch ein ganz anderes Problem. > - Für das Bedienkonzept halte ich Poseidon for UML von Gentleware für > richtungsweisend. Die Erstellung von Schaltplänen dürfte damit sehr > schnell von der Hand gehen. Buzzwords :-( > - Bauteile können als eigene Java-Klassen implementiert werden, was > generische Footprints, Packages, etc. ermöglicht. Völlig an der Zielgruppe vorbei. Warum um Himmelswillen sollen Platinen-Designer Java-Klassen schreiben wollen, nur um einen dusseligen Footprint zu bekommen? Mehr Zeitverschwendung geht doch gar nicht. Das wird dann nur was für Fanboys, die sich einen dran runterholen, wie geil und obskur ("trickreich") sie irgend ein Bauteil implementiert haben.
Und? Geht's dir jetzt besser? Mit so einen Beitrag habe ich eigentlich viel früher gerechnet.
Kai Giebeler schrieb: > Und? Geht's dir jetzt besser? > Mit so einen Beitrag habe ich eigentlich viel früher gerechnet. Aeh... Und wenn er Recht hat? Naja, machste mal, ne? ;)
> wenn die Informatiker mit neuen Hirnfürzen gekommen sind und RCP als > falsch, uncool und veraltet gilt und dir niemand mehr deine Plattform > wartet. > ... von der schon lange keiner mehr weiß >wie alle Einzelteile funktionieren und korrekt zu verwenden sind? Informier dich mal über OSGi und IBM RAD und argumentier dann nochmal. > Sun wird gerade an Orcale verkauft und niemand weiß, was Oracle von Sun > übrig lässt oder wegwirft. Immer noch kein Todesurteil: http://de.wikipedia.org/wiki/Java_%28Programmiersprache%29#Java_als_freie_Software > Zu Eclipse eigenem Müll sag ich nichts. Klar, könnte ja performanter abschneiden und von den Benutzern besser akzeptiert werden ... > Dein Problem ist nur, dass Java's OpenGL-Binding nicht Teil von > Standard-Java ist (JSR 231) und du damit auf den guten Willen von > Platform-Portierern angewiesen bist, ob du das Binding auf einer > Platform zur Verfügung hast. Sehe ich auch als Problem. Die wichtigen Plattformen werden aber mitgezogen werden. Auf Toastern muss das Programm nicht laufen. > Buzzwords :-( Buzzword! >Völlig an der Zielgruppe vorbei. Warum um Himmelswillen sollen >Platinen-Designer Java-Klassen schreiben wollen, Wollen die nicht und müssen die auch nicht. Lies auch noch den Rest. @haku >Aeh... Und wenn er Recht hat? Naja, machste mal, ne? ;) Der Ton macht die Musik. Gruß, Kai
Kai Giebeler schrieb: > Und? Geht's dir jetzt besser? > Mit so einen Beitrag habe ich eigentlich viel früher gerechnet. >@haku >>Aeh... Und wenn er Recht hat? Naja, machste mal, ne? ;) >Der Ton macht die Musik. [Paul Panzer] Richtig! [/Paul Panzer]
> Entwicklung einer Alternative zu EAGLE, KiCAD, gEDA & Co. unter > Nutzung aktueller Technologien und Bedienkonzepte Gute Idee, es würde ja schon reichen, die Bedienkonzepte von vor 20 Jahren endlich mal zu einfliessen zu lassen, es müssten gar nicht mal die neuesten sein (was sind die aktuellen? iPhone Multi-Touch Gestures? Wii Bauteilschubsen? Quantenalgorithmen im Autorouter? Nun, zumindest könnte man die Graphikkarte als Router-Engine nutzen, das sollte die Ergebnisse gegenüber der Konkurrenz DRASTISCH verbessern) ABER: Bevor du anfängst, überlege, warum du das 61te zu dieser Liste http://www.terrypin.dial.pipex.com/ECADList.html hinzufühen willst, und analysiere, was an den 60 anderen falsch ist und was du besser machen willst. Denn die meisten Fehler wurden schon gemacht, die musst du nicht unbedingt wiederholen. Du wirst sie erst dann nicht wiederholen, wenn du sie kennst, denn unterschätze die anderen nicht, die waren nicht dümmer als du.
Hm, was finde ich an Eagle doof? -Auf jeden Fall die dezentrale Verwaltung der Footprints, statt jedes Gehaeuse einmal in Ref-Packages zu haben, kopiert man es in jede Lib -Warum kann ich zB ripup auf einen AVR anwenden?! -Warum werden die gerade bearbeiteten Dinge nicht im anderen Teil des Programms (Board/Schematic) hervorgehoben? Argh, habe keine Lust mehr weiterzumachen, gute Nacht.
Hi MaWin, danke für die Liste! Werde mal ein wenig darin stöbern. Wenn man die Liste auf die Produkte reduziert, die hier im Forum Erwähnung finden, sieht's nicht mehr ganz so düster aus ;) @dude Jo, ich habe auch noch ein paar davon ;) N8
Mal ganz ehrlich: Wie viele Jahrzehnte hast du denn für das Projekt geplant?
Vom jetzigen Standpunkt aus geschätzt: Das vorläufige Ziel ist, dass es nach etwa einem Jahr für die Erstellung von einfachen Schaltplänen verwendet werden kann. Ein Jahr drauf dann das PCB-Layout und genügend Schnittstellen, damit sich auch andere daran austoben können. Fertig im Sinne von Feature-Complete wird es vermutlich nie.
Auch wenn es blöd klingt, aber inzwischen mutiert der Thread mal wieder zu einem destuktiven Geschwätz. Mach ein Projekt auf, zb. bei Sourceforge, und poste ab und an mal den Status. Du wirst sehen, dass die meisten noch nicht mal fähig sind, sich aus einem Repository die Sourcen zu ziehen. Geschweige den den Prototypen zum laufen zu kriegen. Und das trennt schon mal die Spreu vom ....
>Mach ein Projekt auf, zb. bei Sourceforge, und poste ab und an mal den >Status. http://sourceforge.net/projects/jdso/
nur mal ein kleiner Vergleich http://qucs.sourceforge.net/news.html 8 Dec 2003 Released Qucs 0.0.1 ! ... 29 Mar 2009 Added phototransistor .. 6 Jahre !! Immerhin man sieht was .. http://qucs.sourceforge.net/screenshots.html .. aber dennoch, gerade mal bei Version 0.05 angekommen !!! (wer würde dieser Versionsnummer vertrauen und sein SwitcherCad dafür links liegen lassen?) .. und ich behaupte mal, diese Anwendung ist lange nicht so komplex wie eine EDA Software .. 12 Entwickler arbeiten daran !! http://qucs.sourceforge.net/devs.html Kai ich bewundere deinen Mut, aber nicht deinen Verstand (letzteres war in freundschaftlichem, ehrfurchstvollen Respekt gemeint ;))
>> Ich sag nur "Via has been planted!" oder "Double drill!" >M-m-m-m-monster-Drill! ULTRA Drill. ;)
Moin, gerade diese Diskussion entdeckt ... @Kai Hast Du schon mal einen Editor für grafische Objekte mit Java/Eclipse erstellt? ... und Du willst Eagle in Sache Performance schlagen? Keine Frage, ich kann mir den Alltag ohne Eclips auch kaum noch vorstellen, aber das hat mit Sicherheit keine Performancegründe! Ich habe einen solchen Editor geschrieben und bin auch recht zufrieden damit, aber an die Antwortzeiten von Eagle kommt der nicht heran. Vielleicht liest Du mal auf den news-Servern von cadsoft, bevor Du Dein Projekt angehst. Cadsoft hatte massiv Probleme, als sie ihre eigene Grafikengine gegen QT ausgetauschten. Die meisten Probleme wurden von QT importiert - und wen wundert es da, dass Cadsoft inzwischen große Teile von QT gepatcht hat. Dass die Oberfläche von Poseidon PCB-Entwickler erfreut, wage ich doch ganz stark zu bezweifeln. In Eagle sind Tasten und Mausgesten mehrfach belegt, vieles sogar kontextabhängig - so ganz subjektiv: viel besser geht es nicht. Klar gibt es einiges, was mir fehlt, aber das steht auf einem anderen Blatt. Viele Probleme, die ein zügiger, routinierter Anwender von Eagle produziert, kann sich ein Software-Entwickler nicht im Traum vorstellen. Deshalb nur den guten Rat: lies mal, welche Probleme Cadsoft im letzten Jahr behoben hat. Übrigens, die Cadsoft-Mannschaft ist über die News-Server sehr aktiv und man kann dort auch Verbesserungsvorschläge / Änderungswünsche anbringen. Nein - ich gehöre nicht zu Cadsoft und habe mit denen auch nix am Hut. ... außer vielleicht, dass ich großen Respekt vor der Arbeit von K.Schmidinger habe.
Kai Giebeler schrieb: > @haku >>Aeh... Und wenn er Recht hat? Naja, machste mal, ne? ;) > Der Ton macht die Musik. Hm, was genau hab ich jetzt damit zu tun? Wobei ich statt der Quark-VM doch irgendwie mit Lua/Python/Ruby glücklicher wäre.
Entschuldige Sven - hatte den Fehler zu spät zum Korrigieren bemerkt :/ Du warst gar nicht gemeint.
@Kai Giebeler: Wie alt bist du denn? Es ist ja schön das es solch Traumtänzer gibt wie Dich, aber das Projekt ist zum scheitern verurteilt. >- Import von Komponenten oder ganzen Schaltplänen anderer Produkte nicht realisierbar, Du bekommst keine Infos von den Herstellern und Reverse Engineering --> wie viel Jahrtausende sol denn das dauern? >Werkzeuge zur Unterstützung für Reverse Engineering bestehender >Platinen und Gerber-Daten Es gibt im OpenSource bereich nix gescheites um Gerberdaten auch nur rudimentär zu bearbeiten, noch nicht mal einen gescheiten Viewer. Warum wohl? Mir gehts nicht darum Dich zu entmutigen, aber bleib mal auf dem Teppich. Ich hätt auch gerne eine alternative zu Eagle, müßte manchmal fremde Projekte in Eagle importieren. Nach Anfragen beim dortigen Support ist es aber leider nicht realisierbar, was ich nachvollziehen kann.
täglich-8h-eagle-user schrieb: > @Kai Giebeler: > Wie alt bist du denn? > Es ist ja schön das es solch Traumtänzer gibt wie Dich, aber das Projekt > ist zum scheitern verurteilt. > >>- Import von Komponenten oder ganzen Schaltplänen anderer Produkte > nicht realisierbar, Du bekommst keine Infos von den Herstellern und > Reverse Engineering --> wie viel Jahrtausende sol denn das dauern? > >>Werkzeuge zur Unterstützung für Reverse Engineering bestehender >>Platinen und Gerber-Daten > Es gibt im OpenSource bereich nix gescheites um Gerberdaten auch nur > rudimentär zu bearbeiten, noch nicht mal einen gescheiten Viewer. Warum > wohl? > > Mir gehts nicht darum Dich zu entmutigen, aber bleib mal auf dem > Teppich. Ich hätt auch gerne eine alternative zu Eagle, müßte manchmal > fremde Projekte in Eagle importieren. Nach Anfragen beim dortigen > Support ist es aber leider nicht realisierbar, was ich nachvollziehen > kann. full ack... Um was konstruktives Beizutragen: Warum schreibst du nicht erstmal fuer Eagle ein Script/ULP, welches eine beliebige, in dieser Form realisierbare Funktion deines Wunsches hinzufuegt? Wenn - Falls das irgendwann laeuft, sehen wir weiter ;)
Hi,
habe immer wieder die Erfahrung gemacht, dass gute Ideen an der
Komplexitaet des Projekts scheitern. Ansich scheint mir der Ansatz in
Java nicht schlecht, aber bei der Performance wirds ein gewaltiges
Problem geben, die eigentliche Engine wuerde ich auf jeden Fall in C/C++
machen.
Nun zur Komplexitaet: Der Teufel steckt im Detail - sofern Du nicht
bereits eine grosse Bibliothek an CAD-Routinen zur Verfuegung hast,
investierst du da mehrere Mannjahre.
Die einzige Moeglichkeit, solche Grossprojekte zu stemmen, sehe ich in
der Verheiratung diverser Bibliotheken und Routinen via Python
Scripting.
D.h. die wichtigen Kernroutinen ('Kernel') und Bibliotheken werden
mittels C-Wrappern gekapselt und per Python 'verklebt'. Gerade wenn man
alleine an einem Projekt arbeitet, ist das m. E. die effizienteste
Entwicklungsmethode, allerdings kriegt man sowas nicht an einer Uni
beigebracht.
Mein Tip waere allerdings auch, nicht das Rad neu zu erfinden, sondern
besser von kicad oder geda auszugehen und um eigene Funktionen zu
erweitern. Das duerfte schon komplex genug sein..
Gruss,
- Strubi
Kai Giebeler schrieb:
>Fertig im Sinne von Feature-Complete wird es vermutlich nie.
Solche "Dauerbrenner" gibt es schon genug. Sourceforge ist regelrecht
zugemüllt mit Projekten, die Jahrelang nicht bearbeitet bzw. die nie
fertiggestellt werden. Verschone uns bitte mit einer weiteren Totgeburt.
Um ein Projekt wie von dir geplant zu realisieren braucht es Ressourcen
in Quantitäten über die du nicht verfügst.
Ich versuche mal mit dem Anworten hinterher zu kommen: >Hast Du schon mal einen Editor für grafische Objekte mit Java/Eclipse >erstellt? Java und andere Sprachen ja, Eclipse nein. >... und Du willst Eagle in Sache Performance schlagen? Nein - sie soll nur reichen um flüssig damit zu arbeiten. >Keine Frage, ich kann mir den Alltag ohne Eclips auch kaum noch >vorstellen, aber das hat mit Sicherheit keine Performancegründe! Ich setze das Projekt auch nicht aus Performancegründen auf eclipse auf. >Vielleicht liest Du mal auf den news-Servern von cadsoft, bevor Du Dein >Projekt angehst. Gute Idee. >Dass die Oberfläche von Poseidon PCB-Entwickler erfreut, wage ich doch >ganz stark zu bezweifeln. In Eagle sind Tasten und Mausgesten mehrfach >belegt, vieles sogar kontextabhängig - so ganz subjektiv: viel besser >geht es nicht. Klar gibt es einiges, was mir fehlt, aber das steht auf >einem anderen Blatt. Ich fand es bei der ersten Einarbeitung eine Katastrophe. Mittlerweile kann ich damit arbeiten, aber zufrieden bin ich nicht. Visio, Photoshop, Poseidon, GIMP gehen mir sehr viel schneller von der Hand und ich musste kein Tutorial lesen. Um es nochmal klarzustellen: mir geht es um keinen Wettkampf mit einem anderen etablierten Programm. Wer mit seinem Programm glücklich ist soll dabei bleiben. Für alle anderen möchte ich lediglich eine Alternative mit anderen/neueren Ansätzen schaffen. Und noch was. Die ganzen Funktionen an denen sich hier alle hochziehen sind explizit unter "Wunschdenken" aufgeführt und ich habe lediglich zugesagt die nötigen Schnittstellen bereitzustellen. (Versuche nachher noch den Rest zu beantworten)
>mir geht es um keinen Wettkampf mit einem >anderen etablierten Programm. Wer mit seinem Programm glücklich ist soll >dabei bleiben. Für alle anderen möchte ich lediglich eine Alternative >mit anderen/neueren Ansätzen schaffen. Hier widersprichst Du Dich selber! Eine Alternative für unzufriedene User zu entwicklen ist ein Wettkampf mit den Etablierten. gez. ein Schuster
Anstatt ein neues Programm anzufangen, solltest Du lieber an einem Anderen mitarbeiten. Such Dir das Beste raus und verbessere das lieber. Damit bringst Du das Projekt weiter und Du wirst nicht nach X Wochen aufgeben mit dem 61. CAD Programm.
Ich kann den Wunsch nach etwas "Neuem" schon verstehen, und wenn Kai gut ist und ein paar Jahre Vollzeit dran arbeitet ist es auch nicht völlig unrealistisch -- aber auch nur weil man bei KiCAD und gEDA abgucken kann und bei Fragen vermutlich dort auch Hilfe bekommt. Hier mal ein paar Bildchen zur Motivation: Der in Entwicklung befindliche neue Topologische Autorouter für PCB: http://wand.net.nz/~amb33/toporouter/
> ich gehöre nicht zu Cadsoft und habe mit denen auch nix am Hut. > ... außer vielleicht, dass ich großen Respekt vor der Arbeit von > K.Schmidinger habe. Ah, ich verstehe die Zusammenhänge, Klaus Schmidinger, der Typ, der auch vor ein paar Jahren den VDR entwickelt hat, der dann über die c't verbreitet wurde, und in dem ich so viel Potential gesehen habe, dass ich mir so ein System zusammengebaut habe. Und dann kam Jahre lang gar nichts, der Schrott bliebt auf dem Level "funktioniert holperig gerade eben, viel Potential nicht ausgeschöpft" stehen, würde hier am Menü remgezuppelt, kam da ein Bug hinzu. Heute ist es tot "der Kern wird nicht weiterentwickelt, nur HD-TV hinzuimplementiert" und es hatte in der Zwischenzeit nie richtig funktioniert, geschweige denn seine Potentiale erreicht. Ja, ich sehe die Zusammenhänge mit Eagle, auch dort tut sich seit 10? Jahren nicht innovatives, nur wenn die Kundschaft zu sehr tritt, sieht man sich wohl man genötigt, etwas schon lange von der Konkurrenz erfundenes nachzuimplementieren. Das liegt vermutlich einfach an den Entwicklern, die schon zufrieden sind, wenn ihre Software irgendwie holperig läuft, und sich nicht vorstellen können, wie viel noch bis zu einem richtigen Produkt fehlt. Eagle und VDR haben da viel Ähnlichkeit. Alleine die völlig üble zusammengestückelte Library, inkonsistent und unwartbar, ist seit 10 Jahren in so einem Zusatnd. Und mit Klaus Schmidinger wird sich daran wohl nichts tun, der meint, das wäre gut, so wie es ist, und bastelt lieber an "HD-TV". Nein, ich habe keinen Respekt vor Schmidinger, denn ich weiß, wie es besser geht.
>Und dann kam Jahre lang gar nichts, der Schrott bliebt auf dem Level >"funktioniert holperig gerade eben, viel Potential nicht ausgeschöpft" >stehen, würde hier am Menü remgezuppelt, kam da ein Bug hinzu. Heute ist >es tot "der Kern wird nicht weiterentwickelt, nur HD-TV >hinzuimplementiert" und es hatte in der Zwischenzeit nie richtig >funktioniert, geschweige denn seine Potentiale erreicht. Wenn jemand also ein Open Source Projekt startet und veröffentlicht ist er verpflichtet, es weiterzuentwickeln? Es ist die Schuld des Initiators wenn die Gemeinschaft es nicht pflegt und stabil zum laufen bekommt? Ich bleib bei meiner Hardware und werde die finger von OPen source Projekten lassen (als Autor!) @MaWin: Warum hast DU das Potential vom VDR nicht ausgereizt? Zu dumm zum Programmieren? Zu Bequem neue Menüs zu basteln? Zu feige zu all dem, weil man könnte ja einen Bug produzieren?
> Warum hast DU das Potential vom VDR nicht ausgereizt?
Oh, ich habe mein eigenes Projekt.
Aber ich habe mich schon öfters an die Arbeit gemacht, Dinge umzusetzen,
weil sie die Anderen, die dafür viel prädestinierter gewesen wären,
einfach nicht taten. Da wartet man und wartet man, dann sagt man eines
Tages, ich muß es doch selbst tun, und tut es selbst.
Aber das geht nur in einem begrenzten Umfang. Eben in so einem Umfang,
wie sie ein einzelner Mensch machen kann. Und den leiste ich. Ich muß
nicht Politiker werden, um die Politik kritisieren zu können, und
ebensowenig PCB-CAD/VDR Programmierer, um dortige Produkte kritisieren
zu können.
Die Liste dessen, bei denen man spontan erkennt, das man es
OFFENSICHTLICH besser machen könnte, reicht für mehrere hundert Leben.
Die VDR-Sourcen hatte ich mir durchaus mal auf den Rechner gespielt.
Selten so einen undokumentierten laienhaft zusammengekloppten Verhau
gesehen.
>Wie alt bist du denn? Habe mehrjährige Erfahrung mit Projekten > 100000 LOC - das sollte zumindest für eine gesunde Einschätzung reichen. >Es ist ja schön das es solch Traumtänzer gibt wie Dich, aber das Projekt >ist zum scheitern verurteilt. Ok, ich bin halt anderer Meinung. >>- Import von Komponenten oder ganzen Schaltplänen anderer Produkte >nicht realisierbar, Du bekommst keine Infos von den Herstellern und >Reverse Engineering --> wie viel Jahrtausende sol denn das dauern? Zum einen habe ich das bewusst in die Kategorie "Wunschdenken" verfrachtet und KiCAD hat es zumindest für EAGLE-Komponenten bereits implementiert. >Es gibt im OpenSource bereich nix gescheites um Gerberdaten auch nur >rudimentär zu bearbeiten, noch nicht mal einen gescheiten Viewer. Warum >wohl? Vom Bearbeiten habe ich auch nie gesprochen. Zudem habe ich auch nie gesagt, dass ich das selbst implementieren werde. >Ich hätt auch gerne eine alternative zu Eagle, müßte manchmal Nicht nur du. >Um was konstruktives Beizutragen: Warum schreibst du nicht erstmal fuer >Eagle ein Script/ULP, welches eine beliebige, in dieser Form >realisierbare Funktion deines Wunsches hinzufuegt? Wenn - Falls das >irgendwann laeuft, sehen wir weiter ;) Ich weiß jetzt nicht genau wie mächtig ULP ist, aber ich kann mir nur schwer vorstellen, dass ich damit maßgeblich das GUI und die Bedienung mit der Maus nach meinen Wünschen beeinflussen kann. Ich lasse mich da aber gerne eines Besseren belehren. >>Fertig im Sinne von Feature-Complete wird es vermutlich nie. >Solche "Dauerbrenner" gibt es schon genug. Sourceforge ist regelrecht >zugemüllt mit Projekten, die Jahrelang nicht bearbeitet bzw. die nie >fertiggestellt werden. Verschone uns bitte mit einer weiteren Totgeburt. Mach ich. >Um ein Projekt wie von dir geplant zu realisieren braucht es Ressourcen >in Quantitäten über die du nicht verfügst. Das Projekt noch noch nicht vollständig umrissen aber du weißt schon, dass ich nicht über die notwendigen Ressourcen verfüge ... >Anstatt ein neues Programm anzufangen, solltest Du lieber an einem >Anderen mitarbeiten. Such Dir das Beste raus und verbessere das lieber. Das Thema hatte ich weiter oben schon kommentiert. Fällt euch eigentlich auf, dass beinahe die gesamte Kritik an dem Projekt darauf zielt, dass ich die Umsetzung nicht alleine innerhalb akzeptabler Zeit bewerkstelligen könnte? Ich habe nie behauptet, dass ich alles alleine machen werde, noch dass ich in zwei Wochen fertig bin. Nein, ich kann jetzt noch nicht mit Bestimmtheit sage, dass alles so funktioniert, wie ich es mir vorgestellt habe. Aber ja, ich bin bereit es zu versuchen, wenn sich weitere Leute finden, die diese Idee sinnvoll finden oder gar unterstützen würden. Gruß, Kai
>Fällt euch eigentlich auf, dass beinahe die gesamte Kritik an dem >Projekt darauf zielt, dass ich die Umsetzung nicht alleine innerhalb >akzeptabler Zeit bewerkstelligen könnte? Das ist eben der Kernpunkt, neben deinen Fähigkeiten, aber die kennen wir ja nicht. Klar, wenn Du ein paar gute Leute finden würdest, die mitarbeiten. Aber das sieht ganz schlecht aus, insbesondere hier. Ich kenne dieses Forum schon seit einigen Jahren, ich wüsste nicht, dass es hier mal eine Zusammenarbeit gegeben hätte. Wünschen, Meckern, Fordern, Dummschwätzen, das sind hier die Hobbies. Und den meisten ist Eagle gut genug, solange es nur Freibier gibt. Und wenn Du es alleine machst? Wie ich oben schrieb, 5000 Stunden bis es annäherend gEDA/KiCad enspricht. Und auch dann werden sie nur meckern -- musst nen Kasten Bier mitschicken, damit sie es ausprobieren. Und 5000 Stunden hart arbeiten, ohne Geld oder Anerkennung zu bekommen, da fällt es schwer sich zu motivieren. Und wenn es erst in 10 Jahren halbwegs fertig ist? Du lebst auch nicht ewig, der Winfried Hill bekommt sein AoE 3 wohl auch nicht mehr fertig?
>Aber ja, ich bin bereit es zu versuchen, wenn sich weitere Leute finden, >die
diese Idee sinnvoll finden oder gar unterstützen würden.
Das ist ja auch gut, (das war keine Ironie!), aber es gibt schon so
viele Projekte, warum sollten Programmierer Dich unterstützen, noch dazu
wo es schon Open Source PCB-Cad gibt.
Stefan Salewski schrieb: > Ich kann den Wunsch nach etwas "Neuem" schon verstehen, und wenn Kai gut > ist und ein paar Jahre Vollzeit dran arbeitet ist es auch nicht völlig > unrealistisch -- aber auch nur weil man bei KiCAD und gEDA abgucken kann > und bei Fragen vermutlich dort auch Hilfe bekommt. > > Hier mal ein paar Bildchen zur Motivation: Der in Entwicklung > befindliche neue Topologische Autorouter für PCB: > > http://wand.net.nz/~amb33/toporouter/ Wow, cooles Ding, auch wenn die Resultate so... gepfuscht aussehen ;)
>Wow, cooles Ding, auch wenn die Resultate so... gepfuscht aussehen ;)
Wie auch immer das gemeint ist -- Anthony testet momentan nur mit
einseitigem Routing, der Router setzt also keine Vias. Das ist für den
Router eine größere Herausforderung. An die "krummen" Leiterbahnen muss
man sich natürlich erst mal gewöhnen, aber das ist wohl der Trend bei
dichtester Packung. Man kann ja später einen Modus für Gerade Linien
einbauen, evtl. auch mit festem Raster. Ist schon sehr beeindruckend,
aber es baut natürlich auf einer Reihe von Veröffentlichungen zum Thema
auf.
Stefan Salewski schrieb: >>Wow, cooles Ding, auch wenn die Resultate so... gepfuscht aussehen ;) > > Wie auch immer das gemeint ist Naja, nahezu jede professionelle Leiterplatte wird doch mit schoenen 45Grad-Winkeln geroutet, wie du sagst ist der "krumme" Look gewoehnungsbeduerftig.
Die krummen Leiterbahnen könne durchaus ihre Vorteile haben. Ich hab auch grundsätzlich zu wenig Platz für alles senkrecht/waagerecht/genau45grad oder immer perfect gerade aus vias/tht-löchern, was solls, hauptsache es funzt. Ich habe schon den Anspruch auf "schöne" boards, aber meist gehts halt nicht.
Also wenn der topoligische Router auf Leitungsimpedanzen und so aufpasst, dann is das Kreuz-und-Quer bei hochfrequentem Kram manchmal garnich so verkehrt... manchmal!
Kai Giebeler (Firma: SettleBack GbR) (runtimeterror) wrote: > Fällt euch eigentlich auf, dass beinahe die gesamte Kritik an dem > Projekt darauf zielt, dass ich die Umsetzung nicht alleine innerhalb > akzeptabler Zeit bewerkstelligen könnte? Ich habe nie behauptet, dass > ich alles alleine machen werde, noch dass ich in zwei Wochen fertig bin. > Nein, ich kann jetzt noch nicht mit Bestimmtheit sage, dass alles so > funktioniert, wie ich es mir vorgestellt habe. Aber ja, ich bin bereit > es zu versuchen, wenn sich weitere Leute finden, die diese Idee sinnvoll > finden oder gar unterstützen würden. Kai, am besten du fängst überhaupt erst mal an. So wird das mehr ein "Schwatzkasten" und man zerredet alles. Ich glaube allein darüber welches Software-Rahmenwerk verwendet wird kann Monate an Diskussionen nach sich ziehen .. Je eher du anfängst, desto eher wirst du auch wissen ob so ein Projekt realisierbar ist.
@ täglich-8h-eagle-user: Sagmal, faellt 8h Eagle am Tag nicht unter Folter, die international verboten ist?
Ja, Kai soll einfach mal anfangen (obwohl ich der Meinung bin, er solle bei bestehenden Projekten einsteigen). Wenn das gute Ansätze sind, werden weitere Leute aufspringen - wenn nicht, dann nicht. Das Problem ist natürlich, dass die internen Strukturen von Anfang an so flexibel sein müssen, die noch folgenden Wünsche zu erfüllen. Ich wünsche ihm auf jeden Fall Durchhaltevermögen - er wird es brauchen. Ich selbst werde erstmal weiter am Bestückungsautomaten bauen :-) Chris D.
Chris D. schrieb:
> Ich selbst werde erstmal weiter am Bestückungsautomaten bauen :-)
Hi,
wieviel Aufträge hast du Siemens denn schon weggeschnappt?
Gruss Reinhard
Reinhard Kern schrieb: > Chris D. schrieb: >> Ich selbst werde erstmal weiter am Bestückungsautomaten bauen :-) > > Hi, > > wieviel Aufträge hast du Siemens denn schon weggeschnappt? > > Gruss Reinhard Oha, ich habe zwar große Pläne, aber eine Siplace traue ich mir denn doch nicht zu ;-) Also: ich brauche nur einen sehr einfachen Bestückungsautomaten - alles bis 5 Sekunden pro Bauteil ist für mich vollkommen ausreichend, da ich nur meine eigenen Schaltungen produzieren möchte und kaum mehr als 2-3 fertige Platinen am Stück benötige. Ein eigener Automat (mit möglichst vielen Feedern) hat den Vorteil, dass ich immer "auf Zuruf" produzieren kann, ohne mir ein großes Lager an fertigen Baugruppen hinlegen zu müssen. Ebenso kann man so Designverbesserungen schnell und ohne große Kosten durchführen. Da ich für meine Schaltungen fast immer dieselben Komponenten einsetze, sollte auch die Rüstzeit sich nur im Minutenbereich halten ( da die meisten Feeder einfach immer am Automaten verbleiben.) Näheres zum Automaten gibbet hier im Thread: Beitrag "s: Bestückungsautomat" Das Projekt ist durchaus nicht tot - ich bastel immer mal daran, wenn etwas Zeit ist. Auf jeden Fall macht es sehr viel Spaß, die Feinmechanik für den Kopf etc. zu bauen und zu testen. Chris D.
@MaWin Also Deine Kommentare zu K.Schmidinger sind nicht nur sachlich völlig falsch, sondern, für mein Empfinden, eine Rufschädigung. Ich habe im Beta-Programm der frühen 5er Versionen mitgemacht und zu der Zeit gab es bei mir Phasen, in denen ich auch 8h täglich mit eagle gearbeitet habe. Ich empfand es nicht als Folter, sondern im Gegenteil, erst durch die intensive Nutzung lernte ich (eher) verborgene Funktionen von Eagle kennen, die ein flottes Arbeiten erst ermöglichten. Wie bei jeder Firma, werden auch bei cadsoft Fehler priorisiert - und ich habe jetzt schon mehrfach erlebt, dass Fehler einen Tag nach der Meldung behoben waren. Alleine diese Antwortzeiten suchen ihresgleichen! Dann die Liebe zum Detail - für jede Funktion gibt es eine umfassende Kontexthilfe. Die ist aktueller und ausführlicher, als das Handbuch. Neben den 3 Maustasten werden auch Kombinationen mit Shift, Ctrl und Alt unterstützt - bei regelmäßiger Benutzung geht das so in Fleisch und Blut über, dass man sich ein Arbeiten ohne nicht mehr vorstellen kann. Wie andere auch schon schrieben, eagle ist sicher nicht perfekt, aber man merkt, dass der Alltag von PCB-Entwicklern im Vordergrund steht. Nicht Anwender, die alle halbe Jahr mal eine Platine routen. Das was Du zusammen schreibst, zeigt nur, dass Du nicht weißt, wovon Du schreibst. ... und das was Du über den VDR geschrieben hast: > Selten so einen undokumentierten laienhaft zusammengekloppten Verhau > gesehen. Das mag für viele Plugins gelten. Die sind von Anwendern mit unterschiedlichen Programmierkenntnissen erstellt worden. Die VDR-Sourcen sind tadellos, durchgängig und dokumentiert! Wenn die c't ein nicht funktionierendes Sammelsurium erstellt, kann man das nicht K.Schmidinger zum Vorwurf machen. Dass Du Deinen VDR nicht zum Laufen gebracht hast, tut mir leid. Meiner läuft seit Jahren ohne Probleme. Aber dafür gibt es ein anderes Forum, in dem Dir mit Sicherheit geholfen wird, wenn Du denn in der Lage sein solltest, anständig zu fragen :)
@ Chris D. (myfairtux) >Also: ich brauche nur einen sehr einfachen Bestückungsautomaten - alles >bis 5 Sekunden pro Bauteil ist für mich vollkommen ausreichend, da ich >nur meine eigenen Schaltungen produzieren möchte und kaum mehr als 2-3 >fertige Platinen am Stück benötige. Ein eigener Automat (mit möglichst >vielen Feedern) hat den Vorteil, dass ich immer "auf Zuruf" produzieren >kann, ohne mir ein großes Lager an fertigen Baugruppen hinlegen zu >müssen. Nette Spielerei, praktisch aber eher unsinnig. Solche MINImengen bestückt man per Hand oder beim profesionellen Bestücker. >Ebenso kann man so Designverbesserungen schnell und ohne große Kosten >durchführen. Jaja. Das ist nix weiter als Bastelei an Einzelstücken. >Da ich für meine Schaltungen fast immer dieselben Komponenten einsetze, >sollte auch die Rüstzeit sich nur im Minutenbereich halten ( da die >meisten Feeder einfach immer am Automaten verbleiben.) Dann kannst du genausogut 100 Platinen im vorraus fertigen lassen ;-) >Das Projekt ist durchaus nicht tot - ich bastel immer mal daran, wenn >etwas Zeit ist. Eben, es ist Bastelei. Mehr nicht. MfG Falk
@Anfänger Du unterstellst mir > Rufschädigung. und bist nicht mal in der Lage, die Beiträge des Threads den Benutzern zuzuordnen ? > Ich empfand es nicht als Folter Da ist aber mal eine fette Entschuldigung fällig!
Falk Brunner schrieb:
> Eben, es ist Bastelei. Mehr nicht.
Worauf willst du Hinaus? Ist doch schön wenn er was zum basteln hat.
Falk Brunner schrieb: > Nette Spielerei, praktisch aber eher unsinnig. Solche MINImengen > bestückt man per Hand oder beim profesionellen Bestücker. Du kannst das gerne so machen. Meine Mitarbeiter sind mir für diese stumpfsinnigen Arbeiten zu schade. Handbestückung ist fehleranfällig und für zwei Platinen, die heute fertig sein müssen, habe ich noch keinen Bestücker gefunden. Wenn Du Bestücker kennst, die jederzeit innerhalb von 6 Stunden liefern und keine Mondpreise verlangen - immer her damit. >>Ebenso kann man so Designverbesserungen schnell und ohne große Kosten >>durchführen. > > Jaja. Das ist nix weiter als Bastelei an Einzelstücken. Jaja, keine Ahnung - aber Hauptsache, man schreibt etwas. >>Da ich für meine Schaltungen fast immer dieselben Komponenten einsetze, >>sollte auch die Rüstzeit sich nur im Minutenbereich halten ( da die >>meisten Feeder einfach immer am Automaten verbleiben.) > > Dann kannst du genausogut 100 Platinen im vorraus fertigen lassen ;-) Genau das will ich aus guten Gründen ja eben nicht mehr. Ist viel zu unflexibel und man hat totes Kapital rumliegen. >>Das Projekt ist durchaus nicht tot - ich bastel immer mal daran, wenn >>etwas Zeit ist. > > Eben, es ist Bastelei. Mehr nicht. Aber auch nicht weniger. Wenn das Teil das macht, was es soll, bin ich zufrieden :-) Es muss schließlich mir gute Dienste leisten - nicht Dir, Falk. Chris D.
Simon K. schrieb: > Falk Brunner schrieb: >> Eben, es ist Bastelei. Mehr nicht. > > Worauf willst du Hinaus? Ist doch schön wenn er was zum basteln hat. Keine Ahnung, was das Posting bezwecken sollte - sinnvoll war es jedenfalls nicht. Mir ist es letztendlich völlig wurscht, ob man es "Bastelei", "Prototyp" oder sonstwie nennt. Es muss seine Funktion erfüllen. Chris D.
@ Chris D. (myfairtux) >Du kannst das gerne so machen. Meine Mitarbeiter sind mir für diese >stumpfsinnigen Arbeiten zu schade. Klar, lieber bastelt der "Chef" monatelang an seinem Bestückungsautomaten, der dann aber nie fertig wird, geschweige denn einen halbwegsprofessionellen Stand erreicht. "Das Projekt ist durchaus nicht tot - ich bastel immer mal daran, wenn etwas Zeit ist." >Handbestückung ist fehleranfällig und für zwei Platinen, die heute >fertig sein müssen, habe ich noch keinen Bestücker gefunden. Warum auch. Wer sowas macht, hat einen logistischen Fehler gemacht. >Wenn Du Bestücker kennst, die jederzeit innerhalb von 6 Stunden liefern >und keine Mondpreise verlangen - immer her damit. Siehe oben. Warum soll der Bestücker für deine Planungsunfähigkeit einspringen. Und wenn doch, kostet das was. >Genau das will ich aus guten Gründen ja eben nicht mehr. Ist viel zu >unflexibel und man hat totes Kapital rumliegen. Müssen ja wahnsinnig grosse und teuere PLatinen sein. >Aber auch nicht weniger. Wenn das Teil das macht, was es soll, bin ich >zufrieden :-) Wann wird das sein? Wie hoch sind deine ANsprüche? Ein paar surrende Schrittmotoren und drei platzierte SOIC-Gehäuse? >Es muss schließlich mir gute Dienste leisten - nicht Dir, Falk. Zu Glück. MfG Falk
Falk Brunner schrieb: > @ Chris D. (myfairtux) > >>Du kannst das gerne so machen. Meine Mitarbeiter sind mir für diese >>stumpfsinnigen Arbeiten zu schade. > > Klar, lieber bastelt der "Chef" monatelang an seinem > Bestückungsautomaten, der dann aber nie fertig wird, geschweige denn > einen halbwegsprofessionellen Stand erreicht. Es ist interessant, was Du so alles mutmaßt. Man sollte nicht von sich auf andere schließen. > Müssen ja wahnsinnig grosse und teuere PLatinen sein. Ja, die Bauteile sind teuer - sehr teuer sogar. >>Aber auch nicht weniger. Wenn das Teil das macht, was es soll, bin ich >>zufrieden :-) > > Wann wird das sein? Wie hoch sind deine ANsprüche? Ein paar surrende > Schrittmotoren und drei platzierte SOIC-Gehäuse? Falk, das kannst Du alles in obigem Thread nachlesen; oder auch lassen - ganz wie's dem "Ingenieur" beliebt. Und wenn, dann sollte dort weiterdiskutiert werden - hier ist das reichlich OT. Nein, eigentlich möchte ich das gar nicht weiter diskutieren - das ist meine verschwendete Zeit, die ich besser für Wichtiges einsetze. >>Es muss schließlich mir gute Dienste leisten - nicht Dir, Falk. > Zu Glück. Ja, da bin ich auch sehr froh drum. MfG Chris D.
@sach ich nich (dude): ja, das ist Folter, aber egal welches Prog man 8h benützt, es ist immer Folter. Kommt eigenlich dude vom lebowski? @Kai Giebler: Wenn Du mit einem reinen Gerber-Editor anfängst mach ich mit. Was hast du dir denn als internes Datenmodell für die Board angedacht.
täglich-8h-eagle-user schrieb: > @sach ich nich (dude): > > ja, das ist Folter, aber egal welches Prog man 8h benützt, es ist immer > Folter. Kommt eigenlich dude vom lebowski? Naja, stimmt auch irgendwie ;) Ich weiss garnicht mehr genau, woher dude kommt, ich glaube der Nick entstand aus zwei Dingen: -GTA Vice City: In einer Mission an einem Bootshaus trifft man zwei bekiffte Typen, die Tommy immer "dude" nennen -Ein Freund kam von dem Wort nicht mehr los, nach dem er den Big Lebowski gesehen hatte
>Wenn Du mit einem reinen Gerber-Editor anfängst mach ich mit. Wie oben schon geschrieben hatte ich bislang nicht vor einen Gerber-Editor zu schreiben. Einen Export im Gerber-Format wird es geben und einen Import als nice-to-have. >Was hast du dir denn als internes Datenmodell für die Board angedacht. Wird in die Richtung MVC gehen - das Board ist (wie auch der Schaltplan) nichts weiter als eine View auf das vom Autor entwickelte Modell. Schöne Grüße, Kai
Hi >Wird in die Richtung MVC gehen - das Board ist (wie auch der Schaltplan) >nichts weiter als eine View auf das vom Autor entwickelte Modell. Dann würde ich erst mal mit dem Modell(en) anfangen. Die Wahl der Werkzeuge ist erst mal zweitrangig. Irgendwie zäumst du das Pferd von der falschen Seite auf. MfG Spess
>Dann würde ich erst mal mit dem Modell(en) anfangen. Die Wahl der >Werkzeuge ist erst mal zweitrangig. Darauf wollte ich hinaus, danke spess. Was spricht gegen die verwendung einer Models auf Basis Gerber, schön einfach zu visualisieren, Platine sieht am Bildschirm genauso aus wie später in Wirklichkeit, Gerberexport ist kaum Fehleranfällig (da gabs ja schon üble Probleme bei den etablierten), wobei Gerber auch wieder nicht mehr ganz aktuell ist. Aber wenn Kai primär an der Verwendung von buzzwords (MVC) interessiert ist, schwindet mein Interesse. Man könnte immer noch gerbv aufbohren zum editieren.
Hi
>Aber wenn Kai primär an der Verwendung von buzzwords (MVC) interessiert ist,
Ist mir auch aufgefallen. Bis jetzt ging es hier nur um, zu diesem
Zeitpunkt, Belanglosigkeiten. Solange man z.B. nicht weiss, welche
(zukunftsicheren) Parameter ein Track oder Pad haben muss, sind
Überlegungen zur Plattform oder Bedienkonzept ziemlich sinnfrei.
MfG Spess
Wenn Kai primär programmieren unter Eclipse lernen will ist ds ja ok, das er sich was sinnvolles und etwas anspruchvolleres als "hello world" raus sucht auch, aber gleich CAD? Nun ja, vielleicht schafft er es doch anzufangen und wir sehen mal irgendwann irgendetwas.
Kai Giebeler schrieb: > >>Was hast du dir denn als internes Datenmodell für die Board angedacht. > > Wird in die Richtung MVC gehen - das Board ist (wie auch der Schaltplan) > nichts weiter als eine View auf das vom Autor entwickelte Modell. > > Schöne Grüße, > Kai MVC ist ein Design-Pattern. Für die Modellierung in Eclipse bietet sich EMF an: http://de.wikipedia.org/wiki/Eclipse_Modeling_Framework Das währe meiner Meinung nach der erste Ansatz um wieder auf eine kostruktive Diskussion über zu leiten. Ich bin überzeugt davon, dass 90% der Dummschwätzer hier damit eh nix anfangen können.
>Das währe meiner Meinung nach der erste Ansatz um wieder auf eine >kostruktive Diskussion über zu leiten. Ich bin überzeugt davon, dass 90% >der Dummschwätzer hier damit eh nix anfangen können. Ja denke sogar 99.9% Ich gehöre auch dazu! Schwätze aber auch nix zum Thema! Denke die meisten kommen nicht über ihr Schul Basic! Jupp
Jupp schrieb: >>Das währe meiner Meinung nach der erste Ansatz um wieder auf eine >>kostruktive Diskussion über zu leiten. Ich bin überzeugt davon, dass 90% >>der Dummschwätzer hier damit eh nix anfangen können. > > Ja denke sogar 99.9% > > Ich gehöre auch dazu! Schwätze aber auch nix zum Thema! > Denke die meisten kommen nicht über ihr Schul Basic! > > Jupp Und ich hatte nichtmal Basic in der Schule, so eine Sch**sse :D
Ihr wollt mir nicht ernsthaft weismachen, dass Gerber ein Modell ist?? Gerber "ist eine Standard-Dateistruktur im ASCII-Format, die den Datenaustausch zwischen CAD (Entwicklung) und CAM (Produktion) ermöglicht." >Dann würde ich erst mal mit dem Modell(en) anfangen. Die Wahl der >Werkzeuge ist erst mal zweitrangig. Irgendwie zäumst du das Pferd von >der falschen Seite auf. Ich bin gerade am modellieren!! > Für die Modellierung in Eclipse bietet sich EMF an: ... welches wiederum eine gute Grundlage des MVC-Design-Patterns ist: http://en.wikipedia.org/wiki/Graphical_Editing_Framework Danke Dieter. Die Eignung von EMF/GEF bin ich noch am prüfen. Würde das gerne nutzen, da es einem viel unnötige Arbeit abnehmen könnte. >Ich bin überzeugt davon, dass 90% der Dummschwätzer hier damit eh nix >anfangen können. Immer wenn ein Wort fällt mit dem keiner was anfangen kann schreit jemand "Buzzword". Wie wär's wenn ihr euch einfach mal darüber informiert und dann über die Eignung für das Projekt auseinandersetzt? Ich weiß, dass das Arbeit ist - ratet mal woher? Es gibt genug neue Technologien, die ich nicht einsetzen werde weil sie einfach ungeeignet oder nicht ausgereift sind. MaWin hat das weiter oben freundlicher Weise mal ad adsurdum geführt.
> Immer wenn ein Wort fällt mit dem keiner was anfangen kann > schreit jemand "Buzzword". Im Gegenteil, diejenigen, die mit dem Wort was anfangen können, schreien "Buzzword". Diejenigen, die nichts mit dem Wort anfangen können, sollen ja auch in Ehrfurcht verstummen. Ich glaube nicht, daß du auch nur zu Ansätzen eines PCD-CAD Programms kommst. Warum? Ich hab auch mal eins geschrieben, so 1984, angelehnt an WinTek smArtwork, aber mit push&shove Router. Keins deiner Buzzwords war dabei wichtig.
Interessanter Thread - und ein dickes, dickes Projekt! Nur, Kai, bitte überleg mal die Kritik von einigen der Personen hier, dass du das Projekt vom falschen Ende angehst. In deinem EIngangsposting und nachfolgenden sehe ich Java, Eclipse, MVC, Poseidon UML, MVC, RPC etc. Das sind aber alles nun mal Details der Implementierung. Sicher, für die eigentliche Umsetzung ist dies wichtig. Nur wo sehe ich ein Lasten und Pflichtenheft oder eine brauchbare Spec. *Besser als Eagle* ist hier etwas dürftig. Und ohne so eine Spec - so vermute ich - wirst du in Kürze das Problem haben, dass deine Architektur nicht stimmt, ergo eine Krücke nach der anderen angeschlossen werden. Oder wieso meinst du, dass KiCad so ist wie es ist? Also nur als Idee: Überlege dir genau, was du abdecken willst. Dann evaluiere vorhandene Lösungen und dann kann man immer noch über ne Neuentwicklung reden. Aber bitte in der Reihenfolge. Ich persönlich halte nichts von der NIH-Symptomatik (not invented here) und demzufolge eigener Entwickling von open-source Projekten. cu, Michael
Dieter Engelhardt (netdieter) wrote: > .. Ich bin überzeugt davon, dass 90% > der Dummschwätzer hier damit eh nix anfangen können. Außer eigener Borniertheit ist an solch einem Spruch nichts "intelligentes". Kai Giebeler (Firma: SettleBack GbR) (runtimeterror) wrote: > immer wenn ein Wort fällt mit dem keiner was anfangen kann schreit > jemand "Buzzword". Wie wär's wenn ihr euch einfach mal darüber > informiert und dann über die Eignung für das Projekt auseinandersetzt? Mich erinnern Leute die all zu oft diese Abkürzungen gebrauchen immer an die Dampfplauderer der "BWL-Szene". Warum muss man es diesen Typen auch noch nachmachen? Gefühl der "Elite"? Freude daran, wenn andere nicht sofort verstehen was gemeint ist? Die Umgangssprache gibt genügend her, um solche Begriffe zu umschreiben und sich allgemein verständlich auszudrücken. Wir ersticken doch förmlich schon in Akronymen ..
@Kai Giebeler: Wie schon einige geschrieben haben: Fang mit der Entwicklung einfach an! Diskussionen wie diese hier bringen dich nicht viel weiter, denn du hast nur folgende drei Alternativen: - Du gehst auf die Feature-Wünsche ein und versuchst, es den meisten recht zu machen. Dann kommt am Ende ein Programm für den Durchschnitt heraus, von dem alle ein Bisschen, aber keiner so richtig überzeugt ist, nicht einmal du. Bei einem kommerziellen Projekt, wo es um vakaufte Stückzahlen geht, ist das ok, bei einem Hobby-Projekt nicht. Da sollten immer die eigenen Wünsche im Vordergrund stehen, sonst lässt die Motivation schnell nach. - Oder du ignorierst die Wünsche der anderen, dann kannst du dir aber die Diskussion gleich sparen. - Evtl. kannst du aus der Diskussion ein paar gute Anregungen herausfiltern. Wenn du aber in größerem Umfang auf Anregungen von anderen angewiesen bist, könnte das ein Zeichen dafür sein, dass du über zu wenig Anwender- oder technisches Wissen verfügst, um das Projekt durchzuziehen. Der bessere Weg ist meiner Meinung nach (auch wenn sich das etwas geek-mäßig anhört) der, mit der Entwicklung alleine und im Verborgenen zu beginnen und die Features, den Aufbau und die Entwicklungstools so auszuwählen, dass du selbst davon überzeugt bist, es richtig zu machen. Du möchtest das Programm ja hinterher auch selbst nutzen. Irgendwann veröffentlichst du dann eine erste lauffähige Version, die idealerweise mindestens aus Schaltplan- und Layout-Editor besteht. Sie muss noch nicht vollständig sein, aber das, was implementiert ist, sollte einigermaßen fehlerfrei funktionieren. Dann beginnt zwar wieder eine Diskussion, die aber diesmal konstruktiver ist: - Aussagen wie "Das kriegst du nie gestemmt!" werden kaum noch kommen, da ein nicht unwesentlicher Teil des Gsamtbrockens ja schon bearbeitet ist. - Viele werden dein Programm als Müll bezeichnen. Das jedem sein gutes Recht und lässt sich auch kaum vermeiden. Das Gemecker wird aber nicht ewig andauern, weil es am Grundkonzept sowieso nichts mehr zu ändern gibt, anders als zum jetztigen Zeitpunkt. Die, denen dein Konzept nicht gefällt, werden das Programm einfach nicht benutzen und müssen bei zukünftigen Erweiterungen auch nicht berücksichtigt werden. - Einige, die ähnlich denken wie du, werden von deinem Programm sicher begeistert sein. Befinden sich unter diesen zufälligerweise ein paar gute Softwareentwickler, hast du die Chance, von diesen Unterstützung bei der Entwicklung zu bekommen. Und da sie mit dir offensichtlich auf einer Wellenlänge liegen, ist die Gefahr gering, dass sie dein Projekt durch unpassende Änderungen oder Erweiterungen verpfuschen. Das Ergebnis ist also ein Programm, von dem du und einige andere begeistert sind und der Rest überhaupt nicht. Mich persönlich würde das mehr motivieren weiterzumachen, als wenn ich versuche, Software für Hinz&Kunz zu entwickeln. Oder möchtest du mit dem Programm berühmt werden und etwas für die breite Masse kreieren? Dann solltest du aber überlegen, ob du statt eines EDA-Tools lieber eine neuartige Textverarbeitung entwickelst ;-) Noch etwas zum Argument "Das ist ja alles viel zu viel Arbeit und kann nie geschafft werden": - Zum Glück denkt nicht jeder so, sonst würde ich jetzt diese Zeilen nicht in den Vim-Editor auf meinem Linux-Rechner, auf dem im Hintergrund noch ein GCC werkelt, eintippen. Fast alle genialen Open-Source-Entwicklungen haben als Ein-Mann-Projekt angefangen. - Selbst wenn in Eagle zig Mannjahre Entwicklungsaufwand stecken, heißt das nicht, dass die Entwicklung eines vergleichbaren Systems heute wieder so lange dauert. Softwareentwicklung geht heutzutage wesentlich leichter und schneller als vor 10 oder 20 Jahren, dank frei verfügbarer Bibliotheken, besserer Programmiersprachen und Entwicklungstools, leichterer Informationsgewinnung usw. - Und wenn man nicht Richard Stallmann oder Linus Torwalds heißt bzw. der Aufwand die eigene Leistungsfähigkeit übersteigt, merkt man das sehr bald, und lässt die Geschichte dann eben bleiben. Die bis dahin geopferte Zeit kann dann immer noch als Programmierübung gezählt werden. PS: Dieser Beitrag impliziert nicht, dass ich davon überzeugt bin, dass dein Projekt ein Erfolg wird. Das kann ich nicht, weil ich dich und damit deine Fähigkeiten nicht kenne. Ich gehe aber davon aus, dass die meisten der Vorposter dich ebenfalls nicht kennen :)
Danke yalu. Ich werde mich deinem* Rat anschließen und wie in Beitrag "Re: Entwicklung eines neuen CAD/PCB-Programms" angekündigt erstmal was für mich alleine basteln. Ich melde mich, sobald es was Neues gibt - und sei es, dass ich das Projekt einstampfe. Danke an alle für die rege Diskussion! * und dem einiger Vorposter
yalu (Gast) wrote: > Der bessere Weg ist meiner Meinung nach (auch wenn sich das etwas > geek-mäßig anhört) der, mit der Entwicklung alleine und im Verborgenen > zu beginnen und die Features, den Aufbau und die Entwicklungstools so > auszuwählen, dass du selbst davon überzeugt bist, es richtig zu machen. Sehe ich auch so. Man muss erst mal was haben worüber man dann reden kann, sonst wirkt das alles nur wie eine "Trockenübung". Damit wird dann auch der Willen offenbar so ein Projekt ernsthaft enzugehen. Learning by doing ;).
täglich-8h-eagle-user schrieb: > Darauf wollte ich hinaus, danke spess. Was spricht gegen die verwendung > einer Models auf Basis Gerber, schön einfach zu visualisieren, Platine > sieht am Bildschirm genauso aus wie später in Wirklichkeit, Gerberexport > ist kaum Fehleranfällig Hallo, das ist barer Unsinn. In Gerber gibt es nicht einmal Components, sondern höchstens 14 Pads und einen Umriss ohne jeden Zusammenhang, die können auch über die ganze Datei verteilt sein. Auch Connections gibt es nicht, man kann sie sich höchstens rückwärts ableiten. Das ist ungefähr so, als würde man Werbeseiten aus einer Illustrierten als Basis eines Funktionsmodells für Autos verwenden - Gerber (und HPGL,Postscript usw) ist ein reines Zeichenformat zur Ausgabe. Mit sowas sind 98% der Funktionen eines heutigen CAD-Systems von vornherein nicht realisierbar. Gruss Reinhard
Naja. Postscript ist eine komplette Programmiersprache! Das ist der Unterschied! Es gibt auch ein PCB-Programm, was direkt Postscript auch für die Dateien benutzt. Gruß - Abdul
Abdul K. schrieb: > Naja. Postscript ist eine komplette Programmiersprache! Das ist der > Unterschied! Es gibt auch ein PCB-Programm, was direkt Postscript auch > für die Dateien benutzt. Hallo Abdul, dann beschreibe doch mal die Impedanz-Constraints einer LVDS-Differential-Pair-Leitung in Postscript. Möglich, aber nicht sehr intelligent. Abgesehen davon, erst mal abwarten, wahrscheinlich hört man nie mehr was davon. Gruss Reinhard
Reinhard - von was redest du? Ich kann deine Constraints genausowenig in C beschreiben. Das liegt aber daran, das ich von Assembler versaut wurde und mich auch mehr als reinrassiger Hardwareentwickler betrachte. Es gibt halt Leute, die in Postscript die tollsten Sachen machen und es scheint diese Sprache wird total unterschätzt, weil sie eben nur mit Druckern in Verbindung gebracht wird. Und das wollte ich erwähnen. Auch, weil ich 'verschlüsselte' Dateien hasse. Es geht nix über eine simple Struktur, die man mit jedem Editor notfalls reparieren kann. Oder wenn man irgendwas mit einem externen Tool irgendwie verändern möchte. Weil das Programm einfach dazu zu blöde ist. Heutzutage gibt es XML - aber das war nicht immer so. Ich weiß nicht, ob XML wirklich so toll ist. Scheint sich aber langsam durchzusetzen. Ich denke daß ich nicht der einzige hier bin, der von propietären Dateiformaten nachhaltig geschädigt wurde. Du nicht? Gruß - Abdul
Abdul K. schrieb: > Ich denke daß ich nicht der einzige hier bin, der von propietären > Dateiformaten nachhaltig geschädigt wurde. Du nicht? Doch durchaus, und ich habe auch draus gelernt. Allerdings habe ich hier in einem anderen Forum dafür plädiert, bei einfachen Daten-Übertragungen ASCII-Text zu verwenden, weil man das viel leichter überprüfen kann, und dann hat gleich einer "IGITT" geschrieen. Ich würde schon aus langfristigen Überlegungen immer CAD-Systeme vorziehen, für die es eine Text-Ausgabe zumindest gibt. Aber man hat nicht immer die Wahl, Altium z.B. lehnt das grundsätzlich ab (seitdem es Altium heisst, früher gabe es Protel ASCII). Man hat nicht immer die Wahl. Gruss Reinhard
Ich ziehe für die Speicherung der Projektdateien ein XML-Format vor. Das kann man meist ohne große Schmerzen in andere Formate überführen. XMI hätte den Vorteil, dass es halbwegs bekannt und gut dokumentiert ist. ASCII-Formate halte ich für Export und Übertragungsprotokolle geeignet.
Kai Giebeler schrieb:
> Ich ziehe für die Speicherung der Projektdateien ein XML-Format vor. ..
Mit ASCII meinte ich lesbar (für Menschen), also auch XML.
Gruss Reinhard
Hallo Zusammen, ich habe damals die Diskussion mit Spannung verfolgt und frage mich, was ist aus dem großen Vorhaben geworden? Gibt es eine erste Version? Gruß NoName Vielleicht noch eine kleine Anmerkung: Wäre dieser Thread Quelltext würde das Programm sicherlich schon laufen ;-).
Sowas hält meist nur solange wie das Interesses des Hauptziehers. Warum sollte jemand NOCH ein PCB-Programm entwickeln? Für Firmen ist nicht genug Kapital zu gewinnen, für Bastler ist es viel zu aufwändig.
Ich würde schon sagen, dass sich eine Open-Source-Neuentwicklung einer CAD/PCB-Lösung lohnen würde! GEDA und KiCAD hatten bei meinen Ausprobierereien Halbwertszeiten im unteren Minutenbereich. Wenn's damit losgeht, dass beim Bewegen von Teilen Artefakte bei der Darstellung übrigbleiben bis man "F2 Refresh View" ausführt dann ist die Sache für mich gelaufen. Eigentlich schade, ich hatte mein Symboleditier-/Schaltplanprogramm (C++, Qt) auch mal bis zu halbwegs brauchbaren 30000 Zeilen Source-Code getrieben und dann mangels Zeit und Erweiterbarkeit eingestampft.
>GEDA und KiCAD hatten bei meinen Ausprobierereien Halbwertszeiten im >unteren Minutenbereich. Und mit den Sachen von Cadence und Mentor kommst du natürlich sofort zurecht. >Eigentlich schade, ich hatte mein Symboleditier-/Schaltplanprogramm >(C++, Qt) auch mal bis zu halbwegs brauchbaren 30000 Zeilen Source-Code >getrieben und dann mangels Zeit und Erweiterbarkeit eingestampft. Aua -- jetzt habe ich ein Zerrung im Hals... Übrigens: gschem in gEDA 1.6 verwendet jetzt cairo -- das Aussehen ist jetzt wirklich toll. Und PCB in den Entwicklerversionen benutzt OpenGL -- sieht auch sehr gut aus. Zum Glück gibt es nicht nur Dummschwätzer, sondern auch Leute, die fähig und willig sind etwas weiterzuentwickeln. (Aber leider haben die oft nicht viel Zeit.)
Hm. Kicad läuft bei mir absolut stabil. War selbst überrascht wie gut. Und im Gegansatz z.B. zu GIMP hat es offenbar auch die richtige Umgebung für Multiplattform-Entwicklung. Dagegen ist GIMP geradezu krank. Das Problem mit dem Refreshen ist selbst bei professionellen Systemen normal. Früher waren die Rechner nicht schnell genug, damit man "online" redrawen konnte, also wurde der Refresh nur per Tastenkürzel aufgerufen. Heutzutage geht das augenblicklich und das ist damit kein Argument mehr.
Eigentlich sind doch 3D-Umgebungen völlig usus. Die ganzen Zocker und Nintendonisten haben dafür Entwicklungsumgebungen, die das dann auch schnell auf die aktuelle Hardware samt Beschleuniger abbilden können. Guck dir mal die Ballerspiele an. Da gibt es auch Abhängigkeiten wie bei Platinen. Wer berührt wen usw. Aber es fehlt offensichtlich jemand, der sowohl Spieler, als auch Entwickler, als auch PCB-Erfahrener ist und genug Leidensdruck besitzt, das in brauchbare Software zu gießen.
Das Thema ist nicht vergessen. Die Einbettung von OpenGL in Eclipse läuft und ich habe einen Prototypen Klassenhierarchie gebastelt. Ist nicht viel, ich weiß. Ich kann aus privaten Gründen im Moment leider keine Zeit investieren, es kommen aber wieder bessere Zeiten. >Aber es fehlt offensichtlich jemand, der sowohl Spieler, als auch >Entwickler, als auch PCB-Erfahrener ist und genug Leidensdruck besitzt, >das in brauchbare Software zu gießen. Ich denke, der Schuh passt mir - wenn man jetzt noch arbeitslos und ohne Familie wäre, wäre die Software schon fertig ;) Danke für euer Interesse! Gruß, Kai
Stephan M. schrieb: > Ich würde schon sagen, dass sich eine Open-Source-Neuentwicklung einer > CAD/PCB-Lösung lohnen würde! wie denn und für wen??? Der(Die) Entwickler kriegt sowieso nichts dafür. Es lohnt sich bloss für die, die die Software dann kostenlos benutzen möchten - aber die entwickeln sie ja nicht. So nach dem Motto Open Source ist wenn andere ohne Geld für mich arbeiten. Man kann leicht die Freiheit für alle Ideen fordern, solange es sich um die Ideen andrer Leute handelt. Gruss Reinhard
>Der(Die) Entwickler kriegt sowieso nichts dafür. Es lohnt sich bloss für
Ich denke nicht, dass es so einfach ist. Nach deiner Definition dürfte
es diverse OpenSource-Programme gar nicht geben.
Kai Giebeler schrieb: > Nach deiner Definition dürfte > es diverse OpenSource-Programme gar nicht geben. Das hat er nicht gesagt. Ich verstehe nicht, wie man so eine einfache Aussage so missinterpretieren kann?
Kai Giebeler schrieb: >>Der(Die) Entwickler kriegt sowieso nichts dafür. Es lohnt sich bloss für > > Ich denke nicht, dass es so einfach ist. Nach deiner Definition dürfte > es diverse OpenSource-Programme gar nicht geben. Mich interessiert hier ja nur der wirtschaftliche Aspekt. Es gibt viele mögliche Gründe, Software zu verschenken, angefangen mit reinem Gutmenschentum über die Einsicht, dass man sowieso nichts dafür bekommt bis zum Versuch, mit der Software die Weltherrschaft zu erringen (Internet Explorer). Das ändert aber nichts daran, dass ein Entwickler, der nicht bei Sun oder IBM an Opensource-Projekten arbeitet, eben nichts dafür bekommt, für ein CAD-Programm aber einen wesentlichen Teil seiner Arbeitszeit aufwenden müsste. Man mag ja noch einige finden, die das möchten, aber kaum jemand, der das kann. BITTE nicht nochmal den Unterschied zwischen unentgeltlich und Opensource erklären, darum geht es nicht, sondern um die Implikation OpenSource -> Preis = 0. Kein Privatentwickler bekommt Geld für etwas, das jeder nach Belieben benutzen darf. Gruss Reinhard
Reinhard Kern schrieb: >> Ich würde schon sagen, dass sich eine Open-Source-Neuentwicklung einer >> CAD/PCB-Lösung lohnen würde! > > wie denn und für wen??? Ganz einfach: Für mich. Meine Motivation sowas zu machen wäre in erster Linie mein persönlicher Erfolg in folgender Hinsicht: - Ich lerne etwas dazu - Ich gewinne Erfahrung - Ich habe etwas erschaffen - Ich habe eine Software die meinen Wünschen entspricht Wenn mehrere Leute gemeinsam dran arbeiten dann ersetze man "ich" gegen "wir". Ist die Software dann irgendwann auch für andere nützlich, um so besser. Meine Motivation ist und bleibt aber, wenn Du so willst, rein egoistischer Natur, mit einem Hauch von Open-Source-Idealismus. Ich bin mir auch dank meiner eigenen Versuche sehr wohl darüber im klaren, dass so ein Unterfangen hochgradig schwierig und vor allem zeitaufwändig ist. Dennoch bleibe ich bei meiner Meinung. Stephan
Gerade hast du damit geschrieben, das du das Interesse verlieren wirst, wenn die Software deiner Meinung nach fertig ist. Nicht böse sein.
Interessant, gerade hier drauf gestoßen. Dann bin ich einfach mal gespannt und harre der Dinge die da kommen mögen. Viel Erfolg!
Stephan M. schrieb: > - Ich lerne etwas dazu > - Ich gewinne Erfahrung > - Ich habe etwas erschaffen > - Ich habe eine Software die meinen Wünschen entspricht Hallo, 1-3 ist völlig ok, bei 4 habe ich massive Zweifel, es sei denn, im Lauf der Entwicklung passen sich deine Wünsche den Möglichkeiten an. Die grossen kommerziellen Pakete erfüllen auch nach 100000 Mannstunden Entwicklung längst nicht alle Wünsche. Natürlich glaubt jeder Frischling, er könnte alles um den Faktor 100 schneller und besser als die Vorgänger, allerdings ist das IMMER ein Irrtum. Format Einstein mal ausgenommen. Gruss Reinhard
Hallo Reinhard. > 1-3 ist völlig ok, bei 4 habe ich massive Zweifel, es sei denn, im Lauf > der Entwicklung passen sich deine Wünsche den Möglichkeiten an. Meistens hast Du recht. Allerdings hätte ich gelegentlich nur an bestimmten Punkten besondere Vorstellungen, wohingegen mir dann anderes zweitrangig ist. Ich will also eigentlich nicht "besser" sondern "anders". Und das ist eben sehr oft machbar. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Übrigens: Wer meint, dass man ein neues EDA Programm mal eben so aus dem Ärmel schütteln kann, darf gerne mal über folgendes winziges Teilproblem nachdenken: Wir haben zwei Kreisbögen, die mit einem Stift endlicher Dicke gezeichnet werden. Frage: Berühren sich die beiden, oder nicht. Natürlich muss dieser Test sehr schnell durchzurechnen sein, denn auf Leiterplatten können ja tausende davon vorliegen, die jeweils auf Kurzschluss getested werden müsses, möglichst in Echtzeit.
Na ja - ist jetzt nicht so, dass es dafür keinen altbekannten Lösungsansatz gäbe: - http://de.wikipedia.org/wiki/Quadtree - http://de.wikipedia.org/wiki/K-d-Baum - http://de.wikipedia.org/wiki/Gridfile ... und zur Not einfach erstmal ein Bitmap rastern. Kann man ja immer noch optimieren. Da ist das Projektmanagement das weitaus größere Problem. >Übrigens: Wer meint, dass man ein neues EDA Programm mal eben so aus dem >Ärmel schütteln kann, Behauptet ja auch keiner.
@Kai Giebeler Du hast also noch nicht aufgegeben -- schön. Mir ging es hier allein um das geometrische Problem -- arc-arc intersection, wobei die Keisbögen aber eine endliche Dicke haben, insbesondere mit einem runden Stift gezeichnet sind. Ich sehe gerade nicht so recht, wie Deine Links da weiterhelfen. Schnittpunkt von Voll-Kreisen ist ja noch relativ einfach -- darauf wird man es wohl zurückführen müssen. Wie ich darauf komme? gEDA/PCB hat da wohl gerade einen kleinen Bug.
Stefan Salewski schrieb: > Mir ging es hier allein um das geometrische Problem -- arc-arc > intersection, wobei die Keisbögen aber eine endliche Dicke haben, Hi, in einem EDA-Programm solltest du das noch dazu in ms rechnen können, sonst kannst du Online-DRC gleich vergessen. Gruss Reinhard
>in einem EDA-Programm solltest du das noch dazu in ms rechnen können, >sonst kannst du Online-DRC gleich vergessen. Ist mir klar, gEDA/PCB ist da auch recht fix -- blos scheinbar nicht ganz exakt. Ich denke PCB macht sämtlich DRC Sachen geometrisch. Nach Kais letzter Mail will er es vielleicht eher Raster/Bitmap-Orientiert aufziehen?
> Nach Kais letzter Mail will er es vielleicht eher Raster/Bitmap-Orientiert > aufziehen? Die Rasterung würde nur lokal für die Kollisionserkennung verwendet werden - und das auch nur als Notlösung. Das interne Modell (NEIN, DAS IST NICHT DAS DATEIFORMAT!) ist und bleibt vektorbasiert - ich bin vielleicht wahnsinnig, aber nicht blöd. >Ich sehe gerade >nicht so recht, wie Deine Links da weiterhelfen. Warum nicht? Ich kann sogar noch ein paar brauchbare Verfahren drauflegen: - http://de.wikipedia.org/wiki/Bounding_Volume - http://de.wikipedia.org/wiki/Hitbox Alles legitime altbekannte Verfahren, wenn eine analytische Lösung zu aufwändig oder unmöglich ist. POVray verwendet ähnliche Verfahren zum Rendern von Tori, auch wenn eine analytische Lösung möglich wäre. Schöne Grüße, Kai
Die analytische Lösung ist auch alles andere als unschaffbar: 1. Über die CSG (Constructive Solid Geometry) kann man das Problem auf den Schnitt zweier Ellipsen zurückführen. 2. Über entsprechende affine Transformationen lässt sich das Problem auf den Schnitt einer Ellipse im Ursprung (Halbachsen parallel zum Koordinatensystem) mit einem frei positionierbaren Einheitskreis reduzieren. 3. Geradengleichung in Parameterform aufstellen (durch beide Mittelpunkte) 4. Wenn der Schnittpunkt der Gerade mit der Ellipse weiter vom Ursprung entfernt liegt als der Schnitt mit dem Einheitskreis, dann überschneiden sie sich. Zwischen 2. und 3. kann man ggf. noch weiter vereinfachen indem man den Einheitskreis auf einen Punkt reduziert und die Ellipse dafür vergrößert. Müsste aber erst bewiesen werden und bringt vermutlich nicht allzu viel. Da gibt's genug Stolperfallen, bei denen man sich vertun kann - insbesondere die Randbedingungen bei der CSG, da sich die beiden Ellipsensegmente ist sehr unterschiedlicher Weise schneiden können. Aber machbar ist das allemal. Schöne Grüße, Kai
Hallo Zusammen, wieder sind drei Monate ins Land gegangen und erneut stelle ich die Frage: Gibt es eine erste Version? Na ja, ggf. frage ich in drei Monaten noch einmal nach ;-) ? Gruß NoName
Hoi, habe bislang noch keine Zeit gefunden, daran weiter zu machen. Das Projekt reizt mich immer noch, aber so wie's bisher läuft sieht's schlecht aus. Gruß, Kai
Ich wünsche dir viel Glück, aber habe wenig Hoffnung :-) Gruß! Ein nicht ganz nüchterner.
Tag zusammen, wie von einigen vermutet und von mir befürchtet, werde ich das Projekt aus Zeitgründen nicht durchführen können. Ich finde das Projekt jedoch nach wie vor spannend und wer noch Ideen hat kann sich gerne melden. Danke für eure Beteiligung und schöne Grüße, Kai
Warst du dir eigentlich sicher, daß Java für so eine Anwendung performant genug ist?
Hi Uhu, Java ist gar nicht so imperformant. Für die kritischen Teile (GUI und 2D-Grafik) wollte ich ohnehin auf SWT bzw. OpenGL zurückgreifen. Gruß, Kai
Uhu Uhuhu schrieb: > Warst du dir eigentlich sicher, daß Java für so eine Anwendung > performant genug ist? Ach Uhu. Eine Sache wenn man gegen Java staenkert, ich mags auch nicht. Wenn man das aber macht, um dem anderen eine reinzuwuergen ist das arm. Zumal es eCad in java gibt, mit bereichsweise mehr Features als Eagle. Solltest du sagen, es war nicht so gemeint: So kams hier an, und wenn ich da nicht der einzige bin ist das das was zaehlt.
David ... schrieb: > Ach Uhu. Eine Sache wenn man gegen Java staenkert, ich mags auch nicht. Hab ich gestänkert? > Wenn man das aber macht, um dem anderen eine reinzuwuergen ist das arm. Was hast du geraucht?
Kai Giebeler schrieb: > Java ist gar nicht so imperformant. Es sind ja auch eine ganze Menge echte Massenberechnungen nötig, Kolisionsberechnung etc. wo ich mich dann schon frage, ob man sowas sinnvoll auf einem interpretierten System machen kann. Prinzipiell ist die Portabilität natürlich ein Riesenplus, nur wenn die auf Kosten der Laufzeit geht, dann muß man schon genau abwägen.
Gerade bei diesen "Massenberechnungen" kann Java ganz gut mithalten. Damit jetzt nicht wieder eine "meine Programmiersprache ist besser als deine"-Diskussion losbricht empfehle ich folgende Seite als Lektüre: http://www.idiom.com/~zilla/Computer/javaCbenchmark.html Gruß, Kai
Kai Giebeler schrieb: > empfehle ich folgende Seite als Lektüre... Na dann besteht für Ruby ja noch Hoffnung ;-)
Uhu Uhuhu schrieb: > David ... schrieb: >> Ach Uhu. Eine Sache wenn man gegen Java staenkert, ich mags auch nicht. > > Hab ich gestänkert? Wie ich sagte: Es zaehlt wie es ankommt. >> Wenn man das aber macht, um dem anderen eine reinzuwuergen ist das arm. > Was hast du geraucht? Ich schaeme mich dass ich dich ueberschaetzt habe.
Sowas geht schon in Java. Java ist eigentlich gar nicht unperformant, sondern hat aufgrund der VM beim Starten etwas 'Mühe'. Bei einem Layout-Programm, wo ich typischerweise mehrere Stunden dransitze, stören mich aber 10 Sekunden Startzeit nicht. Ob der Rest dann performant läuft, ist primär eine Frage des verwendeten GUI-Toolkits und nicht von Java.
David ... schrieb: >> Hab ich gestänkert? > Wie ich sagte: Es zaehlt wie es ankommt. Mann, Mann, ws kann ich dafür, was in deinem Kopf vorgeht... Ich hatte eine ganz simple Frage frage gestellt und eine eben so einfache Antwort erwartet. Ich hatte nämlich mal mit einer Java-Applikation zu tun, die nicht gerade durch Geschwindigkeit geglänzt hat und das nicht nur beim Start.
Thomas schrieb: > Mach doch bei KiCad mit. Gibt sicher was zu tun. Genau das hätte ich auch vorgeschlagen. Hilfe wird z.B. bei der Übersetzung der Doku ins Deutsche gebraucht, oder man erstellt ordentliche Bibliotheken. Manchmal sind es auch einfach nur Kleinigkeiten, die fehlen oder die man einstellen können müsste. Mir fehlt z.B. das weiche Verschieben/Ziehen per gedrückter mittlerer Maustaste. Das voreingestellte Springen empfinde ich als sehr störend. Leider stecke ich nicht in wxWidgets drin, sonst hätte ich da schon einiges beigetragen :-/ Die neue KiCad-Version ist schon richtig "hübsch" geworden :-) Chris D.
"Hilfe wird z.B. bei der Übersetzung der Doku ins Deutsche gebraucht, oder man erstellt ordentliche Bibliotheken." Ist ja eher "Assi-Arbeit". OK, man kann sein Fach-Englisch ganz gut aufbessern dadurch. Aber Kai sucht ja scheinbar eher eine Herausforderung im Bereich der Programmierung. Gibt es aber sicher auch.
Warum nicht als Layout-Modul passend zu LTspice entwickeln? Der dort integrierte Schaltplan-Editor ist schon fast ein ganz großer.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.