Unter Ubuntu scheint es ein paar mal ein paar Funktionen nicht zu kennen. Hab mal Issue #25 erstellt. Höre jetzt auf mit dem Versuch es zu compilieren.
Michael H. schrieb: > Unter Ubuntu scheint es ein paar mal ein paar Funktionen nicht zu > kennen. Hab mal Issue #25 erstellt. Höre jetzt auf mit dem Versuch es zu > compilieren. Wie schon auf github geschrieben: Da ist dein ubuntu wohl zu alt. Warte entweder auf das neue LTS oder upgrade auf 17.04.
Ich habe das Programm am Laufen. Danke an Lukas für den Support. Ich freue mich, zu sehen, wie dieses Projekt weiterentwickelt wird... Vielen Dank an Lukas für die Arbeit schomal. Mach weiter so!
Gute Neuigkeiten für alle, die den Pool als zip runtergeladen haben und keine sinnvolle Möglichkeit hatten, den Pool aktuell zu halten: Seit soeben kann der Pool-Manager das: Auf der Startseite mit "Download..." den Pool herunterladen, dann gibt's den neuen Tab "Remote" mit dem Knopf "Upgrade Pool", mit dem seinen lokalen Pool unter Beibehaltung eigener neuer Parts und Änderungen auf den aktuellen Stand bringen kann. Bald kann der Pool Manager dann auch mithilfe der Github-API für einen Pull Requests aufmachen, damit man auch ohne weitere Git-Kenntnisse neue Bauteile in den Pool einpflegen kann.
Angehängte Dateien:
-
libcurl-4.dll.PNG
12 KB
Hallo Lukas, ich habe Probleme beim build für Windows. $ ./make_bindist.sh Obiges läuft normal durch. Wenn ich dann in Windows auf horizon-pool-mgr.exe klicke erhalte ich eine Fehlermeldung wegen fehlender libcurl-4.dll. Gruß Helmut
:
Bearbeitet durch User
Helmut S. schrieb: > eine Fehlermeldung wegen fehlender libcurl-4.dll. Ist repariert. Ein wenig unschön ist allerdings, dass ich auf Windows für curl und libgit selber die root-Zertifikate für TLS ausliefern muss...
Hier gibt es ein Tool zum exportieren von Eagle-Designs: https://hackaday.com/2017/12/21/exporting-eagle-libraries-to-foss-tools/ Vielleicht nützt das auch was für dieses Projekt.
chris schrieb: > Hier gibt es ein Tool zum exportieren von Eagle-Designs: Das Tool müsste ja in den horizon pool einspeisen, ist das überhaupt machbar? Nicht nur wegen der unterschiedlichen Datenstrukturen, sondern auch, weil im horizon Wiki steht: > Although you can create your own pool, you are strongly encouraged to > use the pool over at https://github.com/carrotIndustries/horizon-pool/. > To add new parts to it, simply submit a merge request. Wie ist denn das zu verstehen? Ob man wirklich meine Spezialteile im Pool haben will, sei mal dahin gestellt. Aber heißt das, wenn ich ein neues Bauteile brauche, muss ich warten, bis das im Pool eingepflegt ist? Wie ist das gedacht? Und wo wir gerade dabei sind, das README schreibt: > Features for developers > (...) > Everything is referenced by UUIDs Die UUIDs müssten doch zentral erzeugt werden? Und trotzdem wären sie u.U. nicht eindeutig; wie werden Kollisionen behandelt?
eagle user schrieb: > Die UUIDs müssten doch zentral erzeugt werden? Und trotzdem wären sie > u.U. nicht eindeutig; wie werden Kollisionen behandelt? Der Sinn von UUIDs ist, dass man eben ohne zentrale Instanz eindeutige IDs erzeugen kann. Da es ca. 3.4×10³⁸ verschiedene UUIDs gibt, klappt das auch gut genug. Die Wahrscheinlichkeit, dass Dinge aufgrund eines Bugs in meinem Code kaputt gehen, ist deutlich größer, als die, dass man über eine doppelte UUID stolpert. eagle user schrieb: > Aber heißt das, wenn ich ein > neues Bauteile brauche, muss ich warten, bis das im Pool eingepflegt > ist? Wie ist das gedacht? Nein, selber einpflegen. Derzeit heißt das Forken, Branch machen, Bauteil anlegen, Commiten, merge request aufmachen und hoffen dass der akzeptiert wird. Dann haben alle was davon. Gerade bin ich dabei, GitHub-Integration einzubauen, damit diese Schritte in vereinfachter Form direkt im Pool Manager ohne weitere git-Kenntnisse erledigt werden können. eagle user schrieb: > Das Tool müsste ja in den horizon pool einspeisen, ist das überhaupt > machbar? Nicht nur wegen der unterschiedlichen Datenstrukturen, Bei Packages sehe ich einen Importer noch am einfachsten umsetzbar. Bei Symbolen muss sich der Importer eben Units und Entities dazu ausdenken. Alles in allem kein Hexenwerk, Freiweillige vor :) Uwe B. schrieb: > Lukas, > > wirst Du auf der FOSDEM im EDA Devroom vortragen? Ja: https://fosdem.org/2018/schedule/event/cad_horizon/ Auf dem 34C3 bin ich auch anzutreffen, einfach PN schreiben.
Lukas K. schrieb: > Auf dem 34C3 bin ich auch anzutreffen Hälst du einen Vortrag? Das Programm ist so riesig, dass ich zumindest auf Anhieb nichts sehen konnte. Wenn du einen Vortrag hälst und es zeitlich passt, würde ich mir den Livestream reinziehen.
Jörg W. schrieb: > Hälst du einen Vortrag? Ne, dafür ist das Projekt m.E. noch nicht weit genug. Nächstes Jahr dann vielleicht.
Meine perschönliche Sichtweise auf das CAD-Programm ist, dass es auf dem richtigen Weg ist und das was werden könnte. Jedoch denke ich, dass noch einiges an Usability-Improvements von Nöten ist - wie Du selbst sagst ist das Programm in den Kinderschuhen. So hat KiCad auch mal angefangen. Was mich an KiCAD stört, ist das die keine Clearance-Matrix haben und das auch nicht implementieren wollen. Desshlab möchte ich mal dein Program ausprobieren. Ich habe heute ca. 2h gebraucht, um mir grob mal einen Überblick zu verschaffen. Ich erstelle Dir für alles was mir auffällt ein Issue. Das kann etwas bombadierend wirken - ist aber so nicht gemeint. Mit dem Fosdem würde mich auch der Vortrag interessieren - den würde ich mir auch gerne dann als Video reinziehen. Mein Plan ist es eine Testplatine damit zu machen, und mal 5 Euro in eine ChinaPCB zu investieren und den Prozess dann in einem separten Threat zu dokumentieren. Mal sehen, ob ich das hinbekomme. EDIT: Eine Problematik, die ich bei den Pools sehe, was ich aber auch falsch sehen könnte, ist falls jemand mist commited, andere darunter leiden. Desshalb hatte ich separate Pools vorgeschlagen. Jedoch sollte falls man nur einen Pool haben sollte, einen Button haben, der den Pool automatisch updated. Also, dass man nicht erst "umständlich" git clone, etc. machen muss. Praktiker würde das abschrecken...
:
Bearbeitet durch User
Michael H. schrieb: > Jedoch sollte falls man nur einen Pool haben sollte, einen Button haben, > der den Pool automatisch updated. Genau das gibt es doch seit kurzem: Wenn du den Pool mit "Download..." heruntergeladen hast, gibt es im Tab "Remote" den Knopf "Upgrade" um den lokalen Pool auf den Stand von dem auf Github zu bringen. Michael H. schrieb: > ist falls jemand mist commited, andere darunter leiden. Darum schau ich's mir (und in Zukunft hoffentlich noch andere) an. Das entbindet einen als Anwender dennoch nicht davon, das Part selber zu verifizieren. EDIT: Wenn du Bugfixes schnell haben willst, ist es empfehlenswert selber zu bauen: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows
:
Bearbeitet durch User
Lukas K. schrieb: > Darum schau ich's mir (und in Zukunft hoffentlich noch andere) an. Wird aber irgendwann ein Fulltime-Job werden. Man sollte vorher eine Strategie haben, wie jeder dann auf seinem privaten Fork des „offiziellen“ Pools arbeiten kann, von diesem ggf. Updates importiert, aber ansonsten seine eigenen Bauteile privat hält. Ein EDA-Programm, welches alle Bauteile in der Bibliothek hat, wird es ohnehin nicht geben können. Dazu sind erstens die Hersteller zu einfallsreich :) und zweitens die Anforderungen der Anwender zu verschieden. ps: Viel Spaß auf dem 34C3!
:
Bearbeitet durch Moderator
Michael H. schrieb: > Eine Problematik, die ich bei den Pools sehe, was ich aber auch falsch > sehen könnte, ist falls jemand mist commited, andere darunter leiden. Ich fürchte, das siehst du richtig. Deswegen sollte man das... chris schrieb: > Hier gibt es ein Tool zum exportieren von Eagle-Designs: ...wahrscheinlich vermeiden. Die bei Eagle mitgelieferten Bauteile haben mich schon nicht überzeugt, aber was ich bisher aus anderen Quellen gefunden habe war den Download nicht wert. Cadsoft hatte ja ein paar (wenige) Regeln festgelegt, aber nicht einmal die werden eingehalten. Die Idee, im Pool nur die originale Herstellernummer zu verwenden, finde ich ausgezeichnet (ich hoffe, ich hab' das richtig verstanden). Das ist schon mal sehr viel besser als die Praxis bei Eagle.
Bauteile genau anzulegen, und zu pflegen ist ein heiden Aufwand. Desshalb gibt es ja SnapEDA, Librarian und wie die alle heißen. Eventuell könnte man sich mit denen zusammentun? Für den Anfang kann ich gerne helfen, über die Bauteile drüber zu schauen, die reinkommen. Falls Hilfe gewünscht ist.
Hallo Eagle user und Michael . eagle user schrieb: >> Hier gibt es ein Tool zum exportieren von Eagle-Designs: > > ...wahrscheinlich vermeiden. Die bei Eagle mitgelieferten Bauteile haben > mich schon nicht überzeugt, aber was ich bisher aus anderen Quellen > gefunden habe war den Download nicht wert. Das wird wohl so für jede x-beliebige Quelle gelten, weil halt auch jeder andere Vorstellungen von einer guten Bibliothek hat. Darum wird niemand, der sich ernsthaft mit Schaltplänen und Platinenlayout beschäftigt, darumherum kommen, sich seine eigene Bibliothek zusammenzustellen, die er irgendwann halt auch gut kennt, und von deren Bestandteilen er weiss, dass sie auch im Zusammenhang mit seinen anderen "Systemen" gut funktioniert. Offizielle Bibliotheken sind eigentlich nur ein erster Vorschlag, den man oft so aktzeptieren kann, aber auch genauso oft anpassen muss, und der auch immer auf Fehler überprüft werden muss. Darum kann ein breiter Zugriff auch auf fremde Bibliotheken sehr sinnvoll sein. Snapeda bietet eine breite Palette von Programmen, in deren Format exportiert werden kann, aber nur Eagle und KiCad haben davon offene bzw. sogar freie Formate. Snapeda: https://www.snapeda.com/ Viele Distributoren bieten den Download von Bibliotheken zu denen von ihnen vertriebenen Bauteilen an wie zum Beispiel Farnell oder Digikey. Das sind dann auch meistens Eagle oder KiCad Bibliotheken. Digikey: https://www.digikey.de/de/news/press-releases/2017/aug/digi-key-adds-kicad-pcb-model-download Es ist also eher angeraten, eine Import und Exportfunktion für gängige Bibliotheksformate zu schreiben. Gängig und offen oder sogar frei sind aber nur drei: Eagle, KiCad und gEDA. Michael H. schrieb: > Bauteile genau anzulegen, und zu pflegen ist ein heiden Aufwand. > Desshalb gibt es ja SnapEDA, Librarian und wie die alle heißen. Das haut in die gleiche Kerbe. > Eventuell könnte man sich mit denen zusammentun? Warum soll man in den Format Zoo ein weiteres Format einbringen, solange es offene und freie gibt? Lieber auf ein freies vorhandenes gehen, was auch schon unterstützt wird. Ein neues Format müsste schon eine erhebliche Verbreitung bekommen, bevor es bei diesen Anbietern aufgenommen würde. KiCad wäre ein guter Kandidat als Austauschformat , weil dort Symbol, Footprint und 3D-Modell zusammengefasst werden können , aber nicht zusammengefasst werden müssen . Es ist also in dieser Hinsicht sehr flexibel. eagle user schrieb: > Cadsoft hatte ja ein paar > (wenige) Regeln festgelegt, aber nicht einmal die werden eingehalten. Es ist erstens auch immer die Frage, was an Regel sinnvoll ist, und zweitens selbst wenn irgendwann einmal alle Bibliotheken konform mit den Regeln sind, und die Regeln werden überarbeitet, ist es ein großer Arbeitsaufwand bzw. Zeitaufwand, die vorhandenen Bibliotheken anzupassen. Die Bibliotheken hinken den Regeln also immer hinterher. Das habe ich bei Eagle so bemerkt, und bei KiCad eben auch. Bei KiCad existiert für das Bibliotheksprojekt (was vom eigentlichen KiCad Projekt sogar getrennt ist) ein Regelwerk: https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention Wer zu der Bibliothek beitragen will, kann das nur, wenn irgend jemand anderes die Bibliothek auf Konsens mit dem aktuellen Regelwerk überprüft hat. > Die Idee, im Pool nur die originale Herstellernummer zu verwenden, finde > ich ausgezeichnet (ich hoffe, ich hab' das richtig verstanden). Das ist > schon mal sehr viel besser als die Praxis bei Eagle. Das ist ein guter Ansatz. Aber natürlich sind auch alternative Symbole und Footprints für das gleiche Bauteil sinnvoll. Im Schaltplan möchtest Du einmal z.B. eine monolitische Darstellung für z.B. ein Relais, wo Spule und Kontaktsätze zusammengefasst sind, aber auch eins in aufgelöster Darstellung wo Spule und Kontaktsätze getrennt sind, um sie bei größeren Schaltplänen verteilen zu können. Je nach den Umständen ist das eine oder andere Sinnvoll. Bei Footprints gibt es bei THT Bauteilen oft die Möglichkeit, sie liegend oder stehend zu montieren, oder allgemein kleine Pads wo Dichte oder Isolationsabstand wichtig sind, oder aber große Pads, wo Platz ist, aus Robustheitsgründen. Viele Bauteile existieren mit einem mehr oder weniger Festgelegten Gehäuse. Für diese sind generische Footprints gut, die man bei Bedarf auch ändern kann. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
Bernd W. schrieb: > Das ist ein guter Ansatz. Aber natürlich sind auch alternative Symbole > und Footprints für das gleiche Bauteil sinnvoll. Das funktioniert bereits. Die GitHub-Integration zum Erstellen von Pull Requests gibt's nun auch: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard#using-the-github-integration
Angehängte Dateien:
-
make_fehler.PNG
23 KB
Hallo Lukas, das kompilieren in mysys2 bringt eine "Fehler"-Meldung - scheint aber trotzdem richtig kompiliert zu haben. Idee? Helmut
Bernd W. schrieb: > KiCad wäre ein guter Kandidat als Austauschformat , weil dort Symbol, > Footprint und 3D-Modell zusammengefasst werden können , > aber nicht zusammengefasst werden müssen . Es ist also in dieser > Hinsicht sehr flexibel. FÜhrt aber nicht gerade zur Standardisierung eines Übergabeformats, weil dann wieder jeder macht, was er möchte. Andererseits: Wer baucht bei der Übergabe von Produktionsdaten Symbole? Genau das möchte Ich z.B. nicht. Der Produzent soll die Platine machen und mehr nicht, weil Prototyp. Bei einer Serie ist es was anderes.
Helmut S. schrieb: > Hallo Lukas, > das kompilieren in mysys2 bringt eine "Fehler"-Meldung - scheint aber > trotzdem richtig kompiliert zu haben. Idee? > Helmut Richtig gebaut haben kann es damit nicht, ist repariert.
Bernd Wiebus (berndwiebus) Benutzerseite >Das wird wohl so für jede x-beliebige Quelle gelten, weil halt auch >jeder andere Vorstellungen von einer guten Bibliothek hat. >Darum wird niemand, der sich ernsthaft mit Schaltplänen und >Platinenlayout beschäftigt, darumherum kommen, sich seine eigene >Bibliothek zusammenzustellen, die er irgendwann halt auch gut kennt, und >von deren Bestandteilen er weiss, dass sie auch im Zusammenhang mit >seinen anderen "Systemen" gut funktioniert. Das genau bringt mich jedes Mal auf die Palme, wenn ich darüber nachdenke. Ich habe schon in Firmen gearbeitet, bei denen ein Mann mit nichts anderem beschäftigt ist, als Bauteile anzulegen. Wenn man dann ein Neues braucht, muss man jedes Mal warten, bis der Zeit hat. Jeder Hersteller eines Bauteils wird sein Bauteil wohl mit einem CAD-System konstruiert haben. Gäbe es eine einheitliches Format wie z.B. DIN, wäre die ganze Blindleistung dass jede Firma wieder ihr eigenes Bauteil anlegen muss, unnötig.
chris schrieb: > Gäbe es eine einheitliches Format wie z.B. DIN, wäre die ganze > Blindleistung dass jede Firma wieder ihr eigenes Bauteil anlegen muss, > unnötig. Du hast noch nicht verstanden, dass es absolut nicht am fehlenden Format liegt, sondern dass einfach jede Firma ihre eigenen Ideen hat, was beim Anlegen eines Bauteils wichtig ist, wie sich das Ding in die firmeneigene Infrastruktur integriert etc. pp. Die paar Striche zu zeichnen, ist dabei fast der geringste Anteil an Arbeit. Die MechCAD-Daten bekommt man mittlerweile teilweise sogar von den Herstellern (genauso wie die 3D-CAD-Daten). Gehört aber nicht hierher, hier geht es um Horizon.
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
horizon17.png
66 KB
Ich konnte heute (nach einem Update "git pull; make") den interaktiven Router nicht mehr starten. Ich hatte ein paar Leiterbahnen gelöscht und wollte diese neue verlegen. Fehlermeldung siehe Bildschirmfoto.
Klaus R. schrieb: > Ich konnte heute (nach einem Update "git pull; make") den interaktiven > Router nicht mehr starten. Ich hatte ein paar Leiterbahnen gelöscht und > wollte diese neue verlegen. Fehlermeldung siehe Bildschirmfoto. Hallo Klaus, ich konnte den von dir beschriebenen Fehler in WIN10 nicht nachvollziehen. Falls du einen WIndows-Rechner hast, dann könntest du es mal mit der von Lukas generierten WIN-Version vom 01.01.2018 testen. http://0x83.eu/horizon-zip/ Gruß Helmut
:
Bearbeitet durch User
Klaus R. schrieb: > den interaktiven > Router nicht mehr starten. Endlich kommt das Logging mal Sinnvoll zum Einsatz. Davor wäre das ganze Programm abgestürzt :) Der Fehler kam, daher, dass in deinem eigenen Padstack beim SSOP-28 aus noch unbekannter Ursache Polygone ohne Vertices waren. Jetzt werden diese nicht mehr geladen.
:
Bearbeitet durch User
Lukas K. schrieb: > Der Fehler kam, daher, dass in deinem eigenen Padstack beim SSOP-28 aus > noch unbekannter Ursache Polygone ohne Vertices waren. Jetzt werden > diese nicht mehr geladen. Ja, danke! Jetzt geht es. Die "eigenen Padstacks" haben leider mir schon etwas Kummer bereitet. Hätte ich nur am Anfang kapiert, dass die schon vorhandenen Padstacks parametrisierbar sind... wüsste jetzt nicht, wo man dann noch eigene bräuchte.
Hi Lukas! Ich habe gestern ganz zufällig dein Projekt gefunden und ich muss dir wirklich sagen: Hut ab! Ich hatte das gleiche schon (einfaches Tool, globale Library (hier Pool), usw.) vor ein paar Jahren vor zu implementieren, jedoch fehlte mir einfach die Zeit dafür. Ich bin dir auf jeden Fall sehr dankbar für deine Mühe :) Auf Github hast du sicherlich schon mitbekommen, dass ich hier auch mit arbeiten möchte bzw. auch schon mache (Github-user: peterus). Unter anderem habe ich bereits ein Script erstellt um die SMD Widerstände der Größen 0402, 0603, 0805 und 1206 in der E12-Reihe automatisch zu generieren (von 0 bis 100MOhm). Das hab ich eigentlich einmal nur gemacht, um mich mit den Pool-Daten näher zu beschäftigen. Wenn du nichts dagegen hast, würde ich gerne das makefile "austauschen" auf cmake. Ich benütze cmake schon seit ein paar Jahren und man hat damit einige mehr Vorteile (auflösen von externen Bibliotheken ist einfacher, es gibt mehrere config files, logging von dem was man sehen möchte, logging ist auch schöner, usw.). Zusätzlich würde ich auch gleich ein bisschen aufräumen und ein bisschen eine bessere Struktur rein bringen wo die Daten gespeichert sind. Anfangen würde ich damit, dass ich mal alle cpp's und hpp's durch gehe und einen Header mit Lizenz rein schreiben lasse mit einem Script. edit: habs mir anders überlegt: Lizenz solltest du übernehmen :)
:
Bearbeitet durch User
Peter B. schrieb: > Ich bin dir auf jeden Fall sehr dankbar für deine Mühe :) Schön zu hören :) > Auf Github hast du sicherlich schon mitbekommen, dass ich hier auch mit > arbeiten möchte bzw. auch schon mache (Github-user: peterus). > Unter anderem habe ich bereits ein Script erstellt um die SMD > Widerstände der Größen 0402, 0603, 0805 und 1206 in der E12-Reihe > automatisch zu generieren (von 0 bis 100MOhm). > Das hab ich eigentlich einmal nur gemacht, um mich mit den Pool-Daten > näher zu beschäftigen. Okay, aber eigentlich will ich im Pool nur Bauteile mit MPN und Hersteller haben, bzw. die CPL-Teilenummern, die man mit den Octopart-Bomtool zu echten Bauteilen zuordnen kann. Mir schwebt vor, dass man zukünftig die exportierte BOM direkt bei Octopart oder Digikey einwerfen und dann einfach bestellen kann. Allerdings hat nicht jedes Projekt diesen Anspruch und so generische Widerstände können dafür durchaus praktisch sein, mal drüber nachdenken. > Wenn du nichts dagegen hast, würde ich gerne das makefile "austauschen" > auf cmake. Ich benütze cmake schon seit ein paar Jahren und man hat > damit einige mehr Vorteile (auflösen von externen Bibliotheken ist > einfacher, es gibt mehrere config files, logging von dem was man sehen > möchte, logging ist auch schöner, usw.). Bis jetzt fehlt mir an make eigentlich nichts wirklich, was die zusätzliche Komplexität rechtfertigen würde. Externe Bibliotheken zu finden klappt mit pkg-config auf meinen Zielplattformen auch hinreichend gut. > Zusätzlich würde ich auch gleich ein bisschen aufräumen und ein bisschen > eine bessere Struktur rein bringen wo die Daten gespeichert sind. Wie meinst du das genau? Jetzt bezogen auf pool oder source code? > Anfangen würde ich damit, dass ich mal alle cpp's und hpp's durch gehe > und einen Header mit Lizenz rein schreiben lasse mit einem Script. > > edit: habs mir anders überlegt: Lizenz solltest du übernehmen :) Auch wenn es mir persönlich missfällt, muss das wohl so sein...
> Okay, aber eigentlich will ich im Pool nur Bauteile mit MPN und > Hersteller haben, bzw. die CPL-Teilenummern, die man mit den > Octopart-Bomtool zu echten Bauteilen zuordnen kann. Mir schwebt vor, > dass man zukünftig die exportierte BOM direkt bei Octopart oder Digikey > einwerfen und dann einfach bestellen kann. Kann ich voll und ganz verstehen, jedoch gibt es hier gerade ein mal ein paar Widerstände in der CPL-Bibliothek. Ich hab mich ein bisschen eingelesen in das CPL und heraus gefunden, dass diese nur die meist benutzten Sachen rein stellen. Das heißt, dass dort nie ein Widerstand sein wird mit 5.6k (in 1206) weil dieser nicht unter den meist benützten ist. Angenommen ich möchte nun ein Projekt bauen wo dieser Widerstand benötigt wird. Ich kann ihn auch kaufen, nur gibt es den nicht im Pool - wäre ziemlich blöd... > Bis jetzt fehlt mir an make eigentlich nichts wirklich, was die > zusätzliche Komplexität rechtfertigen würde. Externe Bibliotheken zu > finden klappt mit pkg-config auf meinen Zielplattformen auch hinreichend > gut. Sobald das Projekt größer wird, wird es viel einfacher zum managen ;) Spreche da aus guter Erfahrung aus der Arbeit usw. > Wie meinst du das genau? Jetzt bezogen auf pool oder source code? Der Pool ist schon gut strukturiert! Beim Source Code habe ich sehr lange gebraucht bis ich verstanden habe wie wo was liegt. Bzw. was außerdem auch ein externer Code ist.
Peter B. schrieb: > Angenommen ich möchte nun ein Projekt bauen wo dieser Widerstand > benötigt wird. Ich kann ihn auch kaufen, nur gibt es den nicht im Pool - > wäre ziemlich blöd... Meine (vielleicht utopische) Idee war, dass der Anwender sich dann auf digikey den gewünschten Widerstand aussucht und mit einem Skript wie deinem gleich die ganze Serie des Herstellers in den Pool einpflegt. Wenn man sich beim Design der Schaltung nicht von sowas aufhalten lassen will, kann man auch einfach im Schaltplan den Widerstand auch ohne Part, nur als Entity, platzieren und den Wert einfach eintippen. Später kann man dann das Anlegen von den Bauteilen nachholen und mit dem "Assign Part"-Tool den Widerständen das richtige Part zuweisen. Peter B. schrieb: > Beim Source Code habe ich sehr lange gebraucht bis ich verstanden habe > wie wo was liegt. Bzw. was außerdem auch ein externer Code ist. Okay, man könnte alles externe (clipper, etc) in einen "3rd_party"-Ordner stecken, damit das besser getrennt ist. Was hat dich sonst so konkret gestört?
Lukas K. schrieb: > Meine (vielleicht utopische) Idee war, dass der Anwender sich dann auf > digikey den gewünschten Widerstand aussucht und mit einem Skript wie > deinem gleich die ganze Serie des Herstellers in den Pool einpflegt. Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature ist. KiCad kann es ja schon und ich würde mit keinem (neuen) Programm mehr arbeiten wollen, das keine 3d-Fähigkeiten hat.
Vielleicht könnte man wieder die 3D Ansicht von KiCad in horizon integrieren!
Mampf F. schrieb: > Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature > ist. Das trifft sich gut, da bin ich gerade dran :) Laden von STEP-Modellen mit opencascade klappt schon, an der richtigen Stelle in der 3D-Vorschau sind sie auch schon. Fehlt nur noch ein bisschen drumherum. Der Code zum STEP-Importieren mit opencascade ist weitestgehend von https://github.com/KiCad/kicad-source-mirror/blob/master/plugins/3d/oce/loadmodel.cpp abgekupfert. STEP-Export steht auch der Roadmap, das wird dann darauf hinauslaufen kicad2step zu portieren. A. N. schrieb: > Vielleicht könnte man wieder die 3D Ansicht von KiCad in horizon > integrieren! Ne, die haben aus mir unbekannten Gründen gleich ein ganzes Scenegraph-Framework implementiert und verwenden legacy-OpenGL. Ich werfe die Vertices und Indizes für die Dreiecke aller Bauteile auf dem Board in VBOs auf die GPU und kann diese dann durch instancing mehrfach an den vorgesehenen Positionen rendern.
:
Bearbeitet durch User
Welche Funktion hat das Icon "Herz" im Part Browser? Ich kann keine Funktion beim anklicken erkennen.
Helmut S. schrieb: > Welche Funktion hat das Icon "Herz" im Part Browser? > Ich kann keine Funktion beim anklicken erkennen. Das fügt das ausgewählte Part den Favoriten (links im Fenster) hinzu, bzw. entfernt es daraus.
Lukas K. schrieb: > Helmut S. schrieb: >> Welche Funktion hat das Icon "Herz" im Part Browser? >> Ich kann keine Funktion beim anklicken erkennen. > > Das fügt das ausgewählte Part den Favoriten (links im Fenster) hinzu, > bzw. entfernt es daraus. Danke. Da hätte ich auch selber draufkommen müssen. :-)
Lukas K. schrieb: > Mampf F. schrieb: >> Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature >> ist. > > Das trifft sich gut, da bin ich gerade dran :) Laden von STEP-Modellen > mit opencascade klappt schon, an der richtigen Stelle in der 3D-Vorschau > sind sie auch schon. Fehlt nur noch ein bisschen drumherum. Der Code zum Unglaublich! Habe es direkt mal ausprobiert, stecke aber beim Laden der Step-Datei fest. Im 3D-View des Packages klicke ich auf den Browse-Button für die Step-Datei, wählt diese aus und schließe dann den Datei-Dialog. Passieren tut allerdings nichts. Der Dateiname erscheint auch nicht im Textfeld vor dem Browse-Button. Das hätte ich erwartet. Ist das der richtige Weg? Wo liegen die Step-Dateien, wenn man sie denn mal hochgeladen bekommt? Uwe
Sodele, STEP-Modelle funktionieren nun grundlegend einige Worte dazu noch: Integration in die Download/Upgrade-Infrastruktur fehlt noch, kommt aber bald. Angedacht war das dann so: Im Pool wird es dann neben packages, entities, etc. noch den Ordner "3d_models" geben, in dem dann alle STEP-Dateien an Zentraler stelle liegen, also teil des Pools werden. Da die Lizenzbedingungen einiger Hersteller es nicht erlauben, deren Modelle weiterzuverteilen, wird es noch einen Ordner geben, in den man dann selber die Modelle mit dem richtigen Dateinamen ablegen kann. Geduldet euch am besten noch ein Paar Tage, dann wird aus dem Futur im Absatz oben auch Präsens ;) Uwe S. schrieb: > Das hätte ich erwartet. > Ist das der richtige Weg? Wo liegen die Step-Dateien, wenn man sie denn > mal hochgeladen bekommt? Da hat noch eine Fehlermeldung gefehlt (ist jetzt drin), die einem sagt, dass sich die Datei nicht im Pool befindet. Damit man keine absoluten Pfade hat, werden die Dateinamen relativ zum Pool gespeichert. Wenn du deine Modelle in einen Unterordner des Pools kopiert, sollte es klappen.
Welches dev package braucht man denn dafür?
util/step_importer.cpp:2:10: fatal error: TDocStd_Document.hxx: Datei
oder Verzeichnis nicht gefunden
#include <TDocStd_Document.hxx>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
tester schrieb: > Welches dev package braucht man denn dafür? > > util/step_importer.cpp:2:10: fatal error: TDocStd_Document.hxx: Datei > oder Verzeichnis nicht gefunden > #include <TDocStd_Document.hxx> > ^~~~~~~~~~~~~~~~~~~~~~ > compilation terminated. Unter Debian versuchs mal mit liboce-ocaf-dev Uwe
Uwe S. schrieb: > Unter Debian versuchs mal mit liboce-ocaf-dev Ja, danke, das wars. Noch ein Job für Lukas, Wahrscheinlich wieder mein vermurkstes Padstack. Wenn ich im Board auf die 3D Ansicht gehe, crashed horizon. klaus@Yoga:~/horizon/horizon$ ./horizon-prj-mgr SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC col 2 create proc spawn /home/klaus/horizon/horizon/horizon-imp -b /home/klaus/horizon/proj/rpi-codec/board.json /home/klaus/horizon/proj/rpi-codec/top_block.json /home/klaus/horizon/proj/rpi-codec/vias imp rx null (horizon-imp:4658): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: [Unsupported] Opposing point on constrained edge
tester schrieb: > unhandled exception (type std::exception) in signal handler: > what: [Unsupported] Opposing point on constrained edge Oh, den kennen wir doch: Klaus R. schrieb: > [...] > terminate called after throwing an instance of 'std::runtime_error' > what(): [Unsupported] Opposing point on constrained edge > end proc 4244 > exit stat 134 Da es jetzt Logging gibt, hab ich das die exception abgefangen und ein Log-Eintrag draus gemacht: https://github.com/carrotIndustries/horizon/commit/b3bd85d831cbecd4bb0b334cd87188cf0e0aa681 Dann fehlt immerhin nur die Füllung beim Silkscreen an der Stelle, an der's hinfällt.
Angehängte Dateien:
-
make.PNG
31 KB
Hallo Lukas, "make" in mysy64 (WIN 10) funktioniert seit heute nicht mehr. Es bricht einfach nach kurzer Zeit ab. Gruß Helmut
Helmut S. schrieb: > Hallo Lukas, > > "make" in mysy64 (WIN 10) funktioniert seit heute nicht mehr. Es bricht > einfach nach kurzer Zeit ab. > > Gruß > Helmut Seit heute ist opencascade zum Laden von den STEP-Modellen eine Abhängigkeit: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#install-dependencies Zum Installieren:
1 | pacman -Sy mingw-w64-x86_64-oce |
Hi Lukas! Ich arbeite schon seit ein paar Tagen an einer Restrukturierung so dass du normal weiter entwickeln kannst und ich mich eben um ein paar andere Punkte kümmere (Liste weiter unten). Nachdem das schon langsam ein bisschen größer geworden ist, wollte ich mich einmal mit dir absprechen welche Änderungen du übernehmen würdest und welche nicht (nicht das ich hier einige Tage arbeite und du die Änderungen e nicht rein-mergen möchtest). Hier ist die Liste mit einer Erklärung zu jedem Punkt wieso ich denke das diese Änderung besser ist:
1 | 1) externer Code wurde in den Ordner "extern" verschoben (umbenennen in "3part"?) -> Trennung zwischen Projekt-Code und externen/3part-Code |
2 | 2) Projekt-Code wurde in src/* verschoben -> Übersichtlicher Platz für den Code |
3 | 3) Umstellung von Makefile auf CMake -> siehe weiter unten |
4 | 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind |
5 | 5) gresources von CMake erstellen lassen -> Vereinfachung von einem Build Schritt für CMake |
6 | 6) board/board_layers.hpp Konstanten in einem enum verwandelt -> kann mit einer Shared-Lib (cmake) nicht mehr verwendet werden (Linker Error mit CMake), Umwandlung in einem enum war ohne weiteres einfach möglich. |
Natürlich gibt es hier leider ein paar Abhängigkeiten: Wenn 3) gemacht werden soll, muss auch 5) und 6) durchgeführt werden. Auch anders herum 5) ist Abhängig von 3) und das wiederum von 6)! Wieso nun CMake: * Du kannst unabhängig vom Buildsystem arbeiten -> Projekt kann mit Makefile, Visual Studio, <Buildsystem deiner Wahl> usw. geöffnet werden. * Wenn eine neue externe Library hinzugefügt wird (so wie jetzt gerade der Fall ist), meckert schon CMake von vornherein das die Library fehlt und es wird noch gar nicht gebaut. Außerdem bekommt man eine genaue Fehlerbeschreibung wieso und was fehlt. * Nettere Ausgabe (ok, ist Ansichtssache. Aber ich finde es cool das ich den Buildvorschritt mit %e sehen kann) So... das hab ich mal in den letzten 3 bis 4 Tagen fast alles erledigt! Nachdem es aber dein Projekt ist und du das sagen darüber hast, möchte ich dir da nicht auf die Füße treten und gleich einen riesigen "pull request" los schicken :) Ich bin gerne offen meine Änderungen auf deine neusten Änderungen aufzusetzen, würde aber gerne wissen mit was du einverstanden wärst und was ich dir alles schicken darf. Dann würde ich das Schritt für Schritt auf mehrere Pull Requests aufteilen, so dass du und ich nicht zu viel zum ändern haben ;) ------------------------------------------------------------------------ Bezüglich der Änderungen vom Pool die von mir noch offen sind: Mit dem Original Namen von der CPL Lib, kann ich aber auch nicht direkt in der SnapEDA's Library suchen. Möchte ich zb. einen 100Ohm Widerstand in 1206 haben finde ich in der CPL diesen Eintrag: CPL-RES-1206-100-0.25W Gehe ich nun auf die SnapEDA's Seite und gebe diesen Begriff bei der Suche ein, bekomme ich kein Ergebnis! Oder gibt es hier eine andere "Suche" wenn ich schon diesen Begriff habe?
Cool, dass mal jemand anders den Sourcecode anfasst :) Peter B. schrieb: > 1) externer Code wurde in den Ordner "extern" verschoben (umbenennen in > "3part"?) -> Trennung zwischen Projekt-Code und externen/3part-Code Sehr schön :) > 2) Projekt-Code wurde in src/* verschoben -> Übersichtlicher Platz für > den Code Geschmackssache, ist aber wohl so üblich, also ja. > 3) Umstellung von Makefile auf CMake -> siehe weiter unten Hast mich überzeugt. Insb. kann dann opencascade eine optionale Abhängigkeit werden und man kann auf https://github.com/FreeCAD/FreeCAD/blob/master/cMake/FindOpenCasCade.cmake aufbauen. > 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben > werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind Das hatte ich schon längers vor, aber war immer zu faul dazu. Danke! Ganz früher war alles in einem Ordner drin, als ich dann Zeug in Ordner einsortiert hatte, war ich zu faul zum Includes anpassen. -I war da am einfachsten... > 5) gresources von CMake erstellen lassen -> Vereinfachung von einem > Build Schritt für CMake D.h. man gibt Cmake die liste von ressourcen? > 6) board/board_layers.hpp Konstanten in einem enum verwandelt -> kann > mit einer Shared-Lib (cmake) nicht mehr verwendet werden (Linker Error > mit CMake), Umwandlung in einem enum war ohne weiteres einfach möglich. Oh, ganz vergessen, dass es die neben scoped enums auch noch gibt, danke :) Peter B. schrieb: > Oder gibt es hier eine andere > "Suche" wenn ich schon diesen Begriff habe? Octopart, da kommen dann Widerstände von mehreren Herstellern zur Auswahl. Das schöne an den CPL-Parts ist, dass sich schon jemand anders eine Zuordnung von generischer Part-Nummer zu MPN gemacht hat. Wenn es da noch andere Schemata gibt, sind die auch gerne gesehen, Hauptsache man bekommt automatisch eine MPN raus.
Lukas K. schrieb: > Cool, dass mal jemand anders den Sourcecode anfasst :) Ja ich kenn das leider zu gut von einigen Projekten von mir. Da werkelt man ewig lange herum und es gibt zwar viele Interessenten, aber am Schluss steht ma dann doch fast ganz alleine da. Da freut man sich schon wenn mal jemand anderer mit anpackt :) > Geschmackssache, ist aber wohl so üblich, also ja. Du hast hald den Vorteil, dass du wirklich den gesamten Code auf einem Platz hast. Alles was nicht Code ist, kommt einfach wo anders hin und es gibt eine Trennung dazwischen ;) >> 3) Umstellung von Makefile auf CMake -> siehe weiter unten > Hast mich überzeugt. Insb. kann dann opencascade eine optionale > Abhängigkeit werden und man kann auf > https://github.com/FreeCAD/FreeCAD/blob/master/cMake/FindOpenCasCade.cmake > aufbauen. Guter Punkt und wird dann von mir auch gleich mit umgesetzt! >> 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben >> werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind > Das hatte ich schon längers vor, aber war immer zu faul dazu. Danke! > Ganz früher war alles in einem Ordner drin, als ich dann Zeug in Ordner > einsortiert hatte, war ich zu faul zum Includes anpassen. -I war da am > einfachsten... :) In der Zwischenzeit ist das Projekt ja schon ziemlich groß geworden, da muss schon eine Struktur her, sonst wird das nur Chaos. >> 5) gresources von CMake erstellen lassen -> Vereinfachung von einem >> Build Schritt für CMake > D.h. man gibt Cmake die liste von ressourcen? Ja genau (gibt dafür extra eine CMake Erweiterung). Es werden dann automatisch die Files überprüft ob diese existieren und danach wird das xml erstellt und dann das Cpp file. >> Oder gibt es hier eine andere >> "Suche" wenn ich schon diesen Begriff habe? > Octopart, da kommen dann Widerstände von mehreren Herstellern zur > Auswahl. > Das schöne an den CPL-Parts ist, dass sich schon jemand anders eine > Zuordnung von generischer Part-Nummer zu MPN gemacht hat. Wenn es da > noch andere Schemata gibt, sind die auch gerne gesehen, Hauptsache man > bekommt automatisch eine MPN raus. Jaaa stimmt... wenn ich jetzt meine generierten Namen verwende kommt man nicht gleich auf ein Ergebnis. Man muss erst die "-" entfernen und dann kommt auch was raus. Da muss man noch was machen :)
Hat jemand schon Symbole erstellt? Ich brauche z.B. einen OpAmp. Aber irgendwie sehe ich z.B. nicht wo ich die Pins hinzufügen kann. Gibts da einen Trick?
Michael H. schrieb: > Hat jemand schon Symbole erstellt? > Ich brauche z.B. einen OpAmp. Aber irgendwie sehe ich z.B. nicht wo ich > die Pins hinzufügen kann. Gibts da einen Trick? Bei horizon werden die Pins eines Bauteils nicht im Symbol definiert, sondern in der Unit: https://github.com/carrotIndustries/horizon/wiki/The-Pool#units Du legst dir also für dein Bauteil eine neue Unit an, trägst dort die Pins ein und legst dann eines oder mehr Symbole dazu an.
Hm. Und wie soll dann ein Bauelement mit z.B. der typischen Varianten 16 Pins als DIP und 20 Pins als SMT definiert werden?
Abdul K. schrieb: > Hm. Und wie soll dann ein Bauelement mit z.B. der typischen Varianten 16 > Pins als DIP und 20 Pins als SMT definiert werden? Da legst du einfach ein zweites Bauteil an.
Angehängte Dateien:
-
to92-freecad.png
28 KB -
to92-horizon.png
2,3 KB
Hallo, diese 3D-Modelle machen mir gerade wahnsinnig. Angehängt sind mal zwei Screenshots. Einmal das Bauteil in FreeCAD und dann das importierte Bauteil in Horizon. Jetzt frage ich mich warum da zwei Beine fehlen und der Ursprung so verschoben ist. Wie muss man denn so ein Bauteil anlegen, damit es passend auf der Platine erscheint? Uwe
Linkes Bild ist auch noch ein Bug drin. Schau dir den Mittelpin oberhalb 0,0,0 an. Da ist er irrtümlich transparent. Sieht zumindest so aus.
Uwe S. schrieb: > . Jetzt frage ich mich warum da zwei Beine fehlen und > der Ursprung so verschoben ist. Wie muss man denn so ein Bauteil > anlegen, damit es passend auf der Platine erscheint? Hast du mir mal die STEP-Datei?
Abdul K. schrieb: > Linkes Bild ist auch noch ein Bug drin. Schau dir den Mittelpin oberhalb > 0,0,0 an. Da ist er irrtümlich transparent. Sieht zumindest so aus. Nö, das ist nur der eingeblendete Koordinatenursprung mit der Z-Achse, die blau dargestellt ist und direkt auf der Oberfläche des Anschlusses liegt.
Uwe S. schrieb: > Hier ist mal step Datei. Hab ich's mir doch schon fast gedacht, dass ich noch die Platzierung von Unterobjekten berücksichtigen muss. Mit den Modellen, die ich so in der Hand hatte, ging's auch ohne... Ist in https://github.com/carrotIndustries/horizon/commit/514027b3e9bb108b38b51016c16a1b363ac9ed28 repariert.
Lukas K. schrieb: > Uwe S. schrieb: >> Hier ist mal step Datei. > > Hab ich's mir doch schon fast gedacht, dass ich noch die Platzierung von > Unterobjekten berücksichtigen muss. Mit den Modellen, die ich so in der > Hand hatte, ging's auch ohne... > > Ist in > https://github.com/carrotIndustries/horizon/commit/514027b3e9bb108b38b51016c16a1b363ac9ed28 > repariert. Perfekt, damit läuft es. Danke. Uwe
Lukas, ich muss mal sagen: die Geschwindigkeit, in der du Patches bereitstellst und einbaust, sollte jeden kommerziellen Hersteller vor Neid erblassen lassen. Meinen allergrößten Respekt dafür!
Max G. schrieb: > Lukas, ich muss mal sagen: die Geschwindigkeit, in der du Patches > bereitstellst und einbaust, sollte jeden kommerziellen Hersteller vor > Neid erblassen lassen. Das geht nur, solange man kein kommerzieller Hersteller ist und größtenteils alleine daran arbeitet :) > Meinen allergrößten Respekt dafür! Ja, von mir auch! :)
Nochmal was zum Thema Step-Dateien. Kicad hat bereits eine ordentliche Menge Step-Dateien, die ich punktuell versucht habe einzubinden. Grundsätzlich kein Problem, nur die Ausrichtung des Packages und des 3d-Modells passt oft nicht zusammen. Bei dem besagten TO-92 hatte ich den Ursprung auf den mittleren Pin gelegt. Das 3D-Modell aus Kicad legt den Ursprung aber auf einen der äußeren Pins. Wenn ich jetzt das Package passend verschiebe dann zerreißt es mir die Boards, die dieses Packages bereits verwenden. Sicher ich könnte auf das Update des Pools im Projekt verzichten, aber grundsätzlich wird man immer wieder, nicht zu einander passende 3D-Modelle und Packages haben. Könnte man bei der Zuordnung des 3D-Modells zum Package nicht eine Verschiebung und Rotation des 3D-Models angegeben, die das Modell dann zurecht rückt? Uwe
@Uwe: Ich hatte das schon angefragt, es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. https://github.com/carrotIndustries/horizon/issues/61
Michael H. schrieb: > es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. Wenn man mal davon ausgeht, dass man heutzutage STEP-Dateien oft direkt vom Hersteller bekommt, finde ich das nicht so gut. Bei selbst erzeugten ist das sicher was anderes.
Michael H. schrieb: > @Uwe: Ich hatte das schon angefragt, es kam allerdings die Antwort, man > solle es in der STEP-Datei ändern. > https://github.com/carrotIndustries/horizon/issues/61 Ok. Das halte ich aber auch für unglücklich, weil man bei der Menge an bestehenden Step-Dateien kaum noch davon profitieren kann, wenn man die alle anpassen muss. Aber letztlich muss dass natürlich Lukas entscheiden.
Jörg W. schrieb: > Michael H. schrieb: >> es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. > > Wenn man mal davon ausgeht, dass man heutzutage STEP-Dateien oft > direkt vom Hersteller bekommt, finde ich das nicht so gut. Eben bei denen, die von Herstellern kommen, liegt der Ursprung oft im nirgendwo und die Rotation passt auch überhaupt nicht. Sowas behebt man besser in einem anständigen MCAD-Programm wie FreeCAD, anstatt in horizon nach Augenmaß Nummern einzutragen. In Freecad z.B. ist es einfach möglich, das Modell so zu verschieben, dass dessen Unterseite genau bei z=0 liegt. Uwe S. schrieb: > Ok. Das halte ich aber auch für unglücklich, weil man bei der Menge an > bestehenden Step-Dateien kaum noch davon profitieren kann, wenn man die > alle anpassen muss. Bei den Modellen von SMD-Bauteilen, die ich mir so angesehen hatte, hat's gepasst, da dort der Ursprung vom Modell auch in der Mitte liegt. Eine wirkliche Konvention, wo in den Packages der Ursprung liegen soll fehlt noch. Bei Kicad ist's für alles was nicht Through hole ist der Mittelpunkt vom Bauteil und bei TH im Mittelpunkt von Pin 1, was sich auch so in den 3D-Modellen widerspiegelt. Mir persönlich gefällt das nicht so wirklich. Um die Through Hole-Modelle von KiCad verwenden zu können, ist es durchaus sinnvoll, Verschiebung/Rotation eintragen zu können, nur hat man dann wieder das Problem, dass Leute anstatt im MCAD nachzumessen und die Werte daraus zu übernehmen, einfach so lange an den Knöpfen drehen werden, bis es optisch passt.
Lukas K. schrieb: > Um die Through Hole-Modelle von KiCad verwenden zu können, ist es > durchaus sinnvoll, Verschiebung/Rotation eintragen zu können, nur hat > man dann wieder das Problem, dass Leute anstatt im MCAD nachzumessen und > die Werte daraus zu übernehmen, einfach so lange an den Knöpfen drehen > werden, bis es optisch passt. Dann habe ich mir in der Tat die Problemfälle rausgesucht. Ich kann durchaus verstehen, dass hier eine einheitlich Vorgehensweise besser wäre (z.B. den Ursprung auf Pin 1 oder den linken Pin (bei horizontaler Ausrichtung) zu legen). Ist halt blöd, wenn man einen ganzen Schwung 3D-Modelle und Packages hat, die nicht zusammen passen und beides aus Quellen kommt, die möglicherweise noch Änderungen vornehmen. Wenn ich die Kicad-Modelle anpasse, werde ich mögliche Korrekturen darin vermutlich nicht mehr übernehmen können. Folglich muss ich meine Packages in Horizon anpassen und das bedeutet Nacharbeiten in den bereits erstellten Boards. Zur Zeit noch überschaubar, kann aber ziemlich viel Arbeit bedeuten. Uwe
Und genau aus dem Grund ist es üblich eigentlich alles selber neu anzulegen bzw. nach eigenen Vorgaben externe dafür zu beauftragen. Eigentlich ein Witz, denn in DE sind ja sogar die Schaltsymbole in den Schaltplänen zu großen Teilen genormt. Nur die wenigsten halten sich dran. Vielleicht verändert sich das mal irgendwann. In den letzten 40 Jahren war dieser Zeitpunkt aber nie erreicht. Vielleicht liegt es an der Neumodigkeit von Elektronik, den vielen Individualisten in diesem Feld oder weil im Bereich Elektronik einfach noch <zu> viel Geld für Spezialgänge vorhanden ist.
> denn in DE sind ja sogar die Schaltsymbole in den Schaltplänen zu großen Teilen
genormt.
Nur finden alle Firmen außerhalb Deutschlands diese Symbole nicht
überzeugend. Deshalb werden die sich international auch nie durchsetzen.
Deshalb sollte sich Lukas an internationale Geflogenheiten orientieren.
:
Bearbeitet durch User
International würde ich das nicht nennen, eher amerikanisch. Vielleicht in Zukunft auch chinesisch. Zeichnet sich ja jetzt schon deutlichst ab. Z.B. Datenblätter in chinesisch-only.
Abdul K. schrieb: > Und genau aus dem Grund ist es üblich eigentlich alles selber neu > anzulegen bzw. nach eigenen Vorgaben externe dafür zu beauftragen. Ich habe aber dabei noch niemanden (im industriellen Umfeld) gesehen, der sich seine eigenen 3D-Modelle gezimmert hat. Klar baut sich jeder seine Bauteile selbst, aber die 3D-Modelle sind nur dann dabei, wenn man sie irgendwoher bekommen kann: bei einfachen Dingen (Standard-Hühnerfutter) schon auch gut und gern mal aus dem EDA-Tool, bei spezielleren Bauteilen halt die vom Hersteller. Helmut S. schrieb: > Nur finden alle Firmen außerhalb Deutschlands diese Symbole nicht > überzeugend. Falls du die IEC-Symbole meinst: die sind nicht einmal deutsch, sondern international. ;-) Die BRD hat sie sogar relativ spät in die eigene Norm übernommen, im Ostblock sind sie kurz nach ihrer Normierung durch die IEC offiziell übernommen worden (und auch tatsächlich benutzt, sowohl von den Fachzeitschriften als auch in der Industrie). Aber da, wo man Entfernungen immer noch mit Daumen und Füßen misst, wird auch das wohl noch ein bisschen dauern … Ist aber hier egal, hier geht's ja um die Anpassungen, die Horizon gewillt ist, an einem 3D-Modell vorzunehmen. Lukas K. schrieb: > nur hat man dann wieder das Problem, dass Leute anstatt im MCAD > nachzumessen und die Werte daraus zu übernehmen, einfach so lange an den > Knöpfen drehen werden, bis es optisch passt. Sagen wir mal so: solange das einer für sich privat macht und nur „ungefähr“ ein Gefühl bekommen will, wie's am Ende aussieht, finde ich das auch OK. Ob das Modell da noch einen Zehntelmillimeter daneben sitzt, interessiert dafür kaum. In den offiziellen Pool würde ich es natürlich so nicht übernehmen. Nicht jeder will sich unbedingt auch noch privat mit einem 3D-MCAD befassen müssen (wenngleich das natürlich durch des Ingenieurs neues Spielzeug, den 3D-Drucker allmählich ohnehin mehr werden, die es tun :).
3D ist sicherlich ein neuer Trend. Liegt ja auch daran, daß ein dortiges "Symbol" doch deutlich aufwändiger zu erstellen ist als ein planes Schaltplansymbol.
Abdul K. schrieb: > Eigentlich ein Witz, denn in DE sind ja sogar die Schaltsymbole in den > Schaltplänen zu großen Teilen genormt. Nur die wenigsten halten sich > dran. Das Problem an den Normen ist, dass sie in den 70ern stehen geblieben sind bzw. darauf aufbauen, das elektronische Schaltungen wie Schaltschränke aus genormten und austauschbaren Bauteilen bestehen. Dass heutzutage fast jede Schaltung in irgendeine Art proprietäre Bauteile wie Mikrocontroller, FPGAs oder Schaltregler beinhaltet ist in den Normen nicht wirklich reflektiert. Daher muss besser früher als später ein verbindlicher Satz an Regeln her, um Diskussionen wie diese hier https://github.com/carrotIndustries/horizon-pool/pull/11 abzukürzen. Die KiCad library convention ist da schonmal ein guter Startpunkt. Abdul K. schrieb: > 3D ist sicherlich ein neuer Trend. Kommt drauf an. Für den Hobbyisten vielleicht, da kann das Projekt schon fertig sein, wenn das Board funktioniert. In der Industrie hingegen ist es ja üblich, Boards in Gehäuse einzubauen. Mit einem Gehäuse, das irgendwie lose mit vielen Kabeln um das Board zusammengeschustert ist gewinnt man da keinen Blumentopf mehr, man will das Board mit den darauf befindlichen Bauteilen aus dem ECAD ins MCAD exportieren können, damit das Gehäuse genau zum Board passt. In Zeiten von 3D-Druckern auch für Hobbyisten umsetzbar. Jörg W. schrieb: > Nicht jeder will sich unbedingt auch noch privat mit einem 3D-MCAD > befassen müssen Ich werde kein Package ablehnen, nur weil es kein 3D-Modell enthält. Besser gibt keines als ein nach Augenmaß positioniertes.
Hinsichtlich der 3D Diskussion: Ich von meiener Seite habe mir gesagt, das es schön gewesen wäre. Allerdings reicht es meistens schon aus, sich die STEPs von KiCad rüberzuziehen. Wenn da welche sind, dann gut, wenn nicht, halt kein 3D Model. (Sieht für meinen Zweck halt schön aus, allerdings für mich nicht überlebenswichtig...) Ich bin im Moment dabei in freien minuten Bauteile zu erstellen, sodass man eine Grundlage bekommt, schnell loslegen zu können. Ich denke, das Program hat Potential.
Gute Nachrichten für alle Windows-Nutzer hier: Es gibt jetzt automatische Builds mit appveyor: https://ci.appveyor.com/project/carrotIndustries/horizon/history Bei "Artifacts" ist dann die Zip-Datei.
Hab den Thread vor einigen Wochen mal durchgelesen. Ich freue mich auf die erste Beta-Version. :) Ein paar Fragen zu den Funktionen hätte ich da, ob es diese gibt oder geplant sind (und falls nicht, betrachtet dies bitte als Anregung/freundliche Anfrage dies zu integrieren): Bauteilerstellung: -Ist es möglich, Bauteile aus Datenbanken oder Tabellen (Excel) heraus zu erstellen? Ich hab damit unlängst massenhaft Bauteile mit einem Script erstellt, die zwar dasselbe Schaltplansymbol und denselben Footprint gemeinsam hatten, in Details wie Bauteilwert, Herstellerbezeichnung, usw. aber unterschiedlich waren. Einen Skriptinterpreter zu integrieren wäre auch super, der Aufwand würde aber vermutlich völlig ausarten... -Wie sieht es mit der Pin-Pad-Zuordnung aus..kann man da einem Pin im Schaltplan mehrere Pads im Layout zuordnen ohne das es Ärger geben könnte? Bei SMD-Transostoren, Motortreibern und generell Leistungs-ICs wäre das oft sehr nützlich. (In Altium ist dieser Punkt übrigens eine Katastrophe, es gibt da zwar Workarounds, meines Erachtens aber keine wirkliche Lösung.) -Wie siehts mit BOM-Erstellung aus: Kann Horizon Bauteile wie folgt darstellen: Schaltplan ja, Footprint ja, BOM nein (z.B. Layoutsicherung) Schaltplan nein, Footprint nein, BOM ja (Befestigungsmaterial) Schaltplan nein, Footprint ja, BOM bedingt (Drahtbrücken, und in der BOM taucht der Draht entweder gar nicht auf, oder wieviel Draht insgesamt benötigt wird) Schaltplanerstellung: -Benamsung von Netzen: Kann Horizon die Folge LCD-0, LCD-1, LCD-2, ... automatisch fortsetzen? -Schaltplanseiten automatisch kopieren (ich erstelle einmal eine bestimmte Seite, definiere die Anzahl, und Horizon verwaltet die Kopien), und das gleiche Spiel beim Layout, ich route eine solche Seite und Horizon übernimmt das Routing für alle anderen Seiten? Ich spiele auf die Multi-Channel-Funktion in Altium an, die ich gerne nutze, allerdings fehlen da meines Erachtens ein paar Dinge: z.B. daß bestimmte Bauteilparameter zu jeder Kopie variieren können. Eine Frage hätte ich noch an den Chef der Karottenindustrie: Mit welchen EDA-Programmen hast du denn bisher so Erfahrung gesammelt? Das soll es erstmal vorläufig sein...mir fällt nach der ersten Beta-Version bestimmt noch mehr ein. ;) Ich kenne KiCad nicht aus eigener Benutzung und will es nicht kritisieren, aber ich finde es gar nicht so verkehrt wenn es da künftig noch freie Alternative gibt. Und es tut den großen Firmen wie Mentor und Altium auch gut, etwas Konkurrenz auch aus dem OSS-Sektor zu bekommen (keine Ahnung ob das zum Anspruch von Horizon zählt, aber ich unterstütze das gerne).
Wühlhase schrieb: > Einen > Skriptinterpreter zu integrieren wäre auch super, der Aufwand würde aber > vermutlich völlig ausarten... Warte ab - übermorgen zur selben Zeit hat Lukas sicherlich Lua eingebaut xD
Wühlhase schrieb: > Hab den Thread vor einigen Wochen mal durchgelesen. Ich freue mich auf > die erste Beta-Version. :) Damit es eine Beta gibt, müsste es ja auch mal ein Release geben. Keine Ahnung wann da die rechte Zeit für ist. Obwohl man derzeit schon halbwegs bequem Schaltplan / Board entwickeln und Bauteile verwalten kann, fehlen noch einige wichtige Funktionen wie z.B. BOM-Export. Ich müsste mich wohl mal hinsetzen und definieren, was alles es alles für Version 0.1 braucht. > Ein paar Fragen zu den Funktionen hätte ich da, ob es diese gibt oder > geplant sind (und falls nicht, betrachtet dies bitte als > Anregung/freundliche Anfrage dies zu integrieren): > > Bauteilerstellung: > -Ist es möglich, Bauteile aus Datenbanken oder Tabellen (Excel) heraus > zu erstellen? Ich hab damit unlängst massenhaft Bauteile mit einem > Script erstellt, die zwar dasselbe Schaltplansymbol und denselben > Footprint gemeinsam hatten, in Details wie Bauteilwert, > Herstellerbezeichnung, usw. aber unterschiedlich waren. Dazu können Parts voneinander erben, man legt einmal sein Basis-Bauteil an und kann dann in einer Skriptsprache eigener Wahl die Parts aus welcher Quelle auch immer zu erzeugen. Die Parts sind wie der Rest auch json. z.B. https://github.com/carrotIndustries/horizon-pool/pull/6/commits/8b69df90e621348b8fa3ff98b1a379c964a08088 > -Wie sieht es mit der Pin-Pad-Zuordnung aus..kann man da einem Pin im > Schaltplan mehrere Pads im Layout zuordnen ohne das es Ärger geben > könnte? Ja! Einfach im Part-Editor bei einen Pin mehrere Pads auswählen und auf "Map" klicken. > -Wie siehts mit BOM-Erstellung aus: Kann Horizon Bauteile wie folgt > darstellen: > Schaltplan ja, Footprint ja, BOM nein (z.B. Layoutsicherung) Nein, aber einfach implementierbar > Schaltplan nein, Footprint nein, BOM ja (Befestigungsmaterial) Nein, auch einfach machbar > Schaltplan nein, Footprint ja, BOM bedingt (Drahtbrücken, und in der BOM > taucht der Draht entweder gar nicht auf, oder wieviel Draht insgesamt > benötigt wird) Nein, auch nicht einfach machbar, da alles was es auf dem Board gibt aus der Netzliste kommen muss. Zur BOM-Erstellung gibt es derzeit genau nichts. War mir persönlich noch nicht wichtig genug und du bist auch der Erste der danach fragt. Ich bin mir noch unsicher wie die genau geraten sein soll. Einen Dialog mit einer Vielzahl von Optionen, wie sie so manche kommerzielle Software bietet ist mir zu viel Aufwand: - XSLT wie KiCad: horizon gibt XML aus, XSLT macht CSV, etc draus. Vorteil: Kann gut integriert werden. Nachteil: Es gibt schönere Dinge als XSLT - JSON: Der Anwender schreibt in Skript in seiner Lieblingssprache, das macht dann daraus das gewünschte Format. Funktioniert allerdings nur auf Unixen wirklich sinnvoll. Andere/Bessere Vorschläge? > Schaltplanerstellung: > -Benamsung von Netzen: Kann Horizon die Folge LCD-0, LCD-1, LCD-2, ... > automatisch fortsetzen? Nein, es gibt aber Busse. Bis jetzt sind diese mehr auf serielle Busse wie SPI oder I²C ausgelegt. > -Schaltplanseiten automatisch kopieren (ich erstelle einmal eine > bestimmte Seite, definiere die Anzahl, und Horizon verwaltet die > Kopien), und das gleiche Spiel beim Layout, ich route eine solche Seite > und Horizon übernimmt das Routing für alle anderen Seiten? > Ich spiele auf die Multi-Channel-Funktion in Altium an, die ich gerne > nutze, allerdings fehlen da meines Erachtens ein paar Dinge: z.B. daß > bestimmte Bauteilparameter zu jeder Kopie variieren können. Das hatte ich vor mit Hierarchie zu erschlagen, ist aber noch in mehr oder minder ferner Zukunft. > Eine Frage hätte ich noch an den Chef der Karottenindustrie: Mit welchen > EDA-Programmen hast du denn bisher so Erfahrung gesammelt? EAGLE, KiCad, LTSpice und ein bisschen Mentor Graphics Expedition im professionellen Umfeld. Leider hatte ich noch nie wirklich die Gelegenheit sinnvoll mit Altium zu arbeiten, habe ich doch vergleichsweise viel gutes davon gehört. Einige Aspekte von horizon, wie z.B. die Design-Regeln sind von Altium inspiriert. Mampf F. schrieb: > Warte ab - übermorgen zur selben Zeit hat Lukas sicherlich Lua eingebaut > xD Ich hatte da auch mal drüber nachgedacht, war mir aber den Aufwand nicht wirklich wert, müsste man doch eine halbwegs stabile API bereitstellen.
Danke...das klingt doch schon mal gar nicht so schlecht. :) Vor allem wie du das Pinmapping beschreibst klingt in meinen Ohren sehr gut. Ich hab eben nochmal die 3D-Diskussion kurz überflogen-sehr schön, daß das in Horizon mit drin ist. Ohne 3D würde ich auch nicht mehr arbeiten wollen. Zur Positionierung: In Altium gibt es die Möglichkeit, eine ebene Fläche eines Step-Modells als "Boardberührfläche" zu definieren. Dann wird das Bauteil automatisch so ausgerichtet, daß die Fläche mit der Platinenoberfläche in einer Ebene und orthogonal zur Z-Achse liegt. Zum Ausrichten in der XY-Ebene kann man Snappoints am 3D-Modell hinzufügen, die dann in der 2D-Bearbeitung auch sichtbar sind. Einen Snappoint kann man dann z.B. in der Mitte eines Pins anlegen, und dann in der 2D-Ansicht in das entsprechende Lötauge legen. Vielleicht hilft das bei der Orientierung weiter. Dann hab ich noch ein paar Dinge, die Altium an dieser Stelle leider sehr halbherzig umgesetzt hat und die mich manchmal schon etwas ärgern: -Die 'Face-to-PCB-Funktion' kann nur mit planen Flächen, aber nicht mit runden Flächen. Einen aufrechten Zylinder ausrichten ist kein Problem, aber einen liegenden Zylinder ausrichten (z.B. Melf-Bauteile) geht damit nicht. -Altium findet Snappoints nur an Ecken oder Kanten. Rotationsachsen von rotationsymetrischen erkennt Altium leider nicht (was beim Ausrichten an Pins oft ärgerlich ist). Das mal so als Anregung... Ich hab bisher eigentlich nur mit Altium gearbeitet (wie vielleicht schon aufgefallen ist ;)), ich hab mich vor etlichen Jahren (so 2006 herum) mal zwei Stunden mit Eagle befaßt (das zähle ich nicht als Erfahrung) und danach nur etwas mit Sprint Layout herumgespielt, weil mir Eagle allzusehr mißfallen hat. Von daher ist mein Erfahrungshorizont etwas eingeschränkter als deiner (Expedition würd ich aber gerne mal ausprobieren), allerdings kenne ich Altium dafür recht gut und ich arbeite auch sehr gerne damit. Wenn du wissen wilst wie manches da gelöst ist, vielleicht als Inspiration, kann ich dir gerne was beisteuern. :)
Wühlhase schrieb: > -Die 'Face-to-PCB-Funktion' kann nur mit planen Flächen, aber nicht mit > runden Flächen. Einen aufrechten Zylinder ausrichten ist kein Problem, > aber einen liegenden Zylinder ausrichten (z.B. Melf-Bauteile) geht damit > nicht. > -Altium findet Snappoints nur an Ecken oder Kanten. Rotationsachsen von > rotationsymetrischen erkennt Altium leider nicht (was beim Ausrichten an > Pins oft ärgerlich ist). Genau deshalb meine Empfehlung, die Modelle davor im MCAD richtig auszurichten, denn selbst mit FreeCAD bekommt man das hin. Aktuell gibt es keine sinnvolle Möglichkeit mit den Modellen in der 3D-Vorschau zu interagieren, die STEP-Datei wird eingelesen, Trianguliert und auf die resultierenden Dreiecke auf die GPU geladen, das war's schon. Schön wäre es schon, die Modelle in horizon ausrichten zu können, doch steht das in keiner sinnvollen Relation zum dafür notwendigen Aufwand, damit es auch zufriedenstellend funktioniert.
Lukas K. schrieb: > Schön wäre es schon, die Modelle in horizon ausrichten zu können, doch > steht das in keiner sinnvollen Relation zum dafür notwendigen Aufwand, > damit es auch zufriedenstellend funktioniert. Ein Kompromiss wäre das so zu machen wie in KiCad ... Da kann man mit 6 Textboxen die Rotation und Translation einstellen. Für mich war das immer gut genug. Vlt gibt es ja irgendwann mal die Muse, das dann zu verbessern, aber ich würde sagen, besser als nichts :)
Mindestens die XY-Rotation/Position und die Höhe in der Z-Achse einzustellen wäre schon schön. Anders sind viele 3D-Modelle von 3Dcontentcentral leider nicht zu verwenden und jede Ausrichtung in Horizon mit einem externen Programm macht dies sicher auch nicht gerade zum Vergnügen...
Wühlhase schrieb: > Mindestens die XY-Rotation/Position und die Höhe in der Z-Achse > einzustellen wäre schon schön. Ah und die Skalierung noch ... Also 9 Parameter ... Rotation, Translation, Skalierung :) Oft sind die Models in inch pro Einheit oder mm pro Einheit ... Evtl würde da schon eine Checkbox reichen dann zum umskalieren.
Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein entsprechendes Modell, das Skalierung bedarf, präsentiert.
Lukas K. schrieb: > Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für > 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein > entsprechendes Modell, das Skalierung bedarf, präsentiert. Gerne, davon hab ich dutzende ... Alle Models, die von mir mit OpenScad entworfen wurden haben die falsche Skalierung - oder die richtige, aber KiCad nimmt inch statt mm an. Ich schicke dir morgen etwas.
Ich versuche zur Zeit Symbole hierfür zu erstellen. Was mich hier irgendwie stört, ist das iterative beim Package erstellen. Siehe: https://github.com/carrotIndustries/horizon-pool/pull/20 Könnte man nicht die Regeln genauer definieren, bzw. einen automatischen Test einbauen? Ich glaube, wenn man so oft nachbessern musst, hast Du Lukas keinen Spaß daran die anderen auf Ihre Fehler hinzuweisen, andernseits wirkt es nicht sehr motivierend, wenn man 3 Wochen braucht bis ein Package in der Repo ist... Stell dir mal vor, da kommen 5 heinzel wie ich, die sich genauso dumm anstellen... Da kommt man garnicht mehr nach.
Hallo Mampf. Mampf F. schrieb: > Oft sind die Models in inch pro Einheit oder mm pro Einheit ... Evtl > würde da schon eine Checkbox reichen dann zum umskalieren. Eine Voreinstellung für "inch oder mm" Anpassung wäre eine feine Optimierung. Trozdem ist eine individuelle Einstellung nötig, weil auch Modelle kursieren, wo sich jemand beim Umrechenen mm vs. inch und retour vertan hat. Sei es das er Multiplikation mit Division verwechselt hat, oder aber einen falschen Faktor verwendet hat, oder als Längeneinheit preußische Lachter verwendet hat. Mit freundlichem Gruß: Bernd wiebus alias dl1eic http://www.l02.de
Lukas K. schrieb: > Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für > 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein > entsprechendes Modell, das Skalierung bedarf, präsentiert. Hui, schön wie schnell das geht... :) Wie gesagt, ich freue mich auf das erste Beta-Release.
Michael H. schrieb: > Stell dir mal vor, da kommen 5 heinzel wie ich, die sich genauso dumm > anstellen... Da kommt man garnicht mehr nach. Andere haben es ja hinbekommen, auf Anhieb nahezu Perfekte Symbole, Packages etc. abzuliefern, siehe https://github.com/carrotIndustries/horizon-pool/pull/7 Ja, genauer spezifizierte Regeln braucht's noch, wobei ich auch erwarte, dass sich Leute an bereits vorhandenem orientieren. Wenn ein Vierfach Und-Gatter im Pool "Quad AND Gate" heißt, dann ist es doch naheliegend einen Einzel-Opamp "Single Operational Amplifier" oder "Single Opamp" zu nennen, oder? Selbes für die Namen/Prefixe von Gates, etc. Einfach gucken wie es nebendran gemacht ist und nachmachen.
Lukas K. schrieb: > Wenn ein Vierfach Und-Gatter im Pool "Quad AND Gate" heißt, dann ist es > doch naheliegend einen Einzel-Opamp "Single Operational Amplifier" oder > "Single Opamp" zu nennen, oder? Sollte man das "Single" vielleicht doch weglassen? Einen einzelnen Transistor nennt man ja auch nicht "Single Transistor", obwohl es durchaus auch dort "Dual Transistor" gibt.
1 und 4 davor wäre vielleicht schön kompakt.
Selbst dann würde ich die 1 weglassen, sonst müsstest du dann auch "1 Resistor", "1 Capacitor" etc. schreiben (es gibt ja schließlich auch Widerstandsarrays). Ist natürlich Lukas' Sache, welche Richtlinien er herausgibt, und wichtiger noch als die genauen Richtlinien ist, dass sie konsequent befolgt werden.
Und da wären wir beim Thema, es gibt tausend Möglichkeiten, und tausend Geschmacksrichtungen =) Desshalb sagte ich ja, finde ich ein gemeinsames Repository immer schwer. Was hier gut wäre, ist eine Checklist zum Abhaken, am besten wenn das Programm es durchcheckt, für die ganz doofen unter uns. Nur damit bekommt man imho einen Standard rein, und bekommt die Geschmacksvarianzen in Griff. Eine Sache, die ich zum Beispiel sinnvoll finde, ist das Power Gate "Z" zu nennen, da es immer das letzte sein sollte. Und so weiß man, das jedes Power immer Z heißt. Aber das ist deine Entscheidung. Wie gesagt, klare regeln, insbesondere super-verständlicht, und mit vielen Bildern würden hier extrem weiterhelfen.
Hallo Possetitjel. Possetitjel schrieb: > Kompatible DATEIFORMATE setze ich eigentlich voraus; notfalls > tut's ein funktionierender Export/Import. > > Aber genau DAS ist ja offensichtlich nicht gegeben. Da machen sich aber Leute schon einen Kopf drum: https://lists.launchpad.net/kicad-developers/msg33357.html Mit freundlichem Gruß: Bernd wiebus alias dl1eic http://www.l02.de
Angehängte Dateien:
-
remote-update.PNG
52 KB
Benötige ich einne Github-login um einen remote "upgrade-pool" meines lokalen "pools" zu machen? Siehe screenshot.
:
Bearbeitet durch User
Hallo, wie bereits vor einiger Zeit erwähnt stellt Lukas "horizon" am Samstag auf der FOSDEM in Brüssel vor. https://fosdem.org/2018/schedule/track/cad_and_open_hardware/ Gruß Helmut
Bug-Report Die Programme in der aktuellen Version auf appveyor.com "horizon-2018-02-01-0021.zip" funktionieren nicht in WIN10. Wenn man die Programme startet, dann passiert einfach nichts. Die vorletzte Version (31.1.2018?) ging noch. Wenn ich die source mit mysys2 selber kompiliere funktionien die Programme.
:
Bearbeitet durch User
Helmut S. schrieb: > Benötige ich einen Github-login um einen remote "upgrade-pool" meines > lokalen "pools" zu machen? > Siehe screenshot. Es funktioniert auch (wieder) ohne login. Entweder hatte ich etwas falsch gemacht oder jemand hat es gerichtet. Danke.
Hallo, hier mal der Entwicklungsstand und Ausblick auf zukünftige Funktionen von horizon basierend auf den Slides die Lukas auf der FOSDEM gezeigt hat. https://fosdem.org/2018/schedule/event/cad_horizon/attachments/slides/2286/export/events/attachments/cad_horizon/slides/2286/presi.pdf What's working Workflow from schematic to board Interactive router Pool management with GitHub integration Gerber export Planes with thermals Differential Pairs Buses 3D preview, STEP export Airwires Undo/Redo Copy/Paste DRC (Design rules and checks) Coming soon Pool Convention (WIP) UI polish Assembly drawings Title blocks BOM export ERC Hierachical designs Better PDF export Performance Link auf das Projekt in Github https://github.com/carrotIndustries/horizon Helmut
>Das Problem an den Normen ist, dass sie in den 70ern stehen geblieben >sind bzw. darauf aufbauen, das elektronische Schaltungen wie >Schaltschränke aus genormten und austauschbaren Bauteilen bestehen. Vor kurzem kam mal ein Radiobeitrag zur DIN-Normungs Komission. Tatsächlich ist das eine private Instituion und theoretisch kann jeder Privatmann einen Vorschlag zur Normung von Irgendwas einwerfen. Die meisten größeren Elektronikfirmen haben in ihren PCB-Abteilungen Leute, die nichts anders machen als Bauteile anlegen. Ich halte das für eine völlige Blindleistung. Das Ideal wäre, man bekommt die Designdaten fertig vom Hersteller inclusive der 3D-Daten und keiner muss in irgendwelchen CAD-Programmen Bauteile neu anlegen. Ginge alles, wenn es eine einheitlich Norm für das Datenformat gäbe.
Hallo Chris. chris schrieb: > Ich halte das für eine völlige Blindleistung. Das Ideal wäre, man > bekommt die Designdaten fertig vom Hersteller inclusive der 3D-Daten und > keiner muss in irgendwelchen CAD-Programmen Bauteile neu anlegen. Das würde so auch nur in 80% aller Fälle funktionieren. Weil viele eben halt eine eigene Interpretation vom idealen Footprint haben. In einer Firma, wo ich einmal gearbeitet habe, wurden z.B. die Bohrungen aller THT Bauteile gegenüber der Originalbibliothek des Layoutprogrammes vergrößert. In einer anderen Firma wurden für bestimmte Anschlüsse extragrosse Pads verwendet.... Aber eine solche Bibliothek könnte zur Konstruktion von angepassten Varianten verwendet werden. Mal abgesehen davon, das Tom Hausherr vorschlägt, für unterschiedlich dichte Layouts unterschiedliche Footprints für das gleiche Bauteil zu verwenden. Möglichst grob für robustes Design, wenn der Platz langt, aber feiner werdent, wenn der zur Verfügung stehende Platz kleiner wird. http://www.innofour.com/3783/news/literature/pcb-design-perfection-starts-in-the-cad-library/pcb-design-perfection-starts-in-the-cad-library-part-1 Teil 1. Teil 2 und folgende gibt es hier: https://blogs.mentor.com/tom-hausherr/blog/2010/09/22/pcb-design-perfection-starts-in-the-cad-library-part-2/ > Ginge > alles, wenn es eine einheitlich Norm für das Datenformat gäbe. Was hälst Du von Snapeda oder dem Digikey Ansatz? https://www.snapeda.com/ https://www.digikey.de/de/news/press-releases/2017/aug/digi-key-adds-kicad-pcb-model-download Eine einheitliche Norm müsste offen sein, und gut verbreitet. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
:
Bearbeitet durch User
So, heute bin ich mal bleeding-edge. Ich wollte horizon auf xubuntu
18.04 beta 1 compilieren. Es kommt die Fehlermedlung "GLM_GTX_transform
is an experimental extension". Gut ein, #define GLM_ENABLE_EXPERIMENTAL
fixed das Problem, wollte das nur mal erwähnen.
In file included from /usr/include/glm/gtx/rotate_vector.hpp:18:0,
from src/canvas3d/canvas3d.cpp:14:
/usr/include/glm/gtx/transform.hpp:23:3: error: #error "GLM:
GLM_GTX_transform is an experimental extension and may change in the
future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you
really want to use it."
# error "GLM: GLM_GTX_transform is an experimental extension and may
change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before
including it, if you really want to use it."
^~~~~
In file included from src/canvas3d/canvas3d.cpp:14:0:
/usr/include/glm/gtx/rotate_vector.hpp:21:3: error: #error "GLM:
GLM_GTX_rotate_vector is an experimental extension and may change in the
future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you
really want to use it."
# error "GLM: GLM_GTX_rotate_vector is an experimental extension and
may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before
including it, if you really want to use it."
^~~~~
Für LINUX: Unter folgendem Link findet ihr ein Flatpak manifest um Horizon als Flatpak Paket zu installieren. Im Moment wird im Manifest auf mein Repository gezeigt, da der Pull request noch offen ist. Um das Flatpak manifest auszuführen, müsst ihr vorher flatpak und flatpak-builder installieren. Sobald ihr diese installiert habt, müsst ihr aus meinem Repo (https://github.com/Murmele/horizon/tree/flatpak) die Datei "net.carrotIndustries.horizon.json" aus dem Pfad ressources/linux/Flatpak herunterladen. Das Paket könnt ihr dann mit den folgenden 3 Befehlen auf eurem Rechner installieren. flatpak-builder --repo=meinRepo --force-clean Horizon net.carrotIndustries.horizon.json flatpak remote-add meinRepo meinRepo --no-gpg-verify flatpak install meinRepo net.carrotIndustries.horizon "meinRepo" ist dabei ein beliebig gewählter Name für ein Repository Ich hoffe ihr könnt es damit einfach installieren :)
Murmele schrieb: > Sobald ihr diese installiert habt, müsst ihr aus meinem Repo > (https://github.com/Murmele/horizon/tree/flatpak) die Datei > "net.carrotIndustries.horizon.json" aus dem Pfad > ressources/linux/Flatpak herunterladen Sorry das ist falsch, ladet den Ganzen Ordner Flatpak runter, da einige Module übersichtshalber in eigene Dateien ausgelagert wurden, welche im Ordner Flatpak/modules zu finden sind
Hier findet ihr das erstellte Flatpak Paket, damit ihr es nicht lange kompilieren müsst: https://www.dropbox.com/s/r4vpml656xio931/HorizonFlatpak.zip?dl=0 Entpackt die Datei und betretet den Ordner. Wenn ihr diese beiden Befehle ausführt, dann wird das Paket installiert. flatpak remote-add meinRepo2 meinRepo2 --no-gpg-verify flatpak install meinRepo2 net.carrotIndustries.horizon Zum deinstallieren: flatpak uninstall net.carrotIndustries.horizon flatpak remote-delete meinRepo2
Angehängte Dateien:
Hallo Lukas, Ich habe mir gerade die neueste Windows-Version von horizon heruntergeladen. horizon-2018-04-02-1257.zip Der Pool-mamager horizon-pool-mgr.exe läuft nicht mehr wegen fehlender DLL libbrotildec.dll. Kannst du das beheben? Gruß Helmut
Helmut S. schrieb: > Der Pool-mamager horizon-pool-mgr.exe läuft nicht mehr wegen fehlender > DLL libbrotildec.dll. Bin zwar nicht Lukas, aber brotli ist glaub ich eine Bibliothek mit Kompressionsalgorithmen von Google. Vlt ein Anhaltspunkt, wie du das nachinstallieren könntest.
:
Bearbeitet durch User
Helmut S. schrieb: > Kannst du das beheben? Ist im aktuellen Build behoben, libcurl hatte brotli als neue Abhängigkeit bekommen.
ich würde auch mal gerne versuchen die Software zu übersetzen. Allerdings würd ich mich da lieber auf das CMake Build System stürzen. Daher die Frage wie bekomme ich denn diesen Pull Request https://github.com/carrotIndustries/horizon/pull/111 auf meinen Rechner ? Die Frage ist auch ob Lukas K. auch auf CMake umschwenkt ?
Da muss ich W.S. voll zustimmen, die Basics müssen laufen, dann kommen die Spielsachen dran! Und ich sehne gerade nur Spielkram, dabei hatte ich mich so auf das Program gefreut. Ich muss noch ergänzen das die meisten User unfähig sind den Code zu übersetzen. Ich selber kann das auch nur in einer VM machen, weil nur da alle die benötigten Tools drauf sind. Da wäre es recht hilfreich wenn es gelegentlich eine Installation geben würde. VG, Klaus
Super, wenn du eine Installation hast, dann stell die doch mal zur Verfügung. Da würden sich bestimmt viele freuen. Ein Debian-Paket gibt es übrigens seit kurzem in Debian sid.
Windows! Und das ist jetzt auch schon älter. Aber eignetlich ist es doch nicht Sinn und Zweck der User es bereit zustellen. Das Programm will ja weiter kommen und da ist es immer gut Testversion raus zugeben. Es ist zwar nicht SOOOO kompliziert aber es war auch schon für mich eine nervige Sache alles auf den Rechner zubekommen. Es macht halt keinen Spass zig Pakete zuladen nur um entlich mal den Compiler anwerfen zukönnen. Ich stehe immer auf ein Repro laden und Compiler starten, alles andere ist nur nervig. Besser ist nur einen Installer zu laden und zur Sicherheit zugriff auf den Code zu haben, ändern kann ich da sowieso nichts. Na super W.S. hatte auf der 1. Seite unten seinen Kommentar abgegeben und ich wurde mal wieder nicht ans richtige Ende geleitet. Aber sein Kommentar stimmt auch noch Heute!
Hallo Klaus. Klaus schrieb: > Da muss ich W.S. voll zustimmen, die Basics müssen laufen, dann kommen > die Spielsachen dran! Gerade W.S. ist dabei aber ein Problem. Wenn irgendein Tool nur die grundlegenden Funktionen bereitstellt, bemängelt er mangelnde Userfreundlichkeit. ;O) > Und ich sehne gerade nur Spielkram, dabei hatte ich mich so auf das > Program gefreut. Das nächste Problem: Für den einen ist dieses wichtig und jenes Spielkram. Und für den Nächsten, der vorbeikommt, ist es genau umgekehrt. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Klaus schrieb: > Aber sein Kommentar stimmt auch noch Heute! Ich will jetzt hier keine Trolle füttern, aber auch keine falschen Tatsachen im Raum stehen lassen: Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" Seit fast 3 Monaten fällt zu jedem commit automatisch ein zip raus, das man sich nur runterladen und auf eine der exe-Dateien mit icon doppelklicken muss. Sub-Sub schrieb: > Die Frage ist auch ob Lukas K. auch auf CMake umschwenkt ? Das mit cmake ist bis auf weiteres auf leider auf Eis: https://github.com/carrotIndustries/horizon/pull/111#issuecomment-375812240
Lukas K. schrieb: > Das mit cmake ist bis auf weiteres auf leider auf Eis: > https://github.com/carrotIndustries/horizon/pull/111#issuecomment-375812240 Das kann ich nicht verstehen. Tatsächlich würde ich nur dann versuchen die SW zu bazuen wenn es auf CMake bassiert.
Das mit "Artifacts" und der Zip-Datei hatte ich übersehen. Mein letztes eigenes Build ist jetzt auch gut 3 Monate alt, werde heute gleich mal die neueste Version testen. Den Download haben die aber gut verseckt, ich wollte schon hier mich beschwerden.
Sub-Sub schrieb: > Tatsächlich würde ich nur dann versuchen die SW zu bazuen wenn es auf > CMake bassiert. Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da drauf sind ohne cmake gebaut.
Bernd K. schrieb: > Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da > drauf sind ohne cmake gebaut. Tatsächlich ? ich hab einen windows Rechner und da bau ich sonst gar nix selber. aber bei dem Horizon würde mich das schon interessieren
Sub-Sub schrieb: > Bernd K. schrieb: >> Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da >> drauf sind ohne cmake gebaut. > > Tatsächlich ? ich hab einen windows Rechner und da bau ich sonst gar nix > selber. aber bei dem Horizon würde mich das schon interessieren Mit der Anleitung von der Webseite kann sogar jeder "Nicht-Softwerker" erfolgreich kompilieren. Was will man mehr.
Was will man mehr: Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür.
Zweig schrieb: > Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür. CLion kann nicht mit Projekten zurechtkommen die ihr eigenes Buildsystem mitbringen? Das mag ich kaum glauben, ehrlich jetzt. Immerhin kostet das Ding Geld und soll angeblich ziemlich gut sein. Ein beliebiges existierendes Build-System benutzen zu können halte ich im Jahr 2018 für Stand der Technik bei einer C oder C++ IDE.
tester schrieb: > So, heute bin ich mal bleeding-edge. Ich wollte horizon auf xubuntu > 18.04 beta 1 compilieren. Es kommt die Fehlermedlung "GLM_GTX_transform > is an experimental extension". Gut ein, #define GLM_ENABLE_EXPERIMENTAL > fixed das Problem, wollte das nur mal erwähnen. Bin ich eigentlich der einzige, der dieses Problem hat? Ich wollte gerade eben (mal wieder) einen aktuellen build machen und habe dazu meine Änderung gelöscht (git stash), da canvas3d.cpp aktualisiert werden sollte. Anscheinend ist die "Unverträglichkeit" mit Ubuntu 18.04 beta immer noch drin. Ich habe jetzt im Makefile bei den DEFINES ein "-DGLM_ENABLE_EXPERIMENTAL" ergänzt.
Habe ein ähnlichs Problem, allerdings mit Debian. Wird es da langsam mal fertige executables geben? Dann sonst müsste Ich dem beipflichten: Klaus schrieb: > Ich muss noch ergänzen das die meisten User unfähig sind den Code zu > übersetzen. Ich selber kann das auch nur in einer VM machen, weil nur da > alle die benötigten Tools drauf sind.
Bernd K. schrieb: > Zweig schrieb: >> Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür. > > CLion kann nicht mit Projekten zurechtkommen die ihr eigenes Buildsystem > mitbringen? Das mag ich kaum glauben, ehrlich jetzt. Immerhin kostet das > Ding Geld und soll angeblich ziemlich gut sein. Ein beliebiges > existierendes Build-System benutzen zu können halte ich im Jahr 2018 für > Stand der Technik bei einer C oder C++ IDE. Daran sieht man das du in dem Bereich keine Ahnung hast. Clion kann nur mir CMake Dateien. Eine moderne Entwicklung würde ich ausschließlich mit cmake durchführen. Der Grund ist noch nicht einmal Clion sondern eher die Features von cmake. cmake ist ein Build „Generator“ mit dem sich make und Projekt Dateien für verschiedene Entwicklungs Umgebungen generieren lassen. Sogar Microsoft Visual Studio wird unterstützt. Und es kann auch alle Abhängigkeiten zu anderen Paketen auflösen.
Zweig schrieb: > Eine moderne Entwicklung würde ich ausschließlich mit cmake durchführen. Tja, als nächstes kommt dann die SCons-Fraktion und stellt fest, dass sie eine „moderne Entwicklung“ ausschließlich mit SCons durchführen würde … Leute, das ist bislang einfach mal Lukas' Entscheidung, und eine Diskussion über eine Änderung des Buildsystems in diesem Thread ist müßig.
Jörg W. schrieb: > Leute, das ist bislang einfach mal Lukas' Entscheidung, und eine > Diskussion über eine Änderung des Buildsystems in diesem Thread ist > müßig. Da hast du völlig Recht!!! Mir ist halt durch den Kopf gemurmelt ein Import für Eagle Dateien hinzuzufügen..., mal sehen ...
Markus W. schrieb: > Habe ein ähnlichs Problem, allerdings mit Debian. Wird es da langsam mal > fertige executables geben? Jemand der Zeit hat könnte ja mal den Buildvorgang dockerisieren, am besten so daß alles statisch gelinkt wird.
Zweig schrieb: > Daran sieht man das du in dem Bereich keine Ahnung hast. Clion kann nur > mir CMake Dateien. Was hat das mit "Bereich keine Ahnung" zu tun wenn irgendeine kommerzielle IDE ein grundessentielles Feature nicht gebacken bekommt, dann kommt sie halt auch weiterhin nicht in die engere Wahl solange sie nicht mit 99% der existierenden Projekte zurecht kommt, so einfach ist das.
tester schrieb: > Ich habe jetzt im Makefile bei den DEFINES ein -DGLM_ENABLE_EXPERIMENTAL" ergänzt. Das liegt daran, dass Ubuntu 18.04 (ob beta oder final ist egal) glm 0.9.9 verwendet, und dort ist das feature "GLM_GTX_transform" halt nur via GLM_ENABLE_EXPERIMENTAL verfügbar. Bleibt die Frage an Lukas, warum man das nicht ins Makefile einbauen kann?
tester schrieb: > Bleibt die Frage an Lukas, warum > man das nicht ins Makefile einbauen kann? Muss ich wohl übersehen haben, ist jetzt drin.
Angehängte Dateien:
Hallo Lukas, der horizon-pool-mgr.exe bringt eine Fehlermeldung, weil in der neuesten Version für Windows mindestens eine DLL fehlt. Siehe Anhang. Gruß Helmut
:
Bearbeitet durch User
Helmut S. schrieb: > Version für Windows mindestens eine DLL fehlt. Ist repariert. Wie auch letztes Jahr gibt's auch dieses Jahr auf der Gulaschprogrammiernacht einen Vortrag von mir zu horizon: https://entropia.de/GPN18:Fahrplan#Samstag.2C_12.05.2018 Samstag 19:00
Lukas K. schrieb: > Helmut S. schrieb: >> Version für Windows mindestens eine DLL fehlt. > > Ist repariert. > Hallo Lukas, danke für die jetzt mitgelieferte DLL. > Wie auch letztes Jahr gibt's auch dieses Jahr auf der > Gulaschprogrammiernacht einen Vortrag von mir zu horizon: > https://entropia.de/GPN18:Fahrplan#Samstag.2C_12.05.2018 Samstag 19:00 https://entropia.de/GPN18:horizon_EDA_-_ein_Jahr_sp%C3%A4ter Dem versprochenen Inhalt nach könnte das ein Ersatz für ein "user manaual" werden. Wird das ein live stream und/oder wird es eine Aufzeichnung geben die man später herunterladen kann? Gruß Helmut
Helmut S. schrieb: > Wird das ein live stream und/oder wird es eine Aufzeichnung geben die > man später herunterladen kann? Jep, C3VOC sei dank: Stream gibt's auf https://streaming.media.ccc.de/gpn18 und recordings landen dann auf https://media.ccc.de/
... und hier direkt von der media.ccc.de Seite https://media.ccc.de/v/gpn18-136-horizon-eda-ein-jahr-spter
Ich habe mir heute das Repository „horizon.git“ geholt und mit make kompiliert. Nach dem Aufruf des Linkers gab es keine weiteren Meldungen von make. Es sind einige ausführbare Dateien entstanden, die sich auch ausführen lassen. Alle starten. Alle ausser horizon-pool-mgr zeigen keine GUI bevor sie abstürzen. horizon-pool-mgr kann das pool-Repository herunterladen und eine Datenbank anlegen, und stürtzt dabei erst ab. (Mit der Option --help funktionieren alle Programme wie man es erwartet oder tun gar nichts.) Hier die Ausgabe in der Konsole:
1 | tuxpilot@elf:~/horizon/horizon$ ./horizon/horizon-pool-mgr |
2 | |
3 | (horizon-pool-mgr:18103): dbind-WARNING **: 04:52:45.566: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files |
4 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description, FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages on packages.uuid. parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
5 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description, FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages on packages.uuid. parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
6 | gl error 1282 in src/canvas/canvas_gl.cpp: 138 |
7 | Aborted (core dumped) |
8 | tuxpilot@elf:~/horizon/horizon$ ./horizon-imp -y |
9 | terminate called after throwing an instance of 'std::out_of_range' |
10 | what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) |
11 | Aborted (core dumped) |
12 | tuxpilot@elf:~/horizon/horizon$ ./horizon-pool-update-parametric |
13 | created db from shema |
14 | terminate called after throwing an instance of 'std::runtime_error' |
15 | what(): unable to open database file |
16 | Aborted (core dumped) |
Ich habe Lubuntu 18.04 LTS (alternate, 64 Bit) in einer VirtualBox. Da habe ich mit aptitude die Pakete installiert, die in https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Linux aufgezählt sind, das Repository geklont, und make aufgerufen. g++ -v schreibt: gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) Kompiliert habe ich mit folgender angepasster Zeile im Makefile, da (zumindest in Ubuntu 18.04) einige header-Dateien in Unterverzeichnissen von /usr/include landen, wo der Compiler sie nicht findet.
1 | INC = -Isrc -I3rd_party -I/usr/include/uuid/ -I/usr/include/glib-2.0/ -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ |
Mache ich etwas falsch, oder liegt es an Ubuntu 18.04? Ich kann es ja noch mal mit 17.10 versuchen... (Ich habe es auch hier auf dem Hostsystem KDE Neon 5:12.5 versucht, aber da fehlt GTK, wegen Ubuntu 16.04 LTS.) Schade, ich hatte gehofft, endlich einen Platinenlayouter gefunden zu haben, der mir gefällt...
Ach ja: Der dbind-WARNING-Kram kommt in Lubuntu bei allen GTK-Anwendungen, scheint aber keine Probleme zu verursachen.
Von den Binaries, die aus dem Build rausfallen sind nur horizon-pool-mgr und horizon-prj-mgr unmittelbar verwendbar. Der eigentliche Fehler ist der hier: > gl error 1282 in src/canvas/canvas_gl.cpp: 138 Was für eine GPU hast du? Um den Fehler weiter einzugrenzen, füge mal GL_CHECK_ERROR (wie in Zeile 138) nach jedem Funktionsaufruf in https://github.com/carrotIndustries/horizon/blob/master/src/canvas/canvas_gl.cpp#L99 ein.
Ich habe eine Radeon HD 6850, was das für die virtuelle Maschine bedeutet, weiß ich nicht. Gast: tuxpilot@elf:~$ glxinfo | grep "OpenGL version" OpenGL version string: 3.0 Mesa 18.0.0-rc5 Host: $ glxinfo | grep "OpenGL version" OpenGL version string: 3.0 Mesa 17.2.8 VirtualBox Graphical User Interface Version 5.1.34_Ubuntu r121010 Ich habe GL_CHECK_ERRORs in canvas_gl.cpp eingefügt. Der Fehler tritt nun in Zeile 101 (ohne GL_CHECK_ERROR-Zeilen) auf:
1 | void CanvasGL::resize_buffers() |
2 | {
|
3 | […] |
4 | GL_CHECK_ERROR |
5 | glRenderbufferStorageMultisample(GL_RENDERBUFFER, num_samples, GL_RGBA8, width, height); |
6 | GL_CHECK_ERROR // Fehler hier. |
7 | […] |
8 | } |
Wenn ich die Zeile auskommentiere, erscheint eine Liste mit Bauteilen und eine grafische Fehlermeldung: Could not set up framebuffer, in der Konsole steht gl error in Zeile 176. Wenn ich die Zeile auch auskommentiere, ist es Zeile 178–180. (So lößt man auch keine Probleme, habe es also verdient.)
Hallo tuxpilot, falls du auf dem gleichen PC auch ein WIN7,8,10 installiert hast, kannst du ein fertig kompiliertes horizon herunterladen um mal zu testen, ob es an der Grafikkarte liegt. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Diese Version ist immer top-aktuell da die automatisch bei jedem "commit" kompiliert wurde.
:
Bearbeitet durch User
Helmut S. schrieb: > falls du auf dem gleichen PC auch ein WIN7,8,10 installiert hast […] Nö, Tuxpilot hat hier kein Windoof. Ich habe versucht, die .exes aus dem .zip mit Wine auszuführen (auch im virtuellen Lubuntu 18.04 LTS), die Backtraces habe ich sinnloserweise angehängt. Aber ich habe eine Festplatte mit Windows 7 32bit gefunden und in meinen Computer geschoben. <blabla> Ich habe GRUB dazu bewegt, dieses Windows zu starten. Windows war fest davon überzeugt, es müsste für meinen MCP2200 ein paar Treiber suchen, und hat erst nach einer Minute aufgegeben. Für die anderen MCP2200 ging das ganze jeweils von vorne los... Schließlich konnte ich mit einem vorhandenem 7zip das .zip entpacken, was 25 Minuten gedauert hat. (Virtuelles Lubuntu: nur 2 Minuten...) Naja, die .exes wurden erstmal in Inkscape geöffnet. Hä!? </blabla> Schließlich hat Windows mir verraten, dass es nur 32bit ist, war also alles sinnlos. :( Ich habe einen Freund mit einer Radeon HD 6950 gefragt, ob er das fertig kompilierte Horizon testen kann. Wenn es an der Grafikkarte liegt, müsste er ja das gleiche Problem haben?
Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, hast du es mal nativ probiert? Die Radeon HD 6950 ist mehr als neu genug.
Lukas K. schrieb: > Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, hast > du es mal nativ probiert? > > Die Radeon HD 6950 ist mehr als neu genug. Da bin ich gespannt, weil ein Rechner MAC(Bootcamp WIN10) mit HD5800 geht bei mir nicht. "AMDs im Oktober vorgestellte Barts-GPU (Radeon HD 6800) war keine echte Neuentwicklung, sondern im Grunde genommen ein Hybrid verschiedener Radeon-HD-5000-Rechenkerne inklusive einiger kleineren Verbesserungen ..." Seite 3 von https://www.computerbase.de/2010-12/test-amd-radeon-hd-6970-und-hd-6950/3/
Win7/64 installation mit horizon-2018-05-20-1700.zip 20.Mai 2018 *********** c:\horizon\horizon mit exe, dll, ... c:\horizon\horizon-pool-master mit pool-master: pool.json ... c:\horizon\horizon-test-project-master mit test-project: pic32-eth.hprj ... horizon-pool-mgr.exe funktioniert horizon-project-manager funktioniert add pool funktioniert add project funktioniert schematic: this application has requested the runtime to terminate it in an unusual way - win7: imp.exe funktioniert nicht mehr - terminate board: this application has requested the runtime to terminate it in an unusual way - win7: imp.exe funktioniert nicht mehr - terminate part browser. this application has requested the runtime to terminate it in an unusual way - win7: prj-mgr funktioniert nicht mehr - terminate pool chache : funktioniert Kann leider keine spezifischeren Fehlermeldungen liefern. Alexandra
Hallo Alexandra, ich habe die horizon-2018-05-20-1700.zip auf zwei PCs mit WIN10 getestet. Es funktioniert genauso wie auch die früheren Versionen. Meine Verzeichnisstruktür sieht so aus: C:\horizon In dem verzeichnis packe ich immer den zip-File aus. Danach habe ich C:\horizon\horizon In dem Verzeichnis habe ich auch meinen Pool C:\horizon\pool1 und das Test-Projekt(Schaltplan, Layout) von der Github-Siete. C:\horizon\hotizon-test-project-master Man startet nur 2 Programme - horizon-pool-mgr.exe und/oder horizon-prj-mgr.exe. Alle anderen exe siind nicht für den Anwender gedacht. 1. Mit dem File-Explorer in diesen Ordner der exe-Dateinen wechseln. C:\horizon\horizon horizon-pool-mgr.exe starten (Doppelklick). Im pool-mamanger dann einen Pool auswählen. Wenn man den hat, dann gibt es oben im Menu ein Feld "Remote". Da draufklicken. dann Upgrade pool. Dann Merge. Den horizon pool manager schließen. 2. Das Projekt öffnen. horizon-prj-mgr.exe Doppelklick Ganz links oben auf das schwarze "horizon icon" klicken -> Preferences und mit "Add pool" einen pool auswählen, falls da noch keiner gesetzt ist. Zurück ins Hauptmenu. "Open" und das Projekt anwählen z. B. das heruntergeladen Project pic32-eth.hprj Jetzt hat man es fast geschafft. Es gibt jetzt vier buttons. "Top Schematic" "Board" "Part browser" "Pool Cache" "Pool Cache" wählen falls man updaten will (mach ich meistens). Falls es etwas neues für das Projekt gibt, die neuen Teile anklicken und dann "Update from pool". Pool Cache schließen. Jetzt auf "Top Schematic" oder "Board "klichen zum Öffnen des Schaltplanes oder Layouts. Nachtrag: Bei weiteren updates des Programms entpacke ich einfach den zip-file in C:\horizon und lasse das Unterverzeichnis horizon überschreiben. C:\horizon\horizon
:
Bearbeitet durch User
Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - bei einer 3Mbit-Leitung. Macht fuer mich keinen Sinn mehr mitzulesen oder etwas beizutragen.
@Helmut S danke für die Rückmeldung. Auch mit veränderter Verzeichnis-Struktur erzeugen die aus horizon-prj-mgr aufgerufenen Funktionen in meinem Win7/64 AppCrash-Laufzeitfehler Hardware: Toshiba-L770-14N-Notebook mit IntelGraphics PartBrowser : horizon-prj-mgr.exe crasht und wird beendet: Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-prj-mgr.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-prj-mgr.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 000000000011f22a Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: 0252 Zusatzinformation 2: 0252b7e8806be3f352f78783978e4b54 Zusatzinformation 3: 0816 Zusatzinformation 4: 0816dc325007f9d08cf3f87eb61e4aa0 Board : horizon-imp.exe crasht und wird beendet, horizon-prj-mgr.exe funktioniert weiter Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-imp.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-imp.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 00000000002f63ca Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: f3cb Zusatzinformation 2: f3cb96d6f8d6bdc527a608eb82d9985c Zusatzinformation 3: 3461 Zusatzinformation 4: 34610f60121e0543dce0d79c85026758 Top Schematic: horizon-imp.exe crasht und wird beendet, horizon-prj-mgr.exe funktioniert weiter Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-imp.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-imp.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 00000000002f63ca Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: f3cb Zusatzinformation 2: f3cb96d6f8d6bdc527a608eb82d9985c Zusatzinformation 3: 3461 Zusatzinformation 4: 34610f60121e0543dce0d79c85026758 PoolChache: funktioniert
@MitLeserin: Ich hab' mal das Error-Reporting für OpenGL-Fehler auf Windows verbessert, damit man auch ohne Konsole sieht wo es hingefallen ist: https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.197/artifacts
@Mitleserin
> i3-2350M
Ich vermute, dass da die integrierte Grafik zu alt ist.
Versuch es mal mit einem neueren PC.
Ich schreibe gerade auf einem i5-4250U Laptop mit integrierter
Grafikeinheit. Darauf läuft horizon problemlos.
Gruß
Helmut
:
Bearbeitet durch User
Tuxpilot schrieb: > Ich habe mir heute das Repository „horizon.git“ geholt und mit make > kompiliert. […] horizon-pool-mgr […] stürtzt […] ab. > […] > Ich habe Lubuntu 18.04 LTS (alternate, 64 Bit) in einer VirtualBox. > […] > Schade, […] Lukas K. schrieb: > Der eigentliche Fehler ist der hier: > >> gl error 1282 in src/canvas/canvas_gl.cpp: 138 > > Was für eine GPU hast du? Lukas K. schrieb: > Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, > hast > du es mal nativ probiert? > > Die Radeon HD 6950 ist mehr als neu genug. (Ist eine 6850) So, ich habe Lubuntu 18.04 LTS nativ installiert. Da funktioniert make direkt vollständig, und die entstehenden Programme scheinen ohne Abstürze zu funktionieren. Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor, wenn man das Fenster größer macht. Später versuche ich es nochmal mit Lubuntu 17.10.
Tuxpilot schrieb: > Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind > größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor, > wenn man das Fenster größer macht. Kannst du mal einen Screenshot davon machen? Hört sich doch sehr nach Gtk/Grafiktreiber-Bug an. Installiere mal gtk3-examples und mach' aus der gtk3-demo die OpenGL-Demo auf. Sieht die auch so kaputt aus?
:
Bearbeitet durch User
> Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind
größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor,
wenn man das Fenster größer macht.
Normal ist das nicht.
Das wird dann an den Grafiktreibern bzw. der Grafikkarte liegen.
Angehängte Dateien:
Die OpenGL-Demo sieht prima aus. (In VirtualBox ist alles ausser der Grafikfläche schwarz, funktioniert aber trotzdem. (Der Rest dieses Beitrags bezieht sich auf nativ installiert.)) Die anderen Demos, die ich angeguckt habe, sehen auch gut aus, insbesondere die mit den Listen oder Panes. In anderen Anwendungen habe ich auch nichts bemerkt. In den Pool-Ansichten fehlt immer mindestens der rechte oder linke Rand von den Anzeigen, und die Knöpfe oben drüber fehlen irgendwie auch, obwohl da noch Platz wäre. Als ob die Panes ausserhalb des Fensters beginnen würden... Die übrigen Fenster (Schaltplan-Editor und so) funktionieren jetzt überwiegend, nur im Tastenkürzel-Menü habe ich gesehen, dass das letzte Element halb abgeschnitten ist. Übrigens kann man die Spalte Pads in der Breite verändern, die anderen aber nicht. Glaube nicht, dass das so soll.
Angehängte Dateien:
-
horizon-pool-mgr.exe.jpg
220 KB -
horizon-prj-mgr.exe.jpg
150 KB
@tuxpilot Ich vermute dass du das Fenster zu klein gemacht hast. Zieh doch mal das Fenster breiter. Im Anhang die Darstellung auf einem Monitor mit 1920x1080, WIN10. Da muss ich die Fenster schon fast auf die komplette Bildschirmbreite ziehen damit ich alles sehe.
:
Bearbeitet durch User
Toxic schrieb: > Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - > bei einer 3Mbit-Leitung. Melde dich als Nutzer im Forum an, dann kannst du eine Seitenaufteilung einschalten. Der Thread hat dann inzwischen 4 Seiten.
Jörg W. schrieb: > Toxic schrieb: >> Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - >> bei einer 3Mbit-Leitung. > > Melde dich als Nutzer im Forum an, dann kannst du eine Seitenaufteilung > einschalten. Der Thread hat dann inzwischen 4 Seiten. Hallo Joerg, ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? (Ich habe mit 50MBit/s Zugang kein wirkliches Problem mit der Auswahl "alles", aber mich würde trotzdem interessieren wie man die Auswahl 1,2 zurück bekommt.)
Helmut S. schrieb: > ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl > "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? Über der Box "Antwort schreiben" gibt es einen Link "Seitenaufteilung einschalten".
Jörg W. schrieb: > Helmut S. schrieb: >> ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl >> "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? > > Über der Box "Antwort schreiben" gibt es einen Link "Seitenaufteilung > einschalten". Danke, hat geklappt.
Hallo Toxic. Toxic schrieb: > Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - > bei einer 3Mbit-Leitung. Dann hast Du aktuell halt keine 3Mbit-Leitung. Mit einer 600k Leitung dauert es wenige Sekunden. > Macht fuer mich keinen Sinn mehr mitzulesen oder etwas beizutragen. Dann solltest Du mal untersuchen, was auf Deiner Leitung abgeht. 3Mbit-Leitung ist irre viel, falls sie funktioniert. Wenn hier abends die Nachbarn saugen, sackt bei mir die Leitung auch auf teilweise unter 10k ab. Allerdings.....der Mittelwert über ca. 15min bleibt immer in etwa gleich. D.h. Dateien ziehen geht so lala, aber ein Audiostream reisst ab. Anmeckern kann ich den Provider aber dafür nicht. Das steht so im indirekt im kleingedruckten des Vertrags. Vermutlich hast Du ähnliches im Kleingedruckten. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
@Lukas K
Danke,
die Fehlermeldung lautet in allen Fällen:
gl error 1281 in src/canvas/canvas:gl.cpp:120
program will abort
114 void CanvasGL::on_realize()
. {
. Gtk::GLArea::on_realize();
. make_current();
. GL_CHECK_ERROR
. grid.realize();
120 GL_CHECK_ERROR ---------> error
Angehängte Dateien:
-
Horizon.JPG
35 KB
Intel Driver Update direkt von Intel für i3-2350M ************************************************* Der Laufzeitfehler tritt nicht mehr auf. Horizon - Schematic startet mit einer Oberfläche, nur Text, ein leerer Bereich mit x/y Position des Cursors. Auf einem zweiten Notebook(Asusi7): dasselbe Resultat
MitLeserin schrieb: > gl error 1281 in src/canvas/canvas:gl.cpp:120 Seltsam, dass es da hinfällt, in der grid.realize() passiert eigentlich nichts besonderes. MitLeserin schrieb: > Horizon - Schematic startet mit einer Oberfläche, nur Text, ein leerer > Bereich mit x/y Position des Cursors. Hm, auch nicht wirklich besser. Installier' dir mal MSYS2 (vgl. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows) und starte die horizon-prj-mgr.exe aus der mingw64-shell. Da sollte dann irgendwas in der Konsole stehen, das erklärt weshalb es hingefallen ist.
Tuxpilot schrieb: > So, ich habe Lubuntu 18.04 LTS nativ installiert. […] > Später versuche ich es nochmal mit Lubuntu 17.10. Auf Lubuntu 17.10: kein Unterschied feststellbar. gtk3-demo funktioniert auch da einwandfrei. Helmut S. schrieb: > @tuxpilot > > Ich vermute dass du das Fenster zu klein gemacht hast. Zieh doch mal das > Fenster breiter. Im Anhang die Darstellung auf einem Monitor mit > 1920x1080, WIN10. Da muss ich die Fenster schon fast auf die komplette > Bildschirmbreite ziehen damit ich alles sehe. Daran liegt es wohl nicht. Ich habe die Fenster auf 16.000 Pixel Breite gezogen, aber die Widgets waren immer noch halb unter dem Rand. Dann ist X abgestürtzt, was zu erwarten war.
Tuxpilot schrieb: > Daran liegt es wohl nicht. Ich habe die Fenster auf 16.000 Pixel Breite > gezogen, aber die Widgets waren immer noch halb unter dem Rand. Dann ist > X abgestürtzt, was zu erwarten war. Das sollte mit dem Commit repariert sein: https://github.com/carrotIndustries/horizon/commit/0c370219bbb6190a361ac880a3db9a168b7863e0
Angehängte Dateien:
-
Horizon.prj-mgr..JPG
150 KB
@Lukas ich habe da mal mit der Anleitung von Helmut S Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" etwas versucht : horizon startet und die Konsole liefert folgende Meldung: Alexandra@Asus-i7 MINGW64 /home/horizon_/horizon $ ./horizon-prj-mgr.exe SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, tags_view.tags, parts.filename, parts.description FROM parts LEFT JOIN tags_vi ew ON tags_view.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) ORDER BY parts.MPN COLLATE naturalCompare ASC col 2 create proc spawn C:\msys64\home\horizon_\horizon\horizon-imp -c C:\horizon\horizon\horizon-test-project-master\top_sch.json C:\horizon\horizon\horizon-test-project-master\top_block.json imp rx false (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:32.832: fb setup not supported (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:35.047: fb setup not supported ****************** Gtk-WARNING gibt es jede Menge und die Zahl korreliert irgendwie mit den Koordinaten des Mauszeigers.
MitLeserin schrieb: > (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:35.047: fb setup not > supported Vielen Dank für's Debuggen bis hier hin schonmal, viele andere hätten schon (verständlicherweise) entnervt aufgegeben und sich anderen Dingen zugewandt. So auf die Schnelle fallen mir zwei Dinge ein, an denen das liegen könnte: - horizon fasst Buffer falsch an und Gtk ist dann hinterher unglücklich - Bug in Gtk (wär' nich der erste im Bezug auf OpenGL und Windows) So als Vorwarnung: weiteres Debuggen muss nicht unbedingt zur Lösung des Problems führen, sei mir' also nicht böse, wenn's dann immer noch nicht funktioniert. Wenn du jetzt eh schon Msys2 hast, starte mal die gtk3-demo und darin die OpenGL-demo. Funktioniert die?
GTK3-demo.exe funktioniert, verschiedene Demos funktionieren normal. OpenGL Area erzeugt aber sofort eine (gtk3-demo.exe:4500): Gtk-WARNING **: 13:25:13.752: fb setup not supported Warnung und bei jedem move der Slider eine Vielzahl weiterer identischer Warnungen.
Hallo Zusammen, wo finde ich in der Windows Version den Part Editor bzw. wie muss ich vorgehen, wenn ich einen neues Bauteil definieren will. Gruß Frank
MitLeserin schrieb: > (gtk3-demo.exe:4500): Gtk-WARNING **: 13:25:13.752: fb setup not > supported > > Warnung Ok, dann ist wohl das Problem bei Gtk. Leider sagt einem Gtk nicht, wo nun das Problem mit dem Framebuffer ist, daher hier im Anhang ein gepatchtes Gtk, das in der Fehlermeldung mehr anzeigt. Mit der dll ersetzt du dann die gleichnamige im Ordner mingw64/bin in deiner mingw-installation und probierst die OpenGL-Demo nochmal. MitLeserin schrieb: > und bei jedem move der Slider eine Vielzahl weiterer identischer > Warnungen. Das kommt daher, dass dieses Stück code bei jedem rendern aufgerufen wird. Frank L. schrieb: > wo finde ich in der Windows Version den Part Editor bzw. wie muss ich > vorgehen, wenn ich einen neues Bauteil definieren will. Den Part Editor startest du aus dem pool manager heraus. Zum Erstellen von neuen Bauteilen: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard
(gtk3-demo.exe:7300): Gtk-WARNING **: 23:13:39.518: fb setup not supported, status=36055 status=36055 bleibt konstant immer 36055 (gtk3-demo.exe:3264): Gtk-WARNING **: 23:16:46.160: fb setup not supported, status=36055 (gtk3-demo.exe:^^^^) ändert nach Beendigung und erneutem Aufruf von gtk3-demo.exe
MitLeserin schrieb: > (gtk3-demo.exe:3264): Gtk-WARNING **: 23:16:46.160: fb setup not > supported, status=36055 > > (gtk3-demo.exe:^^^^) ändert nach Beendigung und erneutem Aufruf von > gtk3-demo.exe Die sich ändernde Nummer ist die Prozess-ID, das passt schon so. Der Fehlercode ist GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT, irgendwas hat wohl beim Aufsetzen der Framebuffer nicht funktioniert. Die DLL im Anhang hat weitere Debug-Ausgabe drin, selbes Vorgehen wie im letzten post.
Lukas K. schrieb: > Den Part Editor startest du aus dem pool manager heraus. Zum Erstellen > von neuen Bauteilen: > https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard Hallo Lukas, dann habe ich leider einen Fehler entdeckt. Sobald ich im Pool Manager den Pool auswähle, schließt sich die Anwendung. Leider weiß ich nicht, wo ich das LOG in der Windows Version finde. Vielleicht kannst Du Dir das ja mal ansehen bzw. mir sagen, wo ich das LOG finde, dann stelle ich es hier ein. Gruß Frank
RUN [OpenGL Area] erzeugt in der Konsole (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.882: fb attach texture=0 buffer=1 error=1282 (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.886: fb setup not supported, status=36055 - Klick in der Konsole erzeugt 12 weitere identische paarweise Logs, - Frame mit den drei Slidern erscheint nicht, - beenden durch beenden der Konsole.
Frank L. schrieb: > Sobald ich im Pool Manager den Pool auswähle, schließt sich die > Anwendung. Leider weiß ich nicht, wo ich das LOG in der Windows Version > finde. Dann mach' es mal wie MitLeserin und starte es aus der Mingw-shell, sieht auch nach OpenGL-Problem aus. Was für eine GPU hast du? MitLeserin schrieb: > (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.882: fb attach texture=0 > buffer=1 error=1282 Okay, da fällt also was schon davor hin. Die DLL im Anhang hat noch mehr Debug-Ausgabe. Was für eine GPU hast du eigentlich genau?
Lukas K. schrieb: > Was für eine GPU hast du eigentlich genau? Gute Frage, war ich mir eigentlich nicht wirklich bewusst. Bisher je nach Notebook irgendwie automatisch und hat bis jetzt mit horizon scheinbar immer alles funktioniert... Erkenntnis und Stand der Dinge: ****************************** Auf ASUSi7 kann ich für jedes Programm die GPU wählen. - Intel HD Graphics 4600 : gtk3-demo.exe funktioniert NICHT - NVIDIA GeForce GTX 850M : gtk3-demo.exe funktioniert Mit *IntelHD 4600 und libgtk-3-0.dll V3* liefert gtk3-demo.exe zyklische Fehlermeldungen : (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.735: fb setup not supported, status=36055 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.744: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.747: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.750: opengl error 1281 at gtkglarea.c:547 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.753: fb setup not supported, status=36055 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.773: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.774: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.777: opengl error 1281 at gtkglarea.c:547 ... to be continued ...
Auf den folgeneden Grafikkarten läuft horizon nach meiner Erfahrung. NVIDIA GTX560, GTX950, GTX1080 Intel Graphic HD 5000, HD 530 Auf der GTX260 läuft es nicht richtig. Daraus kann man den Schluss ziehen, dass es zumindest ab GTX560 und höher funktioniert.
MitLeserin schrieb: > Mit *IntelHD 4600 und libgtk-3-0.dll V3* liefert gtk3-demo.exe zyklische > Fehlermeldungen : Okay, probier's nochmal mit der DLL im Anhang und achte insb. auf die Ausgabe direkt nach dem starten der OpenGL-Demo.
Bei mir läuft eine Desktop MSI GEFORCE GTX1060 mit 6GB. Es sind zwei 4K Monitore angeschlossen. Die Anwendung lässt sich auch wundervoll bedienen und arbeitet einwandfrei. Lediglich der Aufruf des Part Editors aus dem Pool Manager heraus klappt nicht, da es hier zu einem beendigen der Anwendung kommt. Der Vorgang ist immer gleich, ich wähle im Pool Manager den Eintrags aus, der wird Bildschirm kurz weiß und dann beendet sich die Anwendung. @Lukas Sorry, mit MingW kenne ich mich nicht aus und ich habe nicht genug Zeit mich mit den Dingen zu beschäftigen. Von daher muss ich da passen. Allerdings würde ich die Anwendung gerne intensiver nutzen. Vielleicht hat ja noch wer anders das gleiche Problem und kann sich damit beschäftigen. Besteht eventuell die Möglichkeit, dass Du das Log für die Windows Version, im Verzeichnis %Appdata%\local\Horizon ablegt? Da befinden sich ja auch die Konfigurationsdateien. Gruß Frank
So, ich habe ein wenig geforscht. Jetzt läuft es, bei mir war der OpenGL gar nicht bzw. nicht korrekt installiert. Nachdem ich den aktuellsten Treiber der Karte installiert habe, funktioniert es. Gruß Frank
Alexandra@Asus-i7 MINGW32 /mingw64/bin $ ./gtk3-demo // NVIDIA - libgtk-3-0.dll /V4 //**************************************************************** // startup /***************************************************************** (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.977: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.978: allocate buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.979: attach 0 1 // slider - twisting the triangle //**************************************************************** (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.290: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.290: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.324: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.324: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.340: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.341: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.357: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.358: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.375: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.376: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.391: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.391: attach 0 1 Alexandra@Asus-i7 MINGW64 /mingw64/bin $ ./gtk3-demo //INTEL - libgtk-3-0.dll /V4 //**************************************************************** // startup //**************************************************************** (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.366: fb setup not supported, status=36055 // slider - no graphics visible //**************************************************************** (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: fb setup not supported, status=36055 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: fb setup not supported, status=36055 ... // unnecessary CR removed
Okay, vielleicht ist es ein Problem, dass der Renderbuffer von einer EXT-Funktion erzeugt, aber von einer nicht-EXT Funktion verwendet wird, probier's mal mit der DLL im Anhang.
Angehängte Dateien:
-
Horizon.prj-mgr....JPG
180 KB
MitLeserin schrieb: ****************************************** > - Klick in der Konsole erzeugt 12 weitere identische paarweise Logs, > - Frame mit den drei Slidern erscheint nicht, > - beenden durch beenden der Konsole. Das ist ein Fehler von gtk3-demo.exe. Dieser Fehler ist unabhängig von der ausgewählten GPU: Verschieben des Programm-Windows von gtk3-demo.exe in einen zweiten Monitor hat den Effekt, dass die Programm-Windows einzelner Tochter-Programme nicht erscheinen und die Kontrolle über gtk3-demo.exe verloren geht. -> Beenden von gtk3-demo.exe mit Ctrl-C in der Konsole. Betroffen sind vermutlich alle gtk3-demo-Beispiele mit "Grafik", darunter auch OpenGL Area. ****************************************************** Zurück zum Thema **************** Alexandra@Asus-i7 MINGW64 /mingw64/bin $ ./gtk3-demo // INTEL - libgtk.3.0.dll /V5 //**************************************************************** // startup //**************************************************************** (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: allocate buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: attach 0 1 // slider no effect - background visible //*************************************************************** (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:49.224: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:49.224: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.339: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.339: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.357: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.357: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.373: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.373: attach 0 1 ... Das Grafik-Fenster ist durchsichtig, Mausspur im Grafikfenster wird ohne Einträge in der Konsole dargestellt , Slider hat im Grafikfenster keinen Effekt, erzeugt aber Einträge in der Konsole. ( die Mausspur wird von PrtScr gelöscht und kann deshalb nicht dokumentiert werden )
Hallo Zusammen, ich brauche mal einen Tipp, in welcher Reihenfolge man bei der Definition eigener Bauteile vorgehen muss. Mein Ziel, ich möchte verschiede Röhren mit Oktal und Noval Sockel erstellen. Um Smash verwenden zu können, möchte ich z.B. bei einer ECC83 die beiden Systeme und die Heizung jeweils getrennt halten. Andere Röhren mit Noval Sockel haben unterumständen nur ein System plus Heizung. Ich würde das Ganze gerne in einem Artikel zusammenfassen und hier veröffentlichen. Aber ich finde keinen Einstieg in die Materie :-( Gruß Frank
:
Bearbeitet durch User
Angehängte Dateien:
-
pool.PNG
250 KB
@Frank https://media.ccc.de/v/gpn18-136-horizon-eda-ein-jahr-spter Lade dir doch mal den Vortrag herunter. In der ersten Hälfte wird ganz grob das erstellen von Bauteilen gezeigt. (Lass dich nicht von der Tonstörung(Hall) im ersten Viertel des Vortrages stören.) Das angehängte Bild zeigt dei Struktur und die Namensgebung der Bestandteile eines Bauteils. Das Programm zum erstellen der Bauteile heißt horizon-pool-mgr.exe
MitLeserin schrieb: > Betroffen sind vermutlich alle gtk3-demo-Beispiele mit "Grafik", > darunter auch OpenGL Area. Ich bin untröstlich, aber sieht so aus, als geht's hier nicht wirklich weiter. Im IRC Channel von Gtk meine man, dass das recht sicher ein Bug im Intel-Treiber ist, der nicht durch hohe Qualität im Bezug auf OpenGL bekannt sei. So ohne Problemhardware in der Hand debuggt sich's auch eher mühsam... Immerhin tut's bei dir ja mit der Nvidia-GPU.
Hallo Lukas, ich habe mir das auch so gedacht. Wenn ein Programm auf unterschiedlicher Hardware einerseits prima funktioniert und andererseits so krasse Fehlermeldungen produziert muss ein Hardware naher Fehler vorliegen. Ich denke nicht, dass Intel für die älteren Grafikeinheiten noch BugFixes nachliefern wird. vom Fehler betroffen: ******************** System: Toshiba Satpro L770-14N : Intel i3-2350M mit Intel HD3000 GPU System: Asus............N750 IK : Intel i7-4710HQ mit Intel HD4600 GPU vom Fehler nicht betroffen: ************************** System HP...............Envi 15 : Intel i7-6500U mit Intel HD520 System HP...............Envi 15 : Intel i7-6500U mit NVIDIA GTX 950M System Asus.............N750 IK : Intel i7-4710HQ mit NVIDIA GTX 850M Respekt für horizon! Alexandra
Markus W. schrieb: > Liegt das an den core-steppings der Prozessoren? Hallo Markus, das liegt nicht am CPU-Core sondern an deren GPU und dessen OpenGL-Treiber. Auch alle älteren Grafikkarten versagen hier. Helmut
Angehängte Dateien:
-
Fehler_Plane-Ausschnitt.PNG
599 Bytes -
Kicad-Plane-Ausschnitt.GIF
34 KB
Hallo Lukas, Fehler: "Plane Update" ignoriert Ausschnitte im Board. In meinem Beispiel habe ich ein Polygon auf Lage "outline" gezeichnet. "Plane Update" sollte hier entsprechend der Design-Rule das Kupfer um 0,xmm um den Ausschnitt herum zurückziehen. Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. Gruß Helmut
Zu der Sache mit den Intel 4000er-GPUs habe ich noch das hier gefunden: https://bugzilla.gnome.org/show_bug.cgi?id=792174#c2 Der hatte wohl die selben Ideen wie ich und auch gleich wenig Erfolg... Helmut S. schrieb: > Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. Horizon hatte es mal richtig gemacht, ist wohl in https://github.com/carrotIndustries/horizon/commit/b2ae2dd6348a110d18538b802d88de887ba30547 kaputt gegangen... Jetzt geht's wieder.
Angehängte Dateien:
-
Plane-Ausschnitt.PNG
996 Bytes
> Helmut S. schrieb: >> Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. > Horizon hatte es mal richtig gemacht, ist wohl in > https://github.com/carrotIndustries/horizon/commit... > kaputt gegangen... Jetzt geht's wieder. Hallo Lukas, danke für die schnelle Korrektur. Habe es gerade selbst getestet. Es funktioniert jetzt wie erwartet.
:
Bearbeitet durch User
Für alle die sich wundern, wo seit dem letzten Build Pool- und Projektmanager sind: Die wurden beide in "horizon-eda" vereint, sodass es jetzt nur ein Programm zum Anklicken gibt.
Angehängte Dateien:
-
p1.png
78 KB
Die Vereinigung mach Sinn. Aber: Es gibt Probleme: (horizon-eda:5961): glibmm-CRITICAL **: 20:36:14.899: unhandled exception (type Glib::Error) in signal handler: domain: g-resource-error-quark code : 0 what : Die Ressource auf »/net/carrotIndustries/horizon/prj-mgr/part_browser/part_browser.ui« existiert nicht Auch sind meine selbst definierten Bauteile weg. Starte ich die alten Programme horizon-prj-mgr und horizon-pool-mgr befinden sich die Bauteile alle nur im Cache. Allerdings könnte das schon seit einem länger vergangenen Update sein...
Hallo Lukas, habe die neueste kompilierte Version für WIN heruntergeladen. Dann habe ich horizon-eda.exe gestartet. Darin kann ich aber nur den Pool-Manager starten und den Pool updaten aber nicht das Projekt (Schaltplan, Layout) starten. Weder "Open" noch Doppelklick in "Recent Projects" auf das Projekt hilft. Da passiert einfach gar nichts.
:
Bearbeitet durch User
Helmut S. schrieb: > Da passiert einfach gar nichts. Ähm, ich hätte vielleicht zu meiner Fehlermeldung im vorletzten Post dazu schreiben sollen, dass diese geworfen wird wenn ich versuche, ein Projekt zu öffnen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.