Announcement: there is an English version of this forum on Lukas K. schrieb: > Coole sache! Wäre es arg viel Mehraufwand auch Fragen aus dem #horizon > IRC-Channel auf freenode anzunehmen? Gute Idee! Ich kann mal versuchen ein Auge parallel auf den IRC zu werfen und auch dort Fragen zu klären. Dann muss ich nicht unnötiger Weise Menschen in den Walled Garden "Twitch" locken.
Scheint ja doch geklappt zu haben mit der Aufzeichnung. Schöne Sache. Dann hab ich mal wieder was nettes auf meiner Watch-List.
Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht alleine im Stream war. Hat Spaß gemacht :) Martin S. schrieb: > Scheint ja doch geklappt zu haben mit der Aufzeichnung. Schöne Sache. > Dann hab ich mal wieder was nettes auf meiner Watch-List. Jup. Für zwei Wochen hier nachzusehen: https://www.twitch.tv/videos/919019498 Ich bin heute schon gut vorangekommen. Ich werde dann voraussichtlich nächsten Mittwoch für den Rest am streamen sein. VG Jue
Jürgen F. schrieb: > Für zwei Wochen hier nachzusehen: Wer sich's aufheben will: youtube-dl kann das auch runterladen. Sind aber wohl um die 6 GiB, meint es …
:
Bearbeitet durch Moderator
Jürgen F. schrieb: > Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht alleine im > Stream war. Hat Spaß gemacht :) Danke für den Stream, war mal schön zu sehen, dass viele den implementieren Ideen auch trotz der eher spärlichen Dokumentation verständlich sind. Im Stream sind mir einige Dinge aufgefallen, die inzwischen behoben sind: - Reichelt und Conrad zählen nun zu den unerwünschten Datenblatt-Domains - Beim Platzieren eines Bauteils im Board wird es auch korrekt im Schaltplan highlighted - Wenn man die Anzahl an Innenlagen erhöht, bekommen die in der Layer-box links auch gleich die richtige Farbe - Beim mergen von Parts werden auch Symbole mit vorausgewählt
Jürgen F. schrieb: > Danke an alle Zuseher! Hab mich sehr gefreut, dass ich nicht > alleine im > Stream war. Hat Spaß gemacht :) > > Martin S. schrieb: >> Scheint ja doch geklappt zu haben mit der Aufzeichnung. Schöne Sache. >> Dann hab ich mal wieder was nettes auf meiner Watch-List. > > Jup. Für zwei Wochen hier nachzusehen: > https://www.twitch.tv/videos/919019498 > > Ich bin heute schon gut vorangekommen. Ich werde dann voraussichtlich > nächsten Mittwoch für den Rest am streamen sein. > > VG Jue Hab gerade ein bisschen in den Stream reingesehen - echt sehr interessant und lehrreich. Vielen Dank für die Mühe! Rein aus Interesse: Gibt's eigentlich nen Grund, warum du auf Twitch und nicht auf Youtube streamst? Ich muss gestehen, dass ich Twitch jetzt nicht so auf dem Radar hatte und ich bisher auch nicht wusste, dass das auch Leute aus der Maker Szene nutzen. Was ich ein bisschen schade finde ist, dass die Videos anscheinend auf Twitch nur für 2 Wochen verfügbar sind. Hast du vor, die Videos evt. auch auf YT hochzuladen? Wäre sehr schade, wenn das Video hier nach 2 Wochen wieder verschwindet.
Habe das Video zum Anlass genommen, mal wieder ein "git pull" und einen Rebuild zu machen. Wenn ich jetzt ein altes Testprojekt öffne, bekomme ich:
1 | Seq | Level | Domain | Message; Detail |
2 | 2 | Warning | Canvas | unsupported MSAA; requested:4 actual:1 |
3 | 3 | Warning | Canvas | unsupported MSAA; requested:4 actual:1 |
4 | 4 | Warning | Canvas | unsupported MSAA; requested:4 actual:1 |
5 | 5 | Warning | Canvas | unsupported MSAA; requested:4 actual:1 |
Hmm, was will mir "unsupported MSAA" genau sagen und vor allem, was kann ich dagegen tun?
Was auch immer "MSAA" heißen mag :-) (YAA - yet another acronym), es scheint mit dem Antialiasing zu tun zu haben. Nachdem ich die Einstellungen sowohl für Schematic als auch Board auf "MSAA 1x" geändert habe, taucht die Warnung nicht mehr auf. Danke fürs Zuhören. :-) Edit: beim 3D-Viewer taucht es immer noch auf. Dafür finde ich irgendwie keine Einstellmöglichkeit.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Edit: beim 3D-Viewer taucht es immer noch auf. Dafür finde ich irgendwie > keine Einstellmöglichkeit. In der 3D-Ansicht ist das im Settings-Overlay (Knopf ist oben links) zu finden. Was hast du für eine GPU, die kein MSAA kann?
Lukas K. schrieb: > In der 3D-Ansicht ist das im Settings-Overlay (Knopf ist oben links) zu > finden. OK. > Was hast du für eine GPU, die kein MSAA kann? Gute Frage, irgendeine Radeon. Vielleicht ist da auch was fehlkonfiguriert? Bisschen seltsam im Xorg log:
1 | [ 147.933] (==) Automatically adding devices |
2 | [ 147.933] (==) Automatically enabling devices |
3 | [ 147.933] (==) Not automatically adding GPU devices |
Dafür wiederum geht 3D trotzdem verdammt gut … pciconf sagt:
1 | vgapci0@pci0:1:0:0: class=0x030000 card=0xe164174b chip=0x67791002 rev=0x00 hdr=0x00 |
2 | vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' |
3 | device = 'Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]' |
4 | class = display |
5 | subclass = VGA |
Ein xorg.conf snippet dafür ist eigentlich da … ich werd das mal untersuchen.
Habe jetzt zwar einen Radeon-Treiber von xf86 geladen bekommen, aber beim Start von Horizon gibt's dann:
1 | libGL error: MESA-LOADER: failed to retrieve device information |
2 | unknown chip id 0x6779, can't guess. |
3 | libGL error: failed to create dri screen |
4 | libGL error: failed to load driver: radeon |
Wirklich seltsam finde ich, dass aller 3D-Kram (nicht nur Horizon, auch FreeCAD etc.) gut funktioniert. Naja, weiter suchen …
Bernhard B. schrieb: > Hab gerade ein bisschen in den Stream reingesehen - echt sehr > interessant und lehrreich. Vielen Dank für die Mühe! Schön, dass es dir etwas bringt :) > Rein aus Interesse: Gibt's eigentlich nen Grund, warum du auf Twitch und > nicht auf Youtube streamst? Ich muss gestehen, dass ich Twitch jetzt > nicht so auf dem Radar hatte und ich bisher auch nicht wusste, dass das > auch Leute aus der Maker Szene nutzen. Ich schaue tatsächlich gerne den ganzen Maker-Kanälen auf Twitch zu. So war das für mich der logische Schluss auch dort zu streamen. Aber nichts ist in Stein gemeißelt. Ich bin noch sehr viel am Lernen und Ausprobieren. > Was ich ein bisschen schade finde ist, dass die Videos anscheinend auf > Twitch nur für 2 Wochen verfügbar sind. Hast du vor, die Videos evt. > auch auf YT hochzuladen? Wäre sehr schade, wenn das Video hier nach 2 > Wochen wieder verschwindet. Ich werde das Video etwas zusammendampfen - also Gestammel rausschneiden, Redepausen rausschneiden. Ich glaube die Form ist für die Nachwelt interessanter als der vollständige Stream ;) Das Ergebnis lade ich dann auf YT hoch. VG Jue
Angehängte Dateien:
Bin nun inzwischen ein gutes Stück durch dein Filmchen durch und habe versucht, das Ganze hier mal mit einem leicht anders gearteten Relais (Reed-Relais in SIL-Gehäuse) nachzuvollziehen. Worüber ich am ende stolpere ist eine Verifikationswarnung "Pin x has improper orientation". Interessanterweise bekomme ich diese nicht für das zuvor angelegte einfache Relais-Symbol, sondern nur für das hier mit der integrierten Freilaufdiode. Dafür habe ich das vorige Symbol dupliziert und die Box etwas vergrößert. Was will mir diese Warnung sagen?
Jörg W. schrieb: > Was will mir diese Warnung sagen? Ich vermute mal, dass dein Symbol nicht horizontal zentriert ist. Die helle Box im Hintergrund ist die um den Ursprung zentrierte bounding box, auf der alle Pins liegen sollten. Bei dir kommen die Pins rechts auf der oberen/unteren Kante zu liegen und sollten daher nach dem Symbol-Regeln nach oben/unten zeigen. Gtk im Motif-fensterrahmen ist ja auch eine sehr interessante Kombination ;) Eigentlich sollte bei dem Rules-Fenster da Gtk deinen Fenstermanager davon überzeugen, dass dieses Fenster keinen Rahmen braucht, weil ja Gtk den schon malt. Was ist eigentlich mit den schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus.
Lukas K. schrieb: > Jörg W. schrieb: >> Was will mir diese Warnung sagen? > > Ich vermute mal, dass dein Symbol nicht horizontal zentriert ist. Die > helle Box im Hintergrund ist die um den Ursprung zentrierte bounding > box, auf der alle Pins liegen sollten. Ah OK. Das erklärt es: ich hatte die Box nach links vergrößert, um Platz für die Freilaufdiode zu bekommen. Da hätte ich sie auch nach rechts vergrößern müssen. Habe ich nun getan, jetzt ist das alles OK. Ich fände es gut, wenn es dafür irgendwo bei den Fehlermeldungen eine Hilfe gäbe, die ein paar Details erklärt. Mir ist ohnehin gerade nicht ganz klar, wo diese Rules denn genau stehen (ansonsten hätte ich dort mal nachgeschaut, was sie genau besagen). > Gtk im Motif-fensterrahmen ist ja auch eine sehr interessante > Kombination ;) Ich bin seit mehr als 25 Jahren halt fvwm-Nutzer. Damals war Motif-Look das, dem sie alle nachgeeifert hatten, und fvwm hatte das ganz gut hin bekommen. Irgendwie hat dieser Windowmanager schlicht alles, was ich brauche, und ich habe mich gut dran gewöhnt. Hatte auf meinem neuen Dienst-Laptop (auf dem Unbuntu läuft, anders als mein handgestricktes FreeBSD hier) mal eine Weile lang Mate als Desktop laufen, aber irgendwie bin ich auch dort dann zu fvwm zurück. > Eigentlich sollte bei dem Rules-Fenster da Gtk deinen > Fenstermanager davon überzeugen, dass dieses Fenster keinen Rahmen > braucht, weil ja Gtk den schon malt. Wobei das eben eigentlich dem Sinn von X11 nicht entspricht: Dekoration war schon immer Aufgabe des Windowmanagers. Der bestimmt damit auch das look&feel. > Was ist eigentlich mit den > schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus. Nicht nur die, alle Gtk-Icons. Ich bin mir nicht ganz sicher, ob das nur ein verunglückter Gtk-Build ist, oder ob das mit den weiter oben ja schon festgestellten Problemen zusammenhängt, dass der X-Server beim Start die Grafikkarte nicht erkannt hatte. Bin noch nicht dazu gekommen, mich mal auszuloggen und den X-Server neu zu starten. Ist so lästig, sind so viele Dinge offen, die man danach dann wieder neu zusammen suchen müsste. ;-) Da diese verhunzten Icons ein reiner Schönheitsfehler sind, ist mir das auch nicht allzu wichtig. (Der Radeon-Treiber im X-Server wäre mir schon wichtiger, aber irgendwas spinnt auch an einem SATA-Kabel, ich würde dann wohl die Kiste gleich mal komplett booten wollen.)
Jörg W. schrieb: >> Was ist eigentlich mit den >> schließen-icons schief gelaufen? Die sehen ein wenig verunglückt aus. > > Nicht nur die, alle Gtk-Icons. Ich bin mir nicht ganz sicher, ob das nur > ein verunglückter Gtk-Build ist, oder ob das mit den weiter oben ja > schon festgestellten Problemen zusammenhängt, dass der X-Server beim > Start die Grafikkarte nicht erkannt hatte. Nö, auch nach dem Neustart sind die noch verhunzt. Anyway, wollte nun einen Pull Request für mein hübsches SIL-Relais machen, aber:
1 | error = authorization_pending |
2 | error_description = The+authorization+request+is+still+pending. |
3 | error_uri = https://docs.github.com/developers/apps/authorizing-oauth-apps#error-codes-for-the-device-flow |
4 | |
5 | access_token = b235c6e384957d941a680ff7f6f5e989160a60b8 |
6 | scope = public_repo,workflow |
7 | token_type = bearer |
8 | |
9 | get prs |
10 | merge 3d_models/relay/meder/SIL05-1A72-71D.step |
11 | merge entities/relay/SPST-NO Relay-polarized.json |
12 | merge packages/manufacturer/meder/sil05-1a72-71d/package.json |
13 | merge parts/relay/meder/SIL05-1A72-71D.json |
14 | merge symbols/relay/SPST-NO Relay polarized.json |
15 | merge units/relay/SPST-NO Relay (polarized).json |
16 | Assertion failed: (buf && sig), function git_signature__writebuf, file /usr/ports/devel/libgit2/work/libgit2-1.0.1/src/signature.c, line 305. |
17 | |
18 | [1] Abort horizon-eda (core dumped) |
Core-File liegt noch rum, falls du denkst, dass man dem noch was entnehmen kann. Coredump ist reproduzierbar. Ich kann den pull request natürlich noch mit der Hand erzeugen auf Github.
Jörg W. schrieb: >> Was hast du für eine GPU, die kein MSAA kann? > > Gute Frage, irgendeine Radeon. Selbst mit passendem Treiber macht sie aber nur MSAA 1x.
Jörg W. schrieb: > Core-File liegt noch rum, falls du denkst, dass man dem noch was > entnehmen kann. Ein Backtrace wäre ganz nützlich. So ins blaue hineingeraten, guck mal ob in https://github.com/horizon-eda/horizon/blob/master/src/pool-prj-mgr/pool-mgr/pool_remote_box.cpp#L1241 signature nicht vielleicht ein nullpointer ist. Allerdings sehe ich gerade nicht so recht, wie das auftreten könnte, da in dem Dialog davor eigentlich vom remote-repo user.name und user.email gesetzt werden. Wäre vielleicht doch besser gewesen, den return-code von git_signature_default zu überprüfen.
Tja, jetzt habe ich es aus dem Buildverzeichnis unter GDB-Steuerung laufen lassen, und alles rennt durch. :-/ Hmm, damit hast du jetzt meinen ersten Pool-Pullrequest. :-) Hier ist der Stacktrace aus dem Coredump:
1 | Core was generated by `horizon-eda'. |
2 | Program terminated with signal SIGABRT, Aborted. |
3 | |
4 | warning: Unexpected size of section `.reg-xstate/102284' in core file. |
5 | #0 thr_kill () at thr_kill.S:3 |
6 | 3 RSYSCALL(thr_kill) |
7 | [Current thread is 1 (LWP 102284)] |
8 | (gdb) bt |
9 | #0 thr_kill () at thr_kill.S:3 |
10 | #1 0x0000000803b4b094 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 |
11 | #2 0x0000000803ac1289 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 |
12 | #3 0x0000000803b3b2a1 in __assert (func=<optimized out>, file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:51 |
13 | #4 0x0000000803851106 in () at /usr/local/lib/libgit2.so.1.0 |
14 | #5 0x00000008037dc494 in () at /usr/local/lib/libgit2.so.1.0 |
15 | #6 0x00000008037da932 in () at /usr/local/lib/libgit2.so.1.0 |
16 | #7 0x00000008037dac9f in git_commit_create () at /usr/local/lib/libgit2.so.1.0 |
17 | #8 0x0000000000649e89 in horizon::PoolRemoteBox::create_pr_thread() (this=0x80766ed00) at src/pool-prj-mgr/pool-mgr/pool_remote_box.cpp:1241 |
18 | #9 0x000000000065336d in _ZNSt3__18__invokeIMN7horizon13PoolRemoteBoxEFvvEPS2_JEvEEDTcldsdeclsr3std3__1E7forwardIT0_Efp0_Efp_spclsr3std3__1E7forwardIT1_Efp1_EEEOT_OS6_DpOS7_ |
19 | (__f=@0x807407c08: (void (horizon::PoolRemoteBox::*)(horizon::PoolRemoteBox * const)) 0x649810 <horizon::PoolRemoteBox::create_pr_thread()>, __a0=@0x807407c18: 0x80766ed00) |
20 | at /usr/include/c++/v1/type_traits:3480 |
21 | #10 std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (horizon::PoolRemoteBox::*)(), horizon::PoolRemoteBox*, 2ul>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (horizon::PoolRemoteBox::*)(), horizon::PoolRemoteBox*>&, std::__1::__tuple_indices<2ul>) (__t=...) at /usr/include/c++/v1/thread:273 |
22 | #11 std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (horizon::PoolRemoteBox::*)(), horizon::PoolRemoteBox*> >(void*) (__vp=0x807407c00) at /usr/include/c++/v1/thread:284 |
23 | #12 0x000000080115afac in thread_start (curthread=0x808044000) at /usr/src/lib/libthr/thread/thr_create.c:292 |
24 | #13 0x0000000000000000 in () |
25 | (gdb) up |
26 | #1 0x0000000803b4b094 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 |
27 | 52 return (__sys_thr_kill(id, s)); |
28 | (gdb) |
29 | #2 0x0000000803ac1289 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 |
30 | 67 (void)raise(SIGABRT); |
31 | (gdb) |
32 | #3 0x0000000803b3b2a1 in __assert (func=<optimized out>, file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:51 |
33 | 51 abort(); |
34 | (gdb) |
35 | #4 0x0000000803851106 in ?? () from /usr/local/lib/libgit2.so.1.0 |
36 | (gdb) |
37 | #5 0x00000008037dc494 in ?? () from /usr/local/lib/libgit2.so.1.0 |
38 | (gdb) |
39 | #6 0x00000008037da932 in ?? () from /usr/local/lib/libgit2.so.1.0 |
40 | (gdb) |
41 | #7 0x00000008037dac9f in git_commit_create () from /usr/local/lib/libgit2.so.1.0 |
42 | (gdb) |
43 | #8 0x0000000000649e89 in horizon::PoolRemoteBox::create_pr_thread (this=0x80766ed00) at src/pool-prj-mgr/pool-mgr/pool_remote_box.cpp:1241 |
44 | 1241 if (git_commit_create(&new_commit_oid, repo, "HEAD", signature, signature, "UTF-8", pr_title.c_str(), tree, |
45 | (gdb) p signature |
46 | $1 = {ptr = 0x0,
|
47 | free_fn = {<std::__1::__function::__maybe_derive_from_unary_function<void (git_signature *)>> = {<std::__1::unary_function<git_signature*, void>> = {<No data fields>}, <No data fields>}, <std::__1::__function::__maybe_derive_from_binary_function<void (git_signature *)>> = {<No data fields>}, __f_ = {__buf_ = {
|
48 | __lx = "H=\203\000\000\000\000\000\300\001C", '\000' <repeats 20 times>}, __f_ = 0x7fffdf5f8dc0}}} |
49 | (gdb) p pr_title |
50 | $2 = "Meder SIL05-1A72-71D Reed relay" |
Sieht also schon so aus, als wäre signature::ptr NULL.
Ich glaube, beim vorigen Versuch hatte ich das Feld mit der Mailadresse nicht ausgefüllt. Kann das die Ursache sein?
Jürgen F. schrieb: > Danke an alle Zuseher! Danke dir nochmal für deine Aktivität! Hat mich dazu bewogen, mein Horizon mal auf aktuellen Stand zu bringen und wirklich mal wieder zu testen – siehe ersten Merge Request für den Pool. Ganz zufällig :) habe ich mir auch ein Relais rausgesucht, aber ein Reed-Relais, von dem ich gerade noch 5 Stück rumliegen habe (und welches man auch aktuell noch kaufen kann). Was mir bei der Datenblatt-Geschichte auffällt: könnte man dafür (oder ist vielleicht schon?) einen lokalen Cache einrichten, in dem die die runter geladenen PDFs zwischengespeichert werden? Dann muss man erstens nicht jedesmal das Netz dafür belästigen, und zweitens kann ich mir die gecacheten Datenblätter halt auch in der Regionalbahn in Hinterposemuckel noch ansehen, wo meine Internetverbindung vielleicht gerade nur mit viel Glück von einer 30 km entfernten polnischen GSM-Basisstation erbracht wird. (Tatsächlich schon so erlebt in der Uckermark.)
Was mir an Horizon generell auffällt: die 3D-Darstellung ist um mindestens eine Größenordnung schneller als die von Kicad. Liegt das daran, dass Lukas hier von vornherein (gab damals viele Diskussionen) auf neuere OpenGL-Versionen gesetzt hat?
Hmm, bei den vielen offenen Pull-Requests auf Github bin ich mir gerade nicht ganz sicher: gibt es wirklich noch nirgends ein SOT-23 Package? Ich sehe SOT-23-5 und SOT-23-6, aber kein Standard-Package mit 3 Pins.
Jörg W. schrieb: > Kann das die Ursache sein? Ja, war es. Wird nun im "Confirm PR"-Dialog überprüft. Jörg W. schrieb: > einen lokalen Cache einrichten, in dem die die > runter geladenen PDFs zwischengespeichert werden? Die Idee hatte ich auch mal gehabt. Wenn jemand anders die Idee auch hat, kann sie ja so schlecht nicht sein. Jörg W. schrieb: > die 3D-Darstellung ist um > mindestens eine Größenordnung schneller als die von Kicad. Liegt das > daran, dass Lukas hier von vornherein (gab damals viele Diskussionen) > auf neuere OpenGL-Versionen gesetzt hat Ich hatte die 3D-Darstellung von KiCad nie als übermäßig langsam empfunden. Ich hab gerade mal einen blick in den 3D-Code von KiCad geworfen und die verwenden tatsächlich die doch gut abgehangenen display lists. Dank modernerem OpenGL werden in Horizon durch Verwendung von Instancing alle Bauteile mit dem selben Modell in einem Rutsch gezeichnet. Auch ist der 3D-Code in Horizon erheblich schlanker: Ein wc -l der sourcen von der 3D-Ansicht in KiCad ergibt ca. 25kLOC, bei mir sind's ca. 3700, wobei da noch Code zum ausrichten oder projizieren von 3D-Modellen drin ist. Jörg W. schrieb: > gibt es wirklich noch nirgends ein SOT-23 Package? > Ich sehe SOT-23-5 und SOT-23-6, aber kein Standard-Package mit 3 Pins. Ich meine mich zu erinnern, das mal in einen Pull request gesehen haben, weiß leider nicht mehr welcher.
Lukas K. schrieb: > Wenn jemand anders die Idee auch hat, kann sie ja so schlecht nicht > sein. :-))
Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer noch "halbfertig" drüber steht. ;-) Wenn du willst, kann ich auch den Titel des initialen Postings mal ändern. Der geänderte Titel erscheint ja dann in der Threadliste.
Lukas K. schrieb: > Ich hab gerade mal einen blick in den 3D-Code von KiCad geworfen und die > verwenden tatsächlich die doch gut abgehangenen display lists. Dank > modernerem OpenGL werden in Horizon durch Verwendung von Instancing alle > Bauteile mit dem selben Modell in einem Rutsch gezeichnet. Ich weiß nicht mehr, ob das schonmal gefragt wurde, aber welchen Hintergrund hast du eigentlich? Das Projekt ist absolut nicht trivial und spielt imho in der Profi Liga aus Entwicklerperspektive. Ich hätte dich in die Richtung hauptberuflicher Dev gesehen aber dafür ist das Thema irgendwie zu elektrotechnisch. Was ist denn deine biographie? Von 1000 Menschen, die sich an so eine Software heranwagen, schaffen vielleicht 10 ein brauchbares Ergebnis. Horizon ist aber gefühlt ein bis zwei Klassen über brauchbar. Und woher nimmst du die Zeit?
Martin S. schrieb: > Das Projekt ist absolut nicht trivial > und spielt imho in der Profi Liga aus Entwicklerperspektive. Da bin ich absolut mit dir einverstanden. Soweit ich mal in einem Talk von Lukas auf YouTube gesehen habe hat er Elektrotechnik studiert (und hat vor ~5 Jahren abgeschlossen, mit einer Entwicklung welche er in einer frühen Version von Horizon zeichnen durfte)
Gibt es eigentlich einen Ort wo man dir etwas Geld schicken kann (z.B. Patreon, ...)? Ich bezahle gerne etwas fü gute Software, und finde es nobel, dass du es erstens als OS anbietest und zweitens nirgends etwas über spenden geschrieben hast.
Eine Frage kommt mir gerade in den Sinn: Ich habe hier eine Datenbank (PostgresQL), in der ich so gut wie alle meiner SMD-Bauteile katalogisiert habe. Primärschlüssel der Datenbank ist letztlich einfach eine laufende Nummer, die dann als so eine Art "Lagerhaltungsnummer" fungiert. (Im Moment noch ziemlich chaotisch im "Lager". :) Wenn ich mir nun einen Widerstand oder Kondensator in die Schaltung einplane, würde ich natürlich vorzugsweise einen solchen nehmen (Wert, Bauform), der bereits "im Lager" ist. U.U. würde ich halt beispielsweise von der "Standardbauform" (derzeit 0603 bei mir) abweichen, wenn der gewünschte Wert in großer Stückzahl in 0805 gerade da ist. Oder, mein einziger Mini-MELF-Widerstand (aber davon dann knapp 200 Stück) hat 36,5 kΩ. Könnte man oftmals überall da benutzen, wo man jetzt gerade "nach Nase" einen mit 33 kΩ einsetzen würde. Dafür wäre es cool, wenn man im Pool dafür irgendein Attribut hinterlegen könnte und dann danach filtern. Die Verbindung zur PgSQL-DB muss nicht unbedingt "live" sein, ich könnte mir auch vorstellen, dass per Batch irgendwie nächtlich zu propagieren oder immer nur dann manuell, wenn ich mal wieder "shoppen" war.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer > noch "halbfertig" drüber steht. ;-) Wenn mir ein besserer Titel einfallen würde... Unpassende Threadnamen gehören ja schon fast zum guten Ton hier, man denke nur an "Brauche Hilfe beim Bau eine Uhr". Martin S. schrieb: > Ich weiß nicht mehr, ob das schonmal gefragt wurde, aber welchen > Hintergrund hast du eigentlich? Das Projekt ist absolut nicht trivial > und spielt imho in der Profi Liga aus Entwicklerperspektive. Mit Elektronik angefangen, dann Richtung Software abgerutscht. Aus Software-Sicht ist Horizon EDA eigentlich nichts herausragendes, alles algorithmisch annnährend komplexe wie z.B. Polygonoperationen oder der push&shove Router und Airwire-Berechnung kommt aus Libraries, bzw. aus KiCad. Die 3D-Ansicht entstand u.a. durch Nachprogrammieren von OpenGL-Tutorials wie https://open.gl/. Jörg W. schrieb: > Dafür wäre es cool, wenn man im Pool dafür irgendein Attribut > hinterlegen könnte und dann danach filtern. Das einfachste könnte sein, mit einem Skript alles vorhandene Hühnerfutter zu erzeugen. Kann z.B. so aussehen: https://github.com/horizon-eda/horizon-pool/blob/master/scripts/panasonic-erj/gen.py Wichtig ist dabei, dass die UUID gleich bleibt. Eine anderer Ansatz ist, einen eigenen StockInfoProvider zu implementieren, der dann mit deiner Datenbank redet und so abfragt was gerade da ist. Wäre dann an der Stelle von https://horizon-eda.readthedocs.io/en/latest/feature-overview.html#stock-information
Lukas K. schrieb: >> Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer >> noch "halbfertig" drüber steht. ;-) > > Wenn mir ein besserer Titel einfallen würde... Wie wäre es schlicht und einfach mit "Horizon-EDA"? > Mit Elektronik angefangen, dann Richtung Software abgerutscht. Willkommen im Klub. :-) > Eine anderer Ansatz ist, einen eigenen StockInfoProvider zu > implementieren, der dann mit deiner Datenbank redet und so abfragt was > gerade da ist. Wäre dann an der Stelle von > https://horizon-eda.readthedocs.io/en/latest/feature-overview.html#stock-information Schau ich mir mal an, klingt zumindest passend von der Richtung her.
Kurze schamlose Eigenwerbung: Heute bin ich um 18:00 Uhr wieder online und bastle weiter mit Horizon EDA rum. Thema heute: einen USB-Seriell-Adapter für den Debug-Header zusammenklicken. Speziell ist heute, dass wir uns mit USB beschäftigen und somit differentielle Leitungen auf dem PCB verlegen werden. 03.03.21 18:00 Uhr - https://www.twitch.tv/electrifried Mein Grober Plan für die nächsten Wochen wird übrigens dann etwas Software-lastiger. Die Mikrocontroller bekommen ein RTOS verpasst, mit dem ich mich auch schon ein bisschen länger beschäftigt habe: https://riot-os.org/
Hi! Ich habe heute (mal wieder) Horizon (versucht) zu kompilieren. Leider bleibt es in der Datei zmq_helper.cpp stecken:
1 | src/util/zmq_helper.cpp: In function ‘void horizon::zmq_helper::subscribe_int(zmq::socket_t&, uint32_t)’: |
2 | src/util/zmq_helper.cpp:33:10: error: ‘class zmq::socket_t’ has no member named ‘set’ |
3 | 33 | sock.set(zmq::sockopt::subscribe, buf); |
4 | | ^~~ |
5 | src/util/zmq_helper.cpp:33:19: error: ‘zmq::sockopt’ has not been declared |
6 | 33 | sock.set(zmq::sockopt::subscribe, buf); |
7 | | ^~~~~~~ |
8 | src/util/zmq_helper.cpp: In function ‘Glib::RefPtr<Glib::IOChannel> horizon::zmq_helper::io_channel_from_socket(zmq::socket_t&)’: |
9 | src/util/zmq_helper.cpp:42:20: error: ‘class zmq::socket_t’ has no member named ‘get’ |
10 | 42 | auto fd = sock.get(zmq::sockopt::fd); |
11 | | ^~~ |
Anscheinend funktioniert die Versions-Erkennung nicht richtig. Kommentiere ich diese aus, läuft der build weiter
1 | #include "zmq_helper.hpp" |
2 | |
3 | //#ifdef CPPZMQ_VERSION |
4 | //#if CPPZMQ_VERSION >= ZMQ_MAKE_VERSION(4, 3, 1) |
5 | //#define V431 |
6 | //#endif |
7 | //#endif |
8 | |
9 | namespace horizon::zmq_helper {
|
10 | ... |
Leider gibts dann ein paar Warnings, angeblich habe ich Version >=4.3.1 von zmq. Lt. apt habe ich libzmq3-dev (4.3.2-2ubuntu1). Kann es sein, dass die open angemeckerte get/set Methoden erst in einer späteren Version vom zmq eingebaut wurden? Oder in 4.3.2 schon wieder angeschafft?
1 | src/util/zmq_helper.cpp: In function ‘bool horizon::zmq_helper::recv(zmq::socket_t&, zmq::message_t&)’: |
2 | src/util/zmq_helper.cpp:16:26: warning: ‘bool zmq::detail::socket_base::recv(zmq::message_t*, int)’ is deprecated: from 4.3.1, use recv taking a reference to message_t and recv_flags [-Wdeprecated-declarations] |
3 | 16 | return sock.recv(&msg); |
4 | | ^ |
5 | In file included from src/util/zmq_helper.hpp:2, |
6 | from src/util/zmq_helper.cpp:1: |
7 | /usr/include/zmq.hpp:1407:10: note: declared here |
8 | 1407 | bool recv(message_t *msg_, int flags_ = 0) |
9 | | ^~~~ |
10 | src/util/zmq_helper.cpp: In function ‘bool horizon::zmq_helper::send(zmq::socket_t&, zmq::message_t&)’: |
11 | src/util/zmq_helper.cpp:25:25: warning: ‘bool zmq::detail::socket_base::send(zmq::message_t&, int)’ is deprecated: from 4.3.1, use send taking message_t and send_flags [-Wdeprecated-declarations] |
12 | 25 | return sock.send(msg); |
13 | | ^ |
14 | In file included from src/util/zmq_helper.hpp:2, |
15 | from src/util/zmq_helper.cpp:1: |
16 | /usr/include/zmq.hpp:1326:10: note: declared here |
17 | 1326 | bool send(message_t &msg_, |
18 | | ^~~~ |
Ach ja: XUbuntu 20.04. horizon lässt sich dann starten, habe aber nicht intensiv getestet! Übrigens danke fürs programmieren von Horizon!
Danke fürs Teilen, ich denke, es ist einen Versuch wert.
Jörg schrieb >Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer >noch "halbfertig" drüber steht. ;-) Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des Understatements. Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es wohltuend, mal das Gegenteil zu erleben.
chris_ schrieb: > Understatements Understatement ist echt eine Untertreibung für das, wass diese One-man-show in nichtmal der Hälfte der Zeit aus dem Boden gestampft hat. Ich müsste wahrscheinlich die nächsten 30 Jahre nonstop programmieren lernen, um das zustande zu bringen. Und hätte dann vermutlich schlichtweg keine Lust dazu :-)
> Kann es sein, dass die open angemeckerte get/set Methoden erst in einer späteren Version vom zmq eingebaut wurden? Oder in 4.3.2 schon wieder angeschafft? Danke für den Hinweis, tatsächlich war die Versionserkennung bei mir falsch. Die get/set gibt's erst ab 4.7.0 und nicht schon ab 4.3.1. Doch damit es leider nicht getan: Die Spezialisten von Ubuntu haben statt ein Release von cppzmq zu paketieren, wohl das genommen, was irgendwann auf deren master-Branch rumlag. Das gibt sich zwar als 4.7.0 aus, hat aber die benötigten Funktionen noch nicht. Deswegen tut es auch mit eigentlich korrekter Versionserkennung auf fast keinem Ubuntu: https://github.com/horizon-eda/horizon/runs/2605278090?check_suite_focus=true Magst du einen Bugreport bei Ubuntu aufmachen, oder soll ich? Eigentlich ist der der Eiertanz mit Versionserkennung nur drin, um nervige deprecation-Warnings beim Bauen zu vermeiden...
Beitrag #6695376 wurde von einem Moderator gelöscht.
> Magst du einen Bugreport bei Ubuntu aufmachen, oder soll ich? Das Problem hat schon bei Debian seinen Lauf genommen, ich hab mal einen Bug aufgemacht: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988725
Habe gerade neue Updates auf mein Linux gezogen und horizon Versucht neu zu bauen (hing voher wegen zmq). Dabei kam es zu einem neuen Fehler und ich habe
1 | #include <optional> |
in "src/parameter/program.hpp" und "src/widgets/parameter_set_editor.hpp" einfügen müssen. Damit war "gcc 11.1.0" zufrieden.
neuer PIC Freund schrieb im Beitrag #6700866: > Damit war "gcc 11.1.0" zufrieden. Danke für die Erinnerung daran, auf meinem Arch Linux mal wieder updates zu installieren ;) Kam gerade noch rechtzeitig für das bevorstehende 2.0 Release.
Es ist soweit, Version 2.0 ist da: https://github.com/horizon-eda/horizon/releases/tag/v2.0.0 Einen Überblick über die neuen Features gibt es im Blog: https://blog.horizon-eda.org/new/2021/05/31/whats-new-2.0.html
chris_ schrieb: > Jörg schrieb >>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer >>noch "halbfertig" drüber steht. ;-) > > Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des > Understatements. > Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es > wohltuend, mal das Gegenteil zu erleben. Mich verwirrt es aber ... Ist es nun eher eine Alpha oder schon für den produktiven Einsatz geeignet?
Martin schrieb: > chris_ schrieb: >> Jörg schrieb >>>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer >>>noch "halbfertig" drüber steht. ;-) >> >> Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des >> Understatements. >> Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es >> wohltuend, mal das Gegenteil zu erleben. > > Mich verwirrt es aber ... > > Ist es nun eher eine Alpha oder schon für den produktiven Einsatz > geeignet? und warum genau, folgst Du dann nicht dem Link im ersten Post und schaust den Zustand des Projektes an? Hier für dich der Link direkt zur Release Seite, in der Hoffnung, dass dies Deine Verwirrung auflöst: https://github.com/horizon-eda/horizon/releases
Ralf M. M. schrieb: > Martin schrieb: >> chris_ schrieb: >>> Jörg schrieb >>>>Lustig, dass aufgrund des ellenlangen Threads nun nach 4 Jahren immer >>>>noch "halbfertig" drüber steht. ;-) >>> >>> Also ich finde den Thread-Titel sehr lustig. Mir gefällt diese Art des >>> Understatements. >>> Viele übertreiben ja bei der Beschreibung ihrer Werke und da ist es >>> wohltuend, mal das Gegenteil zu erleben. >> >> Mich verwirrt es aber ... >> >> Ist es nun eher eine Alpha oder schon für den produktiven Einsatz >> geeignet? > > und warum genau, folgst Du dann nicht dem Link im ersten Post und > schaust den Zustand des Projektes an? > > Hier für dich der Link direkt zur Release Seite, in der Hoffnung, dass > dies Deine Verwirrung auflöst: > https://github.com/horizon-eda/horizon/releases Naja, die Reife eines Projekts abzuschätzen ist nicht so einfach und nicht jeder hat die Zeit, es erstmal nen Tag zu testen. Und um das so wirklich einzuschätzen braucht man etwas Einarbeitung. Ich habe das vorhin auch gemacht und festgtestellt, dass es eine Version 2.0 gibt. Dass OSS sich mit Versionsnummer >1.0 noch nicht als produktionsreif sieht, habe ich auch schon gesehen. Und da im Betreff sogar explizit halbfertig steht, finde ich die Frage mehr als gerechtfertigt und so einer schroffen Antwort unwürdig. Bei dieser Frage ist außerdem ein eventuelles Statement regelmäßiger Nutzer oder sogar des Autors deutlich hilfreicher als ne halbe Stunde Changelog lesen und rumprobieren.
Jemand schrieb: > und nicht jeder hat die Zeit, es erstmal nen Tag zu testen Dann bist du bei EDA komplett falsch. Kommerzielle EDA-Tools kannst du kaum unter einer Woche Einarbeitungszeit benutzen. Den Tag wirst du dir schon gönnen müssen um zu sehen, ob du damit klar kommst. Da helfen auch keine Einschätzungen anderer Nutzer (die ja dann typischerweise sehr wohl bereits damit klar kommen).
Jörg W. schrieb: > Jemand schrieb: >> und nicht jeder hat die Zeit, es erstmal nen Tag zu testen > > Dann bist du bei EDA komplett falsch. > > Kommerzielle EDA-Tools kannst du kaum unter einer Woche > Einarbeitungszeit benutzen. > > Den Tag wirst du dir schon gönnen müssen um zu sehen, ob du damit klar > kommst. Da helfen auch keine Einschätzungen anderer Nutzer (die ja dann > typischerweise sehr wohl bereits damit klar kommen). Okay, der Tag war auch sportlich geschätzt, da hast du Recht. Effektiv verstärkt dieser Einwand die Aussage aber noch. In obigem Post ging es ja eher um die Ausgereiftheit. Da finde ich zumindest es echt hilfreich, andere Meinungen zu hören. Insbesondere, wenn die Urheber der Meinungen schon geübter mit der Software sind.
Jemand schrieb: > oder sogar des Autors deutlich hilfreicher als ne halbe Stunde > Changelog lesen und rumprobieren. Gerne doch. Bereits vor fast 3 Jahren habe ich damit das hier layoutet: https://github.com/carrotIndustries/x-band-tx/ Wobei allerdings anzumerken ist, dass Leute auch schon mit weitaus primitiverer Software komplexere Boards entwickelt haben. Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit, spätestens seit Version 1.0 geeignet. Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf dem Buckel haben ist natürlich der geringere Bauteilvorrat und das Fehlen von Dokumentation jenseits der auf https://docs.horizon-eda.org/ Auch ist die wahrscheinlich geringer, dass jemand vor dir ein Problem schonmal hatte und dazu eine Lösung gefunden hat.
Lukas K. schrieb: > Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf > dem Buckel haben ist natürlich der geringere Bauteilvorrat Na klar, in der Werbung zählen nur große Zahlen :( Im Vergleichstest muss man aber alle Punkte gewichten und Bauteilevorrat sollte maximal zu 1% ins Testergebnis einfließen. Wenn man das anders bewertet, kommt so ein Schrott wie die Eagle-Bibliotheken dabei raus. Der Vorrat sollte groß genug sein, dass für jedes Feature ein Beispiel dabei ist. Und das auch nur, weil zu einem guten Handbuch eben auch Beispiele gehören. 3854 verschiedene Stecker (Eagle) verschwenden nur Speicherplatz und der eine, den ich jetzt brauche, ist doch nicht dabei oder, noch schlimmer, unbrauchbar bis falsch.
Lukas K. schrieb: > Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit, > spätestens seit Version 1.0 geeignet. Dann wäre es vielleicht doch gut, wenn ein Moderator den Titel des Ursprungsbeitrags mal anpassen würde. Er hat zwar schon Kultstatus, aber um neue Nutzer anzuziehen, ist "halbfertig" kein guter Werbetext.
Max G. schrieb: > Dann wäre es vielleicht doch gut, wenn ein Moderator den Titel des > Ursprungsbeitrags mal anpassen würde. done
Lukas hat meine Frage jetzt schon beantwortet. Danke und einen Daumen hoch für dein Projekt. Mit dem Einarbeiten bekomme ich schon hin. Ich kann auch ein paar Fehler in kauf nehmen. Aber wenn es quasi nicht möglich wäre am Ende eine funktionstüchtigen Schaltplan und eine Platiene heraus zu bekommen würde ich mir die Arbeit NOCH nicht machen mich einzuarbeiten.
Lukas K. schrieb: > Jemand schrieb: >> oder sogar des Autors deutlich hilfreicher als ne halbe Stunde >> Changelog lesen und rumprobieren. > > Gerne doch. Bereits vor fast 3 Jahren habe ich damit das hier layoutet: > https://github.com/carrotIndustries/x-band-tx/ Wobei allerdings > anzumerken ist, dass Leute auch schon mit weitaus primitiverer Software > komplexere Boards entwickelt haben. > > Für kleine bis mittelgroße Projekte ist Horizon EDA seit einiger Zeit, > spätestens seit Version 1.0 geeignet. > > Nachteil gegenüber anderen Programmen, die schon etliche Jahre mehr auf > dem Buckel haben ist natürlich der geringere Bauteilvorrat und das > Fehlen von Dokumentation jenseits der auf https://docs.horizon-eda.org/ > Auch ist die wahrscheinlich geringer, dass jemand vor dir ein Problem > schonmal hatte und dazu eine Lösung gefunden hat. Super, danke für die Antwort! Ich werde es mir dann auch noch mal bei Zeiten anschauen, aktuell habe ich für sowas keinen Kopf … Seit dem Lesen des Changelogs und der Features habe ich echt Respekt vor der Leistung, so ein Programm aus dem Boden zu stampfen :)
Jemand schrieb: > Seit dem Lesen des Changelogs und der Features habe ich echt Respekt vor > der Leistung, so ein Programm aus dem Boden zu stampfen :) und wenn man sich jetzt zum Vergleich überlegt, wie sich solche Programme wie EAGLE in der gleichen Zeit weiterentwickelt haben ...
Markus W. schrieb: > und wenn man sich jetzt zum Vergleich überlegt, wie sich solche > Programme wie EAGLE in der gleichen Zeit weiterentwickelt haben Paretoprinzip bei der Arbeit: die ersten 80% brauchen 20% des Aufwandes. Auch hilfreich ist bestimmt, keine Vergangenheit zu haben, die bis in die DOS-Ära zurückreicht. Außerdem gab es einige weitere günstige Umstände: - Alles algorithmisch anspruchsvolle wie z.B. Polygonoperationen zum Berechnen von Planes, das Berechnen der Luftlinien oder der interaktive Router kommt aus Libraries: https://github.com/horizon-eda/horizon/blob/master/README.md#included-third-party-software - Da alles mit OpenGL gezeichnet wird, muss ich mir deutlich weniger Gedanken darüber machen, welcher Teil vom Fenster sich nun geändert hat und neu gezeichnet werden muss. Einfach alles neu malen, OpenGL ist schon schnell genug. Wäre 10 Jahre früher nicht so einfach gewesen. - Computer sind schnell: Für Undo/redo wird (fast) das gesamte Board kopiert, anstatt sich zu merken, was tatsächlich geändert wurde. Ist zwar nicht so effizient, aber dafür einfacher korrekt zu implementieren.
Gute Nachrichten für alle die sich hierarchische Schaltpläne gewünscht haben: https://github.com/horizon-eda/horizon/tree/hierarchy-preview-2 Zum Anlegen eines neuen Blocks den "Schematic properties" dialog aufmachen. Der Rest sollte dann hoffentlich selbsterklärend sein. Das nächste Release Ende diesen Monats wird Hierarchie noch nicht beinhalten, damit das noch ein wenig mehr Zeit zum sich stabilisieren bekommt.
Riesen Respekt für die erbrachte Leistung! Ich hoffe sehr, dass sich (bald) eine größere Community findet, die sich um das Projekt kümmert und Codebeiträge liefert. Aktuell hindert mich am Einsatz lediglich der Fakt, dass das Projekt quasi von dir alleine lebt. Und ich bin echt beeindruckt mit welcher Leidenschaft, Ausdauer und Know-How du das Projekt vorwärts bringst, das ist beispiellos für mich! Aber falls du keine Lust mehr daran hast, steht es um die Zukunft von HorizonEDA aktuell leider schlecht. Sobald du eine kleine Gruppe ebenfalls begeistert Contributors für dein Projekt am Start hast, können sich die anderen openSource EDA Systeme warm anziehen, dann gibt es einen würdigen Konkurrenten! Und darauf warte ich :-)
Julian W. schrieb: > Sobald du eine kleine Gruppe ebenfalls begeistert Contributors für dein > Projekt am Start hast, können sich die anderen openSource EDA Systeme > warm anziehen, dann gibt es einen würdigen Konkurrenten! Nur weil sich mehr Leute beteiligen, muss es nicht automatisch besser sein. Jeder hat evtl. andere Vorstellungen davon, was besser ist oder in welche Richtung die Entwicklung gehen soll. Kompromisse finden ist nicht einfach und ein Kompromiss nicht unbedingt besser. Momentan läuft die Weiterentwicklung doch sehr gut und Lukas ist noch jung. Nachdem er so viel investiert hat, wird er nicht von jetzt auf gleich die Lust verlieren.
Habe mir gerade HorizonEDA zum ersten Mal angeschaut. Absoluter Respekt! Die Bedienung ist wirklich intuitiv. Davon ist KiCAD meilenweit entfernt. Eine Sache, die nicht intuitiv war: Wie verschiebe ich die Beschreibungstexte von Bauteilen? Teilweise sind die Strings sehr lang und überschneiden sich mit anderen Elementen.
:
Bearbeitet durch User
>Wie verschiebe ich die Beschreibungstexte von Bauteilen?
Mit Smash. Dazu mit Maus über Bauteil gehen und "h" drücken. Alternativ
über das Kontextmenu. Dann werden die Beschriftungen selektierbar.
Es ist wieder so weit, Version 2.1 ist da: https://github.com/horizon-eda/horizon/releases/tag/v2.1.0 Wirklich neue Features sind diesmal nicht dabei, stattdessen gab es einige Verbesserungen in der Darstellung von Pads sowie der Auswahl von Kreisbögen: https://blog.horizon-eda.org/progress/2021/09/06/progress-2021-06-08.html
Hallo, ein Frage: bekomm ich Horizon irgendwie auf einer virtuellen Maschine (Virtualbox) an den Start? Oder hab ich da aufgrund der nicht vorhandenen 3D Beschleunigung keine Chance? Viele Grüße, Hermann
>> Simulation ist wohl nicht geplant, siehe Vortrag:
Es gibt doch bereits gute Simulationsprogramme .. sogar kostenfrei,
ngspice, ltspice.. weshalb muss ein PCB-CAD tool auch noch simulieren
können?
Ich verfolge die Entwicklung schon seit langem. Tolles Projekt. Leider bin ich mit dem Pool-Konzept noch nicht so auf Du und immer noch hin- und hergerissen, ob ich das so toll finde. Die Schaltungsschlampe in mir hätte einen Pool mit leidlich generischen Bauteilen für den Anfang ganz toll gefunden, anstatt diese Massen anbieterspezifischer Passivbausteine. Aber das würde das Poolkonzept ja ad absurdum führen. Beim Schaltplan-Export als PDF hätte ich mir von einer 2.1 Version auch schon mehr erhofft. Farbige Ausgabe, Zentrier- und Skalieroptionen zum Beispiel, das sind programmiertechnisch ja fast Freebies. Ich weiss, sowas ist Nebenschauplatz, aber ich steh auf schön gezeichnete Schaltpläne (bei KiCad bereiten wir die als SVG exportierten Pläne auch auf, im "Original" sind die auch nicht so tippitoppi, dass mam die unbereinigt in Druck geben wollte).
Kim Cadasia schrieb: > Beim Schaltplan-Export als PDF hätte ich mir von einer 2.1 Version auch > schon mehr erhofft. Farbige Ausgabe Geh' weg. Du hast noch nie auf der Baustelle die eine hellgelbe Verbindung übersehen. Oder geht's um die völlig nutzlosen bunt ausgefüllten Rechtecke?
Schön wäre es, wenn du einen Konverter bauen würdest. Von KiCad zu Eagle und zurück z.b.
Hermann schrieb: > Oder hab ich da aufgrund der nicht > vorhandenen 3D Beschleunigung keine Chance? Ich hab's gerade mal wieder in einem Xephyr-Xserver mit software-renderer llvmpipe ausprobiert und hat alles soweit funktioniert, nur die 3D-Ansicht war arg ruckelig. Du brauchst halt was, das OpenGL 4 oder OpenGL 3 mit den richtigen extensions kann. > anstatt diese Massen anbieterspezifischer Passivbausteine. Die sind inzwischen alle in ihren eigenen Pools. Im standard-Pool gibt es inzwischen nur noch die CPL-passives. Wer will kann die dann im BOM-Export im "similar parts" tab echten Bauteilen zuordnen. > Zentrier- und Skalieroptionen zum Beispiel An was dachtest du da? Hauptanwendungszweck vom PDF-Export ist, den Schaltplan auch ohne das Programm installiert zu haben angucken zu können. Was will man da mehr haben als die Schaltplanseiten wie sie sind als PDF? PDF export in einstellbaren Farben, denn die aus dem Editor will man ja nicht haben, war mir bis jetzt den Aufwand nicht Wert und es hat mich noch niemand davon überzeugt, dass man das wirklich unbedingt braucht.
Lukas K. schrieb: >> Zentrier- und Skalieroptionen zum Beispiel > > An was dachtest du da? Hauptanwendungszweck vom PDF-Export ist, den > Schaltplan auch ohne das Programm installiert zu haben angucken zu > können. Was will man da mehr haben als die Schaltplanseiten wie sie sind > als PDF? Als unbedarfter User hatte ich z.B. beim ersten PDF-Export ein leeres Blatt und war verwundert, bis mir aufgefallen ist, dass ich die Schaltung links vom Nullpunkt gezeichnet hatte. > PDF export in einstellbaren Farben, denn die aus dem Editor will man ja > nicht haben, war mir bis jetzt den Aufwand nicht Wert und es hat mich > noch niemand davon überzeugt, dass man das wirklich unbedingt braucht. Bei Schaltplänen ist man meiner Meinung nach mittlerweile auf die Farbgebungen trainiert, wie man sie von Altium, Kicad, Eagle und so weiter kennt. Wichtigster Punkt sind da die farbliche Hervorhebung von Labels. Bei der Nachbearbeitung für den Druck sind unterschiedliche Farben auch von Vorteil, weil wir die erste Bearbeitung so machen, dass anhand von Farbe selektiert wird und dann eine Stylezuweisung erfolgt. Von Farbe nach irgendwas ist leicht, aber von schwarz nach farbig halt nicht. Von daher wäre schon ein Export mit den ggf. invertierten Farben des Editors nicht schlecht. Letztendlich sind Schaltpläne quasi ein Aushängeschild des erstellenden Programms, weil das die Teile sind, die im Netz und in Doku auftauchen. Sieht das aus wie Grütze, ist es schwer Interesse für das Programm aufflammen zu lassen. Ich weiss, technisch ist das völlig Banane, aber der Mensch ist ein Gewohnheits- und Augentier. Da können wir Ings uns auch nicht ganz frei von machen.
Kim Cadasia schrieb: > Als unbedarfter User hatte ich z.B. beim ersten PDF-Export ein leeres > Blatt und war verwundert, bis mir aufgefallen ist, dass ich die > Schaltung links vom Nullpunkt gezeichnet hatte. Achso, dann liegt das daran, dass du für deinen Schaltplan keine Rahmen festgelegt hast. Wenn du im "schematic properties" dialog einen festgelegt hast, dann tut auch der PDF export sinnvoller. > Bei Schaltplänen ist man meiner Meinung nach mittlerweile auf die Farbgebungen trainiert, wie man sie von Altium, Kicad, Eagle und so weiter kennt. Wichtigster Punkt sind da die farbliche Hervorhebung von Labels. Ich will ja nicht sagen, dass farbige PDF-Schaltpläne gänzlich unnütz sind. Es ist wie so vieles eine Abwägung von Aufwand zu nutzen. Bis jetzt ist diese eben negativ ausgefallen.
Schön wäre es, wenn du einen Konverter bauen würdest. Von KiCad zu Eagle und zurück z.b.
Thorsten schrieb: > Schön wäre es, wenn du einen Konverter bauen würdest. Von KiCad zu > Eagle und zurück z.b. Hatten wir hier glaub schonmal. Ich jedenfalls werde es nicht implementieren, da es unmäßig viel Aufwand ist, das so hinzubekommen, dass es wirklich brauchbar ist. Da gibt es andere Dinge die mehr Spaß machen zu bauen und nützlicher sind. KiCad-Symbole und Footprints kann man übrigens importieren.
Nach ein paar Monaten ist es mal wieder zeit für ein neues Release: https://github.com/horizon-eda/horizon/releases/tag/v2.2.0 Einen begleitenden Blogpost gibt es auch wieder: https://blog.horizon-eda.org/progress/2022/01/09/progress-2021-09-12.html Hauptneuerung in Version 2.2 sind hierarchische Schaltpläne.
Hi! Ich habe mal wieder Horizon kompiliert! Wirklich ein schönes Programm, ich finde die Bedienung auch intuitiv. Zwei Dinge: 1) Ein kleiner Bug: Wenn man im Board Editor auf eine Ecke einer Leiterbahn klickt und diese per Kontextmenü verschieben will (Also rechte Maustaste und dann im Kontextmenü Move) bleibt der Mauspfeil/Fadenkreuz dort wo man im Kontext Menü geklickt hat, man verschiebt aber gleichzeitig das Leiterbahn Eck, das sich woanders befindet. Ich hoffe, es ist nachvollziehbar ;-) 2) Ich arbeite hier auf dem Notebook mit Xubuntu 21.10. Hier kollidieren die ocelibs-dev, die Horizon benötigt, mit dem kicad-nightly. Ich habe kicad nightly zum kompilieren deinstalliert. Siehe unten unter ENTFERNT. Man kann natürlich diskutieren, ob das jetzt ein KiCad Problem ist. Aber für dich als Info.
1 | ~$ sudo apt install kicad-nightly |
2 | Paketlisten werden gelesen… Fertig |
3 | Abhängigkeitsbaum wird aufgebaut… Fertig |
4 | Statusinformationen werden eingelesen… Fertig |
5 | Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt: |
6 | libfreeimage-dev libgl2ps-dev libgl2ps1.4 libxmu-dev libxmu-headers |
7 | Verwenden Sie »sudo apt autoremove«, um sie zu entfernen. |
8 | Die folgenden zusätzlichen Pakete werden installiert: |
9 | kicad-nightly-footprints kicad-nightly-libraries kicad-nightly-packages3d |
10 | kicad-nightly-symbols kicad-nightly-templates |
11 | Vorgeschlagene Pakete: |
12 | extra-xdg-menus |
13 | Empfohlene Pakete: |
14 | kicad-nightly-doc-en |
15 | |
16 | Die folgenden Pakete werden ENTFERNT: |
17 | liboce-foundation-dev liboce-foundation11 liboce-modeling-dev |
18 | liboce-modeling11 liboce-ocaf-dev liboce-ocaf-lite-dev liboce-ocaf-lite11 |
19 | liboce-ocaf11 liboce-visualization-dev liboce-visualization11 |
20 | |
21 | Die folgenden NEUEN Pakete werden installiert: |
22 | kicad-nightly kicad-nightly-footprints kicad-nightly-libraries |
23 | kicad-nightly-packages3d kicad-nightly-symbols kicad-nightly-templates |
24 | 0 aktualisiert, 6 neu installiert, 10 zu entfernen und 0 nicht aktualisiert. |
25 | Es müssen 475 MB an Archiven heruntergeladen werden. |
26 | Nach dieser Operation werden 5.882 MB Plattenplatz zusätzlich benutzt. |
27 | Möchten Sie fortfahren? [J/n] |
tester schrieb: > bleibt der > Mauspfeil/Fadenkreuz dort wo man im Kontext Menü geklickt hat, man > verschiebt aber gleichzeitig das Leiterbahn Eck, das sich woanders > befindet. Ich hoffe, es ist nachvollziehbar Das passiert bei mir nicht. Damit das so ist ist auch extra Code vorhanden, der nach dem man auf einen Eintrag im Kontextmenü klickt die cursorposition aktualisiert und erst dann das Move Tool startet. tester schrieb: > Hier kollidieren > die ocelibs-dev, die Horizon benötigt, mit dem kicad-nightly. Ich habe > kicad nightly zum kompilieren deinstalliert. Siehe unten unter ENTFERNT. > Man kann natürlich diskutieren, ob das jetzt ein KiCad Problem ist. Seltsam. Kicad braucht auch opencascade. Kannst du mal mit ldd und dpkg-quer -S nachgucken woher KiCad dann opencascade bekommt? Horizon EDA baut sehr wahrscheinlich auch mit dieser Opencascade-variante.
Lukas K. schrieb: > Das passiert bei mir nicht. Damit das so ist ist auch extra Code > vorhanden, der nach dem man auf einen Eintrag im Kontextmenü klickt die > cursorposition aktualisiert und erst dann das Move Tool startet. Ich habe mal einen ScreenCast angehängt, der den Effekt zeigt. Bei KiCad vermute ich, dass die bin-libs von KiCad-Nighly mitgebracht werden aber die dev-libs fehlen.
> Ich habe mal einen ScreenCast angehängt, der den Effekt zeigt.
Tut doch alles so wie es soll. Nachdem du auf "Move" geklickt hast,
schnappt der Cursor zur Mausposition und es bewegt sich im Schaltplan
erstmal nichts.
Die alternative wäre ja, dass erstmal nichts passiert und dann beim
ersten Bewegen der Maus das zu bewegende Objekt zum Cursor schnappt.
Kannst du ausprobieren wenn du in der src/imp/imp.cpp
ImpBase::fix_cursor_pos z.B. durch ein return; am Anfang deaktivierst.
Dein Theme scheint im übrigen einen Bug zu haben: Die Buttons am rechten
Rand sollten eigentlich dunkel sein.
Lukas K. schrieb: > Tut doch alles so wie es soll. Also irgendwie scheinen mir die Logiken verschiedener Leute ebenfalls verschieden zu sein. Also denk doch mal an eine eher einfache Arbeitsumgebung, wie z.B. eine Tischlerei: Wie läuft da z.B. der Arbeitsablauf "ein wenig abhobeln" im Detail ab? - Tischler legt das Werkstück auf die Hobelbank (Das ist vergleichbar mit dem Positionieren der Leiterplatte oder des Stromlaufplanes auf dem Display) - Tischler geht zum Werkzeugschrank (Das ist vergleichbar mit dem Öffnen eines Menüs) - Tischler nimmt den Hobel zur Hand (Das ist vergleichbar mit der Auswahl "MOVE" im Menü) - Tischler positioniert den Hobel auf dem Teil des Werkstücks, der abgehobelt werden soll (Das wäre vergleichbar mit dem Anklicken des zu verschiebenden Teiles mit der Maus, aber da geht deine Logik andere Wege) - Tischler betätigt den Hobel, der daraufhin einen Span abhobelt (Das wäre vergleichbar mit dem tatsächlichen Verschieben des Teiles) - Tischler legt den Hobel wieder weg und macht dann irgend etwas anderes Lukas K. schrieb: > Nachdem du auf "Move" geklickt hast, > schnappt der Cursor zur Mausposition und es bewegt sich im Schaltplan > erstmal nichts. Tja, nachdem du deinen Hobel aus dem Werkzeugschrank genommen hast, fliegt der von selbst auf die Stelle, wo du als Tischler vorher zuletzt deine Hand gehabt hast. Eigentlich ist das falsch, denn es ist nicht ungewöhnlich, daß du allein durch das Anschauen deines Werkstückes gemerkt hast, daß Bauteil 4811 ein wenig nach rechts geschoben werden müßte. Das wiederum hat rein garnichts zu tun mit der Stelle, wo du zuletzt mit deiner Hand angefaßt hast. Mich erinnert deine Logik an die Symbol-Plazierung bei Kicad, wie ich sie beim Ausprobieren von Kicad selber erlebt hatte. W.S.
Seit gestern kann Horizon EDA neben Gerber auch ODB++ exportieren. Die meisten bezahlbaren Platinenhersteller können nur Gerber, aber so mancher SI/PI-Simulator kann wohl nur ODB++ und ich wollte mehr über das Format lernen. Wenn ich nichts übersehen habe ist Horizon EDA damit das erste Open Source Layoutprogramm, das ODB++ exportieren kann.
Lukas K. schrieb: > Wenn ich nichts übersehen habe ist Horizon EDA damit das erste Open > Source Layoutprogramm, das ODB++ exportieren kann. Dann werden wohl in Kürze Valor/Mentor/Siemens eine Horde schmieriger Rechtsanwälte zu den Entwicklern schicken und von denen Lizenzzahlungen usw. verlangen, bis die Schwarte kracht.
Lukas K. schrieb: > Seit gestern kann Horizon EDA neben Gerber auch ODB++ exportieren. Das ist mir sowas von egal... Schöner wäre es, wenn irgendwo erklärt wäre, wie man Netzlinien richtig zeichnet. Ich probiere jetzt seit einer halben Stunde mit einem Bauelement und zwei Power-Symbolen rum, und es ist mir erst ein einziges Mal gelungen, eine korrekte Verbindung herzustellen (habe aber leider nicht mitbekommen, wie genau ich das gemacht habe). Ich (und wohl jeder andere) erwarte entweder: Klick für ersten Punkt der Linie, zweiter Klick für zweiten Punkt der Linie. Fertig. (Sprich automatische Erkennung: Pin/Junction getroffen, beende Net) Oder: erster Klick für ersten Punkt der Linie, zweiten (anderen, z.B. Rechts-)Klick zum Beenden und Herstellen des Kontaktes. (Manuelle Unterscheidung zwischen: will nur Richtung ändern oder Net beenden). In meiner Not habe ich dann mal was ganz anderes gemacht, einfach mal ein Symbol so verschoben, dass die verbindenden Punkte der zwei Symbole übereinander zu liegen kamen. Aber auch dabei kam nur Schwachsinn raus. Eine unbrauchbare Verbindung (ERC(?)-Fehler: Junction on Pin), aber die beiden Symbole waren nunmehr so miteinander verbunden, dass sie nicht mehr einzeln beweglich waren. Also diese Sachen sind mindestens erklärungsbedürftig (über die zwei Zeilen in der Doku hinaus!), wahrscheinlich aber eher überarbeitungsbedürftig. Ich kenne eine Menge E-CAD-Software, aber sowas unlogisches und nicht-intuitives ist mir noch nirgendwo untergekommen. Wenn schon einfachste grundlegende Operationen so gestaltet sind, dann möchte ich garnicht tiefer gehen. Ich schaue in einem Jahr noch mal nach...
Andreas S. schrieb: > Dann werden wohl in Kürze Valor/Mentor/Siemens eine Horde schmieriger > Rechtsanwälte zu den Entwicklern schicken und von denen Lizenzzahlungen > usw. verlangen, bis die Schwarte kracht. Ganz im Gegenteil, Horizon EDA ist nun ODB++ Partner: https://odbplusplus.com/design/partners/ c-hater schrieb: > Ich (und wohl jeder andere) erwarte entweder: Klick für ersten Punkt der > Linie, zweiter Klick für zweiten Punkt der Linie. Fertig. ( Genau so verhält sich doch auch das "draw net line" tool.
Lukas K. schrieb: > Genau so verhält sich doch auch das "draw net line" tool. Tja, bei dir. Aber ganz offensichtlich nicht bei anderen Leuten. Auch ich habe schon 2 vergebliche Versuche hinter mir, zuerst scheiterte es an der zu alten Version von OpenGL und später an etwas anderem, vielleicht an einer zu neuen Version von OpenGL - wer weiß? W.S.
Was haben denn deine Probleme, das zu compilieren (oder ein Compilat überhaupt erstmal zu starten), mit der Art und Weise der Benutzung zu tun? c-hater schrieb: > Ich probiere jetzt seit einer halben Stunde mit einem Bauelement und > zwei Power-Symbolen rum, und es ist mir erst ein einziges Mal gelungen, > eine korrekte Verbindung herzustellen Das spricht eher gegen dich denn gegen Horizon-EDA. Es mag ja manches an Konzepten anders angehen als andere EDA-Tools, aber das Zeichnen des Schaltplans ist nun wirklich alles andere als unintuitiv. Da muss ich keine Doku erst lesen dafür, um das hinzubekommen.
Angehängte Dateien:
-
Bauteileauswahl.jpg
250 KB -
Verhakelt.jpg
33 KB
Jörg W. schrieb: > Das spricht eher gegen dich denn gegen Horizon-EDA. Warum immer derart gereizt? Ich häng dir mal zwei Bilder dran. Das erste kommt, wenn man im Schematic ein Bauteil einfügen will. Ich find's recht unübersichtlich. Das zweite kommt, wenn man mehr als nur ein paar Sekunden in dieser Bauteileauswahl verweilt. Aber das ist schlichtweg notwendig, weil Lukas offenbar alle Widerstände und Kondensatoren mit allen Werten einzeln eingepflegt hat. Und ehe man sich durch eine E48 von jeweils mehreren Herstellern durchgehangelt hat, ist einige Zeit verstrichen. Mal abgesehen von der Ungeordnetheit. Da hilft auch keine Voltextsuche - oder ist dir geläufig, was unter "ERJ-2GEJ113" rangiert? W.S.
Angehängte Dateien:
-
Shit.png
2,2 KB
Lukas K. schrieb: > c-hater schrieb: >> Ich (und wohl jeder andere) erwarte entweder: Klick für ersten Punkt der >> Linie, zweiter Klick für zweiten Punkt der Linie. Fertig. ( > > Genau so verhält sich doch auch das "draw net line" tool. Nein, tut es eben leider nicht. Erster Klick, Linie wird mit Startpunkt verbunden (grünes Kreuz am Power-Symbol) und anderes Ende hängt am Cursor. Soweit OK. Zweiter Klick auf den entsprechenden Supply-Pin des IC. Und jetzt passiert Scheiße. Statt mit dem Pin zu verbinden, wird eine Junction auf dem Pin plaziert. Der erste Linienabschnitt ist damit beendet, an der Junktion ist ein neuer befestigt, anderes Ende hängt am Cursor. Rechtsklick beendet das Net, der zweite Linienabschnitt verschwindet, aber die Junction bleibt. Noch ein Rechtsklick (irgendwo) beendet das Werkzeug. Danach scheint so eine Art ERC zu laufen. Endergebnis siehe Screenshot. Richtung spielt keine Rolle, wenn man am Pin beginnt, passiert genau dasselbe, bloß dass die dämliche überflüssige Junction dann halt am Power-Symbol angepappt ist. Und zweiten Klick gleich als Rechtsklick ausführen geht auch nicht, dann verschwindet der erste Linienabschnitt und garnix bleibt über.
W.S. schrieb: > Ich häng dir mal zwei Bilder dran. Hat nur mit des C-haters Sache rein gar nichts zu tun. > Das erste kommt, wenn man im > Schematic ein Bauteil einfügen will. Ich find's recht unübersichtlich. Du hast allerdings genau die entscheidenden Filter-Eingaben darüber weggelassen. > Das zweite kommt, wenn man mehr als nur ein paar Sekunden in dieser > Bauteileauswahl verweilt. Das dürfte irgendwas auf deinem System sein, habe ich noch nie gesehen – und ich habe Horizon schon in der Alpha-Phase gelegentlich probiert. Kann es sein, dass dir irgendwelche Virenchecker oder andere "malware protection" oder dergleichen da in die Quere schießen? Die zusammengebrochene Kommunikation hier bezieht sich auf das message passing (ZMQ) zwischen den beiden Horizon-Komponenten, die über lokale Sockets funktioniert. Die beiden Teile haben eine sehr innige Kommunikationsbeziehung. ;-)
1 | horizon-e 19527 j 4u PIPE 0xfffff800bbc98000 16384 ->0xfffff800bbc98168 |
2 | horizon-e 19527 j 5u PIPE 0xfffff800bbc98168 4096 ->0xfffff800bbc98000 |
3 | horizon-e 19527 j 7u PIPE 0xfffff801585ee8e8 16384 ->0xfffff801585eea50, cnt=1, in=1 |
4 | horizon-e 19527 j 8u PIPE 0xfffff801585eea50 4096 ->0xfffff801585ee8e8 |
5 | horizon-e 19527 j 11u PIPE 0xfffff804b8e912f8 16384 ->0xfffff804b8e91460 |
6 | horizon-e 19527 j 12u PIPE 0xfffff804b8e91460 4096 ->0xfffff804b8e912f8 |
7 | horizon-e 19527 j 25u PIPE 0xfffff8022f4c58e8 16384 ->0xfffff8022f4c5a50 |
8 | horizon-e 19527 j 26u PIPE 0xfffff8022f4c5a50 4096 ->0xfffff8022f4c58e8 |
9 | horizon-e 19527 j 28u PIPE 0xfffff800bbc9b2f8 16384 ->0xfffff800bbc9b460 |
10 | horizon-e 19527 j 29u PIPE 0xfffff800bbc9b460 4096 ->0xfffff800bbc9b2f8 |
11 | horizon-e 19527 j 43u PIPE 0xfffff805f7d7e2f8 16384 ->0xfffff805f7d7e460 |
12 | horizon-e 19527 j 44u PIPE 0xfffff805f7d7e460 4096 ->0xfffff805f7d7e2f8 |
13 | horizon-i 19530 j 26u PIPE 0xfffff8023cf942f8 16384 ->0xfffff8023cf94460 |
14 | horizon-i 19530 j 27u PIPE 0xfffff8023cf94460 4096 ->0xfffff8023cf942f8 |
15 | horizon-i 19530 j 33u PIPE 0xfffff806284bc5f0 16384 ->0xfffff806284bc758, cnt=1, in=1 |
16 | horizon-i 19530 j 34u PIPE 0xfffff806284bc758 4096 ->0xfffff806284bc5f0 |
17 | horizon-i 19530 j 35u PIPE 0xfffff8037bd158e8 16384 ->0xfffff8037bd15a50 |
18 | horizon-i 19530 j 36u PIPE 0xfffff8037bd15a50 4096 ->0xfffff8037bd158e8 |
19 | horizon-i 19530 j 38u PIPE 0xfffff805a760a8e8 16384 ->0xfffff805a760aa50 |
20 | horizon-i 19530 j 39u PIPE 0xfffff805a760aa50 4096 ->0xfffff805a760a8e8 |
21 | horizon-i 19530 j 97u PIPE 0xfffff801585ec8e8 16384 ->0xfffff801585eca50 |
22 | horizon-i 19530 j 98u PIPE 0xfffff801585eca50 4096 ->0xfffff801585ec8e8 |
(Das sind alle bei mir aktuell geöffneten PIPEs zwischen horizon-eda und horizon-imp.) > Aber das ist schlichtweg notwendig, weil Lukas > offenbar alle Widerstände und Kondensatoren mit allen Werten _einzeln_ > eingepflegt hat. Dafür kann man einerseits ja auch filtern (bspw. "100 k" eingeben), außerdem gibt es mittlerweile außer der (standardmäßig geöffneten) MPN-Suche auch vorgefertigte parametrische Suchen für Widerstände, Kondensatoren und Induktivitäten.
c-hater schrieb: > Nein, tut es eben leider nicht. Weil du das "Draw line" tool benutzt hast, zu erkennen an der gelben statt grünen Linie. Dieses Tool malt Linien ohne elektrische Funktion die sich daher auch nicht mit Pins verbinden. W.S. schrieb: > Das zweite kommt, wenn man mehr als nur ein paar Sekunden in dieser > Bauteileauswahl verweilt. A Die Titelleiste sieht mir jetzt nach einem Windows 7 aus, da es ab 8 das classic theme nicht mehr gibt. Da Windows 7 von Microsoft nicht mehr supported ist, ist auch von Horizon EDA nicht mehr supported. Wenn es funktioniert, schön. Wenn nicht, ist es nicht mein Problem.
Lukas K. schrieb: > Da Windows 7 von Microsoft nicht mehr > supported ist, ist auch von Horizon EDA nicht mehr supported. Naja gut, kann ich zu einem gewissen Grad verstehen, aber spekulieren, woran es liegen mag, könnte man ja trotzdem. Ich (als nicht-Windows-Nutzer) habe oben eine Hypothese gewagt, hättest du denn auch eine?
Jörg W. schrieb: > hättest du denn > auch eine? Der Editor (horizon-imp) redet über einen ZeroMQ TCP-Socket auf localhost mit dem Projektmanager (horizon-eda). Wenn der Projektmanager länger als 5 Sekunden braucht zu antworten schmeißt der Editor das Handtuch und befindet den Socket für kaputt. Das war nicht immer so und ein abgestürzter Projektmanger hatte den Editor mit in den Abgrund gerissen. Um genauer zu wissen wo genau das schiefgegangen ist, zeigt dieser Dialog nun auch an bei welcher Operation die Sockets zerbrochen sind. Entweder läuft irgendwas im Projektmanger, der sich aus historischen Gründen um den "Place part"-Dialog kümmert, schief, sodass sich dieser für mehr als eben diese 5 Sekunden nicht mehr meldet oder irgendeine Windows-Verschlimmbesserungssoftware hat etwas gegen den TCP-Socket.
Lukas K. schrieb: > aus historischen Gründen :-) Für Horizon ist das natürlich ein cooler Spruch. ;-)
W.S. schrieb: > Lukas K. schrieb: >> Wenn nicht, ist es nicht mein Problem. > > Nun, das sagt mir genug. Klar, keine Fehler auf der eigenen Seite suchen, oder? Anhaltspunkte gab es ja schließlich jetzt, wo du gucken könntest.
Jörg W. schrieb: > Kann es sein, dass dir irgendwelche Virenchecker oder andere "malware > protection" oder dergleichen da in die Quere schießen? Also, ich bin nicht der Autor von Horizon. Von da her kann ich deine Frage nicht beantworten. Aber ich halte es für eine nicht unzulässige Erwartung, daß ein Programm zuverlässig läuft, egal ob und was für einen Virenscanner man sonst noch so auf dem System hat. Und mal zum Vergleich: das aktuelle Eagle 9.6.2 läuft auf diesem Rechner problemlos. Und Fusion 360 läuft auch problemlos. Und die aktuelle Softmaker-Suite auch. Ich will da jetzt nicht inhaltlich näher drauf eingehen. Es geht bei anderen Programmen ganz offensichtlich. W.S.
W.S. schrieb: > Aber ich halte es für eine nicht unzulässige Erwartung, daß ein Programm > zuverlässig läuft, egal ob und was für einen Virenscanner man sonst noch > so auf dem System hat. Unzulässig nicht, aber unrealistisch. Jedenfalls, was Virenscanner angeht.
W.S. schrieb: > Aber ich halte es für eine nicht unzulässige Erwartung, daß ein Programm > zuverlässig läuft, egal ob und was für einen Virenscanner man sonst noch > so auf dem System hat. Wie mir scheint eine etwas gewagte Annahme in einer Windows-Umgebung.
W.S. schrieb: > Aber ich halte es für eine nicht unzulässige Erwartung, daß ein Programm > zuverlässig läuft, egal ob und was für einen Virenscanner man sonst noch > so auf dem System hat. Auf Windows kann man meiner Erfahrung nach keine derartigen Erwartungen hegen. Wenn da irgendwer der Meinung ist, $NETZWERKVERBINDUNG sei böse, dann kannst du dich als Anwendungsprogrammierer auf den Kopf stellen und mit den Beinen wackeln, das wird nichts nützen. > Und mal zum Vergleich: Das hilft nichts, es sei denn, du hättest etwas zum Vergleich, was architekturell zumindest ähnlich konzipiert ist (zwei Programmteile, die massiv miteinander Socket IPC machen). Es hilft dir ja auch nichts, wenn ich dir zum Vergleich sage, dass das hier auf meinem FreeBSD gar kein Problem hat (und das wohlgemerkt, ohne dass Lukas es jemals selbst auf einem FreeBSD hätte testen müssen – und nein, FreeBSD und Linux sind sich keineswegs ähnlicher als die verschiedenen modernen Windowsvarianten). Das sind dann ungefähr die gleichen Äpfel mit Birnen verglichen, wie du das grad machst.
Jörg W. schrieb: > Das hilft nichts, es sei denn, du hättest etwas zum Vergleich, was > architekturell zumindest ähnlich konzipiert ist (zwei Programmteile, die > massiv miteinander Socket IPC machen). Wozu? Glaubst du etwa, daß jemand, der sich eine Leiterplatte machen will, sich um massiven Socket IPC kümmert? Nee, das sind alles nur Sichtweisen aus Programmierers Sicht. Nicht das, was Anwender betrifft. Nebenbei: Auch bei Eagle hat man wenigstens 3 Programmteile, die "massiv miteinander" kommunizieren. Aber die machen das offenbar anders. Glaube du mal nicht, daß die Ausrede, es sei der Vergleich Äpfel versus Birnen, für den Anwender von irgendeiner Relevanz ist. Ob die Programmteile nun per Socket IPC oder mit reitendem Boten miteinander kommunizieren, ist aus Anwenders Sicht egal. W.S.
Lukas K. schrieb: > Weil du das "Draw line" tool benutzt hast, zu erkennen an der gelben > statt grünen Linie. Dieses Tool malt Linien ohne elektrische Funktion > die sich daher auch nicht mit Pins verbinden. Ah ja, das isses. Falsches Werkzeug erwischt. Erklärt auch den einen gelungenen Versuch, da hatte ich dann wohl versehentlich mal das richtige Werkzeug erwischt. Also: ganz klar mein Fehler, zumal die Tool-Icons zwar nicht beschriftet sind, aber bei Hover wenigstens einen Tooltip einblenden. Ich hätte mir bloß mal die Zeit nehmen müssen, auch mal langsam mit der Maus über die Icons zu fahren. Bleibt allerdings zu fragen, wozu um alles in der Welt setzt ein Tool zum Ziehen von Linien ohne jede elektrische Bedeutung denn Junctions? Hätte es das nicht getan, wäre ich wahrscheinlich viel eher auf die Tatsache gestoßen, dass ich da das falsche Tool am Wickel habe. Und die andere Sache, das seltsame Verhalten beim Plazieren von Pins direkt übereinander bleibt auch ungeklärt.
W.S. schrieb: > Wozu? Glaubst du etwa, daß jemand, der sich eine Leiterplatte machen > will, sich um massiven Socket IPC kümmert? Wenn mit meinem geliebten, aber nicht mehr unterstützten System irgendwas nicht funktioniert, dann gibt es halt zwei Varianten: entweder, ich geh der Ursache mal auf den Grund (könnte ja nächste Woche auch bei etwas ganz anderem auftreten), oder ich aktualisiere auf etwas, was noch unterstützt wird. OK, es gibt noch 'ne dritte Variante: Vogel Strauß spielen. Ob das aber eine sinnvolle Strategie ist, sei dahin gestellt. > Nebenbei: Auch bei Eagle hat man wenigstens 3 Programmteile, die "massiv > miteinander" kommunizieren. Aber die machen das offenbar anders. Deutlich anders, mit einem komplett anderen Zweck. Kicad auch. Aber das "wie" ist halt eine Architekturentscheidung des Programmierers für sein Programm, nicht das Diktat des Anwenders. Das Betriebssystem ist das, was für solche Dinge die Resourcen bereitstellen muss, als Anwendungsprogrammierer möchte ich die einfach nur nutzen können. Wenn eine konkrete Betriebssystemvariante das aus irgendeinem Grund nicht tut, obwohl sie es tun sollte, dann ist das OS kaputt, nicht die Anwendung.
Lukas K. schrieb: > oder irgendeine > Windows-Verschlimmbesserungssoftware hat etwas gegen den TCP-Socket. Das könnte schon die Windows-eigene Firewall sein. Einmal unglücklich geklickt, verhindert sie Socket-Kommunikation selbst über localhost recht zuverlässig, ohne jemals wieder dem Benutzer das Problem erneut zur Entscheidung vorzulegen. Dieses Verhalten ist allerdings konstant über alle Windows-Versionen, seitdem es diese Firewall überhaupt gibt und sie standardmäßig aktiv ist. So weit ich mich erinnere also seit XP(SP3).
Lukas K. schrieb: > Was ist eigentlich mit den schließen-icons schief gelaufen? Die sehen > ein wenig verunglückt aus. Dem bin ich nun endlich mal nachgegangen. War/ist eine kaputte librsvg2. Default librsvg2 in FreeBSD ist 2.40.x, weil es die letzte Version ist, die in C gebaut worden ist und damit auf allen FreeBSD-Plattformen verfügbar ist. Die neuere Version ist ein Rewrite in Rust. Ich habe jetzt die C-Version durch so eine neuere ersetzt, nun sind die Icon-Darstellungen wieder OK.
c-hater schrieb: > Das könnte schon die Windows-eigene Firewall sein. Einmal unglücklich > geklickt, verhindert sie Socket-Kommunikation selbst über localhost > recht zuverlässig, ohne jemals wieder dem Benutzer das Problem erneut > zur Entscheidung vorzulegen. Ergänzend: natürlich kann man das auch nachträglich noch beheben. Einfach die Firewall-Konfiguration benutzen. Allerdings würde ich eine Sache gern mal analysieren. Was passiert eigentlich in einer Mehrbenutzer-Umgebung für Horizon-EDA? Wie findet die eine Anwendungs-Komponente die andere (getrennt nach User!). Und ja: auch Windows kennt mehrere Benutzer auf einer Maschine. Mindestens beim TerminalServer. Ja OK, ich könnte auch die Quelltexte lesen, habe aber ehrlich gesagt keine Lust dazu. C++ nervt mich einfach mal nur. Muss ich mir im Hobby nicht antun.
c-hater schrieb: > Wie findet > die eine Anwendungs-Komponente die andere Der Projektmanager übergibt dem Editor via Umgebungsvariable die Socket-Adressen. Die Portnummern werden gewürfelt, siehe auch https://blog.horizon-eda.org/progress/2022/01/09/progress-2021-09-12.html#inter-process-communication
c-hater schrieb: > Ergänzend: natürlich kann man das auch nachträglich noch beheben. > Einfach die Firewall-Konfiguration benutzen. Wäre natürlich zumindest was, was W.S. ja bei sich mal eruieren könnte.
Lukas K. schrieb: > Der Projektmanager übergibt dem Editor via Umgebungsvariable die > Socket-Adressen. Die Portnummern werden gewürfelt Häh? Das ist doch Bullshit. Die Socketaddresse dürfte doch in der normalen Anwendung sowieso immer localhost sein. Also wäre es höchstens für extrem exotische Anwendungen nützlich, die per Umgebung zu übermitteln, man könnte also dem Client also als default localhost geben. Env-Scheiß über. Komplexität über. Aber das ist nur der kleinere Teil, was soll es bedeuten, dass die Portnummern gewürfelt werden? Wie erfährt der jeweilige potentielle Client das Würfelergebnis? Also irgendwas stinkt hier schon rein im Konzept gewaltig. Und deine Erklärungen machen das kein bissel mehr trustworthy.
c-hater schrieb: > Die Socketaddresse dürfte doch in der normalen > Anwendung sowieso immer localhost sein. c-hater schrieb: > wie erfährt der jeweilige potentielle > Client das Würfelergebnis? Bei ZeroMQ ist die Portnummer teil der Adresse. Sieht dann z.B. so aus: tcp://127.0.0.1:45421
c-hater schrieb: > Aber das ist nur der kleinere Teil, was soll es bedeuten, dass die > Portnummern gewürfelt werden? Zumindest bei Nutzung der Winapi wird der Socket vom System vergeben. Also gewürfelt.
Martin S. schrieb: > Zumindest bei Nutzung der Winapi wird der Socket vom System vergeben. > Also gewürfelt. Für einen TCP-Server? Wohl kaum... Wäre das wirklich so, hätte sich z.B. Winzigweich sicherlich nicht den Mechanismus einfallen lassen müssen, mit dem sie mehrere Instanzen des SQL-Servers auf einem Host anbieten können. Diesen Mechanismus finde ich auch nicht so richtig schön, aber immer noch besser als die für Horizon-EDA gewählte Variante der Übermittlung per Umgebungsvariable. Wennschon IP-Netz, dann sollte sich sowas doch eher auch vollständig hier abspielen.
Nach ein paar Monaten ist es mal wieder zeit für ein neues Release: https://github.com/horizon-eda/horizon/releases/tag/v2.3.0 Einen begleitenden Blogpost gibt es auch wieder: https://blog.horizon-eda.org/progress/2022/05/04/progress-2022-01-04.html Neben bereits erwähnten ODB++-export gibt es nun auch Net ties zum Verbinden von Netzen und die clearance-checks laufen ca. 3× schneller als zuvor.
Ich habe den 3D Mouse Support mal ausprobiert, jedoch ist die Zuordnung der Achsen etwas unintuitiv bei meiner 3Dconnexion Space Navigator 3D Mouse. Kann die Zuordnung konfiguriert werden?
Frank K. schrieb: > Kann die Zuordnung konfiguriert werden? Nein, welcher teil genau ist denn unerwartet? Bei der Maus die ich hatte war es so: - Drücken/Ziehen in Z-Richtung: Zoom - Drücken/Ziehen in der Ebene: Verschieben - Kippen nach vorne/hinten: Kamera-Elevation - Rotieren: Kamera-Azimuth - Links/rechts kippen: ohne Funktion
Angehängte Dateien:
-
spnav-horizon.png
110 KB
Lukas K. schrieb: > Frank K. schrieb: >> Kann die Zuordnung konfiguriert werden? > > Nein, welcher teil genau ist denn unerwartet? > > Bei der Maus die ich hatte war es so: > > - Drücken/Ziehen in Z-Richtung: Zoom > - Drücken/Ziehen in der Ebene: Verschieben > - Kippen nach vorne/hinten: Kamera-Elevation > - Rotieren: Kamera-Azimuth > - Links/rechts kippen: ohne Funktion Als Vergleich habe ich FreeCAD, die Bedienung per 3D Mouse funktioniert bei mir damit so wie im angehängten png. Ich habe mal die Zuordung der Achsen für Horizon so angepasst das es so funktioniert wie in FeeCAD. Patch im Anhang. Es fehlt lediglich die Rotation um die Y-Achse (letztes Bild im png). Gruß, Frank
Frank K. schrieb: > Ich habe mal die Zuordung der > Achsen für Horizon so angepasst das es so funktioniert wie in FeeCAD. Interessant. Heißt das, dass XY-Bewegung, also Nummer 1 und 3 im Bild von dir, sich auf x und z in e.motion auswirkt? In der Konfiguration von spacenavd gibt es eine Option um Y und Z zu vertauschen, das sollte sich dann ja aber auf Horizon EDA und FreeCAD gleichermaßen auswirken. Ich hab gerade mal bei FreeCAD und blender in den Einstellungen nachgesehen und dort gibt es jeweils auch eine Flip Y/Z-Option. Wie ist die bei dir konfiguriert?
Lukas K. schrieb: > Frank K. schrieb: >> Ich habe mal die Zuordung der >> Achsen für Horizon so angepasst das es so funktioniert wie in FeeCAD. > > Interessant. Heißt das, dass XY-Bewegung, also Nummer 1 und 3 im Bild > von dir, sich auf x und z in e.motion auswirkt? In der Konfiguration von Ja, so sieht es aus. > spacenavd gibt es eine Option um Y und Z zu vertauschen, das sollte sich > dann ja aber auf Horizon EDA und FreeCAD gleichermaßen auswirken. Ich habe keine speziellen Einstellungen vorgenommen. Im Anhang mal meine Konfig. > > Ich hab gerade mal bei FreeCAD und blender in den Einstellungen > nachgesehen und dort gibt es jeweils auch eine Flip Y/Z-Option. Wie ist > die bei dir konfiguriert? In FreeCAD kann ich die Einstellung nicht finden. Vielleicht liegt das an der Version, ich verwende 0.19. Zwischenzeitlich habe ich das mal ausprobiert: https://github.com/FreeSpacenav/spnavcfg damit lassen sich die Achsen konfigurieren, und die Einstellungen funktionieren in Horizon. Damit könnten die Einstellungen in meinem Patch vorgenommen werden, ohne den Patch, es fehlt lediglich die Roll-Achse.
Frank K. schrieb: > In FreeCAD kann ich die Einstellung nicht finden. Vielleicht liegt das > an der Version, ich verwende 0.19. Das ist etwas unglücklich versteckt: Rechtsklick auf die Toolbar → Customize → Spaceball motion. Hab's auf Anhieb auch nicht gefunden. Frank K. schrieb: > es fehlt lediglich die > Roll-Achse. Die gibt es auch nicht. In der 3D-Ansicht ist die Z-Achse stets vertikal.
Angehängte Dateien:
Lukas K. schrieb: > Frank K. schrieb: >> In FreeCAD kann ich die Einstellung nicht finden. Vielleicht liegt das >> an der Version, ich verwende 0.19. > > Das ist etwas unglücklich versteckt: Rechtsklick auf die Toolbar → > Customize → Spaceball motion. Hab's auf Anhieb auch nicht gefunden. Ja, das ist kompliziert zu finden. Meine Einstellungen sind im Anhang. > > Frank K. schrieb: >> es fehlt lediglich die >> Roll-Achse. > > Die gibt es auch nicht. In der 3D-Ansicht ist die Z-Achse stets > vertikal. Im Vergleich zu FreeCAD fehlt bei Horizon dennoch die 6. Achse, heisst eine der 3 möglichen Rotationen ist ohne Funktion. Bis jetzt git es Elevation und Azimuth, Roll fehlt.
Nach etwas längerer Zeit als üblich ist es mal wieder zeit für ein neues Release: https://github.com/horizon-eda/horizon/releases/tag/v2.4.0 Einen begleitenden Blogpost gibt es auch wieder: https://blog.horizon-eda.org/progress/2022/10/15/progress-2022-05-10.html Größte Neuerungen sind Unterstützung für abgerundete Tracks und die Möglichkeit Layouts über Projektgrenzen hinweg zu kopieren.
Hallo! Ich wollte mal wieder eine aktuelle Version von horizon auf einem Ubuntu 22.04 System kompilieren. Zunächst war ich überrascht, dass nach einem git pull das Makefile weg war, aber in der Doku fand ich dann den Umstieg auf meson. Das Problem ist aber, dass sich das Paket liboce-ocaf-dev anscheinend mit den KiCAD Paketen der Version 7.0.x zwickt. Das KiCAD Repsoitory: https://ppa.launchpadcontent.net/kicad/kicad-7.0-releases/ubuntu/ jammy main
1 | klaus@medinb:~/src/horizon$ sudo apt install liboce-ocaf-dev |
2 | Paketlisten werden gelesen… Fertig |
3 | Abhängigkeitsbaum wird aufgebaut… Fertig |
4 | Statusinformationen werden eingelesen… Fertig |
5 | Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass |
6 | Sie eine unmögliche Situation angefordert haben oder, wenn Sie die |
7 | Unstable-Distribution verwenden, dass einige erforderliche Pakete noch |
8 | nicht erstellt wurden oder Incoming noch nicht verlassen haben. |
9 | Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: |
10 | |
11 | Die folgenden Pakete haben unerfüllte Abhängigkeiten: |
12 | kicad : Kollidiert mit: liboce-foundation11 aber 0.18.3-2 soll installiert werden |
13 | Kollidiert mit: liboce-modeling11 aber 0.18.3-2 soll installiert werden |
14 | Kollidiert mit: liboce-ocaf11 aber 0.18.3-2 soll installiert werden |
15 | Kollidiert mit: liboce-visualization11 aber 0.18.3-2 soll installiert werden |
16 | E: Fehler: Unterbrechungen durch pkgProblemResolver::Resolve hervorgerufen; dies könnte durch zurückgehaltene Pakete verursacht worden sein. |
Klaus R. schrieb: > apt install liboce-ocaf-dev Nachdem du das Programm sowieso neu bauen willst, hilft evt. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036879 Der Paket-Konflikt selbst lässt sich wahrscheinlich mit equivs lösen https://pkgs.org/search/?q=equivs https://manpages.debian.org/testing/equivs/equivs-build.1.en.html
Eine kleine Rückmeldung. Inzwischen habe ich horizon kompiliert bekommen, aber schön war's nicht. Das Problem ist, dass die OpenCascade-dev libs zwar installiert sind (per apt), aber die korrekten Includes und Linker Flags/Pfade nicht weitergegeben werden bzw. OpenCascade von Meson gar nicht erkannt wird. Da ich mich mit Meson nicht auskenne, habe ich build.ninja per Hand verändern müssen. Konkret musste ich folgendes tun: 1) Die Abfrage für die OCE Libs in meson.build auskommentieren 2) In build.ninja bei den Dateien export_step.cpp imp_package_3d_occt.cpp und step_importer.cpp habe ich per Hand ein -I/usr/include/opencascade ergänzt 3) Beim Linken von horizon_eda und horizon_imp jeweils von Hand die ganzen OpenCascade Libs ergänzt. Wieso erkennt Meson die OpenCascade Pakete nicht? In meson.build schlägt ja schon die Zeile
1 | opencascade = dependency('OpenCASCADE', method : 'cmake', required:false) |
fehl. Installiert habe ich OpenCascade mittels
1 | sudo apt install -y xfonts-scalable libocct-data-exchange-dev libocct-draw-dev libocct-foundation-dev libocct-modeling-algorithms-dev libocct-modeling-data-dev libocct-ocaf-dev libocct-visualization-dev |
:
Bearbeitet durch User
Also, einfacher ist es doch, die meson.build Datei zu modifizieren, Allerdings prüft der Code nicht das Vorhandensein der OpenCASCADE Dateien.
1 | opencascade = declare_dependency ( |
2 | include_directories: include_directories('/usr/include/opencascade'), |
3 | link_args:['-lTKSTEP', '-lTKernel', '-lTKXCAF', '-lTKXSBase', '-lTKBRep', '-lTKCDF', '-lTKXDESTEP', '-lTKLCAF', '-lTKMath', '-lTKMesh', '-lTKTopAlgo', '-lTKPrim', '-lTKBO', '-lTKShHealing', '-lTKBRep', '-lTKG3d', '-lTKGeomBase', '-lTKHLR'] |
4 | )
|
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.