Helmut S. schrieb: > Lukas K. schrieb: >> Helmut S. schrieb: >>> Bei mir in WIN10 geht "Plane to trace" oder auch "plane zu sonstwas" >>> überhaupt nicht >> >> Guck nochmal genau hin, der Haken bei "Enable this rule" fehlt. > > Hallo Lukas, > danke das war. Ich glaube ich sollte mir die Menüs in Zukunft genauer > anschauen. > > Neue Frage: > Hatte ich da nicht schon mal irgendwo "thermal ties" gesehen? Ich finde > nichts um das einzuschalten. Vielleicht war das aber auch in KiCad. Hat sich erledigt. Ich habe es gerade gefunden. Siehe Bild. "Thermal relief"
Angehängte Dateien:
-
Thermal_relief.GIF
230 KB
Hallo Lukas, ich finde keine Anleitung zu "Length tuning". Was muss ich bei "Length tuning" machen um diese Leitung auf 10mm Länge zu "tunen"? Was bedeutet dieses VF:100? Offenbar kann man da 1 bis 100 einstellen.
Angehängte Dateien:
-
length_tuning2.GIF
82 KB
Bin mal wieder einen Schritt weiter zum Thema "length tuning". 1. Mit "Measure track" bekommt man die Leitungen in das "Lenght tuning" Fenster. Mit "Tune track" bekomme ich dann ein für mich nicht wirklich kontrollierbares Mäander. Ich kann mit "Move" und keyboard dann so ein Mänder mit den Pfeiltasten schieben (länger oder kürzer machen). Im Fenster "Length Tuning" wird dann die aktuelle Länge angezeigt. Mit dem button "Ref" erhalte ich dann noch die +/- Abweichung in ps. Ist das die gedachte Vorgehensweise? Das VF:100 bedeutet wohl 100% Lichtgeschwindigkeit. Allerding wird da "er" nicht angepasst. Da steht immer noch 4. Wenn ich in "er" 4 ENTER mache, dann geht VF auf 50(%). Wenn ich dann wieder 100 ENTER eingebe, wird wieder mit Vakuum-Lichtgeschwindigkeit gerechnet aber "er" belibt weiterhin auf 4. Warum wird das nicht auf 1 gesetzt, wenn ich 100% eingebe? Kann man die Form des Mäander gezielt vorab einstellen?
Hallo Lukas, ich kann im Layout Bauteile beliebig übereinander schieben. Ich finde keine Einstellung um da irgend etwas einzustellen. Ist das so gewollt? Kommt da noch eine Funktion für Mindestabstand zwischen "Courtyard"? Natürlich an- und abschaltbar.
Das mit dem Velocity Factor ist mittlerweile besser und hoffentlich verständlicher geworden. Helmut S. schrieb: > Ich kann mit "Move" und keyboard dann so ein > Mänder mit den Pfeiltasten schieben (länger oder kürzer machen). Im > Fenster "Length Tuning" wird dann die aktuelle Länge angezeigt. Mit dem > button "Ref" erhalte ich dann noch die +/- Abweichung in ps. Ist das die > gedachte Vorgehensweise? Genau, mit den automatisch platzierten Mäandern war ich nie so recht zufrieden, deshalb mit diesem Fenster die Möglichkeit die Tracks manuell hinzuzupfen. Helmut S. schrieb: > Kann man die Form des Mäander gezielt vorab einstellen? Im Tool "Tune Track" kann man mit , und . und < und > Periode und Amplitude der Mäander einstellen. Helmut S. schrieb: > ich kann im Layout Bauteile beliebig übereinander schieben. Ich finde > keine Einstellung um da irgend etwas einzustellen. > Ist das so gewollt? Mehr oder minder ja. Bis auf die Paar von KiCad übernommenen Tools kann bei horizon kein Tool online-DRC. Auf absehbare Zeit wird das wohl auch so bleiben. > Kommt da noch eine Funktion für Mindestabstand zwischen "Courtyard"? > Natürlich an- und abschaltbar. Ist als Check geplant und ist eigentlich auch recht einfach zu implementieren, war nur noch niemand wichtig genug.
Lukas K. schrieb: > ... > Helmut S. schrieb: >> Kann man die Form des Mäander gezielt vorab einstellen? > > Im Tool "Tune Track" kann man mit , und . und < und > Periode und > Amplitude der Mäander einstellen. > Hallo Lukas, danke für die vielen Informationen. Die Einstellmöglichkeit der Mäander werde ich morgen mal testen. Beim Überfliegen von EAGLE, und KiCad bin auf microvias und buried vias gestoßen. Ist das ein größerer Aufwand z. B. microvias zu implementieren? Ich gebe ja zu, dass ich mir nicht vorstellen kann so ein teures PCB mit microvias und buried vias privat machen zu lassen. Gruß Helmut
Hallo Lukas Erst mal ein Lob für deine Arbeit. Instalation unter Gentoo Linux
1 | emerge -uav sci-libs/opencascade dev-libs/libgit2 dev-libs/libgit2-glib app-eselect/eselect-opencascade media-libs/glm net-libs/zeromq dev-cpp/yaml-cpp |
2 | |
3 | |
4 | * IMPORTANT: 2 news items need reading for repository 'gentoo'. |
5 | * Use eselect news read to view new items. |
6 | |
7 | |
8 | These are the packages that would be merged, in order: |
9 | |
10 | Calculating dependencies... done! |
11 | [ebuild N ~] app-eselect/eselect-opencascade-0::gentoo 0 KiB |
12 | [ebuild N ] net-libs/http-parser-2.8.1:0/2.8.0::gentoo USE="-static-libs" ABI_X86="32 (64) (-x32)" 50 KiB |
13 | [ebuild N ] dev-cpp/tbb-2017.20161128::gentoo USE="-debug -doc -examples" ABI_X86="32 (64) (-x32)" 2.897 KiB |
14 | [ebuild N ] dev-libs/libsodium-1.0.16-r2:0/23::gentoo USE="asm urandom -minimal -static-libs" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="aes sse4_1" 1.867 KiB |
15 | [ebuild N ] net-libs/libssh2-1.8.0-r1::gentoo USE="zlib -gcrypt -libressl -static-libs -test" ABI_X86="32 (64) (-x32)" 835 KiB |
16 | [ebuild N ] sci-libs/exodusii-6.09::gentoo USE="-static-libs -test" 4.646 KiB |
17 | [ebuild N ] dev-libs/jsoncpp-1.8.4:0/19::gentoo USE="-doc -test" 196 KiB |
18 | [ebuild N ] dev-cpp/yaml-cpp-0.6.2:0/0.6::gentoo USE="-test" ABI_X86="32 (64) (-x32)" 1.364 KiB |
19 | [ebuild N ] dev-libs/libgit2-0.26.8:0/26::gentoo USE="curl ssh threads -examples -gssapi -libressl -test -trace" 4.632 KiB |
20 | [ebuild N ] sci-libs/vtk-7.1.0::gentoo USE="X ffmpeg mysql odbc python qt5 rendering tcl tk -R -all-modules (-aqua) -boost -doc (-examples) -gdal -imaging -java -json -kaapi (-mpi) -offscreen -postgres -tbb -test -theora -views -web -xdmf2" PYTHON_TARGETS="python2_7" VIDEO_CARDS="nvidia" 30.441 KiB |
21 | [ebuild N ] dev-lang/vala-0.36.13:0.36::gentoo USE="-test" 2.803 KiB |
22 | [ebuild N ] net-libs/zeromq-4.2.2-r2:0/5::gentoo USE="sodium -doc -drafts -pgm -static-libs -test -unwind" 1.208 KiB |
23 | [ebuild N ~] sci-libs/opencascade-7.3.0:7.3.0::gentoo USE="ffmpeg tbb vtk -debug -doc -examples -freeimage -gl2ps -gles2 -java" 47.439 KiB |
24 | [ebuild N ] dev-libs/libgit2-glib-0.26.2::gentoo USE="python ssh vala" PYTHON_TARGETS="python3_5 python3_6 -python3_4" 413 KiB |
25 | |
26 | Total: 14 packages (14 new), Size of downloads: 98.784 KiB |
27 | |
28 | Would you like to merge these packages? [Yes/No] yes |
plus ein
1 | emerge -uav net-libs/cppzmq |
2 | * IMPORTANT: 2 news items need reading for repository 'gentoo'. |
3 | * Use eselect news read to view new items. |
4 | |
5 | |
6 | These are the packages that would be merged, in order: |
7 | |
8 | Calculating dependencies... done! |
9 | [ebuild N ] net-libs/cppzmq-0_pre150606::gentoo 4 KiB |
10 | |
11 | Total: 1 package (1 new), Size of downloads: 4 KiB |
12 | |
13 | Would you like to merge these packages? [Yes/No] |
Soweit kein Problem bei make steigt er aber aus
1 | make: *** Keine Regel vorhanden, um das Ziel „.git/HEAD“, |
2 | benötigt von „src/gitversion.cpp“, zu erstellen. Schluss. |
Nachdem das Problem mit Git durch git clone ... anstatt über ein zip gelöst wurde, kamen noch weitere Fehlermeldungen... Ich hab das Problem mal als Issue auf git gepostet
Naja vieleicht bekomme ich irgendwann horizon auf meinem Gentoo Linux auch ans laufen Was mal wirklich genial wäre: Ein Frequenzanalyseprogramm für die fertig geroutete PCB Also so etwas wie Dämpfungselemente,Pulse und Schwingungen an bestimmten Punkten auf die entsprechenden Pads geben. Müsste ja nicht mal mega genau sein, reicht schon wenn z.B. ein I2C Bus oder ein DC/DC simuliert werden könnte. Daten eventuell sogar aus einer Datei mit real gemessenen Kurven. Das kenne ich bis jetzt im Opensource Bereich noch von keiner Software
Hallo Achim, aus einer früheren Message von Frank, 1.11.2017 --- Hast Du git installiert? Wenn ja, dann versuch mal git clone https://github.com/carrotIndustries/horizon.git dann sollte "make" durch laufen. Das Problem ist wohl dass in der *.zip Datei keine git Metadaten enthalten sind. Diese werden jedoch benötigt um einen git-Versionsstring in die Applikation einzukompilieren. --- Schau dir auch mal die anderen Messages vom 1.11.2017 an.
Hallo Helmut, Danke erst mal aber das mit git und zip hatte ich 2 Postings weiter oben schon als gelöst markiert. git clone https://github.com/carrotIndustries/horizon.git ist also ein muss es ging dann etwas später mit weit aus seltsameren Fehlern weiter. Das mit Opencascade im Makefile CASROOT = /usr/lib64/opencascade-7.3.0 hab ich dannach auch noch gelößt, zwar etwas "NAJA" aber tut mal soweit ich denke dass es mit Gentoo Linux zusammenhängt und das make diverse Dinge nicht findet. https://github.com/carrotIndustries/horizon/issues/216
Helmut S. schrieb: > Beim Überfliegen von EAGLE, und KiCad bin auf microvias und buried vias > gestoßen. Ist das ein größerer Aufwand z. B. microvias zu > implementieren? > Ich gebe ja zu, dass ich mir nicht vorstellen kann so ein teures PCB mit > microvias und buried vias privat machen zu lassen. Ist aktuell weder vorgesehen noch geplant, eben weil sich keiner aus meiner Zielgruppe besondere Vias leisten kann/will.
Angehängte Dateien:
-
route-vom-via-geht-nicht.GIF
420 KB
Hallo Lukas, mir scheint das "routen" hin oder weg von vias auf den Innnelagen ist kaputt. Es gelingt mir nicht von diesem Via weg zu routen. Ich bin auf Lage 3. Das Via ist nicht im Grid. Das sollte aber kein Hindernis sein da weg zu routen. Umgekehrt von der Leitung zum Via klappt auch nicht. Die Leitung schnappt nicht auf das off-grid Via. Das ist übrigens dein Board an dem ich das gerade probiert habe. Noch zwei weitere Fragen. Mit welchem Grid hast du eigentlich die Vias gesetzt? Warum geht eigentlich kein Grid unter 0,1mm?
> Es gelingt mir nicht von diesem Via weg zu routen. Ich bin auf Lage 3.
Das Via ist nicht im Grid. Das sollte aber kein Hindernis sein da weg zu
routen.
Habe gerade nochmals probiert vom Via weg auf Lage 3 einen trace zu
starten. Inzwischen habe ich herausgefunden, dass ich dazu zusätzlich
Lage 1 anmachen muss. Dann komm ich von dem Via auch auf Lage 3 weg. Ich
denke so kann das aber nicht gedacht sein.
Helmut S. schrieb: > Ich > denke so kann das aber nicht gedacht sein. Ist repariert. Helmut S. schrieb: > Mit welchem Grid hast du eigentlich die Vias gesetzt? Das meiste auf einem 0.25 mm-Raster, durch copy/paste kann manches auch anders geraten sein. > Warum geht eigentlich kein Grid unter 0,1mm? Ist repariert.
Lukas K. schrieb: > Helmut S. schrieb: >> Ich >> denke so kann das aber nicht gedacht sein. > > Ist repariert. > > Helmut S. schrieb: >> Mit welchem Grid hast du eigentlich die Vias gesetzt? > > Das meiste auf einem 0.25 mm-Raster, durch copy/paste kann manches auch > anders geraten sein. > >> Warum geht eigentlich kein Grid unter 0,1mm? > > Ist repariert. Danke Lukas. Habe die beiden Punkte mit der neuesten Version getestet. Jetzt funktioniert das Programm so wie ich das erwartet hatte.
Ok ich hab ein Overlay für cppzmq gefunden und dann hat alles wunderbar geklappt
1 | layman -a cynede |
2 | emerge -s cppzmq |
3 | net-libs/cppzmq |
4 | Latest version available: 4.2.2 |
5 | Latest version installed: 0_pre150606 |
6 | Size of files: 11 KiB |
7 | Homepage: https://github.com/zeromq/cppzmq |
8 | Description: High-level CPP Binding for ZeroMQ |
9 | License: MIT |
Somit funktioniert unter Gentoo Linux
Sehr schön, kannst du die Schritte für gentoo nochmal kurz zusammenfassen, dass wir was für's Wiki haben?
Angehängte Dateien:
-
shot_18-12-10_225722.jpg
71 KB
Nach Anfangsproblemen unter Gentoo, nun fix und fertig kompiliert, und läuft. STM32L031 Part erstellt ... Schaut schon gut aus, zwar etwas gewöhnungsbedürftig, aber man findet schnell heraus wie es geht. Da bräuchte es einen Importfilter für Bauteile oder hab ich das nur bis jetzt übersehen.
unter Gentoo Installation wie folgt als root erst die standartpakete installieren
1 | emerge -uav sci-libs/opencascade dev-libs/libgit2 dev-libs/libgit2-glib app-eselect/eselect-opencascade media-libs/glm net-libs/zeromq dev-cpp/yaml-cpp |
und dann das Overlay von cynede für cppzmq einbinden (Voraussetzung ist: dass layman installiert und eingerichtet ist)
1 | layman -a cynede |
2 | layman -S |
3 | emerge -av cppzmq |
in */ ein Ordner erzeugen und über git clone alles herunterladen
1 | mkdir ./horizon |
2 | cd ./horizon |
3 | git clone https://github.com/carrotIndustries/horizon.git |
4 | cd ./horizon |
für Opencascade entsprechendes Verzeichnis im Makefile eintragen
1 | CASROOT = /usr/lib64/opencascade-7.3.0 |
dann horizon kompilieren
1 | make
|
ich hab viele packete u.a. STMCubeMX alles unter opt..
1 | mkdir /opt/horizon |
2 | cp horizon* /opt/horizon |
im Xterm # /opt/horizon/horizon-eda und geht
Achim M. schrieb: > Da bräuchte es einen Importfilter für Bauteile oder hab ich das nur bis > jetzt übersehen. Es gibt. https://github.com/carrotIndustries/horizon/blob/master/scripts/stm32_to_json.py Dem wirfst du die XML-Datei aus dem CubeMX hin, und importierst die JSON-Datei in den Part wizard, und zack hast du alle Pins mit all ihren Funktionen drin. Ist das matschige Fenster ein Gtk-Bug oder ein Feature deines Fenstermanagers?
Guten morgen, ich verfolge das Projekt mit dem größten Erstaunen. Respekt erstmal an die abartige Leistung, die Du hier bisher erbracht hast. Sowas braucht in vielen Buden eine ganze Schaar von Entwicklern, die dann in sinnlosen Scrum-Meetings eine dumme Idee nach der anderen zum Nonplus-ultra hochkochen :-) Jetzt meine Frage an die Tester und Dich: Wie sinnvoll ist das Programm produktiv einsetzbar? Riskiert man nach wie vor, dass mit dem nächsten Versionssprung Projekte nicht mehr kompatibel sind? Und wie sieht es mit Bugs aus? Läuft das alles soweit stabil? Ich habe nur eine Eagle 5 Lizenz und mich nervt das Programm enorm. Bevor ich jetzt dreimal umsteige, würde ich gerne mal Deines probieren. Dann aber mit der Hoffnung, dass man auch zum Ziel kommt :-)
Martin S. schrieb: > Jetzt meine Frage an die Tester und Dich: Wie sinnvoll ist das Programm > produktiv einsetzbar? Für kleine bis mittelgroße Projekte durchaus, ich habe das Board für meine Masterabeit damit gemacht: https://github.com/carrotIndustries/x-band-tx Bei mit vielen Bauteilen (wie eben meine Masterarbeit mit über 250) ruckelt es bei einigen Tools ein bisschen, aber nichts was unerträglich wäre. Kannst ja einfach mal das Projekt aufmachen und gucken, wie so deine Empfindung ist. > Riskiert man nach wie vor, dass mit dem nächsten > Versionssprung Projekte nicht mehr kompatibel sind? Alles wesentliche ist mittlerweile gut festgezurrt und wird sich auf absehbare Zeit nicht großartig ändern. Wenn sich doch mal was ändert, bleiben alte Dateien nachwievor verwendbar und werden beim nächsten Speichern mit den neuen Eigenschaften gespeichert. > Und wie sieht es mit > Bugs aus? Läuft das alles soweit stabil? Wie du im Thread hier lesen kannst lauern durchaus noch einige Bugs, aber nichts was wirkliche showstopper wären. Manche Dinge, wie z.B. durchsuchbare Schaltpläne oder Bestückungspläne exportieren gibt's aktuell schlicht noch nicht, weil's noch keinem wichtig genug war.
Lukas K. schrieb: > Achim M. schrieb: >> Da bräuchte es einen Importfilter für Bauteile oder hab ich das nur bis >> jetzt übersehen. > > Es gibt. > https://github.com/carrotIndustries/horizon/blob/master/scripts/stm32_to_json.py > > Dem wirfst du die XML-Datei aus dem CubeMX hin, und importierst die > JSON-Datei in den Part wizard, und zack hast du alle Pins mit all ihren > Funktionen drin. Danke werde ich mal ausprobieren. > Ist das matschige Fenster ein Gtk-Bug oder ein Feature deines > Fenstermanagers? Hm also normal ist es nicht, hatte das bisher bei noch keinem Program. Eventuell ein Feature von GTK sobald man aber mit der Maus drüber geht wird es wieder scharf.. GRINS Aber wie gesagt alle meine sonstigen Programme von Office bis Quartus, Gimp und co funktionieren ohne dieses Feature.
Martin S. schrieb: > Jetzt meine Frage an die Tester und Dich: Wie sinnvoll ist das Programm > produktiv einsetzbar? Den Bauteil-Pool finde ich insgesamt noch etwas dünn gesät (und das, obwohl ich da als einstmaliger BAE-Nutzer wahrlich nicht verwöhnt war ;). Du wirst dich also darauf einstellen müssen, doch deutlich mehr Bauteile als bei Eagle (wo gefühlt jeder zweite im Forum "Wer hat das?" fragt, statt ein Bauteil selbst anzulegen) selbst zu zimmern. Zum deinem Trost :), kommerziell ist es völlig üblich, dass jeder sowieso nur seine eigenen Bauteile benutzt, dann weiß man wenigstens, wer Schuld war, wenn der Footprint am Ende nicht passt … Lukas K. schrieb: > Wie du im Thread hier lesen kannst lauern durchaus noch einige Bugs, > aber nichts was wirkliche showstopper wären. Würde ich so unterschreiben – auch, wenn ich es bislang noch nicht für ein produktives Projekt genutzt habe.
*Bauteil-Pool:* dazu mal folgender Gedanke Eine von Usern erstellte gemeinsame Datenbank mit n*verifiziert n*verifiziert insofern, wenn da 3,4 oder mehr verifiziert haben, kann man davon ausgehen, dass alles stimmt.
Ich bin Maschinenbauing und habe meine Platinen bisher in Inventor gemacht, als dxf exportiert und dann über CAM auf die Fräsmaschine. Ich habe schon lange vor mich in ein E-CAD einzufuchsen. Ich lese diesen Faden seit Anfang an ab und zu mit (auf dem 34C3 habe ich auch kurz mal mit Lukas gesprochen). Wenn hier alle so begeistert sind und in Horizon eine Zukunft sehen, nehme ich am besten gleich das ganz neue und bin dann für die Zukunft gerüstet. Dieser Beitrag hat bisher keinen Mehrwert für diesen Faden, wollte ich aber mal sagen.
Paul A. schrieb: > dann über CAM auf die Fräsmaschine. Wenn du die Platinen weiterhin fräsen willst, ist das allerdings eher eine sehr spezielle Variante, für die die meisten EDA-Systeme nicht sonderlich gut gerüstet sind. Wenn du sie natürlich selbst ätzen oder fertigen lassen willst, dann nur zu. Derzeit würde ich persönlich Kicad noch für die insgesamt „rundere“ Lösung halten, aber da spielt einerseit mit rein, dass Horizon bislang nur recht wenige Bauteile fertig im Pool hat (schrieb ich schon mal), andererseits natürlich, dass ich mit Kicad mittlerweile schon einiges an Routine habe. Wenn du neu anfängst, entfällt letzteres jedoch für dich. Horizon hat meiner Meinung nach auf jeden Fall mehr Potenzial, da Lukas versucht hat, aus den Fehlern u.a. auch von Kicad zu lernen.
Lukas K. schrieb: > aber nichts was wirkliche showstopper wären Ich hab neulich wieder einen Versuch (2018-12-04-2032) auf meinem TP530 mit Windows 7 unternommen - und bin erneut an der Grafik gescheitert. Meine Vermutung: das Thinkpad hat - wie viele andere Notebooks auch - eine Hybrid-Grafikausstattung, beim TP530 sind das: * Intel HDG 4000 - für einfache Anwendungen * NVidia NVS 5400M - wenn's etwas anspruchsvoller wird Horizon sollte doch mit der NVS5400M zurechtkommen? Wenn ich es richtig verstanden, erfolgt die Treiberumschaltung zwischen den beiden Grafikarten - für den Benutzer transparent - durch die jeweilige Anwendung. Das scheint bei Horizon nicht zu passieren; Symbole lassen sich zwar im Schaltplan platzieren, bleiben aber im Einheitsgrau der Arbeitsfläche verborgen.
Burkhard K. schrieb: > Lukas K. schrieb: >> aber nichts was wirkliche showstopper wären > > Ich hab neulich wieder einen Versuch (2018-12-04-2032) auf meinem TP530 > mit Windows 7 unternommen - und bin erneut an der Grafik gescheitert. > > Meine Vermutung: das Thinkpad hat - wie viele andere Notebooks auch - > eine Hybrid-Grafikausstattung, beim TP530 sind das: > * Intel HDG 4000 - für einfache Anwendungen > * NVidia NVS 5400M - wenn's etwas anspruchsvoller wird > > Horizon sollte doch mit der NVS5400M zurechtkommen? Die "unterste" bisher bestätigte(mir bekannte) Grafikkarte auf der horizon läuft ist eine GTX560. Du könntest ja mal mit Rechtsklick in leerem Bereich des Bildschirms Anzeigeinstellungen -> Erweiterte Anzeigeeinstellungen -> Anzeigeinformationen nachschauen welche Grafikkarte verwendet wird. Bei meinem Laptop steht da z. B. "Bildschirm1: mit NVIDIA GeForce GTX1060 verbunden".
Angehängte Dateien:
-
horizon-grey.png
110 KB
Helmut S. schrieb: > Anzeigeinstellungen -> Erweiterte Anzeigeeinstellungen -> > Anzeigeinformationen > > nachschauen welche Grafikkarte verwendet wird. Bei Rechtsklick (Schematic Editor) passiert gar nichts. KiCad fragt beim Öffnen des Boardeditors nach, ob die Grafikkarte verwendet werden soll, bei Horizon gab/gibt es keine solche Nachfrage. Helmut S. schrieb: > Die "unterste" bisher bestätigte(mir bekannte) Grafikkarte auf der > horizon läuft ist eine GTX560. Wo finde ich die Anforderungen dokumentiert? Die 540 unterstützt: DirectX 11 Shader 5.0 OpenGl 4.0
Burkhard K. schrieb: > Helmut S. schrieb: >> Anzeigeinstellungen -> Erweiterte Anzeigeeinstellungen -> >> Anzeigeinformationen >> >> nachschauen welche Grafikkarte verwendet wird. > > Bei Rechtsklick (Schematic Editor) passiert gar nichts. > > KiCad fragt beim Öffnen des Boardeditors nach, ob die Grafikkarte > verwendet werden soll, bei Horizon gab/gibt es keine solche Nachfrage. > > Helmut S. schrieb: >> Die "unterste" bisher bestätigte(mir bekannte) Grafikkarte auf der >> horizon läuft ist eine GTX560. > > Wo finde ich die Anforderungen dokumentiert? Die 540 unterstützt: > DirectX 11 > Shader 5.0 > OpenGl 4.0 Vielleicht wär das ja mal ein Vorschlag an Lukas so eine Abfrage bezüglich der GraKa einzubauen. Mein Wissensstand ist, dass nur OpenGL verwendet wird. Irgendwie habe ich im Kopf, dass neulich nicht mehr nur von Version 3.2 sondern von 4.0 die Rede war. Wenn horizon nicht ging, dann lag es eigentlich immer an der "zu alten" Grafikkarte.
Burkhard K. schrieb: > KiCad fragt beim Öffnen des Boardeditors nach, ob die Grafikkarte > verwendet werden soll, bei Horizon gab/gibt es keine solche Nachfrage. Horizon rendert entweder mit OpenGL oder gar nicht. Siehe dazu auch weiter oben im Thread. Dass der Bereich grau bleibt, sieht mir jetzt erstmal danach aus, dass Gtk es nicht schafft den OpenGL-Kontext hinzubekommen. Wenn du horizon aus der mingw-shell startest, bekommst du auch Ausgabe von Gtk, weshalb das nicht geklappt hat.
Lukas K. schrieb: > Wenn du horizon > aus der mingw-shell startest, bekommst du auch Ausgabe von Gtk, weshalb > das nicht geklappt hat. MinGW hab ich nicht installiert - gibt es eine andere Möglichkeit herauszufinden, was schiefgeht? BTW: Interessanterweise bekomme ich einen Crash beim Schliessen von Horizon: Pfad der fehlerhaften Anwendung: C:\Users\buk\EDA\horizon-pool-master\Horizon\horizon-eda.exe Pfad des fehlerhaften Moduls: C:\Windows\system32\ig7icd64.dll ig7icd64 gehört zum Intel Graphics Driver - also zur Prozessorgraphik. (Wobei auch diese OpenGL 4.0 unterstützt.)
Wenn du selber kompilierst, hast du automatisch Mingw. Dazu MSYS2 installieren. Die Anleitung dazu gibt es auf der Webseite von Lukas. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows Achtung, je nach Schnelligkeit deiner Internetverbindung kann sich die Installation ziemlich hinziehen. Dann gitclone und kompileren. Das Programm aus dem Terminal von MSYS2 heraus starten. ./horizon_eda.exe In dem Verzeichnis in dem horizon-eda.exe liegt muss auch eine Datei "ca-bundle.crt" sein damit das herunterladen und updaten des Pools funtioniert. Das steht aber auch am Ende der obigen Anleitung. Das kompilieren dauert auf einem Q6700K 4GHz 4 cores +hyperthreading weniger als 6Minuten. Achtung, das Installationserzeichnis "mysys64" belegt 4GB und das Verzeichnis in dem kompiliert wird belegt nochmals 2,5GB.
Helmut S. schrieb: > Wenn du selber kompilierst, hast du automatisch Mingw. > Dazu MSYS2 installieren. Danke, aber 4 GB MinGW/Msys64 Geraffel, nur um herauszufinden, dass es bei mir sowieso nicht läuft? Nicht gerade motivierend.
Burkhard K. schrieb: >> Wenn du horizon >> aus der mingw-shell startest, bekommst du auch Ausgabe von Gtk, weshalb >> das nicht geklappt hat. > > MinGW hab ich nicht installiert - gibt es eine andere Möglichkeit > herauszufinden, was schiefgeht? Müsstest du auch sehen, wenn du es von cmd.exe aus startest. Kann man auch dort in eine Datei umlenken:
1 | horizon-eda 2> logfile.txt |
Jörg W. schrieb: > Burkhard K. schrieb: >>> Wenn du horizon >>> aus der mingw-shell startest, bekommst du auch Ausgabe von Gtk, weshalb >>> das nicht geklappt hat. >> >> MinGW hab ich nicht installiert - gibt es eine andere Möglichkeit >> herauszufinden, was schiefgeht? > > Müsstest du auch sehen, wenn du es von cmd.exe aus startest. > > Kann man auch dort in eine Datei umlenken: > >
1 | horizon-eda 2> logfile.txt |
Ich habe es gerade mal ausprobiert. In dem cmd-Window werden keine Debug-Informationen angezeigt und auch der logfile.txt bleibt leer. Wenn man horizon-eda.exe aus dem MSYS2-Terminal startet, dann gibt es einen Debug output. Wenn man den Output nicht einen File umleitet, dann erscheint der Debug-Text im Terminal was ja auch OK ist. $ horizon-eda.exe Fazit: Man muss nicht selbst kompilieren, aber man muss MSYS2 installieren, wenn man den Debug-Output sehen will.
Hallo Burkhard, Ich korrigiere meine Aussage bezüglich geht nicht in cmd.exe. Es sieht so aus, dass zumindest etwas geschrieben wird, wenn man den Ausgabekanal 1 nimmt. Damit war Joerg's Tipp ja fast richtig. cmd.exe starten. Im Terminal zu dem horizon-Ordner wechseln. cd .... horizon-eda.exe 1> logfile.txt
Helmut S. schrieb: > horizon-eda.exe 1> logfile.txt besser: horizon-eda.exe > logfile.txt 2>&1 für anhängen > ersetzen durch >>
Helmut S. schrieb: > wenn man den Ausgabekanal 1 nimmt Gut, damit hatte ich jetzt nicht gerechnet, dass Lukas die Debug-Ausgaben auf stdout schreibt. Ich hätte sie auf stderr erwartet (hatte es aber bei mir auch nicht kontrolliert).
Jörg W. schrieb: > Helmut S. schrieb: >> wenn man den Ausgabekanal 1 nimmt > > Gut, damit hatte ich jetzt nicht gerechnet, dass Lukas die > Debug-Ausgaben auf stdout schreibt. Ich hätte sie auf stderr erwartet > (hatte es aber bei mir auch nicht kontrolliert). Hallo, Ich weiß natürlich nicht ob da auch noch Meldungen im Fehlerfall auf 2 kommen. Am besten beides speichern. cmd.exe starten und darin horizon-eda. horizon-eda.exe 1>log1.txt 2>log2.txt In log1.txt sehe ich z. B. beim Öffnen des Layouts folgendes. SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, tags_view.tags, parts.filename, parts.description, parts.pool_uuid, parts.overridden FROM parts LEFT JOIN tags_view 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 spawn D:\horizon\horizon\horizon-imp -b D:\horizon\prj_helmut2\RC-Osc1\board.json D:\horizon\prj_helmut2\RC-Osc1\top_block.json D:\horizon\prj_helmut2\RC-Osc1\vias rebuild took 0.018 render took 333.333 end proc 0x984 close
IIRC sind die Treiber für die Intel HD 4000 nicht die besten, wahrscheinlich hast du das selbe Problem wie Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm"
Angehängte Dateien:
-
diff_width.GIF
130 KB
Hallo Lukas, Ich teste an deinem TX-board und wundere mich gerade warum diff-traces auf top 0,2mm breit werden, obwohl das nirgens steht. Im setting steht typisch 0,36mm. Von 0,2mm steht da nichts. Wenn ich die neu ziehe, kommen die automatisch mit 0,2mm. Ich zweifle gerade, ob die Rules richtig bzw. überhaupt verwendet werden. Wo werden die 0,2mm Breite der diff-pairs tatsächlich gesetzt? Wo wird der Abstand der diff-pairs tatsächlich gesetzt? Gruß Helmut
Helmut S. schrieb: > Wo werden die 0,2mm Breite der diff-pairs tatsächlich gesetzt? > > Wo wird der Abstand der diff-pairs tatsächlich gesetzt? Guck' mal in der Ecke links unten ;) Unabhängig davon noch: 2019 bin ich auch wieder auf der FOSDEM: https://fosdem.org/2019/schedule/event/horizon/
Angehängte Dateien:
-
diff_usb_300.GIF
52 KB -
diff_100diff_is_200.GIF
54 KB
Lukas K. schrieb: > Helmut S. schrieb: >> Wo werden die 0,2mm Breite der diff-pairs tatsächlich gesetzt? >> >> Wo wird der Abstand der diff-pairs tatsächlich gesetzt? > > Guck' mal in der Ecke links unten Hallo Lukas, danke für die Info. Dieses Menü hatte ich hatte ich nicht erwartet und deshalb wohl übersehen. Jetzt bin ich in dem Rules->Diffpair Dialogfenster auf einen Fehler gestoßen. Wenn ich die "Net class: usb" auf 300um setze und "Apply rules" mache, gelten die 300um für "usb". Dann verlase ich das Fenster. Die "Net class: diff100" hat danach beim routen weiterhin die 200um was ja OK ist. Wenn ich dann aber wieder das Rules->Diffpair Dialogfenster aufmache und auf "Net class: diff100" umschalte, dann werden dort auch die 300um von "usb" angezeigt obwohl das Layout richtigerweise weiterhin mit 200um routet. Ich bekomme die 200um aber nie mehr richtig in dem Rules->Diffpair Dialogfenster angezeigt. Da fehlt ein Dialogfenster-update-Aufruf beim umschalten der "Net class" in diesem Rules->Diffpair Dialogfenster. Bitte prüfe das mal. > 2019 bin ich auch wieder auf der FOSDEM: > https://fosdem.org/2019/schedule/event/horizon/ Danke, da haben wir ja gleich die Chance auf ein "Help" mittels Videoaufzeichnung. Hoffen wir, dass die Video- und Tonaufzeichnung gleich richtig klappt. :-)
Ich glaube, du wirfst da Dinge durcheinander: Die Regeln bei horizon funktionieren grundsätzlich so: Um rauszufinden welche Regel zutrifft, werden alle Regeln des entsprechenden Typs von oben nach unten abgearbeitet und die erste Regel genommen, die Zutrifft (im Falle der Diffpairs also die Netzklasse passt). Wenn keine Regel zutrifft, wird eine Default-Regel genommen. Auf die sollte man sich aber nicht verlassen, die ist primär dazu da, zu verhindern, dass der Code danach segfaultet. Wenn du also sowohl für USB also auch für 100diff Diffpair-Regeln haben willst, musst du dir mit dem + unten links eine neue Regel anlegen und dort die entsprechende Netzklasse eintragen. Die 0.2mm, die du beobachtet hast, sind Einstellung der default-Regel.
Angehängte Dateien:
-
unknown_key_sequence.PNG
47 KB
Hallo Lukas, ich komme ja con Xpedition. Da dachte ich, dass das hier ähnlich ist. Ich versuche mal umzudenken. Ich habe mehrere Rechner. Gestern wollte ich mal wieder an meinem besten Rechner mit horizon arbeiten und musste feststellen, dass die Bedienung des Schaltplanes und des Layouts nicht mehr funktionieren. Ich habe dann erfolglos alles mögliche versucht um das Problem einzukreisen. Selbst der Tausch der Grafikkarte von einem Rechner der dieses Problem nicht hat hat nicht geholfen. Alle Rechner haben WIN10 mit der neuesten Version. Wenn ich auf oben "Help" klicke, dann geht ein leeres Fenster auf, siehe screenshot. Wenn ich eine Taste drücke und den Fokus im Layoutfenster habe, dann kommt immer "Unknown key sequence" in der Stauszeile ganz unten. Auch ältere Versionen von horizon zeigen jetzt auf den 2 Rechnern das gleiche Problem. Von 5 Desktop Rechnern mit WIN10 haben zwei dieses Problem. Verwendet horizon dlls die von anderen Programmen eventuell überschrieben wurden? Hat jemand irgend eine Idee an was das liegen könnte?
> Hat jemand irgend eine Idee an was das liegen könnte?
Hatte ich auch schon mal. Einfach die .config oder so löschen, und da
lief es.
neuer PIC Freund schrieb im Beitrag #5669335: >> Hat jemand irgend eine Idee an was das liegen könnte? > > Hatte ich auch schon mal. Einfach die .config oder so löschen, und da > lief es. Welche .config meinst du?
Ah, da ist wohl beim automatischen Migrieren der Config auf die neue Version was schief gelaufen und alle Tastenkürzel sind verloren gegangen. Ist seit gerade repariert. Damit die Config nochmal neu migriert wird, muss man folgendes Tun: - Schließe alle Instanzen von horizon - In %LOCALAPPDATA%\horizon, lösche die prefs.json - Beim nächsten Start wird die config neu migriert
Lukas K. schrieb: > Ah, da ist wohl beim automatischen Migrieren der Config auf die neue > Version was schief gelaufen und alle Tastenkürzel sind verloren > gegangen. Ist seit gerade repariert. > > Damit die Config nochmal neu migriert wird, muss man folgendes Tun: > > - Schließe alle Instanzen von horizon > - In %LOCALAPPDATA%\horizon, lösche die prefs.json > - Beim nächsten Start wird die config neu migriert Danke, ja das war es. Das Verzeichnis heißt genaugenommen C:\Users\username\AppData\Local\horizon Hab einfach alle Dateien in dem Verzeichnis gelöscht und dann horizon gestartet. Jetzt funktioniert es wieder auf beiden Rechnern.
Wie auch letztes Jahr bin ich auch dieses Jahr wieder aufm Congress: https://events.ccc.de/congress/2018/wiki/index.php/Projects:Horizon_EDA
Lukas K. schrieb: > Wie auch letztes Jahr bin ich auch dieses Jahr wieder aufm Congress: > https://events.ccc.de/congress/2018/wiki/index.php/Projects:Horizon_EDA Das wird doch hoffentlich auch aufgezeichnet oder kann man das nur "life" anschauen?
Helmut S. schrieb: > In log1.txt sehe ich z. B. beim Öffnen des Layouts folgendes. Auf STDERR kommt zighundermal: (horizon-imp.exe:7308): Gtk-WARNING **: 11:36:14.142: fb setup not supported (horizon-imp.exe:7308): Gtk-WARNING **: 11:36:14.265: fb setup not supported Im Logfile steht im Wesentlich nicht mehr als: col 2 spawn <$HOME>\EDA\horizon-pool-master\Horizon\horizon-imp -c <$HOME>\EDA\horizon-pool-master\HP-Dummy\dummy\top_sch.json <$HOME>\EDA\horizon-pool-master\HP-Dummy\dummy\top_block.json imp rx false imp rx null tool add part imp rx null imp rx false imp rx null imp rx false ... Gibt es spezifische GTK-Debug Flags für den Framebuffer?
Burkhard K. schrieb: > (horizon-imp.exe:7308): Gtk-WARNING **: 11:36:14.265: fb setup not > supported Das ist der bug hier: https://gitlab.gnome.org/GNOME/gtk/issues/1003 Liegt scheinbar an unzulänglichen Treibern und bis jetzt hat sich noch keiner die Mühe gemacht, dem weiter auf den Grund zu gehen...
Hallo Lukas, im Schaltplan gibt es ein "Set pins NC" aber kein "Clear pins NC". Stattdessen gibt es bis jetzt nur ein "Clear all pins NC". Das löscht alle NC an einem Symbol. Wenn man jetzt nur einen der NC-pins benutzen will, dann muss man alle mit "Clear all Pins NC" löschen und dann an alle anderen pins wieder NC vergeben. Ds scheint mir sehr umständlich zu sein. Übersehe ich irgend eine Funktion? Helmut
Helmut S. schrieb: > Hallo Lukas, > > im Schaltplan gibt es ein "Set pins NC" aber kein "Clear pins NC". > Stattdessen gibt es bis jetzt nur ein "Clear all pins NC". Das löscht > alle NC an einem Symbol. Wenn man jetzt nur einen der NC-pins benutzen > will, dann muss man alle mit "Clear all Pins NC" löschen und dann an > alle anderen pins wieder NC vergeben. Ds scheint mir sehr umständlich zu > sein. > Übersehe ich irgend eine Funktion? > > Helmut Hallo Lukas, danke für die Implementierung von "Clear pins NC". EIgentlich wollte ich ja die neueste Version von horizon mit dieser neuen Funktion von Appveyor herunterladen aber dort ist nur die Version vom 5. Januar. Offenbar wird Appveyor nicht mehr richtig ausgeführt. Ich habe es dann selber kompiliert. "Clear pins NC" funktioniert wie gewünscht. Helmut
> Helmut S. schrieb > Eigentlich wollte ich > ja die neueste Version von horizon mit dieser neuen Funktion von > Appveyor herunterladen aber dort ist nur die Version vom 5. Januar. > Offenbar wird Appveyor nicht mehr richtig ausgeführt. Hallo Lukas, horizon in Appveyor ist wieder auf dem neuesten Stand. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Helmut
Angehängte Dateien:
-
de_locale.GIF
320 KB
Hallo Lukas, ich schaue mir ja immer die commits an um zu sehen was es Neues gibt. 1. add layer help Wo kann man im Programm den Inhalt von Layer help anzeigen? Irgend einen Sinn muss es doch haben. 1 .gitignore @@ -30,3 +30,4 @@ dist docs */__pycache__ src/preferences/color_presets.json src/imp/layer_help.json 1 Makefile @@ -343,6 +343,7 @@ SRC_IMP = \ src/export_bom/export_bom.cpp\ src/widgets/unplaced_box.cpp\ src/widgets/tag_entry.cpp\ src/widgets/layer_help_box.cpp\ 2. fix parametric values for DE locale Was wurde da "fixed"? Im screenshot sehe ich einen Mix aus "." und ",". Siehe "Parameter"-Fenster. Warum eigentlich nicht konsequent "." als Trenner nehmen egal welche Spracheinstellung man hat. Matheprogramme, Xpedition und LTspice kennen auch kein "," und alle Anwender sind glücklich damit. Helmut
Angehängte Dateien:
Helmut S. schrieb: > 1. > add layer help > Wo kann man im Programm den Inhalt von Layer help anzeigen? > Irgend einen Sinn muss es doch haben. Dafür brauchst du einen aktuellen Pool, allerdings werden die dafür notwendigen Dateien aktuell noch nicht vom Pool manager heruntergeladen. Die Taucht dann im Package-Editor auf. Helmut S. schrieb: > 2. fix parametric values for DE locale > Was wurde da "fixed"? > Im screenshot sehe ich einen Mix aus "." und ",". Siehe > "Parameter"-Fenster. Parametric ist in dem Fall bezogen auf die neuen parametrische Suchfunktion, siehe Anhang. Damit die funktioniert braucht's im Pool die tables.json. Auch die wird aktuell nicht automatisch aktualisiert. Helmut S. schrieb: > Warum eigentlich nicht konsequent "." als Trenner nehmen egal welche > Spracheinstellung man hat. Matheprogramme, Xpedition und LTspice kennen > auch kein "," und alle Anwender sind glücklich damit. Die machen es m.E. nach falsch, die Spracheinstellungen des Betriebssystems sind dazu da, soweit wie möglich von Programmen befolgt zu werden. Im Parameterprogramm wird . verwendet, da diese Unabhängig von der Spracheinstellung sein sollen. Und noch was: FOSDEM ist dieses Wochenende, ich bin auch wieder dabei: https://fosdem.org/2019/schedule/event/horizon/
Danke Lukas, alles klar. Dann versuche ich mal mein Glück mit dem Layer-help. Ich werde am Sonntag deinen Vortrag auf der FOSDEM online verfolgen. Hoffentlich funktioiniert die Kamera und das Mikro.
Hallo, die Videoaufzeichnung von dem Vortrag von Lukas über horizon ist jetzt verfügbar. https://video.fosdem.org/2019/AW1.125/ Lukas hat dort davon gesprochen, dass der Stand jetzt die Version 1.0 ist/wird.
Michel M. schrieb: > ist doch der selbe ?! > http://bofh.nikhef.nl/events/FOSDEM/2019/AW1.125/horizon.webm Ja. Da scheint wohl jemand "privat" die Videos von der FOSDEM zu hosten.
Scheinbar eine "Sicherheitskopie" Hier gibt es die vollständige Liste nochmal von FOSDEM :-) https://fosdem.org/2019/schedule/events/
Roland schrieb: > Der Build benötigt gute 2GB freien Plattenplatz, das sollte man im > voraus wissen, bitte einen Hinweis dokumentieren. Ich würde mal sagen, dass die meisten Rechner, die für CAD und SW-Entwicklung genutzt werden, die lumpigen 2GB frei haben sollen. Ein Build für ein Win32/64-Programm und C# oder klassischer Win API braucht eher mal gerne das Doppelte, teilweise für echt mickrige Pakete und Libs.
Angehängte Dateien:
Hallo Lukas, isr dir aufgefallen, dass mit deinem deinem letzten commit die Generierung der .exe für Windows fehlgeschlagen hat? Wenn man versucht selber für Windows zu kompilieren, dann kommt eine Fehlermeldung. Siehe Anhang. Was macht eigentlich dieser Dispatcher für den Anwender? Helmut
Angehängte Dateien:
-
QFN_Package.png
51 KB
Hallo zusammen. Ich habe mir vor kurzem horizon kompiliert und bin dabei die Software kennenzulernen. Gibt es eine Möglichkeit, auf einem Pad eines Packages ThermalVias einzufügen (siehe angehängtes Bild)? Da ich am Ende des kennenlernen ein PCB haben möchte, bräuchte ich dies. Gruss silsi
Ob man ohne zusätzliche Pins im Symbol extra Vias in das Pad machen kann weiß ich nicht. Normalerweise setzt man die Vias im PCB-Layout in das Pad. Dort ist es überhaupt kein Problem. Siehe auch das Projekt X-Band Transmitter von Lukas. Lukas kann die Frage sicher auf Anhieb beantworten. Ich hoffe er liest hier mit.
Helmut S. schrieb: > Normalerweise setzt man die Vias im PCB-Layout in das Pad. Dort ist es > überhaupt kein Problem. Siehe auch das Projekt X-Band Transmitter von > Lukas. Genau das ist auch der bevorzugte weg, so hat man im Board die größten Freiheiten. Wenn du die wirklich im Package haben willst, musst du dir einen eigenen Padstack mit den entsprechenden Löchern und Pads anlegen.
Ich habe mir (mal wieder) einen aktuellen Build von horizon erstellt. Danach wollte ich einen CAD Frame A4 L im Schematic einfügen. Im Pool sind ja welche vorhanden, nur, wie kann ich diese einfügen?
Angehängte Dateien:
-
add_frame_1.JPG
150 KB -
add_frame_2.JPG
61 KB
tester schrieb: > Ich habe mir (mal wieder) einen aktuellen Build von horizon erstellt. > Danach wollte ich einen CAD Frame A4 L im Schematic einfügen. Im Pool > sind ja welche vorhanden, nur, wie kann ich diese einfügen? Entweder im Hamburger Menü "Schematic Properties" oder über die Leertaste in der Befehlsauswahl "Edit Schematic Properties wählen". In dem Fenster das dann aufgeht auf den Wert "none" bei Frame klicken. Damit geht ein weiteres Fenster auf in dem man dann den Rahmen wählt. Die Einstellungen die man dann vornimmt gelten für die gerade angewählte Seite.
Hallo Lukas, ist das hier noch der angesagte Ort um Fragen zu Horizon zu stellen oder gibt es mittlerweile etwas (möglicherweise) englischsprachiges an anderer Stelle? Ich würde gerne das Debian-Paket horizon-eda weiter betreuen und da tritt schonmal die eine oder andere spezielle Frage auf. Uwe
Uwe S. schrieb: > ist das hier noch der angesagte Ort um Fragen zu Horizon zu stellen oder > gibt es mittlerweile etwas (möglicherweise) englischsprachiges an > anderer Stelle? Es gibt den Thread hier, einen im EEVBlog-Forum, github issues und den IRC-Channel auf freenode. Wo die Frage eingeworfen wird ist mir eigentlich recht egal, nur die issues auf github sollten nicht für allgemeine Fragen zur Benutzung verwendet werden. > Ich würde gerne das Debian-Paket horizon-eda weiter betreuen und da > tritt schonmal die eine oder andere spezielle Frage auf. Nur zu!
Akut stellt sich die Frage, ob es in absehbarer Zeit eine Version 1.x gebeben wird? Hintergrund ist die etwas unglückliche Vergabe einer Version 0.2019xxxx für das aktuelle Debian-Paket. Würde man jetzt ein Paket mit der Version 0.9.2 hochladen, dann wäre dies in der Sortierung nach Versionsnummer kleiner als das alte Paket. Erst mit 1.x ändert sich das wieder. Das Problem ließe sich in Debian mit Epochen lösen, man müsste den Weg aber nicht gehen, wenn demnächst 1.x veröffentlich würde. Bis dahin würde ich dann bei der 0.2019xxxxx Numerierung bleiben. Uwe
Uwe S. schrieb: > Akut stellt sich die Frage, ob es in absehbarer Zeit eine Version 1.x > gebeben wird? Gute Frage, spätestens bis zur nächsten FOSDEM ende Januar 2020 sollte es Version 1.0 geben. Dennoch wäre es gut, wenn man das Packaging vor 1.0 am laufen hätte. Würde dazu ein Release mit der Version 0.9000 helfen?
0.9000 würde nicht reichen, weil wir zur Zeit 0.20191118 haben. Da Debian die Version an den '.' teilt und dann numerisch vergleicht, müsste es 0.90000000 sein. Damit solltest du nicht anfangen! Dann bleibe ich besser beim Datum und warte auf die 1.x. Zumal das nächste stabile Debian noch einige Zeit braucht und bis dahin bist du bestimmt bei 1.0 ... sag ich mal so.
Lukas K. schrieb: > Gute Frage, spätestens bis zur nächsten FOSDEM ende Januar 2020 sollte > es Version 1.0 geben. Ich bin gespannt, dann werde ich die Software auch mal testen :) KiCad hat mir bisher noch nicht zugesagt und vom Adler mit dem Abo-Modell will ich schnellstmöglich weg. Auf jeden Fall Respekt für die Arbeit und Ausdauer, die du in das Projekt investierst!
Lass dich von der Version <1.0 nicht abschrecken. Auch jetzt lässt sich schon gut arbeiten. Und falls jemand die Debian-Pakete ausprobieren möchte https://www.steinmann.cx/horizon-eda/
Julian W. schrieb: > Ich bin gespannt, dann werde ich die Software auch mal testen Allzu viel an der Funktion wird sich bis 1.0 nicht mehr ändern. Der Fokus liegt für hauptsächlich auf einer besseren Website (https://horizon-eda.org/ ist aktuell nur ein Platzhalter) und aktualisiertem "sales pitch" https://horizon-eda.readthedocs.io/en/latest/feature-overview.html
Hallo Lukas, der git snapshot von gestern Abend ist jetzt zu Debian hochgeladen und wird gebaut. https://buildd.debian.org/status/package.php?p=horizon-eda&suite=sid
Respekt! Das finde ich super auch wenn ich es nicht probieren kann. Einmal Zeitmangel und ich befürchte, dass das Linux-exklusiv ist? Leider bin ich ein ignorantes Dummerchen und das ist eine (zu) große Einstiegshürde ;-) Auf der Homepage scheint es mir so, als ob du dich beim Bauteile erstellen etwas von Eagle hast inspirieren lassen? Jetzt nur rein oberflächlich gesichtet bin ich wirklich beeindruckt was man erschaffen kann.
Zoidberg schrieb: > Respekt! > Das finde ich super auch wenn ich es nicht probieren kann. Einmal > Zeitmangel und ich befürchte, dass das Linux-exklusiv ist? Es gibt eine fertige Version für Windows. https://horizon-eda.readthedocs.io/en/latest/installation.html Die wird sogar automatisch bei jeder Änderung der "sourcen" neu kompliert.
Hab's vorher auf meinem Notebook unter Windows getestet, das OpenGL Fenster fehlt. Ansonsten hab mir das Youtube Video angesehen, alle Achtung! Werd's vielleicht n anderes mal auf Linux testen.
Uwe S. schrieb: > Hallo Lukas, > > der git snapshot von gestern Abend ist jetzt zu Debian hochgeladen und > wird gebaut. > > https://buildd.debian.org/status/package.php?p=horizon-eda&suite=sid Ich habe Horizon in Debian10 über Synapse installiert. Funktioniert aber nicht, die Verzeichnisse /usr/bin/horzion... gibt es nicht. kann nichts starten. Christian
Hallo Christian, du arbeitest also mit Debian sid? Ein Verzeichnis /usr/bin/horizon... gibt es auch nicht, aber in /usr/bin sollte horizon-eda existieren. Was liefert denn
1 | dpkg -L horizon-eda |
Uwe
Uwe S. schrieb: > Hallo Christian, > > du arbeitest also mit Debian sid? Ein Verzeichnis /usr/bin/horizon... > gibt es auch nicht, aber in /usr/bin sollte horizon-eda existieren. > > Was liefert denn
1 | dpkg -L horizon-eda |
> > Uwe Ich arbeite mit Debian Buster und KDE. Als Menüeintrag in KDE ist "Horizon EDA Application" und "Horizon EDA Pool manager" vorhanden. Wenn ich da drauf klicke kommt die Fehlermeldung "Programm „horizon-prj-mgr“ ist nicht auffindbar" habe eben mal im Terminal horizon-eda gestartet, da öffnet sich Horizon EDA. Aber alle Projekte und Pools leer. Wäre schön wenn da ein Beispielprojekt und Parts vorhanden wären. Habe jetzt keine Zeit und Lust damit anzufangen. dpkg Ausgabe im Anhang Christian
Habe gerade gesehen das in Github einiges an Parts vorhanden zu sein scheint. Gucke ich mir in Ruhe nochmal an. Christian
Christian B. schrieb: > Als Menüeintrag in KDE ist "Horizon EDA Application" und "Horizon EDA > Pool manager" vorhanden. Wenn ich da drauf klicke kommt die > Fehlermeldung "Programm „horizon-prj-mgr“ ist nicht auffindbar" Woher nimmt das debian-Paket die .desktop-dateien? Seit einiger Zeit gibt es die auch im git: https://github.com/horizon-eda/horizon/blob/master/net.carrotIndustries.HorizonEDA.desktop > Aber alle Projekte und Pools leer. Da sollte eigentlich ein Fenster kommen, das so ausschaut: https://user-images.githubusercontent.com/877304/57181342-a2602000-6e92-11e9-97e3-262f0d9d7f1a.png Welche Version hast du denn installiert? Die aus "stable" ist mittlerweile ein Jahr alt und nicht mehr empfehlenswert. nicht "Gast" schrieb: > Hab's vorher auf meinem Notebook unter Windows getestet, das OpenGL > Fenster fehlt. Also grau, da wo Schaltplan/Board sein sollte? Mach mal einen Schaltplan/Board auf und drück im Projektmanager Ctrl-Shift-o und poste hier die stdout/stderr ausgabe.
nicht "Gast" schrieb: > Hab's vorher auf meinem Notebook unter Windows getestet, das OpenGL > Fenster fehlt. > > Ansonsten hab mir das Youtube Video angesehen, alle Achtung! > Werd's vielleicht n anderes mal auf Linux testen. https://github.com/horizon-eda/horizon Ich habe gerade mal eine Kurzanleitung mit WORD für die Installation von horizon-EDA mit Pool und Beispielprojekt für Windows(WIN7,8,10) zusammengeklickt. Im Prinzip gibt es das alles hier viel ausführlicher. https://horizon-eda.readthedocs.io/en/latest/feature-overview.html Falls die Fenster nicht aufgehen, dann kann das an einer zu alten Grafikkarte liegen. Mit einer 10 Jahre alten GraKa hat man da meistens keine Chance. Da hilft dann auch Linux nicht weiter.
Beginners question... From what I understand: the users will fill the Pool. What is your guidance for naming? Example: https://www.ti.com/lit/ds/symlink/tps60400.pdf see page 25. This IC has several 'varieties', although for the schematic there are no differences: TPS60400DBVR SOT-23 DBV 5 3000 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 TPS60400DBVT SOT-23 DBV 5 250 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 TPS60401DBVR SOT-23 DBV 5 3000 178.0 9.0 3.3 3.2 1.4 4.0 8.0 Q3 TPS60401DBVT SOT-23 DBV 5 250 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 TPS60402DBVR SOT-23 DBV 5 3000 178.0 9.0 3.3 3.2 1.4 4.0 8.0 Q3 TPS60402DBVT SOT-23 DBV 5 250 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 TPS60403DBVR SOT-23 DBV 5 3000 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 TPS60403DBVT SOT-23 DBV 5 250 178.0 9.0 3.23 3.17 1.37 4.0 8.0 Q3 PACKAGE MATERIALS INFORMATION www.ti.com 27-Jun-2014 For my schematic the naming TPS6040x (family) will do, but is that convenient for the Pool? If I have to specify exact, then the more difficult it will be to find in the Pool, as it grows. Even exactly the same part could be given many names by other users, so I fear the Pool will become garbage. So I am missing "Create a part" in the instructions.
Problem1. I try to run Horizon on 24" monitor (Lenovo ThinkVision P24q-10) as a second (extended) screen aside my laptop in Windows10. That does not work: bad mouse control, window titles and contents disappear and so on. Maximise window results in copy of window and freezes, i can only move and close that window then. I think only 3 top right buttons (minimise, maximise, close) buttons work. A duplicate (copied) screen from laptop works as expected. Problem2. In the part browser characters that I type in the search lines get accents. A problem with language (NL keyboard US) or keyboard character sets I suppose. (My install is from 28-11-2019)
> For my schematic the naming TPS6040x (family) will do, but is that convenient for the Pool? I'm glad you asked, since the pool is meant to solve that exact problem: As far as I can tell, there are 4 flavors of your particular part: TPS6040{0,1,2,3}DBV. Each of them is orderable on reels of either 250 or 3000 pcs. There also seems to be a G4 variant for every one of those, that suffix seems to be there only for existing customers, so it's not really needed for our purposes. The recommended process looks like this: 1. Create part, entity, etc. for the TPS6040x 2. Create the TPS6040{0,1,2,3}DBV parts by inheriting from the TPS6040x part. In each of those parts, add the full part numbers (i.e. TPS60400DBVR, TPS60400DBVT) in the "orderable MPNs" field as both part numbers will get you the same thing. Geert H. schrieb: > I try to run Horizon on 24" monitor (Lenovo ThinkVision P24q-10) as a > second (extended) screen aside my laptop in Windows10. > That does not work: bad mouse control, window titles and contents > disappear and so on. Looks like a gtk or graphics drivers bug to me. Does this happen with other gtk apps as well? Geert H. schrieb: > Problem2. > In the part browser characters that I type in the search lines get > accents. > A problem with language (NL keyboard US) or keyboard character sets I > suppose. Is this specific to the part browser search entries or to all text entries (such as in create project)? Does the actual search use the accented or non-accented characters? All in all, this looks like a gtk bug to me as well. A screenshot of this problem might help to determine the root cause.
Uptil now I encountered the accented characters only when typing in the 3 search lines in parts browser. When I installed Horizon my directory and project names appeared normally, without accents. I don't know howto show this problem in screenshots...: On the 24" extended monitor only the preferences app seems to work normal. The other apps not. The board - Interactive manipulator and Schematic -interactive manipulator end up as empty in Windows taskbar, I cannot reopen them. It sometimes worked if I moved there window position somewhat before clicking a button. No reaction or wrong reactions I get from 3D Preview, it ended up in frozen position, same with Projct manager. Finally I could close the programs from Windows taskbar. BTW: I hope you get all those separate program's nice together in 1 window, now they pop up everywhere as unrelated singles. Very confusing for a beginner like me. I need the total view. Oh, and I deeply respect the endless energy you put in this project! May the Capacitor with you and your helpers :)
Nach exakt drei Jahren ist es nun so weit, Version 1.0 ist da: https://github.com/horizon-eda/horizon/releases/tag/v1.0.0 Einen Überblick über die wichtigsten Features gibt es auf https://horizon-eda.readthedocs.io/en/latest/feature-overview.html An dieser Stelle danke an alle, die schon in den ersten Monaten mutig genug waren, das Programm auszuprobieren und ihre Erfahrungen damit zu teilen! Passend dazu gibt es auch dieses Jahr auf der FOSDEM wieder einen Talk: https://fosdem.org/2020/schedule/event/horizon
Das sieht tatsächlich genau nach dem aus was ich brauchen könnte jetzt wo meine Eagle Lizenz ausgelaufen ist. Aber ... der Punkt der mich am meisten davon abhält ist folgender: Wer unterstützt das Projekt und wie lange wird es das geben? Wenn ich zu KiCAD wechsele, dann weiß ich, dass da das CERN dahintersteht, das wird also vermutlich zumindest dieses Jahrzehnt weiterentwickelt. Das ist jetzt überhaupt nicht böse gemeint oder so, aber, hast du einen langfristigen Plan? Machst du das jetzt als Hobby weil du aktuell die Zeit dazu hast? Verdient damit jemand Geld? Ich möchte eben ungerne jetzt ein Programm lernen um mich dann in ein paar Jahren wieder umgewöhnen zu müssen.
Gustl B. schrieb: > Das ist jetzt überhaupt nicht böse gemeint oder so, aber, hast du einen > langfristigen Plan? Berechtige Frage, mein Ziel ist es, in ECAD-Programm zu haben das mir (und hoffentlich auch anderen) gefällt und es Spaß macht damit (und daran) zu arbeiten. > Machst du das jetzt als Hobby weil du aktuell die > Zeit dazu hast? Ja, Zeit ist da und macht Spaß. > Verdient damit jemand Geld? Meines Wissens nach nicht.
OK, super Sache von dir! Ich weiß nicht ob du das schon versuchst, aber es wäre vielleicht schon wichtig da irgendwie eine größere Firma oder Einrichtung zu bekommen die das unterstützt. Wenn ich jetzt zu Altium wechsel oder bei Eagel bleibe, dann weiß ich, dass damit komerzielle Projekte gemacht werden, die Software also grob so funktioniert wie sie soll. Bei KiCAD ist das ähnlich. Vielleicht wäre ein Schritt in diese Richtung, dass du wenn noch nicht geschehen ein Konvertierungsprogramm anbietest um Dateien/Bibliotheken anderer Programme in dein Format zu konvertieren. Mit würde sowas den Umstieg sehr erleichtern. Du könntest dich auch an PCB Hersteller wenden wie PCB Pool damit die dein Dateiformat akzeptieren, der Anwender also nicht zuerst Gerber exportieren muss. Ich werde mir das Programm aber trotzdem mal ansehen und gucken wie anders es sich verhält und wie gut mir eine Umgewöhnung gelingt. Dazu habe ich noch eine generelle Idee (nicht nur für deine Software): Es gibt ja in vielen Bereichen ähnliche Software. GIMP, Photoshop; Word, Libreoffice, Abiword; Eagle, KiCAD, Horizon, ... Und da gibt es eigentlich eine große Teilmenge an Funktionen. Hier ist es eben das Board. Da gibt es Leiterbahnen, es gibt Pads, es gibt Bohrungen, ... Ich fände es schick, wenn man das Benutzerinterface umstellen könnte, so dass sich ein Programm eher wie ein anderes verhält. Ja, die Funktionen sind nur eine Teilmenge, aber zumindest den Aufbau vom Interface, also wo der Benutzer welche Funktion und Einstellung findet könnte man anpassbar machen. Dann wähle ich als Eaglenutzer einfach die Eagleoberfläche aus und schon fühle ich mich halbwegs zu Hause. Klar, manches Verhalten ist dann anders, aber die Shortcuts, Icons, Menüstruktur, Bezeichnungen, ... könnte man dann so wählen wie in dem anderen Programm. Das sieht man aber leider nur sehr selten. Ich kenne da nur Gimpshop. Das hat versucht, dass GIMP so aussieht wie Photoshop. Allerdings leider nur sehr halbherzig, aber trotzdem deutlich besser bedienbar wie GIMP wenn man vorher schon Photoshop bedient hatte.
Good News :-) https://fosdem.org/2020/schedule/track/open_source_computer_aided_modeling_and_design/ https://fosdem.org/2020/schedule/event/horizon/attachments/slides/3773/export/events/attachments/horizon/slides/3773/presi.pdf
Michel M. schrieb: > kann das Video nicht finden :-( Die Videos müssten in den nächsten Tagen hier zu finden sein. https://video.fosdem.org/2020/H.2213/
Gustl B. schrieb: > Ich fände es schick, wenn man das Benutzerinterface umstellen könnte, so > dass sich ein Programm eher wie ein anderes verhält. Da muss ich dich enttäuschen, von mir jedenfalls wird das nicht passieren, da es die Komplexität erheblich erhöht (ohne viel Nutzen) und das Benutzerinterface u.a. Horizon EDA zu dem macht was es ist.
Kein Problem, ist ja quelloffen. Ich meinte das eher generell. Es gibt eben viele Programme die einen sehr ähnlichen Funktionsumfang haben, sich aber komplett unterschiedlich bedienen. Das ist natürlich Alleinstellungsmerkmal, aber eben auch eine Hürde für Leute die wechseln wollen.
Helmut S. schrieb: > Michel M. schrieb: >> kann das Video nicht finden :-( > > Die Videos müssten in den nächsten Tagen hier zu finden sein. > > https://video.fosdem.org/2020/H.2213/ Video ist seit soeben da.
Auch nach dem Release von Version 1.0 ist die Entwicklung nicht stehen geblieben. Das wichtigste des vergangen Monats habe ich deshalb mal einem Blogpost zusammengefasst: https://blog.horizon-eda.org/progress/2020/03/04/progress-2020-02.html
Das nächste Release (1.1) wird es dann Ende April geben: https://blog.horizon-eda.org/misc/2020/03/26/release-schedule.html
Ich habe gerade mal 1.0.91 fuer Debian gebaut. Geht glatt durch. Unter https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957339 gibt es aber auch einen Bug-Report für das Übersetzen mit gcc 10. Vielleicht lässt sich das ja ganz einfach korrigieren. Uwe
Uwe S. schrieb: > einen Bug-Report für das Übersetzen mit gcc 10 Ich hab zur CI mal testhalber debian bullseye mit gcc 10 addiert und es hat tadelllos durchgebaut: https://github.com/horizon-eda/horizon/runs/624041033?check_suite_focus=true was hab ich da anders gemacht? Prinizpiell sieht es so aus, als würde ein
1 | #include <string> |
in der src/export_pdf/export_pdf.hpp bereits helfen.
Das liest sich schonmal gut. Ich warte mal die 1.1 ab, lade dann nochmal eine neue Version zu Debian hoch und schließe den gcc 10 Fehler. Uwe
> Das liest sich schonmal gut.
Weiß nicht, mir wär es schon lieber, wenn ich den Fehler auch
reproduziert bekommen würde. Wenn ich das jetzt so blind repariere, kann
man ja nicht sicher sein, ob noch ähnliche Dinge lauern.
Daher werde ich jetzt erstmal nichts ändern. Wenn es dann doch ein
Problem geben sollte, könnt ihr ja immer noch einen Patch anwenden.
Gustl B. schrieb: > Du könntest dich auch an PCB Hersteller wenden wie PCB Pool damit die > dein Dateiformat akzeptieren, der Anwender also nicht zuerst Gerber > exportieren muss. Das wird wohl keine große Begeisterung auslösen. Aber wie wär's, wenn Horizon ein verbreitetes Board-Format exportieren würde, vielleicht nicht gerade eagle.brd, aber .kicad_pcb? Mein anderer Traum wäre ein Hersteller-spezifischer Gerber-Export, also 2 Mausklicks bis zum fertigen zip-File. Die Hersteller müssen nichts weiter machen, als eine config zu erstellen und der unbedarfte Bastler könnte endlich fehlerfreie Gerber-Daten abliefern.
Beitrag #6244251 wurde von einem Moderator gelöscht.
Beitrag #6244263 wurde von einem Moderator gelöscht.
So, Version 1.1 ist da! https://github.com/horizon-eda/horizon/releases/tag/v1.1.0 Mit u.a. diesen neuen Features: - Pick & place export - Ordentliches panelizen - Unterstützung von nicht zu bestückenden Bauteilen - Luftlinien selektiv ausblenden - Zoomen und Verschieben via Touchscreen Den ganzen Changelog findet ihr da: https://github.com/horizon-eda/horizon/blob/v1.1.0/CHANGELOG.md Hintergrundinfos zu diesen und anderen Neuerungen gibt es in den monatlichen Fortschrittsberichten auf https://blog.horizon-eda.org/
Bauform B. schrieb: > Mein anderer Traum wäre ein Hersteller-spezifischer Gerber-Export, also > 2 Mausklicks bis zum fertigen zip-File. Das gibt es schon so gut wie. Die ganzen chinabuden wollen ja alle Gerber-Daten mit Protel-Dateiendungen haben, was aktuell die Standardeinstellung ist und ein Zip kann auch automatisch erzeugt werden. Für meine Bestellungen war es tatsächlich eine Ein-Klick-Angelegenheit. Grundsätzlich ist es das Ziel den Gerber-Export Dialog so frei wie möglich von unnützen Einstellungen wie z.B. Anzahl an Nachkommastellen oder mm/inch zu halten. Bis auf ein paar Anlaufschwierigkeiten wie https://blog.horizon-eda.org/misc/2019/11/18/gerber.html ist mir nichts von Problemen mit den erzeugten Gerberdaten bekannt.
Schade aber mein i3 & mein i5 Rechner mit interner Grafikkarte geht nicht. Klar die sind schon älter aber es sind Entwicklungs und keine gamer Systeme, aber das braucht man ja schon hierfür, echt schade.
Klaus schrieb: > Schade aber mein i3 & mein i5 Rechner mit interner Grafikkarte geht > nicht. > Klar die sind schon älter aber es sind Entwicklungs und keine gamer > Systeme, aber das braucht man ja schon hierfür, echt schade. Ja, Intel-GPUs auf Windows(?) waren wohl schon immer problematisch. Ich meine mich zu erinnern, dass da auch Gtk mit dran schuld hat. Gamer-Systeme braucht man aber bei weitem nicht, ich entwickel hier auf einem Laptop mit Intel HD 5500 GPU und auf einem 10 Jahre alten Laptop mit Nvidia GeForce 9650M GT tut es auch problemlos.
Ich probiere es mal mit einer anderen Grafikkarte, aber schade das mein hauptsystem ist ein Laptop ist.
Und bei mir funktioniert es prima auf einem Intel i5-6200U mit integrierter Grafikkarte (Intel HD Graphics 520). Arbeite aber unter Linux, nicht Windows.
Da ist es wieder, Windows gegen Linux. Das die Intel Treiber unter Windows das nicht so gut unterstützten hatte ich bisher nicht gemerkt, dabei ist es schon Windows 7 und 10. Aber wie schon gesagt probiere ich es mit einer anderen Grafikkarte aus und versuche mein Glück. Das Projekt sieht einfach nur genial aus und es wäre eine Dummheit es nicht hier mit zu versuchen.
Klaus schrieb: > Da ist es wieder, Windows gegen Linux. > > Das die Intel Treiber unter Windows das nicht so gut unterstützten hatte > ich bisher nicht gemerkt, dabei ist es schon Windows 7 und 10. > Aber wie schon gesagt probiere ich es mit einer anderen Grafikkarte aus > und versuche mein Glück. > Das Projekt sieht einfach nur genial aus und es wäre eine Dummheit es > nicht hier mit zu versuchen. Es gibt nicht den I5. I5 gibt es schon seit 10Jahren und aus der Zeit gibt es auch Grafikkarten von Nvidia die GTK3 nicht könnnen, z. B. GTX260. Ab GTX560 läuft es auf WIN7/10. Die GTX560 machte auf LINUX(Ubuntu 17.10) allerdings noch Probleme. Das liegt dann wohl an den Grafiktreibern. Das Problem löst man bei Desktops indem man einfach für kleines Geld eine etwas neuere Grafikkarte kauft.
Habe halt bis jetzt nur die interne Intel Grafikkarte benutzt. Und bisher nie Probleme gehabt, aber wie ich es schon gesagt habe teste ich es mit einer anderen Grafikkarte.
Uwe S. schrieb: > Das liest sich schonmal gut. Ich warte mal die 1.1 ab, lade dann nochmal > eine neue Version zu Debian hoch und schließe den gcc 10 Fehler. > > Uwe Mir ist noch aufgefallen, dass die Makefile in Version 1.1.0 noch einen bug hatte, der dazu geführt hat, dass während make install noch binaries gebaut wurden. In Version 1.1.1 ist das nun behoben. Ich empfehle dir daher die 1.1.1 zu nehmen.
Lukas K. schrieb: > Uwe S. schrieb: >> Das liest sich schonmal gut. Ich warte mal die 1.1 ab, lade dann nochmal >> eine neue Version zu Debian hoch und schließe den gcc 10 Fehler. >> >> Uwe > > Mir ist noch aufgefallen, dass die Makefile in Version 1.1.0 noch einen > bug hatte, der dazu geführt hat, dass während make install noch binaries > gebaut wurden. In Version 1.1.1 ist das nun behoben. Ich empfehle dir > daher die 1.1.1 zu nehmen. Ich hatte gerade die 1.1.1 gebaut und hochgeladen, dann kam ein Bug-Report, der ein Problem beim Cross-Complieren beschreibt. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959791 Spricht was dageben das PKGCONFIG im Makefile in PKG_CONFIG umzubennen? Uwe
Uwe S. schrieb: > Spricht was dageben das PKGCONFIG im Makefile in PKG_CONFIG umzubennen? Ne, würde dann so aussehen:
1 | PKG_CONFIG ?= pkg-config |
Stellt ihr euch das so vor?
Hut ab! Das Programm sieht wirklich beeindruckend aus.
Lukas K. schrieb: > Uwe S. schrieb: >> Spricht was dageben das PKGCONFIG im Makefile in PKG_CONFIG umzubennen? > > Ne, würde dann so aussehen: >
1 | > PKG_CONFIG ?= pkg-config |
2 | > |
> > Stellt ihr euch das so vor? Genau so. Danke.
Uwe S. schrieb: > Genau so. Danke. Sehr gut, ist jetzt auf master und wird dann dementsprechend im nächsten Release drin sein.
Zwei Dinge sind mir noch gerade zum Debian-packaging eingefallen: In Version 1.1 gibt es die -prj und -pool Programme nicht mehr (standardmäßig). Ihr müsst dann wohl noch die entsprechenden manpages entfernen. Es kann auch ein Python-Modul gebaut werden: https://horizon-eda.readthedocs.io/en/latest/python.html Wär' praktisch wenn das als python3-horizon-eda oder so paketiert wird.
Lukas K. schrieb: > Zwei Dinge sind mir noch gerade zum Debian-packaging eingefallen: > > In Version 1.1 gibt es die -prj und -pool Programme nicht mehr > (standardmäßig). Ihr müsst dann wohl noch die entsprechenden manpages > entfernen. Kein Problem. > Es kann auch ein Python-Modul gebaut werden: > https://horizon-eda.readthedocs.io/en/latest/python.html Wär' praktisch > wenn das als python3-horizon-eda oder so paketiert wird. Ich probier's. Aufgefallen ist mir schon, wenn ich das python Module baue, dann räumt das 'make clean' nicht mehr vollständig auf. Es bleibt z.B. build/picobj/src/export_step/export_step.o und build/picobj/src/util/step_importer.o übrig. Läuft das python module mit allen python versionen? Uwe
Ich bin gerade auf diese Diskussion gestoßen. Was kann das "neue halbfertige Elektronik-CAD", was KiCad nicht kann? Und warum ist dieser USP nicht im README erklärt? Zweitens, warum ist das halbfertige Programm immer noch nicht fertig, da es doch 2017 schon halbfertig war?
MaWin schrieb: > Zweitens, warum ist das halbfertige Programm immer noch nicht fertig, da > es doch 2017 schon halbfertig war? Es gibt doch schon die Releases 1.0 und 1.1. Wenn an einem Layoutprogramm nicht mehr weiter entwickelt würde, dann wäre das ein schlechtes Zeichen. Kennst du ein Layoutprogramm das nicht ständig verbessert wird?
Helmut S. schrieb: > Es gibt doch schon die Releases 1.0 und 1.1. Ich vergaß. Wenn man eine Release 1.0 nennt, ist das Programm natürlich fertig. Da hast du vollkommen recht. > Wenn an einem Layoutprogramm nicht mehr weiter entwickelt würde, dann > wäre das ein schlechtes Zeichen. Ein gutes Programm muss nicht weiterentwickelt werden, solange es alle Anforderungen erfüllt und keine Anforderungen hinzukommen. > Kennst du ein Layoutprogramm das nicht ständig verbessert wird? Da gibt es einige. Eagle z.B. wird ständig weiter verschlechtert. Und was ist nun mit erstens? Was kann dieses Progeamm, was KiCad nicht kann? Oder hatte da nur mal wieder ein Nichtsnutz ein bisschen Geltungsbedürfnis und msuste das Rad neu erfinden, auch wenn es dann etwas eckig und schief wurde?
MaWin schrieb: > Helmut S. schrieb: >> Es gibt doch schon die Releases 1.0 und 1.1. > > Ich vergaß. Wenn man eine Release 1.0 nennt, ist das Programm natürlich > fertig. Da hast du vollkommen recht. KiCad hat vermutlich auch mit 1.0 angefangen und zum Glück wird es trotzdem permanent weiterentwickelt. >> Wenn an einem Layoutprogramm nicht mehr weiter entwickelt würde, dann >> wäre das ein schlechtes Zeichen. > > Ein gutes Programm muss nicht weiterentwickelt werden, solange es alle > Anforderungen erfüllt und keine Anforderungen hinzukommen. Dann verstehe ich gar nicht warum an KiCad noch so viel weiterentwickelt wird, wenn das deiner Meinung nach schon fertig ist. Hast du dich etwa mit einem nicht fertigen Programm zufriedengegeben? >> Kennst du ein Layoutprogramm das nicht ständig verbessert wird? > > Da gibt es einige. Eagle z.B. wird ständig weiter verschlechtert. Das ist jetzt deine Meinung aber sicher nicht die Meinung der Eagle-Nutzer die jetzt bei AutoCad sind. Schau dir mal Altium an. Die sind schon bei Version 20 obwohl den meisten die Features von Version 14 gereicht hätten. > Und was ist nun mit erstens? Was kann dieses Progeamm, was KiCad nicht > kann? Horizon kann man Design-Rules pro Lage definieren. KiCad kann das leider nicht. So etwas ist bei Multilayer-Platinen eigentlich Pflicht. Selbst in dem in der Ferne liegenden KiCad 6.0 ist das nicht angedacht. In horizon ist die Teilenummer das Kennzeichen eines Bauteils. Damit ist immer auch der "footprint" verknüpft. Die großen Layout-Programme gehen noch einen Schritt weiter. Dort hat ein Bauteil einfach eine Nummer und darunter sind dann die Teilenummer oder mehrere Teilenummern falls es das Teil bei verschiedenen Herstellern gibt. In KiCad ist das anders. Aber da muss halt jeder selber entscheiden was ihm lieber ist. > Geltungsbedürfnis und musste das Rad neu erfinden, auch wenn es dann > etwas eckig und schief wurde? Lukas hat halt andere Schwerpunkte gesetzt. Da er ein begnadeter Software-Architekt und Programmierer ist, hat er selber ein neues CAD-Programm gemacht das die Struktur und die Features hat die er für sinnvoll hält. Ich denke ein Vergleich mit LTspice und anderen SPICE-Programmen passt ganz gut. Auch dort hat ein Architekt und Programmierer ein neues SPICE-Programm nach seinen Vorstellungen gemacht.
Helmut S. schrieb: > Lukas hat halt andere Schwerpunkte gesetzt. Da er ein begnadeter > Software-Architekt und Programmierer ist, hat er selber ein neues > CAD-Programm gemacht das die Struktur und die Features hat die er für > sinnvoll hält. Ein begnadeter Softwarearchitekt würde KiCad übernehmen oder forken und seine Features einbauen, aber nicht bei 0 anfangen. Du machst dich hier gerade reichlich lächerlich mit deinen nicht vorhandenen Argumenten. Bis jetzt stehen die Zeiger immer noch voll auf einer narzisstischen Persönlichkeit, die Vorhandenes kopieren muss, um sich toll zu fühlen.
MaWin schrieb: > Helmut S. schrieb: >> Lukas hat halt andere Schwerpunkte gesetzt. Da er ein begnadeter >> Software-Architekt und Programmierer ist, hat er selber ein neues >> CAD-Programm gemacht das die Struktur und die Features hat die er für >> sinnvoll hält. > > Ein begnadeter Softwarearchitekt würde KiCad übernehmen oder forken und > seine Features einbauen, Mit einem Fork hätte sich Lukas weit von KiCad wegbewegt und damit könnte man das nie mehr in den Hauptpfad zurück "mergen". Außerdem ist KiCad ständig im Fluss. Wer da "forked" ist in wenigen Monaten inkompatibel zum Hauptpfad.
MaWin schrieb: > Ein begnadeter Softwarearchitekt würde KiCad übernehmen oder forken und > seine Features einbauen, aber nicht bei 0 anfangen. Muhaha. Gerade bei KiCad hätte man schon längst mal bei 0 anfangen sollen. > Bis jetzt stehen die Zeiger immer noch voll auf einer narzisstischen > Persönlichkeit, die Vorhandenes kopieren muss, um sich toll zu fühlen. Wie jetzt? Hat er jetzt kopiert oder bei 0 angefangen? Entscheiden Sie sich jetzt. Dass horizon Padstacks und Layer kennt, kann man eigentlich nicht "kopiert" nennen.
Uwe S. schrieb: > Es bleibt > z.B. build/picobj/src/export_step/export_step.o und > build/picobj/src/util/step_importer.o übrig. Ok, ist auf master behoben. > Läuft das python module mit allen python versionen? Gute Frage. Mit dem python 3 aus debian buster tut es jedenfalls. Mir ist nicht bewusst, dass es da irgendwelche Einschränkungen geben sollte. MaWin schrieb: > Und warum ist dieser > USP nicht im README erklärt? Weil das README für Entwicker ist. Für Anwender gibt es https://horizon-eda.readthedocs.io/en/latest/feature-overview.html. Ist auch im README verlinkt. Zu KiCad: https://horizon-eda.readthedocs.io/en/latest/why-another-eda-package.html Es ist ja nicht so, als hätte ich das Rad komplett neu erfunden. Einige Dinge, wie z.B. der Router, STEP Import/Export, die Berechnung von Luftlinien und die Darstellung von Text in Leiterbahnen sind aus KiCad übernommen bzw. davon inspiriert.
MaWin schrieb: > Bis jetzt stehen die Zeiger immer noch voll auf einer narzisstischen > Persönlichkeit Ist das jetzt Selbstkritik? Fängt ja schon mit dem Namensklau an, nichtmal für einen eigenen Nicknamen reicht es bei dir. Nun genügt es mit deinen "Beiträgen" in diesem Thread, bitte verschone uns damit. All das, was du da glaubst fragen zu müssen, ist ohnehin schon im Thread erklärt worden.
Jörg W. schrieb: > Ist das jetzt... Ach Jörg, laß mal. Es war zu erwarten, daß aus Kicad-Kreisen irgendwann einmal der Kleinkrieg gegen Horizon beginnt. Meine Vermutung ist, daß dies jetzt zunehmen wird. So wie ich das sehe, ist wohl das größte Problem bei Horizon, daß Lukas mehr oder weniger allein dasteht - und unendlich viel Kraft hat niemand. Das hat natürlich Auswirkungen, siehe z.B. das Problem der OpenGL-Versionen - aber mir sind auch noch recht hochnäsige Worte von Lukas im Gedächtnis, so etwa "wer braucht schon Windows.." - ohne daß er dabei erkannt hat, daß gerade Windows mit DirectX eine leistungsfähige Infrastruktur hat, die bei Linux schlichtweg fehlt. Es hat eben seine Gründe, weswegen PC-Spiele fast komplett auf Windows ausgerichtet sind. Naja - und mit seinem "Pool"-Konzept hat er sich mMn. verrannt. Er wird zwar nicht müde, seinen Pool zu erklären, aber ich hab Zweifel, daß ihn dabei jemand wirklich versteht. Ein simples Library-Konzept mit Dateien, die sich selbst genügen und keine Abhängigkeiten zu anderen Bibliotheksdateien aufweisen, ist mMn. wesentlich tragfähiger. Aber das alles sind Dinge, die man in Ruhe diskutieren kann - Flames von der Kicad-Seite hingegen sind ein Ärgernis. W.S.
W.S. schrieb: > Es war zu erwarten, daß aus Kicad-Kreisen irgendwann > einmal der Kleinkrieg gegen Horizon beginnt. Dieser Forenteilnehmer hat mit „Kicad-Kreisen“ nichts zu tun. Wenn sich einer fremder Identitäten annimmt, um als „Trittbrettfahrer“ derer, die er da beerben möchte auzutreten, dann ist die „Mutwillige Störung von Diskussionen“, wie es die Nutzungsbedingungen beschreiben, mehr als zu vermuten. Der „originale MaWin“ hat gewiss seine Eigenheiten, aber er tritt nie als vorsätzlicher Stänkerer irgendwo auf. Das scheinen manche dieser Trittbrettfahrer absolut nicht kapiert zu haben, und sie glauben, dass sie mit diesem Nicknamen irgendwie Narrenfreiheit hier hätten. Dem ist nicht so. > So wie ich das sehe, ist wohl das größte Problem bei Horizon, daß Lukas > mehr oder weniger allein dasteht - und unendlich viel Kraft hat niemand. Da gebe ich dir recht, aber das muss ja erstens nicht dauerhaft so bleiben, und zweitens hat er bisher verdammt flexibel (und oft auch schnell) auf allerlei Vorschläge reagiert, sofern sie halt nicht gegen die Grundkonzeptionen von Horizon stehen. Solange er diese Aktivität halten kann, braucht das Projekt auch nicht unbedingt weitere aktiv Mitwirkende. > Das hat natürlich Auswirkungen, siehe z.B. das Problem der > OpenGL-Versionen Nein, das siehst du komplett falsch. Er hat das zu Beginn seines Projekts so beschlossen, um sich auf tatsächliche Aufgabengebiete konzentrieren zu können und eben keine Rückwärtskompatibilität bis zur Braunkohle pflegen zu müssen, wenn man sowieso gerade ein komplett neues Projekt aus dem Boden stampft. Das ist genau das gleiche, wie du eben viele neue oder neu aufgezogene auch kommerzielle Softwareprojekte nun nicht mehr für 32-Bit-Betriebssysteme erhälst, weil man auch dort mal einen Schnitt gemacht hat und sich auf die Zukunft konzentrieren will. Ein Altium setzt eben in der aktuellen Version auch ein bestimmtes Mindestmaß an ActiveX-Version voraus. Habe jetzt nicht nachgesehen, aber wird sich von der dafür benötigten Hardware kaum grundlegend von Horizon und seiner OpenGL-Version unterscheiden. > Naja - und mit seinem "Pool"-Konzept hat er sich mMn. verrannt. Deine Meinung. Die ist dir natürlich unbenommen (und wir wissen ja schon von Kicad, dass für dich praktisch kein anderes Bibliothekskonzept als das von Eagle in Frage kommt ;-). Andere haben da andere Meinungen. Ich bin mir sicher, dass das einer der Punkte ist, über die Lukas nicht mit sich reden lassen wird, zumindest nicht, solange die Argumentation sich auf dem Niveau „das gefällt mir nicht“ bewegt. Wem das nicht gefällt, für den gibt es doch genügend andere Programme zur Auswahl.
Beitrag #6259528 wurde von einem Moderator gelöscht.
Jedes Jahr sehe ich horizon in der Aufzeichnung von FOSDEM und ich habe immer noch nicht verstanden was es mit dem Library-Konzept nun so auf sich hat? Ist das jetzt mehr wie EAGLE/Altium/Mentor/Zuken/Pulsonix/Target oder ganz was neues? Wo ist der Mehrwert gegenüber KiCad? Kann mir das jemand an einem Beispiel aufzeigen? Noch traue ich mich nicht ran. PS: Ich denke das ist eine großartige Leistung von einer One-Man-Show. Mit der Zeit hätte Lukas die Welt verändern können, aber so hat man wenigstens ein halbfertiges EDA Programm ;-)
D. C. schrieb: > Ist das jetzt mehr wie EAGLE/Altium/Mentor/Zuken/Pulsonix/Target oder > ganz was neues? Wahrscheinlich ganz was neues, in Anlehnung an alle anderen. ;-)
Jörg W. schrieb: > D. C. schrieb: >> Ist das jetzt mehr wie EAGLE/Altium/Mentor/Zuken/Pulsonix/Target oder >> ganz was neues? > > Wahrscheinlich ganz was neues, in Anlehnung an alle anderen. ;-) Genau, in gewissermaßen mein persönliches Best-of. > Wo ist der Mehrwert gegenüber KiCad? > Kann mir das jemand an einem Beispiel aufzeigen? In KiCad ist das Pin/Pad mapping im Symbol mit drin, was dann dazu führt, dass man z.B. bei Transistoren, die in verschiedenen Pinbelegungen daher kommen für jede Belegung ein eigenes Symbol braucht. Auch hängt in KiCad sonst sehr viel am Symbol, was da meines Erachtens nicht hin gehört, wie Teilenummern und Datenblatt-Links. In Horizon EDA ist das alles strikt getrennt: - Die logischen Pins sind in Unit/Entity definiert - Da Symbol legt fest wie die Unit im Schaltplan ausschaut - Package ist wie fast überall anders auch - Im Part werden Package und Entity zu einem bestellbaren Teil mit Datenblatt -Links und vollständiger Teilenummer zusammengefügt In voller Länge gibt's das auch in der Dokumentation nachzulesen: https://horizon-eda.readthedocs.io/en/latest/pool-why.html
Nach dem ich nun ein paar Tage mit Horizon EDA gespielt habe kann ich nur meinen Hut ziehen. Als halbfertig würde ich es nicht mehr bezeichnen, das ist schon was brauchbares. Für einen "EAGLE Freund" der sich mit anderen Systemen immer schon schwer getan hat ist das nun eine gute alternative. Klar ist vieles wieder anders und ungewohnt, aber egal auf was ich umsteigen würde, es wäre immer anders. Die ersten Probleme werde ich wohl erst festellen wenn ich die erste richtige Platine damit mache, aber ich erwarte hier weniger Probleme wie bei meinen Versuchen (vor ca 5 & 2Jahren) auf KiCad umzusteigen. Das einzige was mir persönlich nicht gefällt ist das es eine one man show ist. Das ist zwar auf der einen Seite hilfreich für den Entwickler, aber es ist ein Risiko für den Nutzer. Ich habe nichts dagegen das Änderungen nur durch den Entwickler in den Code rein kommen, das sorgt wenigstens dafür das alles geordnet passiert. Aber das öffentlich machen vom Code oder einer eingeschrängten Gruppe den aktuellen Code zugänglich zu machen würde das überleben sicherer machen. Denn was passier jetzt wenn der heute einen Unfall hat und niemand den Code in die Finger bekommt? Richitg das Ende von Horizon und das wäre Schade.
Klaus schrieb: > Das ist zwar auf der einen Seite hilfreich für den Entwickler, aber es > ist ein Risiko für den Nutzer. Nein. "One-man show" heißt doch nicht, dass es nicht opensource wäre. Jeder kann sich den Sourcecode runterladen und selbst compilieren. Wenn du dir den Anfang des Threads mal ansiehst, so war dies in der Anfangszeit (als es noch "halbfertig" war) in der Tat sogar die einzige Möglichkeit, es überhaupt zu testen. Binärversionen gab es erst sehr viel später. https://github.com/horizon-eda/horizon
Jörg W. schrieb: > Nein, das siehst du komplett falsch. Er hat das zu Beginn seines > Projekts so beschlossen,... nein, das sehe ich komplett richtig: Die Kraft, das ganze Grafik-Subsystem allgemeingültiger hinzukriegen, hat er nicht - er ist schließlich keine Großfirma. Zum Beispiel bei Autodesks "Eagle" sehe ich da eine richtig fette DLL allein für das Herumhantieren mit OpenGL. Aber soweit sogut - zumindest die Fundamente des Ganzen sehe ich bei Horizon an der richtigen Stelle, also ist da Potential drin. W.S.
W.S. schrieb: > Die Kraft, das ganze Grafik-Subsystem allgemeingültiger hinzukriegen, > hat er nicht Die muss er auch nicht haben. Wie geschrieben, auch kommerzielle Systeme limitieren sich hier an bestimmten Stellen selbst, üblicherweise halt dann, wenn man sowieso ein Subsystem neu aufsetzt (wie eben Altium mit der 18er Version). Ansonsten: das Ganze ist Opensource. Wenn jemand wirklich der Meinung ist, dass das ein derart limitierender Punkt ist, dann stünde es ihm ja frei, das Grafiksystem so neu zu schreiben (oder ein alternatives), dass es auch auf älterer Hardware läuft.
Lukas K. schrieb: > In Horizon EDA ist das alles strikt getrennt: > > - Die logischen Pins sind in Unit/Entity definiert > - Da Symbol legt fest wie die Unit im Schaltplan ausschaut > - Package ist wie fast überall anders auch > - Im Part werden Package und Entity zu einem bestellbaren Teil mit > Datenblatt -Links und vollständiger Teilenummer zusammengefügt > > In voller Länge gibt's das Das ist für mich der einzig sinnvolle Ansatz. Es gibt z.B. 790x, die ein verdrehtes Pinning beim TO220 haben. Oder die beliebte BAT56 gibt's mit Anode auf Anode, und Anode auf Kathode.
Martin S. schrieb: > Es gibt z.B. 790x, die ein verdrehtes Pinning beim TO220 haben. Es gibt auch 78L05 in SOT-89 mit zwei verschiedenen Pinnings. Da bin ich mal auf die harte Tour bei BAE drüber gestolpert. :/
Oh man, war ich vergesslich, den Code hatte ich sogar mal vor einem Jahr mir angesehen. War mit meinen Gedanken anscheinend wo anders und habe es mit 2 andern Projekten hier im Forum verwechselt. Änderdert aber nichts daran, das Projekt ist Super und ich hoffe das ich das sogar an der Arbeit einsetzen kann. Fehlen zwar noch einige Tests aber bis jetzt läuft alles bei einer neuen kleinen Testplatine. Klar Wünsche hat man immer wie zB. Import von anderen Systemen (EAGLE, KiCad, ...), aber auch ohne das das perfekt geht ist Horizon schon sehr gut. Was ich aktuelle noch suche ist die Möglichkeit einen SCAN (JPEG, BMP) als Bild im Board drunter zulegen um das nach zu malen. Entweder es geht nicht oder ich übersehe es einfach. Ja nach malen klingt komisch, ist aber manchmal die einzige Möglichkeit um von einer alten Leiterplatte (geklebt oder uralt CAD) aktuelle CAD Daten zu bekommen.
Klaus schrieb: > Was ich aktuelle noch suche ist die Möglichkeit einen SCAN (JPEG, BMP) > als Bild im Board drunter zulegen um das nach zu malen. > Entweder es geht nicht oder ich übersehe es einfach. Ne, das geht nicht. Ist auch nicht ganz so einfach zu bauen, da man das Bild dafür als Textur vorhalten müsste. Das nächstbeste, was es derzeit gibt, ist DXF-Import. Da wäre eine denkbare Erweiterung, aus den importierten Linien per Tool tracks zu machen.
"nachmalen" können wäre ja schon mehr als die halbe Miete, automatisch muss das nicht sein. Dann fehlt eigentlich nur noch ein Postscript-zu-DXF-Konverter. Inkscape kann Bitmapgrafik vektorisieren wenn der Kontrast gut ist.
Zum nachmalen gibt es das Programm "Glass2k", das Windowsfenster (cooles Wort) halbtransparent schalten kann. https://chime.tv/products/glass2k.shtml
DFX probiere ich mal aus. Von EAGEL kenne ich es das man BMP Datein einlesen kann, die werden dabei dann wohl in irgendwas umgesetzt (Linien / Polygone). Wenn das sozusagen so was wie ein DFX Import ist dann ist das ja fast drin. Wie man gescheit BMP nach DFX wandelt muss ich dann sehen. Das man da am besten auch S/W Bilder hat ist klar, Farbe wäre da wohl etwas schlecht. Das Fenster durchsichtig machen ist zwar nett, aber da geht jede Skalierung verloren. Außerdem lesse ich da was von XP und ob das unter WIN10 geht werde ich nicht testen, denke aber nicht.
DXF ist halt ein Zeichnungsformat und damit eine Vektorgrafik. BMP ist so ziemlich das primitivste Bitmap-Grafik-Format. Vektorgrafik nach Bitmap wandeln ist einfach, Bitmap nach Vektor ist aufwändig. Man muss ja entlang der Kontrastgrenzen der Pixel einen Vektor ermitteln. Inkscape wurde schon genannt als Tool, was sowas zumindest prinzipiell beherrscht.
Jörg W. schrieb: > Vektorgrafik nach Bitmap wandeln ist einfach, Bitmap nach Vektor ist > aufwändig. Für den Zweck nicht - du kannst auch die Bitmap ganz stumpf in eine Punktewolke wandeln. Gibt zwar große und hässliche Dateien, müsste für den angestrebten Zweck aber reichen. Wäre eine schöne Fingerübung in Python. Wer mehr Aufwand spendieren will, fasst wenigstens noch nebeneinanderliegende Pixel zusammen.
Max G. schrieb: > du kannst auch die Bitmap ganz stumpf in eine Punktewolke wandeln. Genial. Mit ein wenig Vorarbeit in irgendeiner Bildbearbeitung zwecks Kontrastverstärkung und vielleicht pngtopnm... Die genaue Skalierung ist etwas fummelig, aber das wäre mit echter Vektorisierung auch nicht einfacher. Wenn DXF für Punkte keine Strichstärke kennt, sieht man die vielleicht nicht. In dem Notfall erzeugt man eben Linien, die so kurz wie breit sind.
Meine Versuche gehen zwar irgendwie, aber schön ist was anderes. Da werde ich jetzt mal unverschämt und äussere den Wunsch einer solchen Funktion für die nächste Version. Mit PC Software schreiben habe ich es nicht so und kann das leider nicht Lukas fertig anbieten. Max G. wenn das eine schöne Fingerübung ist dann bitte leg los, da werden sich bestimmt noch andere drüber freuen.
Klaus schrieb: > Meine Versuche gehen zwar irgendwie, aber schön ist was anderes. Dann gib uns doch dein Bild mal, und wir werden versuchen, es dir in ein benutzbares DXF zu wandeln.
Klaus schrieb: > Max G. wenn das eine schöne Fingerübung ist dann bitte leg los, da > werden sich bestimmt noch andere drüber freuen. Bitteschön. Inkscape braucht zwar ein bisschen zum Laden, aber es tut :) Eingabe: PBM ASCII (kann z.B. IrfanView erzeugen), Ausgabe SVG. Für die Wandlung SVG->DXF gibt es diverse Möglichkeiten, z.B. Inkscape.
Lukas K. schrieb: > Klaus schrieb: >> Was ich aktuelle noch suche ist die Möglichkeit einen SCAN (JPEG, BMP) >> als Bild im Board drunter zulegen um das nach zu malen. >> Entweder es geht nicht oder ich übersehe es einfach. > > Ne, das geht nicht. Ist auch nicht ganz so einfach zu bauen, da man das > Bild dafür als Textur vorhalten müsste Geht nicht gibt's nicht. Ich hatte genau das jetzt auch für ein Projekt gebraucht und eingebaut. Mit place picture kann man nun Bilder beliebigen Formates (alles was GdkPixbuf kann) in Schaltplan, Board und Package importieren. Alternativ kann man auch Bilder aus der Zwischenablage pasten. Um die Projektdateien nicht übermäßig aufzublähen werden die Bilder als PNG im Projektverzeichnis gespeichert.
>Ich hatte genau das jetzt auch für ein Projekt gebraucht und eingebaut.
Läuft. Damit hast du EAGLE bei mir auf ein rostiges Abstellgleis
gestellt.
Danke.
Ein Monat ist mal wieder rum und es gibt wie üblich wieder einen kurzen Bericht darüber, was so passiert ist: https://blog.horizon-eda.org/progress/2020/06/02/progress-2020-05.html Unter anderem: - Import von KiCad-Symbolen - Schöneres Laden von 3D-Modellen - Es gibt nun eine Toolbar - Gateswapping
Angehängte Dateien:
-
error.png
12 KB
Hi! Habs mal installiert. Kann man hier Fragen stellen oder ist dafür extra woanders was eingerichtet worden? Anyway, auf meinen Win7 Rechner stürzt es ab mit einer Fehlermeldung. siehe Bild. Auf meinem Win10 PC läuft es anscheinend. Habe noch nicht so viel probiert. Wenn ich das Beispielprojekt X-Transmitter öffne, fliegen die SMD-Bauelemente über der Platine. Haben also eine falsche Höheninformation. Sieht lustig aus, aber was mache ich falsch? Damit sind wir bei der Pool-Sache. Ich habe den Standard-Pool geladen. Wenn ich nun ein eigenes Bauelement definiere, wo landet es? Muß ich einen eigenen lokalen Pool sinnvollerweise anlegen? Danke für Infos!
Abdul K. schrieb: > auf meinen Win7 Rechner stürzt es ab mit einer Fehlermeldung. > siehe Bild. Auf meinem Win10 PC läuft es anscheinend. Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" vom 31.01.2017 ...OpenGL 3.2 ist leider Pflicht, da zum Rendern u.A. geometry shader verwendet werden.... Vielleicht liegt es an der OpenGL Version auf dem Win7 Rechner.
Abdul K. schrieb: > OpenGL 6.14 liegt vor. Kann nicht sein. OpenGL 4.6 ist letzter Stand, siehe https://www.khronos.org/registry/OpenGL/index_gl.php
Abdul K. schrieb: > Anyway, auf meinen Win7 Rechner stürzt es ab mit einer Fehlermeldung. Ich lehne mich jetzt hier mal entspannt zurück und verweise darauf dass Windows 7 inzwischen am Ende des Lebenszyklus angelangt ist. Abdul K. schrieb: > Habe noch nicht so viel > probiert. Wenn ich das Beispielprojekt X-Transmitter öffne, fliegen die > SMD-Bauelemente über der Platine. Haben also eine falsche > Höheninformation. Sieht lustig aus, aber was mache ich falsch? Ein Screenshot wäre an der Stelle hilfreich. Abdul K. schrieb: > Ich habe den Standard-Pool geladen. > Wenn ich nun ein eigenes Bauelement definiere, wo landet es? Muß ich > einen eigenen lokalen Pool sinnvollerweise anlegen? Kommt drauf an, im großen und ganzen sind drei Modelle denkbar: 1. Git benutzen und die eigenen Bauteile auf einem eignen Branch halten 2. Einen eigenen Pool anlegen und den Standardpool inkludieren 3. Die Bauteile im Standardpool hinzufügen und da lassen.
Angehängte Dateien:
-
OpenGL_version.png
78 KB
Also hier sagt das Kontroll von AMD. siehe Bild Lukas K. schrieb: > Abdul K. schrieb: >> Anyway, auf meinen Win7 Rechner stürzt es ab mit einer Fehlermeldung. > > Ich lehne mich jetzt hier mal entspannt zurück und verweise darauf dass > Windows 7 inzwischen am Ende des Lebenszyklus angelangt ist. > Bei mir nicht, arbeite damit auch lieber als mit Win10. > Abdul K. schrieb: >> Habe noch nicht so viel >> probiert. Wenn ich das Beispielprojekt X-Transmitter öffne, fliegen die >> SMD-Bauelemente über der Platine. Haben also eine falsche >> Höheninformation. Sieht lustig aus, aber was mache ich falsch? > > Ein Screenshot wäre an der Stelle hilfreich. > gerne. Moment, anderer PC... > Abdul K. schrieb: >> Ich habe den Standard-Pool geladen. >> Wenn ich nun ein eigenes Bauelement definiere, wo landet es? Muß ich >> einen eigenen lokalen Pool sinnvollerweise anlegen? > > Kommt drauf an, im großen und ganzen sind drei Modelle denkbar: > > 1. Git benutzen und die eigenen Bauteile auf einem eignen Branch halten > 2. Einen eigenen Pool anlegen und den Standardpool inkludieren > 3. Die Bauteile im Standardpool hinzufügen und da lassen. Danke.
Abdul K. schrieb: > bla Sieht ja in der Tat recht lustig aus. Da du der erste mit dem Problem bist gehe ich jetzt mal von einem Bug im Grafiktreiber aus. Zum malen von den 3D-Modellen wird die recht neue (seit 4.2) OpenGL-Funktion glDrawElementsInstancedBaseInstance benutzt, mit der in einem einzigen Draw call alle Instanzen eines Modells gezeichnet werden können. Gut möglich dass der Treiber da bugs hat. Ist der ATI-Screenshot da von Windows 7 oder 10?
Sieht so aus als ginge es jetzt auf dem Win7 Läppi. Ich habe den Grafiktreiber aktualisiert. Von der AMD-Seite, denn Windoof selbst meinte er wäre vorher schon aktuell gewesen. OpenGL zeigt immer noch Version 6.14 . Allerdings läuft es so langsam, daß es unbenutzbar ist. Und der Fehler der fliegenden Bauelemente in der 3D-Ansicht ist auch da. Was bedeutet denn in der Pool-Verwaltung "out of date" bei einem Bauelement?
Gibts irgendwo kleinste Beispielprojekte, an denen man rumfummeln kann. Und ganz wichtig, komplette Videos, in denen eine komplette Erstellung einer Platine gezeigt wird? Das muß ja nicht viel sein, ein NE555 mit bisserl Hühnerfutter und Steckverbinder, fertig. Wo findet man die Tastendefinitionen? Wie kann man zoomen ohne Scrollrad? Wie definiert man die Platinengröße? Werden Änderungen transparent zwischen Schaltplan und Layout aktualisiert? Ein Bauelement im Layout eingefügt ohne Schaltplan, scheint gar nicht zu funktionieren. Boah, ich als professioneller Layouter finde erstmal garnix. Einen 10K Widerstand in einer endlosen Liste aussuchen, geht eigentlich gar nicht. Fällt das nur mir auf? Dann poppt ein Fenster auf, ich solle meine Arbeit sichern. Geht aber nicht, denn Save ist deaktiviert. Fenster einfach zugemacht und wieder auf, Schaltplan noch da. Hm, aber ich habe doch nicht gesichert?? Gibt es unbegrenztes undo? Schön wäre ein Liste, wo die häufigsten Operationen kurz erklärt sind. Dann ist der Umstieg von einem anderen Programm ein Klacks. Es sind ia immer die gleichen Fragen, die sich einem stellen. Nur das Prozedere ist meist völlig unterschiedlich. Sehe es nicht als Gemeckere an.
Abdul K. schrieb: > Was bedeutet denn in der Pool-Verwaltung "out of date" bei einem > Bauelement? Wenn man ein Bauteil in einem Projekt verwendet, wird es in den cache-ordner kopiert. Wenn sich das Bauteil dann im Pool ändert wir es im cache als out of date angezeigt. Abdul K. schrieb: > Wo findet man die Tastendefinitionen? Hamburger Menü -> Help (oder ? drücken) > Wie kann man zoomen ohne Scrollrad? Mit pinch-to-zoom auf Touchscreen oder Touchpad auf unterstützten Plattformen (ob windows dazugehört weiß ich gerade nicht) > Wie definiert man die Platinengröße? Polygon im outline layer malen (leertaste drücken und nach draw polygon rectangle suchen) > Werden Änderungen transparent zwischen Schaltplan und Layout > aktualisiert? Wenn den Schaltplan speicherst wird auch die Netzliste gespeichert. Im Board-Editor kannst du die dann mit "reload netlist" neuladen. > Dann poppt ein Fenster auf, ich solle meine Arbeit sichern. Geht aber nicht, denn Save ist deaktiviert. Hast du einen screenshot davon? > Gibt es unbegrenztes undo? Gab es mal, ist aber nun auf 50 begrenzt, da sonst der RAM voll lief. > Ein Bauelement im Layout eingefügt ohne Schaltplan, scheint gar nicht zu > funktionieren. Ja, das muss so. > Boah, ich als professioneller Layouter finde erstmal garnix. Liegt wohl daran, dass du das Leertasten-Menü noch nicht gefunden hast. Da ist alles drin. > Einen 10K Widerstand in einer endlosen Liste aussuchen, geht eigentlich gar nicht. Fällt das nur mir auf? Dazu gibt es im Part browser den tab 'Resistors' mit parametrischer suche. Was will man mehr haben?
Beitrag #6316876 wurde von einem Moderator gelöscht.
Nach 3 Monaten ist es wieder Zeit für eine Release: https://github.com/horizon-eda/horizon/releases/tag/v1.2.0 Neu ist darin u.a.: - Action bar / toolbar für häufig benutzte Tools - Import von KiCad-Symbolen - Einfärben von Netzen im Board - Konfigurierbare Tastenkombinationen in Tools - Grid-Ursprung ist einstellbar
Falls hier noch jemand mitliest, es gibt wie geplant wieder ein neues Release: https://github.com/horizon-eda/horizon/releases/tag/v1.3.0 Details zu den neuen Funktionen gibt es in den letzten zwei Blogposts: https://blog.horizon-eda.org/progress/2020/10/29/progress-2020-09-10.html und https://blog.horizon-eda.org/progress/2020/08/29/progress-2020-07-08.html
Es ist mal wieder an der Zeit für eine neue Version: https://github.com/horizon-eda/horizon/releases/tag/v1.4.0 Neben den üblichen neuen Features und Verbesserungen sind dieses mal auch zwei wichtige Bugfixes für die Windows-Fraktion dabei: - Auf Intel-GPUs wurde der Fensterinhalt immer ein Frame zu spät angezeigt, das ist nun nicht mehr der Fall - 3D-Vorschau stürzt nicht mehr zufällig mit "gl error 1285" ab
Moin, Hab' mir die sourcen der 1.4.0 mal gezogen und versuche die auf einem BLFS-10.0 zu bauen. Da scheint mir aber verschiedenes schief zu gehen: 1.) ich hab' glm-0.9.9.8 "installiert", ich find da aber nirgends ein glm.pc file, was das horizon buildsystem aber anscheinend irgendwo haben will. 2.) wahrscheinlich geht irgendwas mit den Includepfaden schief. Ich krieg Meldungen wie:
1 | src/util/sqlite.cpp:2:10: fatal error: glib.h: No such file or directory |
2 | 2 | #include <glib.h> |
3 | | ^~~~~~~~ |
aehnlich mit sigc++ Da fehlt jeweils noch was in der Art glib-2.0 etc. im Includepfad, der dem gcc mitgegeben wird. Den ich leider nicht sehen kann, weil weder make V=1 noch VERBOSE=1 das tun, was ich gerne sowieso als default bei allen Buildsystemen haette. Gut find ich, dass in der Doku schon mal (hoffentlich) alle Abhaengigkeiten aufgefuehrt sind, besser waers' wenn da auch gleich noch Versionsnummern stuenden, ggf. min/max oder mit welchen Versionen das jeweils getestet wurde. Waere mir persoenlich natuerlich lieber als die Tipps, wie man die jeweiligen Paketmanager von zig Distries jeweils dazu bringen kann, die zu installieren. Gruss WK
Dergute W. schrieb: > Da scheint mir aber verschiedenes schief zu gehen Evtl. bekommst du schneller eine Antwort, wenn du deine Frage auf dem Discourse Forum frägst: https://horizon-eda.discourse.group/
Dergute W. schrieb: > wahrscheinlich geht irgendwas mit den Includepfaden schief. Ich > krieg Meldungen wie: Guck mal ganz oben in der Ausgabe von make, da wo pkg-config aufgerufen wird. Wenn pkg-config ein Paket nicht findet gibt's garnichts mehr aus und es gibt Folgefehler. glm ist allerdings auch ein Spezialfall: Da hat vor einiger Zeit der Maintainer das Install-Target entfernt und jede mir bekannte Distribution patcht das wieder rein. z.B. https://github.com/archlinux/svntogit-community/blob/packages/glm/trunk/PKGBUILD#L30 Keine Ahnung wie das deine Distro handhabt. Alternativ kannst du auch Version 0.9.9.5 vom glm nehmen, da ist das Install target noch drin. > Den ich leider nicht sehen kann
1 | make QUIET= |
Zeigt den Compileraufruf an.
> Versionsnummern stuenden, ggf. min/max oder mit welchen Versionen das jeweils
getestet wurde.
Bis jetzt war das noch nie ein Problem. Das älteste was noch supported
wird, ist das was bei Ubuntu 18.04 dabei ist.
Moin, Merci, das hilft schon mal weiter. Lukas K. schrieb: > Guck mal ganz oben in der Ausgabe von make, da wo pkg-config aufgerufen > wird. Wenn pkg-config ein Paket nicht findet gibt's garnichts mehr aus > und es gibt Folgefehler. Huh, fiese Falle. Ja das war hier wohl das fehlende glm.pc. Bei BLFS wird bei GLM nur ein Haufen Header nach /usr/include kopiert; die werden dann wohl auch ohne pkg-configs Segen vom gcc gefunden. Lukas K. schrieb: > make QUIET= > > Zeigt den Compileraufruf an. Na, das nenn ich mal intuitiv ;-D Schaut schon besser aus. Beim finalen linken geht grad noch was schief, da werd' ich aber heut nicht mehr dazukommen, das genauer anzugucken. Merci nochmal fuer den schnellen Tip. Gruss WK
Moin, So, wenn man zufaellig grad ein BLFS-10.0 hat und moecht' horizon-1.4.0 bauen, dann koennte das mit den jeweiligen Versionen aus dem BLFS Book fuer die libs aus dieser Liste https://horizon-eda.readthedocs.io/en/latest/build-linux.html sowie diesen Versionen von Zeugs, was nicht im BLFS-Book behandelt wird: libzmq-4.3.4 libgit2-1.1.0 opencascade-7.5.0 cppzmq-4.7.1 podofo-0.9.7 libzip-1.7.3 unter zuhilfennahme des angepappten Makefiles hinhauen. Da hab' ich entfernt, dass pkg-config auf glm.pc hofft (Gibbet nicht beim BLFS) und dafuer ein paar libs extra mitangegeben, die mutmasslich podofo braucht, aber nicht explizit Bescheid sagt. Hab mit dem dann rausfallenden Binary zwar noch keine Platine/Schaltplan erstellt, aber zumindest mal den default Pool gezogen. Gruss WK
Hi! Kommenden Donnerstag probiere ich mal etwas neues: Ich streame 2-3 Stunden, wie ich mit Horizon EDA eine Platine designe. Da es sich nur um eine kleine Platine handelt, versuche ich tatsächlich in dieser Zeitspanne mit Schaltplan und Layout fertig zu werden. Wer interessiert ist, darf mir gerne am __18.02. um 18:00 Uhr CET__ über die Schulter schauen: https://www.twitch.tv/electrifried Wenn während des Streams Fragen zur Bedienung oder dem Design auftauchen, können diese gerne im Chat des Streams gestellt werden. Dafür wird dann aber ein Twitch-Account benötigt. VG Jue
Jue schrieb: > Da es sich nur um > eine kleine Platine handelt, versuche ich tatsächlich in dieser > Zeitspanne mit Schaltplan und Layout fertig zu werden. Auch die Kreierung der Bauteile oder nur Schaltplan + Layout?
testi schrieb: >> Da es sich nur um >> eine kleine Platine handelt, versuche ich tatsächlich in dieser >> Zeitspanne mit Schaltplan und Layout fertig zu werden. > > Auch die Kreierung der Bauteile oder nur Schaltplan + Layout? Ich habe glaube ich schon alles was ich brauche im Pool. Aber wenn es von Interesse ist, kann ich auch ein Bauteil anlegen. Für ein anderes Projekt benötige ich noch ein Relais. Ich kann gerne zeigen, wie ich da vorgehe. VG Jue
Jue schrieb: > Wer interessiert ist, darf mir gerne am __18.02. um 18:00 Uhr CET__ über > die Schulter schauen: > https://www.twitch.tv/electrifried Gibt's davon eine Aufzeichnung?
Martin S. schrieb: > Jue schrieb: >> Wer interessiert ist, darf mir gerne am __18.02. um 18:00 Uhr CET__ über >> die Schulter schauen: >> https://www.twitch.tv/electrifried > > Gibt's davon eine Aufzeichnung? Wenn ich es technisch nicht versaue - ich streame das erste Mal - werde ich wohl eine Aufnahme (evtl. sogar geschnitten) auf Youtube hochladen. Ich kann aber nichts versprechen.
Heißt: Twitch bietet da nichts an, oder? Youtube-Streams werden ja automatisch? gespeichert und sind nachträglich als VoD abspielbar.
Martin S. schrieb: > Heißt: Twitch bietet da nichts an, oder? Youtube-Streams werden ja > automatisch? gespeichert und sind nachträglich als VoD abspielbar. Afaik speichert Twitch für die einfachen Accounts nur zwei Wochen ... aber wie gesagt: bin noch am lernen, wie der ganze neumodische Kram funktioniert ;)
Jürgen F. schrieb: > Martin S. schrieb: >> Heißt: Twitch bietet da nichts an, oder? Youtube-Streams werden ja >> automatisch? gespeichert und sind nachträglich als VoD abspielbar. > > Afaik speichert Twitch für die einfachen Accounts nur zwei Wochen ... Schau vorher nochmal, welche Rechte du an dem von der Plattform aufgezeichneten Stream hast - nicht dass du eine Aufzeichnung durch die eine Plattform nicht mehr selber nutzen (und damit z.B. bei einer anderern Plattform uploaden) darfst. Meine Einschätzung: lieber selber aufzeichnen und selber encodieren.
Jue schrieb: > Wer interessiert ist, darf mir gerne am __18.02. um 18:00 Uhr CET__ über > die Schulter schauen: > https://www.twitch.tv/electrifried > > Wenn während des Streams Fragen zur Bedienung oder dem Design > auftauchen, können diese gerne im Chat des Streams gestellt werden. > Dafür wird dann aber ein Twitch-Account benötigt. Coole sache! Wäre es arg viel Mehraufwand auch Fragen aus dem #horizon IRC-Channel auf freenode anzunehmen?
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.