Hallo Zusammen, nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs vorzeigbar: https://github.com/carrotIndustries/horizon Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis man damit ernsthaft Platinen entwickeln kann. Viel Spaß damit, Lukas
Und du bist dir sicher, das eine Vielzahl von Leuten dein Programm
ausprobieren, nutzen und weiterempfehlen werden, weil es sich ja so
leicht von jedermann installieren läßt ?!?
Jeder "Electronic-CAD-Programm" - Nutzer ist ja automatisch auch ein
fähiger Programmierer, der sich mit sowas
"For building on Windows, use MSYS2
Dependencies:
Gtkmm3
libepoxy
cairomm-pdf
librsvg
util-linux (on linux only)
yaml-cpp
sqlite "
easy
("It's as easy as make.")
auskennt ....
[Wer Ironie gefunden hat, darf sie behalten ]
Lukas K. schrieb: > nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: https://github.com/carrotIndustries/horizon Was ist den hier los ? Hat hier jemand den CAD-ÖTZI aus Versehen aufgetaut ? ? Ob er wohl checkt wie es in dieser bösen CAD-Welt zugeht. Es bleibt zu hoffen, dass er nicht dieser listigen Autodesk-Schlange anheimfällt :-( ? ---- Bitte nicht allzu ernst nehmen ;-)? Ich frage mich halt, ob es mit deinem Wissen nicht andere Projekte gibt die einen weitaus größeren Nährwert versprechen, als wie hier alte 'Suppen' aufzuwärmen.
Wer was kostenloses sucht und nicht scharf auf Frust ist, der greift zu Kicad...
Lukas K. schrieb: > Hallo Zusammen, > > nach einigen Monaten ist mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: https://github.com/carrotIndustries/horizon > > Auch wenn es schon alles von Schaltplan bis Gerber-Export da ist, gibt > es immer noch mehr als genug Dinge, die anders/besser werden müssen, bis > man damit ernsthaft Platinen entwickeln kann. > > Viel Spaß damit, > Lukas Nur 6 commits auf github?? Sieht auf den Screenshots aber schonmal vielversprechend aus. Werde es bei Gelegenheit mal ausprobieren. @hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen, dann solltest Du Dir vielleicht ein anderes Hobby suchen.
Lukas K. schrieb: > Viel Spaß damit Schön, daß sich jemand bemüht, etwas zu erschaffen. Aber meinst du wirklich, daß noch eines nötig war ? https://en.wikipedia.org/wiki/Comparison_of_EDA_software http://www.eevblog.com/forum/eda/pcbeda-software-list/ Vielleicht hätte man besser bei den anderen halbfertigen Projekten mithelfen können. AutoTrax macht beispielsweise eigentlich alles richtig, schönes Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit 10 Jahren keinen Fuss an den Boden. https://dexpcb.com/ Wenn man schon von vorne anfängt, hat man wenigstens keine Altlasten und kann bei Standards beginnen: https://de.wikipedia.org/wiki/Electronic_Design_Interchange_Format http://pcad-libs.embedders.org/rules/ref_617.pdf http://wiki.fed.de/index.php/Lageorientierung_von_Bauteilen_in_Bibliotheken http://www.lp-akademie.de/publikationen/cad-bg/vom_layout_zur_bg.html http://www.k-state.edu/edl/docs/pubs/technical-resources/Technote8.pdf
Michael B. schrieb: > Wenn man schon von vorne anfängt, hat man wenigstens > keine Altlasten und kann bei Standards beginnen: Das ist zwar im Prinzip richtig, aber ein Standard nutzt wenig, wenn man ihn als einziger benutzt. Den firmenübergreifenden Standard für Leiterplatten-CAD gibt es nicht, und meiner Ansicht nach besteht auch wenig Hoffnung. Ich habe selbst schon Konversionsprogramme geschrieben und weiss, an welchen Kleinigkeiten eine 1:1 Umwandlung scheitert - nur als ganz einfaches Beispiel, man hat 6eckige Lötaugen und im Zielsystem gibt es das nicht. Von komplexeren Sachen wie differential Lines garnicht erst zu reden. Georg PS besonders "beliebt" sind grundsätzliche Unterschiede in der Definition von beliebigen Flächen.
> @hardyf: Wenn Du erwartest, dass Dir andere Leute das Denken abnehmen, > dann solltest Du Dir vielleicht ein anderes Hobby suchen. Ja, und die Keramikkondensatoren töpfern wir auch selbst.
Was Ich an Gihub überhaupt nicht leiden kann, ist das komplett unsoriterte und unübersichtliche Schema! Man kriegt ein Repository hingeknallt, das weder Übersicht hat noch schafft! Und die Nutzer führen auch keine Übersicht ein! Richtig wäre, mal 1) Beschreiben, WAS das ist 2) für welchen Nutzerkreis es sein soll 3) Wie es funktioniert! Dazu braucht es ein Übersichtsdigramm, welche Module es gibt, wie man sie benutzt, was man dazu noch braucht und in dem Fall, dass es nur sourven sind, wie man sie zusammenbaut. Also a) Schnittstellen zur Aussenwelt b) Schnittstellen inten c) Bedienerfunktionalität. All das wäre in einigem richtigen Projekt sauber und übersichlich vorhanden und dokumentiert, damit es auch einer nutzen kann. So ist das einfach nur ein großer Saustall und Chaos! Leider gilt das auch für dieses Projekt. Das macht es unmöglich, da mit einzusteigen, Interesse zu wecken oder einen in die Lage zu versetzen, einzuschätzen, ob man es verwenden kann. DAS IST DER GRUND; WARUM AUS SOLCHEN PROJEKTEN NIX WIRD. DA ENTWROGT JEMAND NUR SEINEN MÜLL; DEN ER IM KOPF HAT IN FORM VON SOFTWARE AUF EINEM OFFENEN SERVER. eigentlich ist das dann nicht viel mehr, als eine Müllhalde ... ............ und wenn Ich jetzt noch etwas zu der Notwendigkeit eines CAD-Programmes sagen würde, wäre es ganz haarig ...
Ingenieur schrieb: > Was Ich an Gihub überhaupt nicht leiden kann Und was hat das mit Github zu tun?
Bernd K. schrieb: > Ingenieur schrieb: >> Was Ich an Gihub überhaupt nicht leiden kann > > Und was hat das mit Github zu tun? Nix. Aber wenn man schon gewohnt ist alles umsonst haben zu wollen dann ist es doch auch egal worüber man meckert^^ Ansonsten @ingenieur: Ja, etwas mehr Effort könnte so ein Projekt sicher vertragen. Wann willst Du mit was helfen? Hardy F. hat ja schon festgestellt, dass ein Build für Windows hilfreich wäre... @Lukas K.: Nette Idee :-) Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du evtl. eine minimale SW Beschreibung anlegen (meist reichen die "normalen" Doxygen Kommentare schon aus). DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten sich das erst zusammensuchen, was unnötiger Aufwand ist. Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? /regards
Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte Installation an ;) Ohne Push&shove ist es doch sinnlos
Ich bekomms es nicht compiliert:
In file included from /usr/include/c++/5/bits/stl_algobase.h:64:0,
from /usr/include/c++/5/bits/char_traits.h:39,
from /usr/include/c++/5/ios:40,
from /usr/include/c++/5/ostream:38,
from /usr/include/c++/5/iostream:39,
from util/uuid.hpp:8,
from pool/part.hpp:2,
from pool/part.cpp:1:
/usr/include/c++/5/bits/stl_pair.h: In instantiation of ‘constexpr
std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const
nlohmann::basic_json<>&; _U2 = const nlohmann::basic_json<>&;
<template-parameter-2-3> = void; _T1 = bool; _T2 =
std::__cxx11::basic_string<char>]’:
pool/part.cpp:10:30: required from here
/usr/include/c++/5/bits/stl_pair.h:145:64: error: call of overloaded
‘basic_string(const nlohmann::basic_json<>&)’ is ambiguous
: first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
^
In file included from /usr/include/c++/5/string:52:0,
from /usr/include/c++/5/bits/locale_classes.h:40,
from /usr/include/c++/5/bits/ios_base.h:41,
from /usr/include/c++/5/ios:42,
from /usr/include/c++/5/ostream:38,
from /usr/include/c++/5/iostream:39,
from util/uuid.hpp:8,
from pool/part.hpp:2,
from pool/part.cpp:1:
/usr/include/c++/5/bits/basic_string.h:476:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc
= std::allocator<char>]
basic_string(basic_string&& __str) noexcept
^
/usr/include/c++/5/bits/basic_string.h:398:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT =
char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]
basic_string(const basic_string& __str)
^
/usr/include/c++/5/bits/basic_string.h:390:7: note: candidate:
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
_Alloc&) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc =
std::allocator<char>]
basic_string(const _Alloc& __a)
^
Makefile:238: die Regel für Ziel „pool/part.o“ scheiterte
make: *** [pool/part.o] Fehler 1
tester schrieb: > Ich bekomms es nicht compiliert: Wieso ???? Ist doch easy.... Oder ? Dann bleib ich mal lieber bei meinem Hobby ;-)
tester schrieb: > Ich bekomms es nicht compiliert: Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. Ich hab mir die Zeile mal angesehen, versuch mal das zu ändern: Wo vorher war:
1 | attributes[Attribute::MPN] = {j.at("MPN").at(0),j.at("MPN").at(1)};
|
Das:
1 | attributes[Attribute::MPN] = {j.at("MPN").at(0).get<bool>(),j.at("MPN").at(1).get<std::string>()};
|
bei den beiden Zeilen drunter analog dazu.
3162534373 .. schrieb: > Wenn Push&shove Routing dabei ist, dann tue ich mir sogar komplizierte > Installation an ;) > Ohne Push&shove ist es doch sinnlos Push-and-shove gibt's noch nicht, aber der Router weicht immerhin schon den meisten Hindernissen aus. Der push-and-shove-Router von KiCAD hat änhlich viele lines of code wie horizon derzeit, um mal so die Komplexität darzustellen...
@ Lukas Ich würde sehr gern dein Programm mal ausprobieren. Ich komme aber mit Selbstcompilieren nicht klar. Da habe ich in der Schule wohl nicht aufgepasst damals vor 5x Jahren... Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf der Seite. Es dürften sicher paar mehr Leute ganz dankbar dafür sein so wie auch ich.
Lukas K. schrieb: > Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei...
Andreas H. schrieb: > Aber wenn Du nicht "Alleinunterhalter" bleiben willst, dann solltest Du > evtl. eine minimale SW Beschreibung anlegen (meist reichen die > "normalen" Doxygen Kommentare schon aus). > DU (!) weisst ja, was Du wie implementiert hast. Alle Anderen müssten > sich das erst zusammensuchen, was unnötiger Aufwand ist. Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code steht, aber die grobe Struktur fehlt. > Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? Unabhängig von dem Programm selber: Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen kann. Kurz/mittelfristige ziele: - Platzieren von Bauteilen einfacher machen Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part" auch als nicht modales Fenster zur Verfügung stellen. - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt "nur noch" ne hübsche GUI drüber. - DRC: mit der clipper-Library ist der algorithmisch schwere Teil (Polygon-Operationen) schon erledigt, fehlt noch die gesamte Infrastruktur außenrum. - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu hantieren macht derzeit gar keinen Spaß. - "Projekt-Manager", dass man sich nicht mehr die Argumente für horizon-imp selber ausdenken muss, sondern einfach Klicken kann. Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch nicht in einer Nacht)
tester schrieb: > Ich bekomms es nicht compiliert Schön das Du es probierst :-) Benutzt Du MSYS2 (<-- 2 !!!)? Lukas K. schrieb: > Bei mir hier baut's mit GCC 6.3.1 Unter MSYS2 ist afaik GCC5 erst seit Anfang Januar verfügbar. Vieleicht liegt es daran? /regards
Michael B. schrieb: > AutoTrax macht beispielsweise eigentlich alles richtig, schönes > Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit > 10 Jahren keinen Fuss an den Boden. > > https://dexpcb.com/ Das Programm sieht super aus. Aber die Webseite aus dem letzten Jahrtausend. Vorallem mit diesen käsig eingefügten Stock-Fotos: https://dexpcb.com/Company Es scheint aber alles zu haben... Ich versteh aber auch nicht wieso es noch ein neues gibt. LibreCAD ist doch auch gerade durchs Forum hier gehuscht... Prinzipiell find ichs aber gut, man weiss ja nie, welches von den vielen Free Software Programmen dann letztendlich die breitere User-Basis bekommt. Was ich aus meinen Softwareprojekten aber gelernt hatte: Wenn man in einem Forum, in dem es nicht hauptsächlich um Softwareentwicklung geht, postet, dann sollte man eine ZIP oder EXE oder tar.gz/.deb (für Ubuntu) parat haben. Sonst bekommt man eben genau die Sprüche und Probleme zu lesen wie oben (been there, done that). Es ist letztendlich immer die Frage welche Motivation hinter dem Projekt steckt. Wenn man nur ausprobieren will, ob man es theoretisch hinbekommt sowas zu programmieren, dann ist ca. ab dem jetzt erreichten Stand die Luft raus. Wenn man etwas schreibt, damit mans selbst benutzt, dann gehts meist noch weiter. Aber selbst gebastelte Lösungen, die nicht noch von anderen mit getragen werden, werden erfahrungsgemäß irgendwann abgelöst. Beispielsweise wenn man in ein paar Jahren selbst ein Feature braucht welches andere Programme (KiCAD, Eagle, ...) haben, aber nicht die Zeit hat es selbst zu implementieren, weil man das Projekt seit 5 Monaten nicht mehr angefasst hat und zu faul ist sich wieder in den Code einzuarbeiten. Prinzipiell kann ich es aber nur unterstützen und finde es absolut großartig, dass Entwickler weiterhin Projekte für die Allgemeinheit schreiben und den Quelltext veröffentlichen. Würde aber gerne wissen wo sich Horizon und bspw. auch LibreCAD relativ zu KiCAD positionieren. Ein Problem bei KiCAD ist ja nachweislich die etwas merkwürdige Benutzerführung. Wenn man sich aber einmal zurecht gefunden hat, kommt man sehr gut damit klar - "eigentlich".
Andreas H. schrieb: > Benutzt Du MSYS2 (<-- 2 !!!)? Evtl. verstehe ich dich falsch, aber MSYS2 ist doch für Windows der Cygwin Posix Layer, oder? Ich versuche, das ganze unter Ubuntu 16.04 zu kompilieren, also brauche ich kein MSYS!
tester schrieb: > Ich versuche, das ganze unter Ubuntu 16.04 zu > kompilieren, also brauche ich kein MSYS! Ne,das brauchst Du dann wirklich nicht, Ich dachte dass Du unter Windows arbeitest :-) /regards
Lukas K. schrieb: > Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" > in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. Den Teil fand ich (nicht böse gemeint) eher wirr. "Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der Benutzer nur zum Teil sieht. Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin (des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren unterschiedlichen "Units" vorkommen. Du verstehst meine Verwunderung? > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Das ist leider SOOOO wahr. Aber man muss solche Fehler ja nicht unbedingt wiederholen^^ > >> Hast Du schon eine Idee wie sich das Projekt weiterentwickeln soll? > Unabhängig von dem Programm selber: > Pool befüllen, dass man auch sinnvolle Schaltpläne und Boards machen > kann. Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu basteln? Dann füllt sich das von selbst. > > Kurz/mittelfristige ziele: Ich Deinen Text etwas umsortiert schreib da mal frech meine Gedanken dazwischen :-D > - Platzieren von Bauteilen einfacher machen > Liste von zuletzt benutzten Bauteilen; den Dialog "Select Part" > auch als nicht modales Fenster zur Verfügung stellen. > - Parametrische Suche: Die pool-parametric.db wird schon erzeugt, fehlt > "nur noch" ne hübsche GUI drüber. > - GUI für die constraints. Die als JSON zu bearbeiten und mit UUIDs zu > hantieren macht derzeit gar keinen Spaß. > - "Projekt-Manager", dass man sich nicht mehr die Argumente für > horizon-imp selber ausdenken muss, sondern einfach Klicken kann. Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu kriegen bevor man "Comfortfkt's" einbaut? Z.B.: > - DRC: mit der clipper-Library ist der algorithmisch schwere Teil > (Polygon-Operationen) schon erledigt, fehlt noch die gesamte > Infrastruktur außenrum. > Was behandelt der DRC denn? Clearance & width sind ja die Minimalforderungen. Wenn der Router Necking können soll, dann muss der DRC aber auch Mintracewidth handhaben können, ggf. auch mit Längenbeschränkungen. Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. Appropos Baustelle: Du schreibst "der Router weicht immerhin schon den meisten Hindernissen aus". Was für einen Router hast Du denn da am Start? (SOWAS habe ich z.B. gesucht) Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O directions bei den Gates ist mir nicht aufgefallen. > Nicht vergessen: Rom wurde auch nicht an einem Tag erbaut (und auch > nicht in einer Nacht) Du hattest doch in diesem Leben nichts anderes mehr vor (hoffe ich)? /regards
Andreas H. schrieb: > Lukas K. schrieb: >> Als ganz groben Anhaltspunkt gibt's den Abschmitt "Theory of operation" >> in der README, damit sollte man schonmal halbwegs wissen wo vorne ist. > > Den Teil fand ich (nicht böse gemeint) eher wirr. > "Unit" ist sehr ungünstig gewählt, weil man bei CAD als Unit immer an > eine Masseinheit denkt (typischerweise gibt es davon ja Mehrere, die der > Benutzer nur zum Teil sieht. > > Anyway. Lt. README wäre die atomare "Unit" ein Gate? Also ist ein Pin > (des Gates) was? Und ein Pin(-typ) kann ja auch in mehreren > unterschiedlichen "Units" vorkommen. > Du verstehst meine Verwunderung? Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte Ausrede, aber so ist's nun eben... Ich versuch's nochmal zu erklären, diesmal andersherum: Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity" definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps, IO-Bänke, etc). Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern extern davon und die Gates diese Definition referenzieren zu lassen. Ebendiese nennt sich dann "Unit". Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet... > Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu > basteln? > Dann füllt sich das von selbst. Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder geringfügig anders macht. Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher Importer durchaus sinnvoll sein. Einen Massenimport ohne Qualitätskontrolle wünsche ich mir allerdings nicht. Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann hoffentlich sinnvolles Feedback, was einen nicht so gefällt... Wenn jemand einen schreibt, der zufriedenstellend funktioniert, habe ich nichts dagegen :) > > Wäre es nicht sinnvoller Horizon erst mal vollständig zum laufen zu > kriegen bevor man "Comfortfkt's" einbaut? Z.B.: Durchaus, alles eine Sache der Prioritäten. > Was behandelt der DRC denn? Clearance & width sind ja die > Minimalforderungen. Wenn der Router Necking können soll, dann muss der > DRC aber auch Mintracewidth handhaben können, ggf. auch mit > Längenbeschränkungen. Genau, das war auch so mein Gedanke. > Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle > DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand an. > Appropos Baustelle: Du schreibst "der Router weicht immerhin schon > den meisten Hindernissen aus". > Was für einen Router hast Du denn da am Start? > (SOWAS habe ich z.B. gesucht) Ist recht primitiv: Der routet immer zwei Segmente (eines davon horziontal/vertikal und eines im 45°-Winkel), und versucht durch "umdrehen" der zwei Segmente DRC-Fehler zu vermeiden. Wenn das nicht klappt, bleibt der Track da stehen, wo's als letztes keinen DRC-fehler gab. Nicht vergleichbar mit dem was KiCAD macht, aber immerhin etwas. > Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O > directions bei den Gates ist mir nicht aufgefallen. Die gibt es, allerdings nur in der Datenstruktur: https://github.com/carrotIndustries/horizon/blob/master/pool/unit.hpp#L25 Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für "Checks" rausfallen, in die man dann auch ERC einhängen können sollte.
Lukas K. schrieb: > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Das habe ich früher auch mal gedacht. Mittlerweile habe ich -- dank der freundlichen Hilfe eines großen Meisters und meiner Erfahrung -- jedoch festgestellt, daß doxygen & Co. hervorragende und nützliche Dokumentation erzeugen können, wenn der Entwickler seinen Code sauber dokumentiert hat. Ganz unabhängig davon, ob Du doxygen oder ähnliche Werkzeuge magst oder nicht: wenn Du andere Entwickler dazu animieren willst, bei Deinem Projekt mitzuhelfen, solltest Du ihnen den Einstieg so einfach wie möglich machen. Und das beginnt nun einmal mit einer ordentlichen Dokumentation. Solche Werkzeuge können einem natürlich nicht die Arbeit abnehmen, seinen Code ordentlich und verständlich zu dokumentieren. Aber wenn man das macht, also: Klassen, Methoden, Variablen und vor allem die Konzepte und Schichten der Software vernünftig dokumentiert, dann können doxygen & Co. daraus eine sehr gute Dokumentation erzeugen. Und mit dieser Dokumentation können dann die vorhandenen und neuen Entwickler viel schneller verstehen, was gemacht wird, wo es gemacht wird, wie es gemacht wird und warum. Klar, so wie Dein Code bisher dokumentiert ist -- nämlich gar nicht, wie ein zugegeben oberflächlicher Blick zeigt -- wird kein Werkzeug der Welt daraus etwas Sinnvolles machen können. Keine Software kann Informationen aus dem Nichts generieren. Nicht einmal doxygen. ;-)
tester schrieb: > Lukas K. schrieb: >> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. > > Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, > ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. > Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei... Ubuntu im Allgemeinen ist wohl ne mittelgroße Baustelle, da auch in Ubuntu 16.10 nur Gtk 3.20 dabei ist, ich aber Funktionen von Gtk benutze, die es erst seit 3.22 gibt. Nichts was unbedingt notwendig ist, aber die #if GTK_CHECK_VERSION() kommen auch nicht von alleine... Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora 25. Hoppla.
Baendiger schrieb: > Gibt es gar keine Screenshots? Ich finde auch, dass fehlende Scennshots abschreckend wirken. Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst kann er sein Projekt gleich begraben.
Cyborg schrieb: > Baendiger schrieb: >> Gibt es gar keine Screenshots? > > Ich finde auch, dass fehlende Scennshots abschreckend wirken. > Wer weiß, was man sich da im Worst-Case-Fall einfängt und nicht > alles findet der Virenscanner. Vielleicht lernst der TO noch, sonst > kann er sein Projekt gleich begraben. EDA Sw für Leute die nicht lesen können wäre bestimmt eine Marktlücke. Der lesekundige Teil der Menschheit wird dann damit abgespeist: https://github.com/carrotIndustries/horizon/tree/master/screenshots /regads
tester schrieb: > Lukas K. schrieb: >> Hm, welcher GCC? Bei mir hier baut's mit GCC 6.3.1 und clang 3.9.1. > > Bei mir der Standard gcc/g++ 5.4 von Ubuntu 16.04. Aber der Patch läuft, > ich konnte part.cpp kompilieren. Jetzt hängt er bei schematic.cpp. > Die Meldung ist dieses Mal etwas länger. Ist als Anhang dabei... War nun doch weniger aufwändig als gedacht: https://github.com/carrotIndustries/horizon/commit/bf16b4bfb8179641f8a21b1eee4dfbbb7cf2a065 Baut nun auf Ubuntu 16.04, der Part-Editor tut auch, ob der interaktive Manipulator funktioniert, konnte ich nicht testen, da meine VM kein OpenGL 3 kann.
Lukas K. schrieb: > Bei KiCAD gibt's auch "Unit" im sinne von nicht-Maßeinheit. Schlechte > Ausrede, aber so ist's nun eben... Genau das. Schlechte Ausrede :-) > > Ich versuch's nochmal zu erklären, diesmal andersherum: > Das logische Bauteil (ohne Gehäuse, etc) ist in einer "Entity" > definiert. Eine solche Enity kann mehrere Gates haben (Gatter, Opamps, > IO-Bänke, etc). > Nun haben mehrere Entities die selben Gates, z.B. Quad- und Doppel-opamp > haben beide vier bzw zwei Opamp-Gates. Daher bietet es sich an, die > Gates mit ihren Pins nicht innerhalb der Entities zu definieren, sondern > extern davon und die Gates diese Definition referenzieren zu lassen. > Ebendiese nennt sich dann "Unit". > > Ich hoffe ich habe damit nicht noch mehr Verwirrung gestiftet... > Nö, leider nicht. Ein "logisches Bauteil" ist doch nur eine Funktion (ggf mit einem Symbol). Den Parametern muss man, genau wie dem Result einen Namen geben (Ports). Die vergibt man pro Funktion (z.B. Q = A & B). Mehr kann man jetzt noch nicht zuordnen. Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der Funktionen definiert. Und erst jetzt kann (und muss) man den Ports eindeutic Pins zuordnen (Pin == das wo Du Dich raufsetzen und pieksen kannst, zumindest bei z.B. THT Bauteilen). Dann hätten Deine Funktionen endlich unterschiedliche "Namen" für die Pors der jeweiligen Funktionen (Q1 = A1 & B1, Q2 = A2 & B2 usw). Du hast also ZWEI Sachen. Die "Ports" an der "Funktion" und die "Pins" am Gehäuse. Ports haben z.B. elektrische Parameter (z.B In-/Output), Pins eher Mechanische (Fläche, evtl. Drill usw.). Ob es wirklich sinnvoll ist, dem jetzt nochmal "frei gewählte" Bezeichnungen zuzuordnen? Ich sehe da wenig Sinn. >> Spricht etwas dagegen einen Eagle/KiCad/Whatever -> Horizon Converter zu >> basteln? >> Dann füllt sich das von selbst. > > Wäre ein doch bedeutender Aufwand, man müsste eben gemeinsame Gates über > Bauteile hinweg finden, daraus Units machen, etc. Die Platzierung von > Texten ist dann wahrscheinlich vollkommens im Eimer, weil das jeder > geringfügig anders macht. > > Für einzelne Bauteile (große Mikrocontroller z.B.) kann ein solcher > Importer durchaus sinnvoll sein. Einen Massenimport ohne > Qualitätskontrolle wünsche ich mir allerdings nicht. > Checken muss man das sowieso. Ich kenne auch kaum Leute, die die Libs der Tools benutzen, ohne vorher die Bauteile, die sie benutzen, mal geprüft zu haben. Auch EDA Hersteller machen Fehler^^ > Auch ist man ohne Importer gezwungen, horizon zu benutzen und gibt dann > hoffentlich sinnvolles Feedback, was einen nicht so gefällt... Das ist Mutig. Denn niemand ist GEZWUNGEN horizon für irgendetwas zu benutzen. Im Gegenteil. Ich würde meine eigenen Libs ungern nochmal einhacken müssen. >> Was behandelt der DRC denn? Clearance & width sind ja die >> Minimalforderungen. Wenn der Router Necking können soll, dann muss der >> DRC aber auch Mintracewidth handhaben können, ggf. auch mit >> Längenbeschränkungen. > > Genau, das war auch so mein Gedanke. > Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker (zumindest ältere PicknPlace Automaten hatten da Limits). >> Ist Dein Router (if any) schon DRC aware (d.h. berücksichtigt er alle >> DRC Rules)? Ansonsten hast Du da noch eine große Baustelle. > > Er legt keine Leiterbahn, so dass der Minimalabstand zu anderen Netzen > unterschritten wird, aber schmiegt sich nicht an diese auf DRC-Abstand > an. > Muss er auch nicht unbedingt (Diff-Pairs mal ausgenommen). >> Und finally: ERC? Ich hab nur kurz in die Quellen reingeschaut aber I/O >> directions bei den Gates ist mir nicht aufgefallen. > > Die gibt es, allerdings nur in der Datenstruktur: > https://github.com/carrotIndustries/horizon/blob/master/pool/unit.hpp#L25 > > Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für > "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. Ob da zwei Pins geneinander treiben ist dem Router genauso egal, wie die Tatsache, das ein Netz nur Eingänge als Pins hat. Andersherum interessiert es den ERC nicht wenn Du 20A über eine 6mil Leitung jagst oder 20KV mit 10mil clearance routest. /regards
Lukas K. schrieb: > Schaut also aus, als liefe horizon derzeit nur auf Arch Linux und Fedora > 25. Lukas K. schrieb: > konnte ich nicht testen, da meine VM kein > OpenGL 3 kann. Wäre vielleicht sinnvoll, die Anforderungen (compiler, HW) etwas zu reduzieren. Ansonsten fallen viele potentielle Tester schon mal weg, selbst wenn du es Dir antust für diverse OS Packages zu bauen. Spätestens bei Graphikkarten kanns eng werden. KiCad hat z.B. eine ganze Zeit mit einem Problem von WxWidgets mit GTK3 gekämpft. Und da konnte KiCad garnichts dafür. Was spricht denn gegen eine "konservative" Toolchain (bei Linux z.B. Debian Jessie oder RH/CentOs6, bei Windows Win7, bei Mac k.A.^^)? Das Ganze mit AutoConf oder cMake erleichtert auch das Portieren. Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn man so einigen Foren glauben darf. /regards
Hardy F. schrieb: > Also bitte versuche einen fertigen Windows-Build mit dazuzustellen auf > der Seite. Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet, dann sind Leute, die es sich nicht selbst compilieren können oder wollen ohnehin keine sinnvollen Alpha-Tester. Falls da wirklich „was abgeht“, dann musst du damit rechnen, dass du das täglich oder aller zwei Tage neu bauen musst, damit du nicht die Bugs nochmal versuchst zu finden, die seither schon beseitigt sind. In dieser Phase kann man sowas einfach nicht durch vorgekochte Builds erschlagen. Ich weiß auch nicht, inwiefern es wirklich Sinn hat, das x-te Programm dieser Art anzufangen, aber das wird die Zeit sicher zeigen. Solange es Lukas erstmal nur aus Spaß an der Freude gemacht hat, ist es doch nur fair, wenn er anderen die Möglichkeit einräumt, es ebenfalls zu testen und ggf. Verbesserungen vorzuschlagen. Aus eigener Erfahrung kann ich natürlich sagen, dass solche Vorschläge am besten die Form eines "diff" annehmen :) (oder bei github wahrscheinlich eines pull requests).
Vielleicht orientiert ihr euch an bereits bestehenden Workflows. Kicad erinnert mich an OrCad und lässt sich so von mir fast intuitiv bedienen. Vielleicht springt ihr in die Bresche und macht nen Adler-Kompatiblen Workflow. Da dürfte dann für viele User der Grund zum Wechsel werden.
Andreas H. schrieb: > Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der > Funktionen definiert. Da liegt der Hund begraben. In horizon gibt es da noch den Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es problemlos bei einem Component (instantiierte Entity) das Part auszutauschen, ohne dass die Netzliste was davon mitbekommt. Andreas H. schrieb: > Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden > (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen > willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker > (zumindest ältere PicknPlace Automaten hatten da Limits). Das Raster kommt daher, dass der Cursor auf's grid einschnappt. Andreas H. schrieb: >> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für >> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. > > Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. Klar, die Implementierung der Checks ist vollständig verschieden, am Ende vom Tag können beide aber die gleiche Infrastruktur zur Konfiguration und Darstellung der Ergebnisse nutzen. Was Toolchains, etc anbetrifft: Mittlerweile baut's ja auf Ubuntu 16.04 und kommt auch mit Gtk 3.18 zurecht. OpenGL 3.2 ist leider Pflicht, da zum Rendern u.A. geometry shader verwendet werden. Mag zwar erstmal unnütz klingen, ist voraussichtlich bei großen Boards von Vorteil. Ist jetzt auch schon über 7 Jahre her, dass das wirklich neu war. Andreas H. schrieb: > Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn > man so einigen Foren glauben darf. War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht nachvollziehen, works for me. Jörg W. schrieb: > Hardy: wenn sich ein Programm selbst noch als „halbfertig“ bezeichnet, > dann sind Leute, die es sich nicht selbst compilieren können oder > wollen ohnehin keine sinnvollen Alpha-Tester. Da ist was wahres dran. Rein technisch sind windows-Builds kein Problem [1], nur erwarten viele Windows-user, dass dann eine Exe rausfällt, auf die sie doppelklicken können und was sinnvolles passiert - so weit ist horizon nun noch nicht. Auch wünsche ich mir, dass von den Anwendern backtraces, etc kommen. "horizon-imp.exe funktioniert nicht mehr" ist da nicht wirklich hilfreich. Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn ich will nicht nach jedem commit meine Windows-VM anwerfen müssen. [1] https://github.com/carrotIndustries/horizon/blob/master/make_bindist.sh
Lukas K. schrieb: > Auch bräuchte ich für die Windows-Builds sowas wie nen buildbot, denn > ich will nicht nach jedem commit meine Windows-VM anwerfen müssen. ich würd jetzt in dieser frühen Phase erstmal primär kein Gewicht auf zeitnahe Windows-Builds (oder andere Exotenplatformen) legen sondern auf das System konzentrieren unter dem auch primär die Entwicklung stattfindet, und da brauchst Du auch keine Binaries zu bauen, das machen die Tester und Mitentwickler eh selbst. Früher oder später wirst Du dann jemanden finden der genug Interesse an Windows hat daß der sich um die Windows-Builds kümmert.
Bernd K. schrieb: > Früher oder später wirst Du dann jemanden finden der genug Interesse an > Windows hat daß der sich um die Windows-Builds kümmert. Oder man kann sich dann auch wirklich die Infrastruktur selbst mal aufsetzen. Ich habe mittlerweile (bei AVRDUDE) lernen müssen, dass das am Ende schneller geht als zu hoffen, dass sich einer der Windowsianer zu sowas freiwillig hinreißen lässt. :( Das hat dann das Kuriosum, dass dabei Windows-Builds enstehen, die selbst beim Bauen nie ein Windows gesehen haben. :-)
Bernd K. schrieb: > Früher oder später wirst Du dann > jemanden finden der genug Interesse an Windows hat Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist das natürlich konsequent. Der grundlegende Irrtum ist wohl, dass man eine abgeschottete Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur nicht später wundern, wenn keiner das Programm benutzt. Georg
Georg schrieb: > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, Wieso Linux? Das Ding compiliert ja offenbar unter Windows. Vermutlich bekommt man es auch unter anderen Systemen zum Laufen. Es sind also nicht Windows-Nutzer per se ausgeschlossen, wie du das unterschwellig darstellst. > und nicht Leute, die > Leiterplatten entwerfen. Das ist erstmal völlig unabhängig vom OS: in solch einer frühen Entwicklungsphase wirst du so oder so keine Platinendesigner groß finden, die da ernsthaft gewillt wären mitzuentwickeln. Es wurde ja schon dargelegt, dass „Kunden“, die als Feedback dann lediglich „horizon.exe hat einen Fehler verursacht und wurde beendet“ oder „ich hätte gern Feature XYZ, bevor ich mir das ansehe“ in so einer Entwicklunsphase sowieso nicht zielführend sind. In dieser Phase braucht man Leute, die Bugs nicht nur melden, sondern zumindest analysieren, oder die eben auch mal anfangen, wenigstens über die Implementierung eines Features nachzudenken. Opensource kennt in diesem Sinne erstmal keine „Kunden“, sondern eher „Macher“ (auch wenn dieser Begriff mittlerweile anderweitig verzerrt worden ist). Das ist ein sehr grundlegender Unterschied zu Bezahlsoftware. Übrigens ignorierst du geflissentlich, dass ein großer Teil der CAD-Szene im IC-Design, das ja durchaus mit Platinendesign verwandt ist, historisch auf großen UNIXen und heute nach wie vor massiv auf Linux abläuft. Ist also keineswegs so, dass es da keine Anwender gäbe. Aber das wissen natürlich Leute, die in ihrer abgeschotteten Windows-Brüderschaft herumwerkeln, vermutlich gar nicht (um mal deine Worte zu gebrauchen).
was ist an Autotrax nicht gut? Nutze selber Target, aber AT sieht gut aus auch die Aufmachung der Seite
Stefan schrieb: > was ist an Autotrax nicht gut? Das sollte ihr bitte in einem eigenen Thread diskutieren. Den hier hat Lukas angefangen, um über horizon zu diskutieren.
das wird noch sowieso nie einer benutzen also völlig wertlos
Stefan schrieb: > das wird noch sowieso nie einer benutzen also völlig wertlos Also ich mache als Hobby auch viele Dinge die niemand benutzt. Beim Hobby ist der Weg das Ziel. Solange es Spaß macht spricht nichts dagegen.
Wer sich ins Abenteuer stürzen will, und auf Windows bauen möchte: https://github.com/carrotIndustries/horizon/blob/master/build_win32.md
Lukas K. schrieb: > Wer sich ins Abenteuer stürzen will.. Nun ja, so ganz im Prinzip ist es allemal lobenswert, wenn jemand anfängt, sich mit so einem Projekt eine Mühe zu geben. Aber wer soll sich da zusätzlich ins Abenteuer stürzen? Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien entwickelt und dargestellt sind. Dort gehört also hinein, wie das ganze Programm von seiner ineren Logik her funktionieren soll, wie die Daten gehalten werden sollen, wie das Userinterface funktionieren soll, also wie man mit dem Programm später umgehen kann. So etwas ist tausendmal wichtiger als sofort in die Tasten zu hauen. Es ist aber nötig vor jeglichen Programmieranstrengungen - zum einen damit man selber sowie eventuelle Mitarbeiter wissen, wie das Ganze zusammenspielen soll und zum anderen, damit interessierte Anwender ihre Sicht auf die Dinge einbringen können. Sonst wird das Ganze mal wieder ein Ding, das nur aus Sicht der Programmierer konstruiert wurde und an den tatsächlichen Bedürfnissen der Benutzer vorbeigeht. Man mag sowas ein Pflichtenheft nennen, ich würde das zunächst nur ein Papier zur Ideen-konsolidierung nennen. Wenn sich das dann entwickelt, kommen interne Schnittstellen-Definitionen hinzu, damit verschiedene Leute an verschiedenen Teilen arbeiten können ohne sich gegenseitig zu hakeln. Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig herauszufinden, wie hier was funktionieren soll? Nee, ich selber bin da außen vor, ich mache nix in cpp, sondern allenfalls mit Delphi oder Lazarus. Aber die Wahl einer Programmiersprache oder einer Toolchain ist mMn zweitrangig. Zuerst geht es um den tatsächlichen Systementwurf - und den vermisse ich hier. W.S.
Lukas K. schrieb: > Andreas H. schrieb: >> Erst wenn das Ganze in ein Device wandert, dann ist die Art & Anzahl der >> Funktionen definiert. > > Da liegt der Hund begraben. In horizon gibt es da noch den > Zwischenschritt "Entity". Für die Netzliste ist ein Quad-Nand-Gatter in > CMOS-4000er Logik in DIP Gleichwertig mit einem 74HC in (theoretisch > BGA). Wenn man sich mitten im Design-Prozess anders entscheidet, ist es > problemlos bei einem Component (instantiierte Entity) das Part > auszutauschen, ohne dass die Netzliste was davon mitbekommt. Was bringt das? Eine Netzliste ist doch on-the-fly erzeugt und ändert sich während des Schematic entrys laufend (bei Backanotation ja auch noch). Der Sinn will sich mir nicht erschliessen, sry. Ich sehe da z.Z. nur potentielle Fehlerquellen. > > Andreas H. schrieb: >> Ich habe beim Überfliegen auch nirgens irgendwelche Grids gefunden >> (übersehen?) Man kann ja gridless routen. Aber wenn Du Gridless Placen >> willst, dann hast Du evtl. interessante Diskussionen mit dem Bestücker >> (zumindest ältere PicknPlace Automaten hatten da Limits). > Das Raster kommt daher, dass der Cursor auf's grid einschnappt. > Das Raster IST das Grid. Und das ist ja nicht nur dort wo der Cursor ist. Ich entnehme Deiner Aussage mal, dass es mindestens ein Grid gibt :-) > Andreas H. schrieb: >>> Wenn es DRC gibt, sollte dabei als Nebenprodukt eine Infrastruktur für >>> "Checks" rausfallen, in die man dann auch ERC einhängen können sollte. >> >> Nö. Das sind zwei (fast) komplett unterschiedliche Baustellen. > Klar, die Implementierung der Checks ist vollständig verschieden, am > Ende vom Tag können beide aber die gleiche Infrastruktur zur > Konfiguration und Darstellung der Ergebnisse nutzen. Never. DRC geht auf geometische Daten, dem ERC reicht eine "annotierte" Netzliste (annotiert meint hier, das die Pins noch die "Direction" Attribute brauchen). Ansonsten könntest Du keinen ERC machen, bevor das Layout steht^ (Ok, theoretisch könntest Du Parasitics aus dem Layout extrahieren & prüfen. Aber das ist eine GAAANZ andere Geschichte.) >> Auch GTK3 erfreut sich ja anscheinend zunehmender Unbeliebtheit, wenn >> man so einigen Foren glauben darf. > > War absehbar, dass das kommt ;) Ich persönlich kann das Gejammer nicht > nachvollziehen, works for me. Nimm was Dir Spass macht. Aber wenn es nachher nur bei 30% der Leute läuft dann macht es auch wenig Sinn, oder? Und einen kleinen Vorgeschmack hast Du ja gestern schon bei tester mitbekommen. Das Ganze dann *100^^ /regards
Georg schrieb: > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die > Leiterplatten entwerfen. DEIN grundlegender Irrtum ist, dass OSS Entwickler soviel Zeit haben, dass sie neben der Weiterentwicklung auch noch Unmengen an Hilferufen bearbeiten können. Das wird meist noch nerviger wenn die "Kunden", wie Du sie nennst, meist nicht mal vernünftige Fehler-/Environmentbeschreibungen liefern. Und das findest Du bei Linux/Windows/Mac "Kunden" gleichermassen.
W.S. schrieb: > Eigentlich müßte man mMn so ein Projekt völlig anders angehen, nämlich > mit einem Dokument, PDF oder LibreOffice oder so, wo die Grundprinzipien > entwickelt und dargestellt sind. Im Prinzip schon. Aber das kann man auch im Forum diskutieren. Gerade am Anfang fliessen dann auch Erfahrungn von Anderen ein ohne das erst mal viel "Papier" gemacht wird. Mir würde es auch nur bedingt Spass machen, erst mal eine komplette Spec zu schreiben (das V-Modell nervt auf Arbeit schon genug). > Aber so, wie es vorliegt? Wer soll sich da hineinknien, um mühselig > herauszufinden, wie hier was funktionieren soll? Da gibts aber einige Hinweise auf der Projektseite. /regards P.S: W.S. schrieb: > Nee, ich selber bin da außen vor, ich mache nix in cpp, sondern > allenfalls mit Delphi oder Lazarus. Ich leiste mir meist nicht den Luxus mich auf eine Programmiersprache festzubeissen. Aber bei Lazarus wäre ich dabei (Delphi geht ja leider nur unter Windows). Dann wäre man z.B. schon einen Großteil des "Buildwahns" los.
Lukas K. schrieb: > OpenGL 3.2 ist leider Pflicht Tja, das ist z.Zt. das Problem. Nach dem letzet git pull ist die Compilierung durchgelaufen, danke dafür. Aber starten kann ich es nicht: xxxxx@HPi7:~/src/horizon$ ./horizon-imp -c sch.json block.json constr.json (horizon-imp:5550): GLib-GObject-CRITICAL **: g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed horizon-imp: Couldn't find current GLX or EGL context. Mein X.org Server scheint nur OpenGL 3.0 zu haben: xxxxx@HPi7:~/src/horizon$ glmark2 ======================================================= glmark2 2014.03+git20150611.fa71af2d ======================================================= OpenGL Information GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.8.0) GL_VERSION: 3.0 Mesa 11.2.0 ======================================================= Hm... eingebaut ist eine Radeon HD6570, die sollte das eigentlich können. Nach https://wiki.ubuntuusers.de/Grafikkarten/AMD/radeon/ sogar OpenGL4.1, aber mindestens OpenGL3.3. Mal sehen...
Also, prüfst du irgendwo im Quelltext die OpenGL Version? Die
Grafikkarte sollte Shader 3.3 können, der Treiber scheint aber nach
außen hin
nur die 3.0 zu melden. Den Error-String "Couldn't find current GLX or
EGL context" habe ich im Quelltext nicht gefunden, um die Stelle zu
lokalisieren...
xxxxx@HPi7:~/src/horizon$ glxinfo | grep version
#server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0
OpenGL core profile shading language version string: 3.30
OpenGL version string: 3.0 Mesa 11.2.0
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES
3.00
Fehler hatte wohl doch nichts mit OpenGL zu tun. Aus
imp/main_window.cpp:
[...] x->add_from_resource("/net/carrotIndustries/horizon/window.ui");
Wie viele hardcodierte Pfade sind denn da drin?
xxxxx@HPi7:~/src/horizon$ grep -r -i "/net/carrotIndustries/horizon" |
wc
36 151 4173
Ok, habe jetzt mal einen Symlink angelegt. Recht viel weiter komme ich leider nicht: xxxxx@HPi7:/net/carrotIndustries/horizon$ ./horizon-imp -c sch.json block.json constr.json terminate called after throwing an instance of 'Gio::ResourceError' Abgebrochen (Speicherabzug geschrieben) Gut für heute...
Das OpenGL-Problem sollte nun behoben sein, hatte mal wieder mit älteren Gtk-versionen zu tun: https://github.com/carrotIndustries/horizon/commit/3df57bea51b54b41e15d4d45c9bf844e2c1c8469 Die Pfade da sind keine Pfade im engeren Sinne: https://developer.gnome.org/gio/stable/GResource.html Mit den "resources" können Dateien, die das Programm zur Laufzeit benötigt mit in die Binary gebacken werden.
Andreas H. schrieb: > Aber das kann man auch im Forum diskutieren. Im Prinzip - ja. Aber so ganz blank - ohne wenigstens ein Anfangspapier? Nee. geht nicht. Du siehst ja an den Beiträgen kurz unter deinem, was da losgeht. Ärger mit OpenGL ist doch eigentlich etwas, das so unendlich lowlevel ist, daß es die eigentliche Funktionalität garnicht berührt. Also MUSS man eine Trennung einziehen zwischen der CAD-Funktionalität und solch niederen Dingen wie Betriebssystem, GraKa und so weiter - versteh das richtig: es ist beides vonnöten, aber es muß strikt auseinander gehalten werden. Womit wir wieder beim Papier mit der Grundsatzrede (a la Honecker.. oder lieber nicht) sind. Es hat wirklich keinen Zweck, draufloszucoden, solange kein "Honecker"-Papier existiert, das wenigstens einigermaßen ausdiskutiert ist. Beruflich kenne ich das so, daß im Gremium ein Papier im Word-Format existiert, wo reihum jeder seinen Senf reinschreibt - und das wird dann beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben so lange, bis alle abgenickt haben. W.S.
W.S. schrieb: > das wird dann > beim nächsten Treffen diskutiert. Dann geht die nächste Runde los.. eben > so lange, bis alle abgenickt haben. Da hast du die Zeichen der Zeit nicht erkannt - in Zukunft zählt nur noch die Methode Trump, Abweichler werden sofort standrechtlich erschossen und technische Fragen werden durch alternative Fakten gelöst. Im Ernst, Konsens ist sowas von gestrig. Georg
Lukas K. schrieb: > mein Elektronik-CAD-Programm endlich halbwegs > vorzeigbar: Hallo Lukas! Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas zustande bringen, statt immer nur rumzumosern. Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse. Aber du wirst wohl eh nicht erwarten, dass sich jemand an Deinem Projekt beteiligt. Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst, warum hast Du dann nicht gleich Qt verwendet? Die Kombination ist doch eigentlich ganz gut. Und GTK ist ja momentan extrem unbeliebt bei Anwendern. Manch mal denke ich, dass ich der Einzige bin, der es noch verwendet. Community ist ja auch so gut wie tod. Aber gut, einige wenige arbeiten im stillen Kämmerlein wohl doch noch an GTK4, vielleicht wird GTK dann wieder populärer. Es soll ja immerhin ein Vulkan Backend geben! Und wenn schon GTK, dann hätte man ja auch eine moderne und schönere Sprache nehmen können. Language Bindings gibt es ja reichlich, vom mir für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen. Oder aber, man hätte das ganze eher Web-basiert aufziehen können -- davon schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder so. Tablet Support. Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na ja gerade so. Ja ich werde mir Dein Projekt wahrscheinlich mal ansehen. Falls Du es tatsächlich fortführst, künnte ich ja drüber nachdenken, Dein Dateiformat zu übernehmen. Momentan verwende ich das gEDA Format, aber das gEDA Projekt ist ja wohl auch recht tod. Allerdings, wenn ich irgendwann mal daran weiterarbeite, werde ich von Ruby wohl auf Nim umsteigen. Abernatürlich gibt es genügend andere interessante Aufgaben.
Angehängte Dateien:
Stefan S. schrieb: > Ja was soll ich sagen? Zunächst sollte ich Dir wohl mal meine > Anerkennung aussprechen -- Du bist einer der wenigen hier, die mal etwas > zustande bringen, statt immer nur rumzumosern. Freut mich sehr auch mal das zu lesen :) In gewisser maßen kann man horizon als "opinionated software" bezeichnen. Horizon ist die Materialisierung eines EDA-Programms, so wie ich es mit meiner Erfahrung für richtig und sinnvoll erachte. Dass das andere Leute nicht so sehen, ist dann eben so. Allen kann man's eh nie recht machen. Stefan S. schrieb: > Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren > mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und > auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das > Interesse ja praktisch null. Leider nicht, aber in der Tat scheint das Interesse der Leute hier an nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt") auf PCB elegance aufmerksam gemacht: Beitrag "PCB Elegance" Hat genau niemanden interessiert. Ähnlich mit librepcb: Beitrag "librepcb Free Schematic und PCB Editor Erfahrungen Leistungsvergleich" Auf das Projekt wurde ich auch erst zufällig auf dem 33C3 aufmerksam. Stefan S. schrieb: > Was mich doch etwas wundert: Wenn Du schon in C++ programmieren magst, > warum hast Du dann nicht gleich Qt verwendet? Historisch gewachsen. Ich hatte schon seit ca. 5 Jahren GUIs mit Gtk programmiert, praktisch nur mit Python und hab hab damit sehr gute Erfahrungen gemacht. Horizon hatte ursprünglich als eine Kombination von C und python angefangen, wurd' mir dann irgendwann zu doof und ich hab' dann C genommen. Das ging gut, bis ich UUIDs durch GObject schieben wollte und mir der GObject-Krams zu umständlich erschien. Dann hatte ich mir mal C++ und Gtkmm angesehen und die Kombination für perfekt befunden. Mit Qt hatte ich noch nie wirklich was am Hut, hatte aber auch nie das Gefühl, dass mir als Entwickler was bei Gtkmm fehlt. Vielleicht auch eine Mischung aus Vendor-Lockin und Stockholm-Syndrom... Die Gtk-Entwickler sind im IRC und in bugreports auch durchaus hilfreich, kann mich diesbezüglich nicht beschweren. Persönlich gefallen mir auch die Client-Side decorations von Gtk nach anfänglicher Skepsis gut, als Beispiel der Footprint-Generator aus horizon im Anhang. Stefan S. schrieb: > Language Bindings gibt es ja reichlich, vom mir > für GTK3, aber auch für Rust oder Crystal hatte ich welche gesehen. C++ mag zwar ein wenig altbacken wirken, aber mit C++ hat man noch die größte Chance Leute zu finden die das auch können. Außerdem ist die Nutzerbasis von Gtk-Bindings zu z.B. Rust nochmal geringer, als die von Gtkmm. >Oder > aber, man hätte das ganze eher Web-basiert aufziehen können -- davon > schwärmen ja einige (ich selber weniger). Also Java-Script, HTLM5 oder > so. Tablet Support. Bloß nicht. Die Frameworks im Web-bereich haben eine gefühlte Haltbarkeitszeit von 3 Monaten, danach ist schon wieder das nächste hip. Gtk und C++ sind da deutlich gemächlicher. Stefan S. schrieb: > Du hast OpenCL verwendet -- alle Achtung, dass hatte ich mir damals > nicht zugetraut. Aber Cairo ist eigentlich auch noch schnell genug -- na > ja gerade so. Eben. OpenGL war mehr so nen Angstreflex, dass später auch mal größere Boards halbwegs schnell rendern. Auch dreht die GPU eh größtenteils Däumchen, warum die nicht mit Malen vom Grid, Linien mit runden Enden und schraffierten Dreiecken beauftragen? Schaden kann's ja nicht und das OpenGL-programmieren mit shadern und so macht auch Spaß.
Lukas K. schrieb: > aber in der Tat scheint das Interesse der Leute hier an > nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Stefan S. schrieb: > Du kennst ja sicher meinen Schaltplaneditor, den ich vor einigen Jahren > mal in Ruby programmiert hatte (http://ssalewski.de/PetEd.html.en), und > auch meinen Toporouter(http://ssalewski.de/Router.html.en). Da war das > Interesse ja praktisch null. Oder den Schaltplaneditor, den hier jemand > vor etwa einem jahr in Jawa präsentiert hatte -- auch null Interesse. Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen warum das so ist. Euer Wissen, das ja anscheinend vorhanden ist, könnte man sicherlich 'gewinnbringender' an den Mann bringen.
il Conte schrieb: > Ihr solltet mal eure Scheukappen bei Seite schieben und mal überlegen > warum das so ist. ... wenn die Fähigkeit, das Programmieren zu beherrschen, nur mit Gleichgesinnten geteilt wird, dann darf man sich nicht beklagen, wenn die "Übriggebliebenen" sich leider mangels ebendieser Fähigkeiten abwenden... Wenn man jemandem etwas hinstellt, mit dem er nicht umgehen kann, wird er sich damit nicht beschäftigen.
Lukas K. schrieb: > Leider nicht, aber in der Tat scheint das Interesse der Leute hier an > nicht-mainstream EDA-Tools im allgemeinen eher gering zu sein. Vor > einiger Zeit hatte ich hier mal (keine Ahnung warum im Forum "Markt") > auf PCB elegance aufmerksam gemacht: > Beitrag "PCB Elegance" Hat genau niemanden > interessiert. Doch. Nur ist ein EDA-Tool einfach nur dazu da seine Schaltung mit einer Leiterplatte zu verheiraten. Es muß schon einen Grund geben sein bisher verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was Neuem produktiv arbeiten kann ganz schön lange dauert. Und Leute die wirklich gut programmieren können und richtig gut Entwickeln/Entflechten können sind wirklich rar.
Michael X. schrieb: > Und Leute die wirklich gut programmieren können und richtig gut > Entwickeln/Entflechten können sind wirklich rar. Wobei ich die Idee des Toporouters schon mal nett fände. Weiß ja nicht, inwiefern man den vielleicht auch mit KiCad verheiraten könnte? Ist aber 'ne andere Baustelle, hier geht's um horizon. Auch, wenn ich selbst keine Ressourcen frei habe, finde ich die Diskussion darum allemal interessant und werde hier weiter mitlesen.
Michael X. schrieb: > Es muß schon einen Grund geben sein bisher > verwendetes Tool ersetzen zu wollen, da die Einarbeitung bis man mit was > Neuem produktiv arbeiten kann ganz schön lange dauert. Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache, dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter gepflegt werden müssen. Für Elektronik-Firmen ist CAD-Layout eine strategische Software, die die Existenz der Firma beeinflussen kann. Es kann schon zur Katastophe werden, wenn die BWLer entscheiden, dass die Entwickler plötzlich mit anderer Software arbeiten müssen. Es ist also vernünftig, bei solchen Fragen sehr konservativ zu sein. Georg
Georg schrieb: > Das ist nur ein Teil des Problems, wichtiger ist meist die Tatsache, > dass zahlreiche, u.U. hunderte fertige Layouts existieren, die weiter > gepflegt werden müssen. Kein großes Argument: die Benutzung einer neuen Software zwingt doch keinen dazu, die alte deswegen gleich zu verschrotten. Aber Georg, für derartige Entscheidungsfragen ist es bei horizon ganz gewiss zu früh, ich schätze mal wenigstens 5 Jahre zu früh. Das ist jetzt keine Missachtung von Lukas' Leistung, aber er nennt es ja selbst „halbfertig“. Erst müsste es also mal fertig werden, und dann noch so interessant für Platinendesigner werden, dass sie überhaupt drüber nachdenken, sich in eine weitere Software einzuarbeiten. Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester haben können, aber dazu hätte horizon erstmal Beta-Charakter haben müssen. So weit ist es wohl noch nicht.
Jörg W. schrieb: > Wenn Lukas ein wenig eher damit fertig geworden wäre, hätte er jetzt > vielleicht ein paar angep***ste Adler-Nutzer als willige Betatester > haben können, aber dazu hätte horizon erstmal Beta-Charakter haben > müssen. So weit ist es wohl noch nicht. Was Du da schreibst gilt aber eher für kommerzielle Software, und ich glaube nicht, dass Lukas ersthaft hofft, sein Programm mal teuer verkaufen zu können. Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind, die Mitwirkung anderer sinnvoll und hilfreich -- etwa durch gut durchdachte Vorschläge, Problemlösungen, oder womöglich sogar durch Programmcode. Wenn alles schon fast fertig ist, dann kann man nicht mehr viel ändern, und es bleibt im wesentlichen nur das Mosern. Aber die breite Masse postet heute eben lieber Fotos von ihrem Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos. Und das ist auch völlig OK.
Stefan S. schrieb: > Aber die breite Masse postet heute eben lieber Fotos von ihrem > Mittagessen auf Fakebook, sucht Pokemons oder guckt Videos. Jetzt erinnerst du an Sokrates. > Bei EDA-CAD wäre gerade in der frühen Phase, wenn etwa 30 % fertig sind, > die Mitwirkung anderer sinnvoll und hilfreich Nur, dass du in dieser Phase eben noch niemanden da bekommen wirst, der das wenigstens halbwegs produktiv benutzen will. Diese Leute hatte ich als Eagle-Umsteiger im Blick, von denen es gerade ein paar mehr geben dürfte als zuvor.
Entwickeln und "produktiv benutzen" sind bei einem größeren Softwareprojekt schon sehr verschiedene Sachen. In der Anfangsphase kann man Ideen und Problemlösungen einbringen, die Software damit aktiv mitgestalten und womöglich Freude daran haben. Produktiv nutzen kann man so ein Programm in dieser Phase aber eher nicht, schon gar nicht wenn man wirklich Platinen herstellen lässt und auf deren Funktionsfähigkeit angewiesen ist. Später, wenn das Programm weitgehend fertig ist, kann man es hoffentlich produktiv nutzen, aber dann wird man sich auf Fehlerberichte beschränken und hoffen das sie irgendwann behoben werden. Letzteres hatte ich lange Jahre bei gEDA beobachtet -- fast alle neuen Ideen oder größeren Erweiterungen wurden von einigen Altusern abgelehnt, und selbst ohne diese Ablehnung wäre es für Neulinge schwer diese ohne Hilfe der ursprünglichen Entwickler zu implementieren.
Ach Lukas, was mir gerade noch einfällt... Wie machst Du das mit der Textausgabe in den Gerber-Dateien? Am Bildschirm hat man ja zunächst hochwertige Fonts, etwa Truetype oder was auch immer, bei mir wäre das Pango-Rendering. Gerber hat ja aber keine wirklichen Fonts, man muss also alles durch Linien und Kreisbögen darstellen. gEDA/PCB verwendet auch am Bildschirm primitive Fonts, die aus Kreisbögen und Linien bestehen, darunter leidet aber die Darstellungsqualität. Mein Ansatz wäre gewesen, zunächst echte Fonts zu verwenden und die dann in Linien/Kreisbögen für Gerber zu wandeln. Und noch eine andere Bemerkung: Wenn ich ein C++ Freund wäre, hätte ich womoglich auf Qucs mit Qt aufgebaut -- da hätte man Schaltplan- und Simulation schon mal, und müsste dann nur noch den Platinenteil machen. Hast Du schon über Simulations-Anbindung nachgedacht? Dein Git-Reposity werde ich mir demnächst ansehen, ich bin mir eigentlich sicher dass es sich lohnt, blos momentan ist die Zeit etwas knapp...
Stefan Salewski schrieb: > Mein Ansatz wäre gewesen, zunächst echte Fonts zu verwenden und die dann > in Linien/Kreisbögen für Gerber zu wandeln. Den Vorteil dieses Ansatzes sehe ich darin, dass man schon alles für den Bildschirm fix & fertig hat und dass die Geschwindigkeit dafür optimiert ist. Der Nachteil ist, dass man eine deutlich höhere Genauigkeit vorgegaukelt bekommt, als sich am Ende erzielen lässt. Man neigt meiner Erfahrung nach dann dazu, viel zu kleine Schriften zu benutzen.
Ja, das ist richtig. Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine Bibliothek die so etwas schon gut macht? Ist extended Gerber eigentlich immer noch "State of the Art"? Vor ca. 5 Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich dunkel, dass es zwei "modernere" Alternativ-Formate gab.
Stefan Salewski schrieb: > aber ich errinnere mich > dunkel, dass es zwei "modernere" Alternativ-Formate gab Modern muss nicht besser heissen. ODB++ löst zwar manche Probleme, andere aber nicht, auch weil sie garnicht lösbar sind - es gibt nun mal keine Norm für Lagenbezeichnungen, das macht jeder wie er will, und neben üblichen wie "Top" oder "Bestückungsseite" gibt es ungefähr so viele wie Layouter. Ausserdem, was heisst bei einer heutigen Schaltung überhaupt "BS" oder "Oben"? Und ist die Lage 1 die obere oder die erste innen?? Folglich muss der CAD-Mann beim Hersteller selber interpretieren, welche Datei im Layerstack wohin gehört, genau wie bei Gerber auch, das ist die Hauptarbeit den ganzen Tag über. Dazu ist ODB++ eine traditioneller Unix-Albtraum, für jedes Objekt wird eine eigene Datei in einem bestimmten Verzeichnis angelegt, so dass ein Layout mit ODB++ leicht aus tausend kleinen Dateien besteht, selbstverständlich ohne Dateiendung, von denen auch unzählige den gleichen Dateinamen haben, reisst das mal auseinander, sind alle Daten verloren. Aber du kannst dich ja mal im Netz über ODB++ einlesen. Georg
Stefan Salewski schrieb: > Ist extended Gerber eigentlich immer noch "State of the Art"? An sich schon, es gibt aber eine neuere Spec von Ucamco, die sich Gerber X2 nennt.
Sehe ich das richtig das ich zum Testen erst ein mal das Zeug compillieren muss?
So schaut es wohl aus. Das dürfte wohl die beste Abschreckung sein.
@Stefan Salewski Kannst du den Toporouter Algorithmus beschreiben, so dass man ihn in C nachbauen kann?
Hallo Stefan. Stefan Salewski schrieb: > Ergänzung: Vielleicht möchte man ja auf der Platine chinesische oder > kyrillische Schrift haben. Deshalb denke ich, dass man tatsächlich die > Wandlung von einer echten hochwertigen Unicode-Schrift am Bildschirm zu > Linien/Bögen auf Gerber machen sollte. Vielleicht kennt ja jemand eine > Bibliothek die so etwas schon gut macht? Schau mal nach dem Cenon Projekt. Die bearbeiten allgemein Vektor Formate und darunter auch SVG und Gerber. Die könnten passende Bibliotheken entwickelt haben. http://www.cenon.info > Ist extended Gerber eigentlich immer noch "State of the Art"? Grundsätzlich ja. Es gibt zwar mittlerweile ein "X2", aber das ist voll rückwärtskompatibel zu extended Gerber. Die einzige Ergänzung sind "Attribute" Desweiteren taucht bei vielen Gerber Elementen in der Ucamco Dokumentation der Hinweis auf, dass sie nach Möglichkeit nicht mehr verwendet werden sollen. Damit soll Gerber weiter vereinfacht werden. Trozdem bleiben sie bestehen, damit auf diesen Unterlagen basierende Gerber Software immer noch mit alten Daten umgehen kann. FAQ zu Gerber X2: https://www.ucamco.com/files/downloads/file/131/the_gerber_file_format_version_2_faq_de.pdf?ffadb605ad51e2ab5d87820700d9d26c Die z.Z. aktuelle Spezifikation von Gerber X2 Revision 2016.12 ist hier: https://www.ucamco.com/files/downloads/file/81/the_gerber_file_format_specification.pdf?cb3475a30bcf27121f13b2f307f8231b > Vor ca. 5 > Jahren war das noch so, ich glaube ich hatte dazu sogar hier mal > gefragt. Neueres weiß ich dazu aber nicht, aber ich errinnere mich > dunkel, dass es zwei "modernere" Alternativ-Formate gab. Ja, OBD++ und IPC-2581. Ersteres ist aber nicht offen, und zweiteres nur halb, was für Austauschformate ein "No-Go" ist. Desweiteren sind auf XML basierende Verfahren wie IPC-2581 schon wieder deutlich komplizierter als Gerber. Gerber schlägt halt so leicht keiner. Und wenn ich mir unbedingt eine Alternative ausdenken müsste, würde ich z.B. eher zu einer Art Lisp Notation greifen. ;O) http://www.mikrocontroller.net/articles/Gerber-Tools#Alternativen_zu_Gerber Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
Hallo C lover. C lover schrieb: > @Stefan Salewski > Kannst du den Toporouter Algorithmus beschreiben, > so dass man ihn in C nachbauen kann? Bis er soweit ist, hast Du hier was Lesefutter: https://pdfs.semanticscholar.org/1003/57a8a958587baca5b930ce9a6d439c11970d.pdf https://pdfs.semanticscholar.org/91ce/7726d0b103db47ab5db433ed75b538e6e7f8.pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.8349&rep=rep1&type=pdf Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
C lover schrieb: > @Stefan Salewski > Kannst du den Toporouter Algorithmus beschreiben, > so dass man ihn in C nachbauen kann? Besser wohl in C++, weil CGAL benutzt wird, aber mit etwas Mühe geht es sicher auch in C. Du guckst am Besten zunächst mal kurz in die zugrunde liegende Doktorarbeit, zumindest in die ersten Kapitel. Constrained-Delaunay-Triangulation und Appolonius Graph von CGAL. Und der Rest ist eben der Ruby Code, der sollte mit minimalen Ruby-Kenntnissen lesbar sein und ist eigentlich schon die vollständige Dokumentation, mehr braucht man wirklich nicht. Ich glaube es waren rund 2k lines of code Ruby, alles recht einfach. Gut bis auf das Sortieren der Bahnen von innen nach aussen, das ist so als ob man solche Aussteckformen für Kuchenteig sortiert, so dass sie ineinander passen. Da habe ich mir wirklich einen abgebrochen, mein räumliches Vorstellungsvermögen ist wohl nicht so gut. Mit C wird es natürlich etwas mehr Code, die Doktorarbeit sprach von 14k, aber die hatten wohl auch nicht CGAL als Grundlage. Übrigens, wenn ich das gleich von Anfang an in C probiert hätte, hätte ich das nie in annehmbarer Zeit hinbekommen. Aber jetzt die Übertragung von Ruby nach C sollte schon möglich sein. Die Frage wäre ob man es gleich komplett portiert, oder in Teilen. Weiss ich nicht. Nach Nim würde ich es komplett Portieren, ich kenne mich mit Ruby und Nim etwas aus, da ist das keine große Sache. Blos ich müsste die Bindings für Nim zu CGAL machen, auch keine große Sache, aber ich habe keine Lust momentan. Das sparst Du Dir mit C oder C++. Noch eine Warnung: Der Toporouter verträgt sich ganz schlecht mit bereits manuell gerouteten Bahnen. Das war der Haupt-Kritikpunkt der gEDA-Leute. Deshabl macht es auch nicht viel Sinn den Router als externes Programm einzusetzten, man müsste ihn schon in ein PCB-Programm einbinden, so dass man dann interaktiv Bauteile verschieben kann, so dass der Router alles fertig bekommt. Ein paar weitere Gedanken mag man auf der gEDA Mailingliste im Archiv finden, ich habe viele Details schon wieder etwas vergessen und errinnere mich gerade so Stück für Stück wieder...
Hallo Georg. Georg schrieb: > Es ist allerdings fragwürdig, die überwiegende Mehrheit der CAD-Benutzer > von vornherein vom Testen auszuschliessen. Aber für Linux-Fanatiker ist > das natürlich konsequent. Der Grund, dafür Linux zu nehmen ist wohl eher der, dass sich dort leichter etwas entwickeln lässt. Und in dem Stadium können das eigentlich auch nur Leute testen, die weit genug wären, selber daran zu programmieren. > > Der grundlegende Irrtum ist wohl, dass man eine abgeschottete > Linux-Brüderschaft als "Kunden" sieht, und nicht Leute, die > Leiterplatten entwerfen. Muss aber jeder Entwickler selber wissen. Nur > nicht später wundern, wenn keiner das Programm benutzt. Wer open source macht, hat in dem Sinne keine "Kunden". Und bei open source Nutzern sind viele mit Linux Kenntnissen. ;O) Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der damit umgehen muss. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Lesefutter Die erste Arbeit kannte ich gar nicht. Aber das entscheidende Werk ist die Arbeit von Tal Dayan von 1997. Übrigens, ich habe nicht wirklich alles verstanden, insbesondere nicht wie das Ripup and Retry funktionieren könnte. Übrigens, einen alternativen Toporouter gab es ja in gEDA/PCB, war als Google Summer als Code Project um 2008 gemacht, gleich in C. Hat Ansatzweise funktioniert, hat aber niemand verstanden, und der Autor war dann schnell wieder weg. Der Code ist wohl noch in gEDA/PCB, soll aber entfernt werden, da damit niemend zurecht kommt.
Der entscheidende Teil damit ein neues Layoutprogramm überhaupt angenommen wird ist garantiert nicht der Autorouter egal ob das Ding Topo, Gridless, "Freestyle" oder sonstwas heißt bzw. kann. Mir scheint, dass die Programmierer lieber so einen Autorouter schreiben da man da viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den Wünschen der Anwender auseinandersetzen muss. Viel wichtiger sind die folgenden Punkte die leicht erlernbar und bedienbar sein müssen. Schaltplansymbole erstellen; Bibliotheken Schaltplaneingabe Bauteile für das Layout aufsetzen (pads, drills, ...); Bibliotheken Bauteile platzieren Verdrahten: Leitungen ziehen, schieben abknicken, 45°; Flächen zeichnen, Flächen füllen; online DRC,.... Gerber Ausgabe
Bernd W. schrieb: > Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der > Entscheider betrachtet wird, der das Zeug kauft Aber das ist doch auch genau richtig - ich habe es schon erlebt, dass die Entwickler sich vollkommen eindeutig nach sorgfältiger Evaluation für eine bestimmte Software entschieden haben, aber eine ganz andere gekauft wurde, weil die Geschäftsführer mit den Managern des Herstellers zusammen Golf spielten. Das war in dem speziellen Fall nicht nur sowieso eine Katastrophe, sondern die Software wurde im folgenden Jahr eingestellt und so waren einige Millionen in den Sand gesetzt. Aber egal was man davon hält, man muss sich danach richten, wie beim Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder auch völlig korrupt ist. Dem Ingenieur kann man nichts verkaufen. Georg
Helmut S. schrieb: > Mir scheint, > dass die Programmierer lieber so einen Autorouter schreiben da man da > viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den > Wünschen der Anwender auseinandersetzen muss. Ja sicher. Man macht halt das, womit man seinen Lebensunterhalt verdient, oder das, was interessant ist und was man sich noch halbwegs zutraut. Nur selten fällt beides zusammen. Manchmal macht man auch öde Dinge unentgeltlich, weil man denkt dass sie für die Allgemeinheit nützlich sind oder Leute danach fragen -- aber letzteres trifft auf den EDA-Bereich weniger zu, Eagle oder KiCad ist den meisten gut genug.
Ja, ich würde es in ein bestehendes PCB Programm einfügen, programmiert in C++, 82% ist aber C mit gplv2 Lizenz, nur v2, keine v2+ .
Hallo Georg. Georg schrieb: >> Und bei ser viel kommerzieller Software sehe ich, dass als "Kunde" der >> Entscheider betrachtet wird, der das Zeug kauft, und nicht der, der >> damit umgehen muss. ;O) > Aber das ist doch auch genau richtig - ~~~~ ~~~ ~~ ~ > Aber egal was man davon hält, man muss sich danach richten, wie beim > Kunden die Entscheidungen getroffen werden, auch wenn das absurd oder > auch völlig korrupt ist. Eben. Und open Source hat in dem Sinne halt keine "Kunden". Ser viel open Source wird aus Spass geschrieben, weil man es mal endlich so machen möchte, wie man es selber für richtig hält, oder open Source wird aus Verzweiflung und mit einem "dicken Hals" geschrieben, weil man sich über den gekauften Kram geärgert hat oder man einfach nichts passendes findet. Letzteres kann durchaus der Fall sein, wenn die Anwendung so speziell ist, das kein Markt existiert. Das kommt öfter vor als man denkt. Letztendlich ist man damit selber sein eigener "Kunde" und Entscheider. ;O) Und aus allen den Gründen ist die Funktionalität von kommerzieller Software nur sehr bedingt ein Masstab für open Source, auch wenn vieles halt ähnlich ist. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Helmut S. schrieb: > Mir scheint, > dass die Programmierer lieber so einen Autorouter schreiben da man da > viel weniger Schnittstellen zur Außenwelt hat und sich nicht mit den > Wünschen der Anwender auseinandersetzen muss. Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads bedeuten? Hier geht's um "horizon", und dafür ist dein Kommentar wohl völlig daneben. Das kümmert sich just um die Dinge, die du da genannt hast, zumindest bereits zu einem großen Teil (und nennt sich ja selbst nur „halbfertig“). Der Topo-Router würde mich als externe Engine für ein KiCad wohl schon interessieren, da könnte einem auch die Programmiersprache egal sein – aber das gehört dann nicht mehr in diesen Thread. BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf meinem FreeBSD zu compilieren. Allerdings kommen da nicht nur Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers. Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen, ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder im Code von "horizon". Lukas, wenn es dich interessiert, kann ich das Buildlog mal hochladen. Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe:
1 | ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
2 | {"path", path + "/" + std::to_string(i)},
|
> Was soll diese Bemerkung denn eigentlich im Kontext dieses Threads
bedeuten? Hier geht's um "horizon", und dafür ist dein Kommentar
wohl völlig daneben.
Der Thread gleitet hier im Moment in Richtung Autorouter. Hier geht es
aber nicht um einen Autorouter sonder um Horizon, ein neues
Layout-Programm. Da ist der Autorouter nur ein kleiner Teil davon und
der wird erst interessant, wenn alles andere fertig ist und Anhänger
gefunden hat. Macht doch einen Extra-Thread auf mit dem Thema ich
schreibe einen Autorouter.
Jörg W. schrieb: > BTT: habe mir mal einen GCC 5.x installiert und versucht, das Teil auf > meinem FreeBSD zu compilieren. Allerdings kommen da nicht nur > Warnungen, sondern an vielen Stellen noch Fehlermeldungen des Compilers. > Meine C++-Kenntnisse sind vermutlich nicht gut genug um einzuschätzen, > ob dabei das eigentliche Problem in meiner Umgebung zu suchen ist oder > im Code von "horizon". > > Ein Beispiel, welches ich jetzt schon mehrmals gesehen habe: > >
1 | > ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
2 | > {"path", path + "/" + std::to_string(i)},
|
3 | > |
Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum std: http://de.cppreference.com/w/cpp/string/basic_string/to_string Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem Fehler aus?
Ohne jetzt die einzelnen Leute zu zitieren: Als Font nehme ich die Hershey-Fonts: http://paulbourke.net/dataformats/hershey/ Da sind durchaus auch nicht-ASCII Zeichen drin, nur sind die älter als Unicode, d.h. man muss die Zuordnung von Codepoint zu index manuell machen: https://github.com/carrotIndustries/horizon/blob/master/canvas/text.cpp#L242 Truetype-Fonts mache ich aus von Jörg angesprochenen Gründen nicht. Autorouter sind gleichauf mit Simulation "out of scope" für mich, stehen also auf keinerlei (imaginären) Roadmap. Bevor man an sowas überhaupt denkt, braucht man wichtigere Dinge wie, ERC, DRC oder mehr GUI. Bauen auf Freebsd: Man hat mir gesagt, dass das mit der libc++ von FreeBSD zusammenhängt. Probier mal http://stackoverflow.com/questions/35869206/freebsd-error-to-string-is-not-a-member-of-std Wenn's das repariert, bau ich das so in die Makefile ein.
Lukas K. schrieb: > Als Font nehme ich die Hershey-Fonts: Das ist ein interessanter Kompromiss! Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte erscheinen wird, benutzt Du einen echten Font? DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen effizient macht, insbesondere wenn die Bogensegmente auch noch unter einem beliebigen Winkel gedreht sind.
Stefan Salewski schrieb: > Lukas K. schrieb: >> Als Font nehme ich die Hershey-Fonts: > > Das ist ein interessanter Kompromiss! > > Ich vermute mal, für den übrigen Text, der nicht auf der Leiterplatte > erscheinen wird, benutzt Du einen echten Font? Nein. Truetype=Fonts machen unter Umständen Probleme bei der Skalierung und sind schwerer zu rendern. Und so unansehnlich sind die Hershey-Fonts nun auch nicht. > DRC hast Du also noch nicht? Für Liniensegmente ist das ja wohl noch > einfach, aber ich wüsste so spontan nicht, wie man das für Kreisbögen > effizient macht, insbesondere wenn die Bogensegmente auch noch unter > einem beliebigen Winkel gedreht sind. Bögen hab' ich derzeit nicht. Für Polygon-Operationen (online-drc) verwende ich http://www.angusj.com/delphi/clipper.php. Eigentlich ist DRC ganz einfach: Alles Kupfer auf einem Layer einsammeln, nach Netzen gruppieren, das zu testende Netz um die Clearance expandieren und mit den übrigen Netzen schneiden. Der ganze algorithmisch schwere teil ist schon in clipper gelöst.
Sheeva P. schrieb: > Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum > std: > > http://de.cppreference.com/w/cpp/string/basic_string/to_string > > Da das Makefile allerdings "-std=c++14" vorgibt, ist der Fehler > zumindest etwas merkwürdig. Wie sieht denn der Compileraufruf vor dem > Fehler aus?
1 | g++5 -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic -Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections -ffunction-sections -I/usr/local/include -I/usr/local/include/uuid -I/usr/local/include/gtkmm-3.0 -I/usr/local/lib/gtkmm-3.0/include -I/usr/local/include/atkmm-1.6 -I/usr/local/include/atk-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/giomm-2.4 -I/usr/local/lib/giomm-2.4/include -I/usr/local/include/pangomm-1.4 -I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/cairomm-1.0 -I/usr/local/lib/cairomm-1.0/include -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/pango-1.0 -I/usr/local/include/harfbuzz -I/usr/local/include/gtk-3.0 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -I/usr/local/include/gtk-3.0/unix-print -I/usr/local/include/gdkmm-3.0 -I/usr/local/lib/gdkmm-3.0/include -I/usr/local/include/librsvg-2.0 -pthread -D_THREAD_SAFE -MP -MMD -pthread -Wall -Wshadow -std=c++14 pool/unit.cpp -o pool/unit.o |
2 | In file included from pool/unit.cpp:3:0: |
3 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)': |
4 | ./json.hpp:3163:58: error: 'to_string' is not a member of 'std' |
5 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
6 | ^ |
7 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::at(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type) const': |
8 | ./json.hpp:3206:58: error: 'to_string' is not a member of 'std' |
9 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
10 | ^ |
11 | ./json.hpp: In member function 'void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::erase(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::size_type)': |
12 | ./json.hpp:4176:58: error: 'to_string' is not a member of 'std' |
13 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
14 | ^ |
15 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::string_t nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::iteration_proxy<IteratorType>::iteration_proxy_internal::key() const': |
16 | ./json.hpp:6649:32: error: 'to_string' is not a member of 'std' |
17 | return std::to_string(array_index); |
18 | ^ |
19 | ./json.hpp: In member function 'long double nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(long double*, char**) const': |
20 | ./json.hpp:8820:20: error: 'strtold' is not a member of 'std' |
21 | return std::strtold(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr); |
22 | ^ |
23 | ./json.hpp:8820:20: note: suggested alternative: |
24 | In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0, |
25 | from /usr/local/include/boost/assert.hpp:83, |
26 | from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29, |
27 | from /usr/local/include/boost/shared_ptr.hpp:17, |
28 | from /usr/local/include/yaml-cpp/node/ptr.h:11, |
29 | from /usr/local/include/yaml-cpp/node/node.h:17, |
30 | from /usr/local/include/yaml-cpp/yaml.h:16, |
31 | from pool/unit.hpp:5, |
32 | from pool/unit.cpp:1: |
33 | /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:127:3: note: 'strtold' |
34 | strtold(const char * __restrict, char ** __restrict); |
35 | ^ |
36 | In file included from pool/unit.cpp:3:0: |
37 | ./json.hpp: In member function 'float nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::lexer::str_to_float_t(float*, char**) const': |
38 | ./json.hpp:8860:20: error: 'strtof' is not a member of 'std' |
39 | return std::strtof(reinterpret_cast<typename string_t::const_pointer>(m_start), endptr); |
40 | ^ |
41 | ./json.hpp:8860:20: note: suggested alternative: |
42 | In file included from /usr/local/lib/gcc5/include/c++/cstdlib:72:0, |
43 | from /usr/local/include/boost/assert.hpp:83, |
44 | from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:29, |
45 | from /usr/local/include/boost/shared_ptr.hpp:17, |
46 | from /usr/local/include/yaml-cpp/node/ptr.h:11, |
47 | from /usr/local/include/yaml-cpp/node/node.h:17, |
48 | from /usr/local/include/yaml-cpp/yaml.h:16, |
49 | from pool/unit.hpp:5, |
50 | from pool/unit.cpp:1: |
51 | /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd10.0/5.3.0/include-fixed/stdlib.h:124:8: note: 'strtof' |
52 | float strtof(const char * __restrict, char ** __restrict); |
53 | ^ |
54 | In file included from pool/unit.cpp:3:0: |
55 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_and_create(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::reference) const': |
56 | ./json.hpp:9419:77: error: 'stoi' is not a member of 'std' |
57 | result = &result->operator[](static_cast<size_type>(std::stoi(reference_token))); |
58 | ^ |
59 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const': |
60 | ./json.hpp:9511:75: error: 'stoi' is not a member of 'std' |
61 | ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token))); |
62 | ^ |
63 | ./json.hpp: In member function 'nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::pointer) const': |
64 | ./json.hpp:9545:53: error: 'to_string' is not a member of 'std' |
65 | std::to_string(ptr->m_value.array->size()) + |
66 | ^ |
67 | ./json.hpp:9556:63: error: 'stoi' is not a member of 'std' |
68 | ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token))); |
69 | ^ |
70 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_unchecked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const': |
71 | ./json.hpp:9597:53: error: 'to_string' is not a member of 'std' |
72 | std::to_string(ptr->m_value.array->size()) + |
73 | ^ |
74 | ./json.hpp:9608:71: error: 'stoi' is not a member of 'std' |
75 | ptr = &ptr->operator[](static_cast<size_type>(std::stoi(reference_token))); |
76 | ^ |
77 | ./json.hpp: In member function 'const value_type& nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::get_checked(nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::const_pointer) const': |
78 | ./json.hpp:9641:53: error: 'to_string' is not a member of 'std' |
79 | std::to_string(ptr->m_value.array->size()) + |
80 | ^ |
81 | ./json.hpp:9652:63: error: 'stoi' is not a member of 'std' |
82 | ptr = &ptr->at(static_cast<size_type>(std::stoi(reference_token))); |
83 | ^ |
84 | ./json.hpp: In static member function 'static void nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::json_pointer::flatten(const string&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&)': |
85 | ./json.hpp:9799:62: error: 'to_string' is not a member of 'std' |
86 | flatten(reference_string + "/" + std::to_string(i), |
87 | ^ |
88 | ./json.hpp: In lambda function: |
89 | ./json.hpp:10178:46: error: 'stoi' is not a member of 'std' |
90 | const auto idx = std::stoi(last_path); |
91 | ^ |
92 | ./json.hpp:10182:74: error: 'to_string' is not a member of 'std' |
93 | throw std::out_of_range("array index " + std::to_string(idx) + " is out of range");
|
94 | ^ |
95 | ./json.hpp: In lambda function: |
96 | ./json.hpp:10226:53: error: 'stoi' is not a member of 'std' |
97 | parent.erase(static_cast<size_type>(std::stoi(last_path))); |
98 | ^ |
99 | ./json.hpp: In static member function 'static nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType> nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>::diff(const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const nlohmann::basic_json<ObjectType, ArrayType, StringType, BooleanType, NumberIntegerType, NumberUnsignedType, NumberFloatType, AllocatorType>&, const string&)': |
100 | ./json.hpp:10427:82: error: 'to_string' is not a member of 'std' |
101 | auto temp_diff = diff(source[i], target[i], path + "/" + std::to_string(i)); |
102 | ^ |
103 | ./json.hpp:10444:51: error: 'to_string' is not a member of 'std' |
104 | {"path", path + "/" + std::to_string(i)}
|
105 | ^ |
106 | ./json.hpp:10455:51: error: 'to_string' is not a member of 'std' |
107 | {"path", path + "/" + std::to_string(i)},
|
108 | ^ |
Das wäre der erste Fehler, bei dem "make" anhält. Bei "make -k" rennt er zwar insgesamt weiter, stolpert aber immer wieder über sowas.
Eigentlich gehört das Thema in die Programmiererecke verschoben. So richtig sehe ich hier nichts mehr von "Platinen".....
Hardy F. schrieb: > Eigentlich gehört das Thema in die Programmiererecke verschoben. Man könnte es auch nach "Projekte & Code" schieben. Gibt es Meinungen, wo es sinnvoller wäre?
Jörg W. schrieb: > Man könnte es auch nach "Projekte & Code" schieben. Das wollte ich auch schon anmerken. Nachdem ich diesen Thread zum ersten mal gesehen hatte, hatte ich ein paar Tage später Probleme ihn zu finden, ich hatte mir schon gedacht, Lukas hätte ihn ob blöder Kommentare wieder gelöscht! Übrigens, den Thread mit dem Java Schaltplaneditor kann ich auch nicht wieder finden, muss gut ein jahr her sein. An den Namen des Tools kann ich mich nicht errinnern. Eigentlich müsste man solche Projekte im Wiki sammeln!
Stefan Salewski schrieb: > Eigentlich müsste man solche Projekte im Wiki sammeln! Es gibt doch einen Artikel Schaltplaneditoren. Da spräche doch nichts dagegen, am Ende eine Liste mit Links auf entsprechende Threads einzufügen. Edit: Habe mit einem Link auf diesen Thread begonnen. Wer noch weitere Threads kennt, möge sie einfach einfügen.
Sheeva P. schrieb: > Eigentlich gehört die Funktion to_string() seit C++11 zum Namensraum > std: OK, nachdem ich das hier ergugelt habe: http://www.bsdforen.de/threads/problem-gcc-and-std-to_string.31386/ sieht es mir mittlerweile einfach so aus, als wäre GCC völlig glibc-zentrisch geworden. Die vielen _GLIBCXX_VISIBILITY() in den vom GCC installierten Headern weisen auch alle in diese Richtung. Daher habe ich mir clang 3.8 installiert und benutzt. Nun kommen wenigstens keine Trivialitäten mehr als Fehler raus. Anbei das Buildlog eines "gmake -k". Es sind eine ganze Reihe davon dabei:
1 | In file included from util/uuid.hpp:8: |
2 | In file included from /usr/include/c++/v1/iostream:38: |
3 | In file included from /usr/include/c++/v1/ios:216: |
4 | In file included from /usr/include/c++/v1/__locale:15: |
5 | In file included from /usr/include/c++/v1/string:439: |
6 | In file included from /usr/include/c++/v1/algorithm:626: |
7 | /usr/include/c++/v1/utility:294:15: error: no viable overloaded '=' |
8 | first = __p.first; |
9 | ~~~~~ ^ ~~~~~~~~~ |
Da sind Verweise auf die FreeBSD-Headers drin, möglicherweise sind diese zu alt? Vielleicht ließe sich aber auch ein Workaround finden? Es gibt aber auch eine Reihe anderer Dinge, die mir schon Probleme in horizon zu sein scheinen. Vielleicht will Lukas ja mal einen Blick reinwerfen. Kann mir vorstellen, dass ein clang unter Linux die genauso anmeckern würde.
Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten Felder const sind. Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm aber nur in 3.16...
Ich habe das Java-Tool dann doch noch mit google gefunden: Beitrag "HobbyCi Schaltplan Entwicklungsprogramm" Ist doch schon zwei Jahre her, und war wohl, wie ich bereits vermutet hatte, eher ein Osterferienprojekt. Aber wer mag kann es ja auch im Wiki eintragen.
Lukas K. schrieb: > Diese Fehler kommen Wohl daher, dass einige der in der map gespeicherten > Felder const sind. Siehst du da eine Abhilfe? > Unabhängig davon braucht horizon mindestens Gtkmm 3.18. Aus > unerfindlichen Gründen ist Gtk 3.18 zwar in den Freebsd-ports, Gtkmm > aber nur in 3.16... Der Port wird vom gnome-Team bei FreeBSD gepflegt. Ich kann mir vorstellen, dass man da mit Upgrades vorsichtig ist, um nicht das gesamte Gnome komplett nachziehen zu müssen. Da ich Gnome nicht als Desktop-Umgebung benutze, riskiere ich nicht sehr viel, wenn ich mal einen Upgrade von gtkmm versuche. Edit: naja, man hätte es sich denken können:
1 | Package dependency requirement 'giomm-2.4 >= 2.46.1' could not be satisfied. |
2 | Package 'giomm-2.4' has version '2.44.0', required version is '>= 2.46.1' |
3 | Package dependency requirement 'pangomm-1.4 >= 2.38.1' could not be satisfied. |
4 | Package 'pangomm-1.4' has version '2.36.0', required version is '>= 2.38.1' |
5 | Package dependency requirement 'cairomm-1.0 >= 1.12.0' could not be satisfied. |
6 | Package 'cairomm-1.0' has version '1.10.0', required version is '>= 1.12.0' |
Das zöge dann eine größere Update-Orgie nach sich, da habe ich gerade nicht die Zeit dafür. Eventuell kann ich das mal in einem Jail probieren (lightweight VM).
Jörg W. schrieb: > Siehst du da eine Abhilfe? Die Felder nicht-const machen. Tut der Anwendung als solcher keinen Abbruch, ist aber unschön.
Michael B. schrieb: > AutoTrax macht beispielsweise eigentlich alles richtig, schönes > Programm, alles möglich dabei, nicht zu teuer. Und bekommt trotzdem seit > 10 Jahren keinen Fuss an den Boden. > > https://dexpcb.com/ Hmm. Download kostenlos ... alles außer Gerber Export ... Kompatibel mit Windows (Liste von Windows-Versionen) Das ist die komischste Variante von "macht beispielsweise eigentlich alles richtig" die ich seit langem gesehen habe. Wenn ich bereit wäre, für EDA auf Windows zurück zu gehen, dann hätte ich aber ganz andere Auswahl. Will ich aber gar nicht. Genauso wenig, wie ich die Postkutsche als Alternative zum ICE in Betracht ziehe ... Ach so, zurück zum Thema ... OpenGL zwingend für ein EDA? GTK und & Freunde in einer "blutige Kante" Version? Nein, danke. Wirklich. Ich brauche meine Kiste hier zum arbeiten. Sind die bleeding edge features von GTK & Co wirklich notwendig? Kann ich mir irgendwie nicht so recht vorstellen. Und andererseits ist mein Leidensdruck gar nicht mal besonders hoch. pcb funktioniert prima für meine Bedürfnisse. Versteh mich recht: ich bin Neuem gegenüber eigentlich recht aufgeschlossen. Aber das Problem ist nicht so sehr ein Mangel an EDA-Systemen, als vielmehr die Unzahl an (selbstredend zueinander inkompatiblen) Nischenlösungen. Ein weiteres Produkt in einer weiteren Nische erscheint mir daher wenig verlockend.
Axel S. schrieb: > OpenGL zwingend für ein EDA? Ist bei KiCad am Ende auch so. Naja, man kann dort auch den Cairo-Renderer noch nehmen, aber der ist langsamer. Ich stecke da nicht drin, aber OpenGL scheint außer 3D eben auch im 2D-Bereich einige Nettigkeiten gegenüber Standard-X11 zu bieten zu haben (shading und dergleichen). > GTK und & Freunde in einer "blutige Kante" > Version? Vielleicht könnte Lukas ja hier ein bisschen erzählen, was seine Motivation ist. Aber: das ist ja im Moment (bezüglich der Anwender) noch reiner Entwicklungs-Vorlauf. Dahingehend finde ich es nicht grundsätzlich daneben, mit vergleichsweise „moderner Technik“ ins Rennen zu gehen, denn man kann getrost davon ausgehen, dass das in zwei, drei Jahren dann bei den potenziellen Anwendern in der Tat Standard sein wird. CAD/EDA macht man ja nun seit jeher nicht gerade auf der letzten Kiste, die gerade noch irgendwo in der Ecke zu finden ist.
Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich will nicht anfangen zu compilieren, nur um es zu testen!
Alex W. schrieb: > Gibt es auch eine downloadbare ausführbare Datei für Win und Linux? Ich > will nicht anfangen zu compilieren, nur um es zu testen! Geduld, mein lieber. Ich bin gerade am Projekt-Manager, wenn der halbwegs fertig ist, gibt es auch eine Executable auf die man doppelklicken kann und was sinnvolles geschieht. Für Windows sollt's dann sogar für 'ne mit NSIS zusammengeklickte setup.exe reichen. Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh immer gegen die falschen Bibliotheken linken. Git pull und make sollten nun für den durchschnittlichen Linux-user auch keine schwarze Magie sein... Betreffend OpenGL und Gtk: Kicad verwendet im Gegensatz zu horizon die veraltete OpenGL API mit glBegin/glEnd. Funktioniert zwar überall, wird dies auch auf absehbare Zeit tun, aber ist eben obsolet und wird auch von Gtk nicht unterstützt. OpenGL in Version 3 haben wir nun auch schon seit über 5 Jahren, wird Zeit, dass das auch eingesetzt wird. Bleeding edge wär's wenn ich Vulkan verlangen würde... Warum nicht auf der CPU mit cairo oder so malen? In jedem Computer steckt eine Grafikkarte die genau für so Dinge wie Polygone malen, etc da ist. Wär' ja schade, wenn die sich langweilt. Gtk 3.18 gibt's auch schon seit über einem Jahr, auch nicht mehr bleeding edge. Wie auch schon von Jörg angesprochen, horizon ist ein Projekt für die Zukunft, insofern ist es nur richtig mit nicht-obsoleter Technik anzufangen. Warum Gtk und nicht Qt? (alles andere muss nicht wirklich sein) Mir gefällt die Art, wie die Entwickler von Gtk (und Gnome) über UI-Schemata von Windows 95 hinausdenken und dabei einen gelungene Kombination aus Konzepten aus dem Mobile- und Desktop-Umfeld finden. Mag nicht jedermanns Geschmack sein, ich mag's.
Mag sein. Das stört Lukas aber nicht, und es ist sein Projekt. Wer bleeding edge haben will (und das ist sein Projekt), sollte sich daran nicht stören. Es verbietet übrigens m.W. niemand, .deb- oder .rpm-Packages zu bauen und zur Verfügung zu stellen. Nein, ich tue es nicht, keine Zeit.
Lukas K. schrieb: > Git pull und make sollten > nun für den durchschnittlichen Linux-user auch keine schwarze Magie > sein... Als Softwareentwickler sollte ich dem eigentlich nur zustimmen können. Aber es ist eben nicht nur "git pull" und dann einfach "make" in das Terminal kloppen. Man muss schon wissen was man tut wenn es Probleme gibt. Meine Frau würde ich als "durschnittlichen" Linux-user bezeichnen. Sie hat Linux gute 10 Jahre als Anwender benutzt (sie hat es sogar selbstständig ohne mein Wissen installiert). Ein Tutorial für einen trivialen Build-Prozess hätte sie auch ohne Probleme durchgearbeitet bekommen. Aber sobald da Abhängigkeiten dazu kommen, die man installieren muss, und wissen muss, dass Gtk1 != Gtk2 != Gtk3 != Qt begibt man sich als "durchschnittlicher" doch schnell aufs Glatteis. Und wenn dann noch ein Compiler-Fehler dazu kommt, und man mangels Verständnis rätselraten muss woher das Problem wohl kommen mag, dann ist auch dem letzten 0815-Anwender die Laune vergangen. Unter Anleitung ist das alles kein Problem, aber wenn man sonst niemanden hat den man direkt fragen kann und der die Zeit hat sich mit einem hinzusetzen, ist das alles nix. Als fortgeschrittener Softwareentwickler überschätzt man meist auch seine Kollegen. Ich seh doch schon wie meine Kollegen auf Arbeit von weitergehenden Funktionalitäten von SVN (Also bspw. mal das Tortoise-Diff-Tool aufrufen, oder ein Tag setzen, oder ein Update auf eine spezifische Revision machen) überfordert sind. Das betrifft nicht nur meine 50+ Kollegen, sondern auch den einen frischen Uni-Abgänger. Das ist breit gestreut, viele unserer FH/Uni-Praktikanten sind extrem fähig. Die kennen sich zum Teil auch bestens mit Github aus und können sich fix in neues einarbeiten. Ist aber alles meiner Erfahrung nach sehr individuell und breit gestreut.
Lukas K. schrieb: > Binaries für Linux gibt's von mir nicht, da solche unüblich sind und eh > immer gegen die falschen Bibliotheken linken. Git pull und make sollten > nun für den durchschnittlichen Linux-user auch keine schwarze Magie > sein... Völlig korrekt. Bin ganz deiner Meinung. Ich finde es bei Linux grade so gut dass es da nicht überall Binaries gibt sondern man immer selber bauen kann.
Zwei Hinweise: a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der Fall. Ich würde aber ruhig noch -Werror dazusetzen. b) check den Source mal mit CppCheck. Da kommen Tonnen von Warnungen. Idealerweise sollte da gar nichts kommen, und bei den Dingen, die wirklich so gehören, sollte in der Projektdokumentation (später!) begründet werden, wieso diese Warnungen trotzdem OK sind. c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren. Das wird noch viel Arbeit mit Build, Troubleshooting und Wartung werden, wenn es mehr als "auf meinem Rechner läuft's ja" werden soll. Da sollte man sich frühzeitig Gedanken um die Versionsverwaltung der Gesamtkette machen. d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's best to start with the library structure:", ist das ein Warnzeichen. Klar, die Erklärung, wie das Programm intern arbeitet, geht logischerweise über Interna. Aber man muß da aufpassen, darüber nicht den Nutzer aus den Augen zu verlieren - und statt eines Designs für einen Workflow dann haufenweise Interna zu exportieren und dem Benutzer um die Ohren zu hauen. Das passiert schnell mal, wenn kein UI-Design stattfindet bzw. dies als nachrangig betrachtet wird, bis es zu spät ist.
Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt zu sein, keine extremen Monsterfunktionen - Kompliment. Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp, schematic.cpp und polypartition.cpp im Auge behalten. Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig Kommentare drin. Man kann das auch als undokumentierten Code ansehen. Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht hatte. Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut, und wie der Bug aussieht. Mit "was er hätte tun sollen" meine ich natürlich keine Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU.
Nop schrieb: > Solange Du das Projekt eh alleine machen willst, mag es noch halbwegs > angehen, obwohl ich persönlich bei so undokumentiertem Code ja schon > nach 6 Monaten Probleme hätte zu erinnern, was ich mir dabei gedacht > hatte. Ich bin also nicht allein ;-) > Das kann die spätere Fehlersuche schwierig machen, weil Du dann aus dem > Code entnehmen mußt, was er hätte tun sollen, was er stattdessen tut, > und wie der Bug aussieht. > > Mit "was er hätte tun sollen" meine ich natürlich keine > Redundanzkommentare wie "i++; // increment i by 1", sondern welche, die > den Sinn dahinter erläutern, denn der ist nicht im Quelltext. Quelltext > sagt, WAS denn WIE implementiert ist, aber nicht WARUM und WOZU. Ja. Es muss noch nicht einmal jede Funktion extra kommentiert werden. Es ist wichtiger, bspw. zu jedem Modul wirklich einen richtigen ausführlichen Text zu schreiben, in dem erklärt wird, was das Modul überhaupt macht und wie dessen einzelne Funktionen zusammenspielen. Dann kann man sich viel besser in die Denkweise dessen hineinversetzen, der das Modul geschrieben hat. Nach sechs Monaten (und noch mehr nach ein paar Jahren) sind diese Texte mehr als Gold wert :-}
Nop schrieb: > Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code.
Ein weiterer Tip: Nicht das Projekt über-organisieren. Im frühen Stadium ist es glaub ich wichtiger, dass es gut genug funktioniert um bei anderen Entwicklern erstmal Interesse auszulösen. Bekomm die Grundfunktionalität so früh wie möglich stabil. Bau ein paar automatisierte Tests, damit du noch effektiv refaktorieren kannst ohne zuviel kaputt zu machen. Genug Tests dass du dich sicher fühlst, und nicht soviele dass sie dich nerven wenn du eine API mal änderst. Das ist so meine Pi*Daumen-Regel dabei. Hier sind viele gute Tipps, auch Code-Doku die von "Nop" erwähnt wird ist nicht allzu unwichtig. Aber übertreibs nicht, wenn jemand wirklich einen nenneswerten Beitrag liefern will, dann lässt er sich auch nicht von fehlenden Kommentaren aufhalten. Wichtig ist da eher, dass du zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein nicht zugespammtes E-Mail-Verzeichnis.
Robin R. schrieb: > Nop schrieb: >> Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, > > Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code. Den Spruch werd ich ausdrucken und in Großformat an den Eingang zu unserem Entwickler-Keller hängen.
Robin R. schrieb: > Ja, Code von dritten immer refaktorieren! Stabiler Code ist toter Code. Muß man abwägen. Wenn der Code von jenen Dritten noch aktiv weiterentwickelt wird, hat Refactoring keinen Sinn, weil es das Updaten unnötig schwierig macht. Andererseits habe ich auch schon Code übernommen - zigtausend Zeilen mit diversen Funktionalitäten in einer einzigen Datei. Wenn ich die Funktion "alle Vorkommnisse in der aktiven Datei suchen" regelmäßig brauche, um die Definition einer Funktion überhaupt noch zu finden, dann weiß ich, daß ein Refactoring überfällig ist. > wenn jemand wirklich einen nenneswerten Beitrag liefern will, >dann lässt er sich auch nicht von fehlenden Kommentaren aufhalten Doch, denn sinnvolle Kommentare setzen hätte den Entwickler wenig Zeit gekostet - das so herauszufinden würde mich als Nachfolger die fünffache Zeit kosten. Wer so mit meiner Zeit umgeht, bekommt davon einfach keine. Chris D. schrieb: > Ich bin also nicht allein ;-) So ziemlich jeder, der schonmal seinen eigenen Senf drei Jahre danach nochmal anfassen mußte, hat sich entweder über gute Kommentierung gefreut, oder in dem Moment verstanden, wieso sie gut gewesen wäre. :-)
Mal für Dumme Windows User wie mich, gibt es auch einen fertigen Installer? VG, Peter
Peter schrieb: > Mal für Dumme Windows User wie mich, gibt es auch einen fertigen > Installer? Nein, wurde doch schon geschrieben. Einfach mal den ganzen Thread lesen … Das ist im Moment eher Entwickler-Baustelle, also was für Leute, die wirklich in irgendeiner Weise mitmachen wollen. „Mitmachen“ heißt dabei nicht notwendigerweise, eigenen Code beizutragen, aber wenn man als Tester mitmachen will, muss man in so einer frühen Phase damit rechnen, in kürzeren Abständen (immer, wenn sich wesentlich was getan hat) neu zu bauen, ansonsten testet man Dinge, die so schon gar nicht mehr aktuell sind. Alternative: die Tests in einer VM machen, allerdings muss die VM dann die gewünschte OpenGL-Funktionalität unterstützen.
Das habe ich dann wohl überlesen, dabei hatte ich mich recht gut von oben bis unten durch gekämpft. Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt weiter folgen sollte. Vg, Peter
Peter schrieb: > Auch ein 2 Tage alter Intaller würde mir zeigen ob ich dem Projekt > weiter folgen sollte. Das mag ich dir glauben, aber sowas zu pflegen bindet einiges an Energie beim Entwickler, die er in dieser Phase wohl lieber in die Sache selbst steckt.
Nop schrieb: > Zwei Hinweise: > > a) sollte -Wall enabled sein, das ist lobenswerterweise im Makefile der > Fall. Ich würde aber ruhig noch -Werror dazusetzen. Hm, einige Warnungen könnte ich in der Tat noch ausbügeln, war bis jetzt bloß zu faul dafür. Werror muss jetzt nicht unbedingt sein, je nach Compiler und dessen Version können schon mal Warnings dazu kommen > b) check den Source mal mit CppCheck. Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen? Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das auch so gewünscht. Horizon ist mein erstes C++-Projekt, wenn jemand Tipps zu C++14 hat, her damit. > c) das sind eine Menge an Abhängigkeiten von verschiedenen Autoren. Meinst du mit Abhänigkeiten, die die im Repository selber drin sind (json, clipper, etc) oder das ganze externe (Gtk, etc)? Viele von den externen Abhängigkeiten sind Projekte mit recht guten "Track record", denke mal, daran wird's nicht scheitern. > d) Doku: wenn ich im Readme lese: "To explain horizon's operation it's... Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen, insofern sollte man als Anwender schon wissen, was damit gemeint ist. Die Tools sind ein anderes Beispiel dafür: Alle Änderungen am Dokument (Schaltplan, Board, etc) müssen durch ein Tool (oder property editor) stattfinden: von Verschieben über löschen bis zum einfügen aus der Zwischenablage. Andere Programme mögen das intern vielleicht ähnlich lösen, bei horizon wird das so direkt an den Anwender durchgereicht. Ich bevorzuge es Dinge, die ich benutze halbwegs zu verstehen. Wenn das mentale Modell mit dem Tatsächlichen Aufbau der Anwendung übereinstimmt, umso besser. Nop schrieb: > Ach ja.. mal Sourcemonitor drüberlaufen lassen. Scheint gut aufgeteilt > zu sein, keine extremen Monsterfunktionen - Kompliment. Hätte ich anders erwartet, insb. die expand()-Methoden von Board und Schematic sind doch ein wenig ausufernd... > Besonders json.hpp könnte ein Kandidat für etwas Refactoring werden, > aber in geringerem Maße sollte man auch clipper.cpp, tool_delete.cpp, > schematic.cpp und polypartition.cpp im Auge behalten. json, clipper und polypartition sind externe Libraries, die damit angepriesen werden nur aus 1...2 Dateien zu bestehen. Solang die funktionieren ist mir's egal, ob die 10kLOC haben. Das tool_delete ist leider der Architektur geschuldet. Da der interaktive manipulator der selbe für alles von Symbol bis Board ist, sind auch die tools die selben - das Tool zum Löschen von einem Symbol ist das selbe wie zum Löschen von einem Track. Einiges aus dem Tool könnte man allerdings in's Schematic/Board/etc verschieben. > Was aber die Code-Doku angeht, es sind insgesamt gesehen arg wenig > Kommentare drin. Man kann das auch als undokumentierten Code ansehen. Das stimmt in der Tat, vielleicht wird's bald besser... Robin R. schrieb: > Wichtig ist da eher, dass du > zur Kommunikation da bist. Bspw. ein IRC-Channel oder ein > nicht zugespammtes E-Mail-Verzeichnis. Dazu sind der Thread hier und issues auf github vorgesehen.
Lukas K. schrieb: > Werror muss jetzt nicht unbedingt sein, je nach > Compiler und dessen Version können schon mal Warnings dazu kommen Stimmt, aber im Moment sind die Versionen ja ohnehin festgezogen, auch bei den Libraries. Für "später", wenn Du ins richtige Release gehst, kann's sinnvoll sein, das wieder rauszunehmen. Vorteil: Du kriegst bei den jetztigen pre-alpha-Testern keine Bugreports, die letztlich an Dingen lagen, welche der Compiler schon bemerkt hatte. > Danke für den Tip, mit welchen Optionen hast du cppcheck laufen lassen? Einfach Defaults und alles an, inklusive Stilwarnungen. Ich nehm aber auch Windows und die GUI dafür - auch wenn ich dann u.a. mit Cygwin entwickele. Stilwarnungen kann man aber auch kollektiv wegklicken, wenn sie so gar nicht zum eigenen Stil passen. > Vieles scheinen ja implizite Konstruktoren zu sein, manchmal war das > auch so gewünscht. Ich vermeide Warnungen wegen Implizitheit, damit der nachfolgende Programmierer sieht, daß ich da nichts vergessen habe, sondern das genau so gewollt habe. > Meinst du mit Abhänigkeiten, die die im Repository selber drin sind > (json, clipper, etc) oder das ganze externe (Gtk, etc)? Die im Repo sind noch unkritisch, weil Du selber derjenige bist, der da mögliche Updates zentral einpflegen und testen wird. > Viele von den > externen Abhängigkeiten sind Projekte mit recht guten "Track record", > denke mal, daran wird's nicht scheitern. Ich denke dabei gar nicht mal an Bugs, sondern an Änderungen, die bestehende Funktionalität unabsichtlich zerbrechen. Sowas wie neulich bei Cryptkeeper plus Enc_FS. Allein schon die Bugreports später werden schwer auszuwerten: Geht mit Lib X in Version Y, aber nicht mit Version Z. Dummerweise kann man auch nicht dem Anwender sagen, er soll halt nur Lib X bis maximal Version Y installieren, weil ein anderes Programm dann garantiert Version Y+1 als Mindestanforderung hat. > Vielleicht habe ich hier eine etwas verzerrte sich auf die Dinge, aber > Units, Entitites, etc. Sind Begriffe die auch in der GUI auftauchen, > insofern sollte man als Anwender schon wissen, was damit gemeint ist. Ich würde die Anleitung für den Endnutzer strikt getrennt von der Doku für andere Programmierer halten, und auch das technische Niveau sollte ein ganz anderes sein. Beim Endnutzer geht es letztlich als Grundanliegen nicht darum, das Programm selber zu verstehen, sondern darum, wie man mit dem Programm die Aufgaben löst, zu denen es da ist. Ganz andere Mentalität. Ein epic fail in der Nutzerführung ist es, wenn man das Programm dazu verstehen muß. Daß man die Materie an sich verstehen muß bei so einer Software, ist hingegen klar - wer nicht weiß, was ein Layout überhaupt ist, zählt aber auch nicht zur Zielgruppe. > Andere Programme mögen das intern vielleicht ähnlich > lösen, bei horizon wird das so direkt an den Anwender durchgereicht. Autsch. Das ist Offenlegung von Interna und Vermeidung von Designentscheidungen, was letztlich beim Anwender abgeladen wird. Ist nicht verkehrt, wenn man diese Möglichkeit eröffnet, aber dann als Fallback, den man zum Troubleshooting nehmen kann, wenn das Programm nicht geht wie gewünscht. An sich sollte das Programm aber selber das tun, was es tun muß, um die gewünschte Aufgabe zu erreichen, ohne daß man ihm das alles erst manuell sagen muß. Das macht Nutzerführung schwieriger, als es aussieht, und deswegen ist es nicht damit getan, am Ende einen GUI-Wrapper drüberzulegen. Der Schlüssel als Entwickler ist es, nicht feature-orientiert zu denken, sondern Workflow-oriientiert. > Ich bevorzuge es Dinge, die ich benutze halbwegs zu verstehen. Da geht das Programmiererdenken los, und wenn es das Grunddesign der Anwendung ist, werden Anwender damit nie glücklich. Das bleibt ein Tool von Programmierern für Programmierer. Wenn ich in Word einen Text schreibe, mache ich mir ja auch keine Gedanken über die internen Datenstrukturen von Word. > Hätte ich anders erwartet, insb. die expand()-Methoden von Board und > Schematic sind doch ein wenig ausufernd... Sourcemonitor mißt Komplexität, nicht Zeilenlänge. Viele einfache Zeilen sind gut zu verstehen, wenige komplexe auch, aber viele komplexe (lokaler Spaghetticode) nicht. > json, clipper und polypartition sind externe Libraries, die damit > angepriesen werden nur aus 1...2 Dateien zu bestehen. OK, dann ist das ein Feature. Wobei Refactoring auch nicht unbedingt heißt, die Dateien zu zerlegen, sondern auch einzelne Funktionen, die in der Komplexität nach oben gehen. Aber wenn's eh externe Dinge sind, die aktiv gepflegt werden, ergibt ein Fork keinen Sinn. > Dazu sind der Thread hier und issues auf github vorgesehen. Ich würde vor allem auf Dauer kein synchrones Kommunikationsmedium wie IRC empfehlen. Das kostet nämlich aasig Zeit. Es ist effizienter, die Fragen zu sammeln, und wenn 10 Leute mehr oder weniger dasselbe wissen wollen, das in der Online-FAQ einmal zu beantworten. Deine Zeit als Entwickler ist schließlich kostbar. Auf jeden Fall wünsche ich bei dem Projekt gutes Gelingen!
Lukas K. schrieb: > Doxygen-Dokumentation hatte ich persönlich nie als wirklich hilfreich > empfunden, da darin oft erklärt ist, was auch eine Zeile drunter im Code > steht, aber die grobe Struktur fehlt. Du siehst das Problem, aber ziehst den falschen Schluss daraus! Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen anzulasten, sondern dem, der falsch dokumentiert. Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz) nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten alles auch als pdf zum selberausdrucken.
Michael L. schrieb: > Ich benutze Doxygen fast von Anfang an, und mache damit (und graphviz) > nicht nur meine Codedokumentation, sondern erstelle nebenbei auch noch > die Onlinehilfe zum Programm als html + chm, und für Papierfetischisten > alles auch als pdf zum selberausdrucken. Ja und? Dann steht auf dem Ausgedruckten auch bloß das, was im Quelltext zwei Zeilen drunter auch bloß steht - sowas ist keine Dokumentation! Egal ob im chm oder pdf Format. Merke dir mal, daß eine Dokumentation - wenn sie gut ist - eine Menge Informationen beinhaltet, die eben NICHT aus anderen Quellen auf dem PC zusammengesammelt werden können, sondern aus dem Vermögen eines menschlichen Autors kommen, Dinge sinnvoll und erhellend erklären zu können. Ein Programm hingegen kann immer nur aus Maschinentext einen anderen Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität und der menschliche Geistes-Horizont. W.S.
W.S. schrieb: > Ein Programm hingegen kann immer nur aus Maschinentext einen anderen > Maschinentext erzeugen - es fehlt einfach die menschliche Kreativität > und der menschliche Geistes-Horizont. Die Doku ist natürlich immer nur so gut wie deren Autor. Doxygen kann deutlich mehr als nur wiederzukäuen, was zwei Zeilen darunter im Code steht … Kreative Inhalte muss jedoch natürlich immer noch der Mensch liefern, das ist bei Doxygen nicht anders als bei Word, LibreOffice, DocBook oder LaTeX.
Gute Doku zu schreiben braucht auch Erfahrung, ganz besonders mit den WTF-Momenten bei schlecht dokumentierten Projekten. Außerdem noch den Willen, es besser zu machen. Viele Opensource-Projekte kranken entweder daran, daß der Entwickler von Doku keine Ahnung hat, weder von technischer Doku noch von Userdoku (und von Usability auch nicht), oder an der "scratch-my-itch"-Einstellung. Letztere führt im Wesentlichen dazu, totalen Müll zusammenzustoppeln, aber sich dank der Ausrede "Opensource" dabei auch noch großartig vorzukommen. Ganz nach dem Motto "sobald ich kein Geld bekomme, kann ich auch endlich mal Mist machen".
Michael L. schrieb: > Es wird häufig falsch dokumentiert. Aber das ist nicht Doxygen anzulasten, sondern dem, der falsch dokumentiert. Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich setze Doxygen ein, lerne aber gerne dazu. EDIT: gibt es für SourceMonitor eine grobe Richtlinie, welche Komplexität noch ok ist und wo man was tun sollte? Gruß von Max, der in diesem Thread schon eine Menge gelernt hat
Max G. schrieb: > Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Es gehört halt nicht nur ein Stück Beschreibung vor jedem Funktionskopf dazu, die möglichst mehr als nur die Parameter erklärt, sondern jede logische Einheit (kann eine Datei sein, muss nicht) sollte oben einen größeren Textblock haben, der zum „Großen Ganzen“ dieser Einheit eine Beschreibung enthält. Man kann auch logische Gruppen über mehrere Dateien bilden. Für Dinge, die nicht in den normalen Sourcecode passen, kann man immer noch „Additional Pages“ hinterlegen. Es hat sich eingebürgert, dass man dafür Dateien mit der Endung .dox schreibt, die inhaltlich einfach Doxygen-Sourcecode sind (also wie ein einziger großer /** ... */ Kommentar aussehen). Weiß nicht, mittlerweile kann Doxygen wohl auch Markdown verarbeiten, damit habe ich noch keine Erfahrung, vielleicht sieht das ja besser aus. Was sich auch bewährt hat ist, dass man zu „verknispelte“ Dinge vor dem Leser der Doku verbirgt, so in etwa:
1 | /**
|
2 | * This function implements some foo bar.
|
3 | */
|
4 | #ifdef DOXYGEN
|
5 | void foobar(int mumble); |
6 | #else
|
7 | static inline void foobar(int mumble) { |
8 | __asm__ ("foo bar\n" |
9 | : mumble); |
10 | #endif
|
Der Makro „DOXYGEN“ wird dann im doxygen.conf gesetzt. Ohne das #ifdef würde Doxygen den Nutzer mit dem gesamten inline-Asm überfallen, mit dem #ifdef dagegen hinterlegt man etwas Lesbareres. p.s.: Natürlich ist und bleibt Doxygen ein Tool in erster Linie für Programmierer-Dokumentation. Eine Anwenderdoku würde ich damit nicht schreiben, aber so weit dürfte „horizon“ noch nicht sein.
Max G. schrieb: > Hast du einen Vorschlag, wie man in Doxygen sinnvoll dokumentiert? Ich > setze Doxygen ein, lerne aber gerne dazu. Es geht bei der Dokumentation von Klassen, Funktionen und Methoden weniger darum den Inhalt des Namens der Jeweiligen Abstraktion zu wiederholen alla:
1 | int countAnswers; // Antworten-Zähler der die Antworten zählt |
Es geht darum, dass du dem nächsten sinnvolle Tips für die Verwendung mit gibst. Meine Daumenregel heisst: "Wenn du nichts sinnvolles schreiben kannst, schreib wenigstens ein Beispiel wie man es Verwendet." Ein Beispiel aus einem meiner Projekte:
1 | /// Setzt den Datenbank-Cursor auf die nächste Ergebnis-Zeile und liest die Zeile aus. |
2 | /// Es ist notwendig beim ersten Zugriff auf die Ergebnisse auch Result::next |
3 | /// aufzurufen, daher ergibt sich folgendes Idiom um über die Zeilen eines |
4 | /// SQL-Ergebnisses zu iterieren: |
5 | /// |
6 | ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
7 | /// ResultPtr r = db.execute(...); |
8 | /// for (r->next(); r->available(); r->next()) |
9 | /// {
|
10 | /// // ... r->row() ... |
11 | /// } |
12 | ///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
13 | /// @return true wenn eine Ergebnis-Zeile verfügbar ist und nicht das Ende der Datenmenge erreicht wurde. |
14 | /// (das selbe wie available() zurückgeben würde) |
15 | /// @sa available() |
16 | bool next(); |
Und wie Jörg schon schrieb, genau das selbe gilt auch für die gesamte Klasse. Sag dem Leser, wie er die Klasse benutzt, was er für andere Klassen braucht, welche Methoden in welcher Reihenfolge aufgerufen werden müssen und wie sie im Zusammenhang stehen. Bei der Dokumentation von bisher undokumentiertem Code sehe ich auch immer zu, dass mindestens die "äußeren" APIs dokumentiert sind. Also die High-Level APIs die für einen Anwender wichtig sind. Komplett internen code der den kram nur implementiert versehe ich meist nur mit API-Dokumentation wenn ich die Zeit und Muße dazu habe. In den Internas ist es mir meist wichtiger komplizierte Code-Teile mit hilfreichen Kommentaren zu versehen, damit der nächste weiß wieso etwas so komisch implementiert ist, oder wo die Fallstricke sind bei der Modifikation. PS: Ich schreib die Doku auch häufig für mich selbst. Weil ich nach 2 Wochen auch nicht mehr ganz genau weiss wie man eine API benutzt. Darum sind mir Beispiel so wichtig. Da kann ich schnell Copy&Paste machen wenn ich faul bin und anpassen. Die Doxygen-Doku ist auch meistens schneller aufgerufen als die Tests der jeweiligen Bibliothek, in welchen die API ja meist nochmal Beispielhaft niedergeschrieben ist. Achja, und für generische Komponenten kann ich wirklich automatisierte Tests empfehlen. Ich persönlich nutze booost::test - aber das Setup davon kann manchmal etwas kompliziert sein.
Es gibt endlich Binaries! https://github.com/carrotIndustries/horizon#quickstart-using-the-project-manager Für nen Installer war ich noch zu faul, ist aber auch noch zu früh dafür. Abgesehen vom initialen Einrichten des Pools braucht man nun zum Erzeugen und Bearbeiten eines Projektes keine Kommandozeile mehr.
Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber vermutlich eher dran, dass ich keine Maus zur Hand hatte? Der Tool-Popover reagiert teilweise sehr langsam. Bspw hab ich versucht "zoom" zu tippen, aber er hat sehr träge reagiert. Konnte aber aufm ersten Blick nix am Code erkennen, was das Verhalten erklärt. Zum Code habe ich nur folgende, vollkommen subjektive und auf Geschmack basierende Gedanken, die sich hauptsächlich um die Formatierung drehen: Ich rücke lieber mit Spaces ein. Die Zeilen sind ´relativ unlesbar, weil 152 Zeichen lange Zeilen mit dem Auge schwer zu lesen sind (Das Auge muss die Höhe ja bei jedem horizontalen Sprung justieren). Manche Methoden sind recht lang. bspw. Schematic::expand. Und ich bin ein Freund von Leerräumen beim Formatieren. Also "if (a == b)" statt "if(a == b)" und mehr Leerzeilen. Die Kopplung der Klassen untereinander ist relativ hoch. Bspw. muss Schematic offenbar sehr genau wissen, wie ein Symbol genau funktioniert und aufgebaut ist: "sym->component->entity->prefix" - das koppelt die Implementierung vom Symbol sehr stark an Schematic.
bzgl. meines letzten Posts: Das sind natürlich zum Teil auch Stil-/Geschmacks-Fragen. Aber meiner Erfahrung nach ist gut lesbarer Code auch einfach zu wartender Code. Dass Schematic etwas über die Komponenten mit denen es hantiert ist auch kein gravierendes Problem, aber man sollte ein Auge drauf haben wenn der Code anfängt (stark) zu wachsen. Unter Windows 7 öffnet sich leider weder der Schematic noch das Board, es kommt nur ein weißer Kasten - und es scheinen unsichtbare Bedienelemente vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten Positionen und der Kasten lässt sich auch größer/kleiner ziehen.
Robin R. schrieb: > Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar > platziert bekommen im Schematic. Konnte sie auswählen und hatte dann son > Magenta-Farbenen Marker aufm Plan. Reinzoomen ging nicht, liegt aber > vermutlich eher dran, dass ich keine Maus zur Hand hatte? Hört sich nach OpenGL-Problem an (Shader für den Inhalt konnten nicht kompiliert werden). Was für eine Grafikkarte hast du? CAD ohne Maus macht natürlich nur wenig Sinn.. Wenn du debuggen willst, musst du wohl selber Bauen und den imp direkt auf mingw starten: https://github.com/carrotIndustries/horizon/blob/master/build_win32.md Dann kommt auch sinnvolle Ausgabe, was schief gelaufen ist. Robin R. schrieb: > Der Tool-Popover reagiert teilweise sehr langsam. Keine Ahnung was 'sehr' heißt, eine gewisse Verzögerung ist aber drin: https://developer.gnome.org/gtk3/stable/GtkSearchEntry.html Robin R. schrieb: > Unter Windows 7 öffnet sich leider weder der Schematic noch das Board, > es kommt nur ein weißer Kasten - und es scheinen unsichtbare > Bedienelemente > vorhanden zu sein, der Cursor ändert nämlich seine Form an bestimmten > Positionen und der Kasten lässt sich auch größer/kleiner ziehen. Der Projektmanager tut aber? Hört sich wieder nach OpenGL-Problem an...
Windows 7: Intel HD Graphics 4000, GPU Caps Viewer liefert folgende
Infos:
OpenGL 3.3 (Intel(R) HD Graphics 4000 with 132 ext.)
OpenCL 1.1, Intel(R) HD Graphics 4000 compute units:16@350MHz
Report hab ich hier hochgeladen (gpu_caps_viewer_report_win7.txt)
Windows 10: Nvidia GeForce 840M
OpenGL 4.5 (GeForce 840M/PCIe/SSE2 with 360 ext.)
OpenCL 1.2, GeForce 840M compute units:3@1124MHz
Report hab ich auch hochgeladen (gpu_caps_viewer_report_win10.txt)
PS: Die Intel-Karte scheint offenbar keine Geometry Shader Texture Units
zu haben. Daher kann da natürlich auch der Shader nicht laufen.
Lukas K. schrieb: > Robin R. schrieb: >> Läuft bei mir unter Windows 10. Hab leider keine Komponenten sichtbar [.snip.] > Was für eine Grafikkarte hast du? CAD ohne Maus > macht natürlich nur wenig Sinn.. Habs jetzt nochmal mit Maus (via VNC nach Hause) probiert, das Problem ist nur der initiale Zoom. Wenn ich weiter rein Zoome (mit Mausrad) sehe ich die Komponente auch richtig, und nicht nur den mangenta-farbenen Selektionsmarker. Touch-Pad-Support is auch ersmtal nicht wichtig, bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends im Bett hab ich halt keine Maus zur Hand ;-) Finds übrigens super, dass Undo/Redo bereits in so früher Phase eingebaut ist - sowas nachträglich einbauen is immer ein Krampf... OpenGL-Mäßig ist die NVidia-Karte halt eher aufm aktuellen Stand. Ist auch ein Lenovo-Consumer-Laptop, die Windows 7 Kiste ist ein 3-4 Jahre alter Büro-Dell-Rechner. Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will. Aber sollte es nicht schon ausreichen wenn man mit vertext buffer objects arbeitet? PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit einer selbst-compilierten Version ausm Git):
1 | (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment shader: |
2 | ERROR: 0:10: 'texture2D' : no matching overloaded function found (using implicit conversion) |
3 | ERROR: 0:10: 'assign' : cannot convert from 'const float' to 'FragUserData 4-component vector of float' |
Robin R. schrieb: > PS: Auf dem Windows 7 Rechner bekomme ich folgende Fehlerausgabe (mit > einer selbst-compilierten Version ausm Git): > >
1 | (horizon-imp.exe:2356): Gdk-WARNING **: Compile failure in fragment |
2 | shader: |
3 | ERROR: 0:10: 'texture2D' : no matching overloaded function found |
4 | (using implicit conversion) |
5 | ERROR: 0:10: 'assign' : cannot convert from 'const float' to |
6 | 'FragUserData 4-component vector of float' |
Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die OpenGL-Demo. Die sollte dann auch kaputt sein. Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann klappt.
Lukas K. schrieb: > Oh, das schaut nach einem Bug in Gtk/Gdk bzw. dem Intel-Treiber aus. Ist > der aktuell? Passt auch dazu, dass das Fenster komplett leer ist. Zum > Test, starte mal gtk3-demo aus der mingw-Konsole und öffne die > OpenGL-Demo. Die sollte dann auch kaputt sein. Jo, die OpenGL-Demo is auch kaputt, selbe Symptome. Bzgl. der Treiber hab ich keine Ahnung. > > Schnapp' dir nen Hexeditor und mach die libgdk-3-0.dll aus dem > mingw-Verzeichnis auf. Nach Offset 0x87340 texture2D durch texture > ersezten (2D durch zwei Leerzeichen ersetzen) Schau mal nach, ob's dann > klappt. Hmm, damit hab ich bei mir die gtk3-demo nur komplett kaputt bekommen.
In dem von dir Angehängten Report steht was von - Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll bei Intel gibt's einen von 2016 https://downloadcenter.intel.com/download/25977/Intel-Graphics-Driver-for-Windows-10-and-Windows-7-8-1-15-33-?product=81499 Wenn du magst, kannst du mal mit dem dein Glück versuchen. Robin R. schrieb: > Touch-Pad-Support is auch ersmtal nicht wichtig, > bei KiCAD bleibt mir auch nur F2/F3 zum Zoomen übrig. Morgens/Abends > im Bett hab ich halt keine Maus zur Hand ;-) Auf X11 und Wayland erkennt das Canvas-Widget, wenn ein Input-Event von 'nem Trackpoint kam und "pannt" dann, anstatt zu scrollen. Zum zoomen dann ctrl festhalten. Damit ist horizon auch recht brauchbar ohne Maus zu bedienen. Robin R. schrieb: > Ich kann gut verstehen, dass man aktuelle OpenGL-Features nutzen will. > Aber sollte es nicht schon ausreichen wenn man mit vertext buffer > objects arbeitet? Mit geometry shadern macht's eben mehr Spaß ;) Lästiger Kram, wie z.B. Linien mit abgerundeten Ecken malen geht recht bequem im Zusammenspiel von Geometry- und Fragment-Shader.
Lukas K. schrieb: > In dem von dir Angehängten Report steht was von > - Driver: 8.15.10.2639 (2-1-2012) - GL:ig7icd64.dll > bei Intel gibt's einen von 2016 > https://downloadcenter.intel.com/download/25977/Intel-Graphics-Driver-for-Windows-10-and-Windows-7-8-1-15-33-?product=81499 > > Wenn du magst, kannst du mal mit dem dein Glück versuchen. Die Intel-Treiber wollen leider nicht direkt auf diesem Dell-Rechner, aber die Treiber von der Dell-Webseite haben dann zumindest das Fehlerbild geändert. Jetzt bekomme ich immerhin ein Fenster, aber der Canvas ist nicht zu sehen (nur der graue Gtk-Hintergrund). Selbes Bild auch mit gtk3-demo. Immerhin gehts unter Win10 auf dem neueren Rechner.
Auch wenn's hier die letzten Monate doch eher still geworden ist, ist die Entwicklung von horizon nicht stehen geblieben. Neben Annehmlichkeiten wie GUI zum Verwalten von Bauteilen und Projeken sind Funktionen wie interaktives regelbasiertes Routing und DRC hinzugekommen. Seht selbst: https://github.com/carrotIndustries/horizon#horizon-is-a-free-eda-package
Ja, ich hatte vor einigen Tagen auch mal kurz hineingeschaut. Mitstreiter haben sich ja wohl sogut wie keine gefunden, und hier in dem Thread gab es soweit ich mich errinnere nur gemecker --war ja auch nicht anders zu erwarten. Ich werde mir demnächst mal dein Dateiformat und dein Vorgehen beim Bauteilentwurf ansehen. Denn mein high level GTK3 Nim wrapper ist nun endlich weitgehend fertig, so dass ich auch mal wieder etwas an meinen Programmen arbeiten könnte. Die kompatibilität mit gEDA werde ich wohl aufgeben, das scheint ja eh keiner mehr zu benutzen. Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja seltsamerweise langsamer als das CPU Backend. Kürzlich fand ich Intels https://github.com/intel/fastuidraw Das ist schon ganz interessant, aber wohl noch unfertig. 9 mal schneller als cairo CPU.
Stefan S. schrieb: > Hast Du eigentlich mal probiert, wie viel schneller Dein GL Zeichnen im > Vergleich zu Cairo's CPU Backend ist? Denn Cairo's GL Backend ist ja > seltsamerweise langsamer als das CPU Backend. Ausprobiert habe ich da noch nichts, wenn man sich aber mal ansieht wie furchtbar langsam Kicads Cairo-GAL canvas ist... Cairo mit OpenGL zu beschleunigen halte ich auch für nur mäßig zielführend, da cairos Zeichenmodell nicht so wirklich zu dem von OpenGL passt.
Ja das ist richtig. Nach https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ ist SkiaGL ja auch nicht wesentlich schneller als Cairo. Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und dann wird es leider schon wieder aufwendiger und langsamer. Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck aufgebaut?
Stefan S. schrieb: > Ja das ist richtig. > > Nach > > https://www.x.org/wiki/Events/XDC2016/Program/rogovin_fast_ui_draw/ > > ist SkiaGL ja auch nicht wesentlich schneller als Cairo. > > Aber wenn man schon mit OpenGL zeichnet sollte man schon geglättete > diagonale Linien, Bezier-Kurven und auch hochwerttige Fonts haben. Und > dann wird es leider schon wieder aufwendiger und langsamer. MSAA wäre in der Tat machbar, ist halt Aufwand: https://www.khronos.org/opengl/wiki/Multisampling#Render-to-FBO Für die anderen Methoden müsste der GdkGLContext MSAA können, was nicht der Fall ist. Was Fonts anbetrifft: Die derzeit verwendeten Hershey-Fonts sind mir hübsch genug. Andere Programme, die echte Truetype-Schriften verwenden haben mitunter Probleme damit, diese entsprechend dem Rest drum herum zu skalieren. Text, der bei einer Zoomstufe passt, ragt dann bei einer anderen schon ins Symbol nebendran... > Hast Du Deine GL Zeichenroutinen auf dem GL-Area Demo mit dem Dreieck > aufgebaut? Jep, hauptsächlich der Boilerplate-Code zum Shader aufsetzen ist größtenteils aus der Demo übernommen. Irgendwo muss man ja mal anfangen ;)
Stefan S. schrieb: > Mitstreiter haben sich ja wohl sogut wie keine gefunden, Naja, interessieren würde es mich schon, aber ich denke, ich bin technisch und mental nicht mit euch kompatibel. Mein normales Desktop Environment ist der fvwm2, und übliche Projekte umfassen bei mir 1000 Zeilen tcl/tk-Code (eher weniger als mehr). > [...] so dass ich auch mal wieder etwas an meinen Programmen > arbeiten könnte. Du bist der Stefan S., der die psychedelischen Bilder, die der topologische Router produziert hat, auf der Homepage zeigt!? > Die kompatibilität mit gEDA werde ich wohl aufgeben, Sehr schade. > das scheint ja eh keiner mehr zu benutzen. Ich spiele gelegentlich damit herum. -- Das Projekt scheint sich totgelaufen zu haben. Kennt jemand Hintergründe? Ich habe den diffusen Eindruck, dass sich die Entwickler auf faule Kompromisse "geeinigt" haben, die dann doch niemand wirklich wollte. Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände ich es WIRKLICH wichtig, eine Software zu haben, die eine klare Aufgabenteilung ermöglicht. Generell scheint meine persönliche Vorstellung von Software- ergonomie mit der der Programmierer absolut inkompatibel zu sein. Ideen gäbe es schon -- allein, ich bin programmier- technisch nicht versiert genug, sie umzusetzen.
Possetitjel schrieb: > Du bist der Stefan S., der die psychedelischen Bilder, die > der topologische Router produziert hat, auf der Homepage > zeigt!? Ja sicher. > >> Die kompatibilität mit gEDA werde ich wohl aufgeben, > > Sehr schade. > >> das scheint ja eh keiner mehr zu benutzen. > > Ich spiele gelegentlich damit herum. -- Das Projekt scheint > sich totgelaufen zu haben. Kennt jemand Hintergründe? Da gibt es eine vielzahl von Gründen. Der ursprüngliche Hauptentwickler und auch auch viele andere Entwickler haben sich nach und nach zurückgezogen. Neue Ideen oder größere Veränderungen wurden von den wenigen alten Usern stets abgelehnt. Dann war gEDA/PCB ja nur mit Mühe unter Windows zum Laufen zu bringen. GTK ist eh nicht mehr so beliebt, und die Entwicklung mit plain C ist eben auch sehr zäh. Und Scheme als Script- und Konfigurationssprache ist auch nicht jedermanns Sache. Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND bzw. gEDA-RND gibt. Ich hatte aber nur die Ankündigung gesehen, u.a. C89 und soll auch mit reinem X11 funktionieren, also auch ohne GTK. So macht man sich das Leben wieder sehr schwer. > > Im Vergleich zum nächsten, (n+1)ten All-in-one-Klotz fände > ich es WIRKLICH wichtig, eine Software zu haben, die eine > klare Aufgabenteilung ermöglicht. Das war gEDA/PCB ja, und gerade das wurde aber sehr viel kritisiert. Die meisten wollten lieber alles in einem Programm und sind dann zum Teil zu KiCad abgewandert. > Generell scheint meine persönliche Vorstellung von Software- > ergonomie mit der der Programmierer absolut inkompatibel zu > sein. Ideen gäbe es schon -- allein, ich bin programmier- > technisch nicht versiert genug, sie umzusetzen. Man muss ja nicht unbedingt C++ verwenden. Und auch nicht Haskell oder Rust. Es gibt ja heute eine Reihe von recht einfachen aber doch sehr leistungsfähigen Sprachen, da kann schon jeder, der etwas denken kann auch programmieren. Mit den GUI's sieht es natürlich noch immer schlechter aus, für Qt kommt wohl im wesentlichen nur C++ in frage, oder eventuell Python. Für GTK gibt es Bindings für viele Sprachen, mit unterschiedlicher Qualität. Aber Programmieren kann man ja auch Dinge die keine GUI benötigen. Oder man macht Webanwendungen, Java-Script und Konsorten scheinten ja immer beliebter zu werden. Oder C# oder Android Apps.
Wird hier eigentlich das selbe Programm vorgestellt, über das hier diskutiert wird? https://www.youtube.com/watch?v=OpwMhz_3Tbs
Davon würde ich angesichts des Programmnamens und des Namens "lukas" ausgehen. :)
ich schrieb: > Wird hier eigentlich das selbe Programm vorgestellt, über das hier > diskutiert wird? > https://www.youtube.com/watch?v=OpwMhz_3Tbs Ja. In dem Video präsentiert Lukas sein Projekt. Man findet die Videoaufzeichnung auch hier. https://media.ccc.de/v/gpn17-8592-neues_ecad-programm_horizon
ich schrieb: > Wird hier eigentlich das selbe Programm vorgestellt, über das hier > diskutiert wird? > Youtube-Video "Neues ECAD-Programm horizon (GPN17)" Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht kompatibel. Für mich wieder mal ein Beispiel für die vielen nahezu unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken als motivieren. Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann und ist unmöglich als One-Man-Show erfolgreich umzusetzen. Wieviel Mann-Jahre developer time beispielsweise wurden bisher an eagle ver(sch)wendet und bis heute hat eagle quirks, die manch einen zur Verzweiflung oder zur Konkurrenz treiben. Das Problem bei EDA ist nämlich, dass es extrem um die Feinheiten, d.h. das Zusammenspiel zwischen Schaltplan, Layout und Bibliothekshandling (schnelle Erstellung, Pflege, hohe Vollständigkeit, 3D etc.) geht und schon Kleinigkeiten einem das Leben schwer machen können. Für ein Ein-Mann-Projekt ist das in absehbarer Zeit (wir reden über JAHRE!!) viel zu schwierig umzusetzen und alle die hier falsche Hoffnung und Schulterklopf befördern werden selber so eine halbgare Software NIEMALS einsetzen. Was bleibt ist später eines der unzähligen angefangenen und verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran verloren hat.
Leute, Leute schrieb: > Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht > kompatibel. Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den du gehalten hast? Klingt er denn viel besser? > Für mich wieder mal ein Beispiel für die vielen nahezu > unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken > als motivieren. Thread nicht gelesen, aber rummaulen. Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit zugemutet werden soll. Folglich ist das Video auch kein „Tutorial“, sondern eine Darstellung des Arbeitsstandes. Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr als ein Jahr zu früh. > Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner > Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann > und ist unmöglich als One-Man-Show erfolgreich umzusetzen. Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei sofort, dass das als One-Man-Show nicht zu machen ist. Das leuchtet sofort ein. Deine Erfahrungen als Nutzer ermöglichen dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler in diesem Bereich so arbeiten muss …
Leute, Leute schrieb: > Was bleibt ist später eines der unzähligen angefangenen und > verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran > verloren hat. Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen? Wer was macht hat recht, wie man in der Szene sagt. Ich meine die Kritik war ja nicht mal konstruktiv... man hätte ja zum Beispiel das was gut ist herausstellen und vorschlagen können seine Mann-Jahre in ein vorhandenes Projekt wie KiCad einzubringen? Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht, hat recht!
Jörg W. schrieb: > Leute, Leute schrieb: > >> Mein Gott, diese abhackte Sprechweise ist für mein Gehör einfach nicht >> kompatibel. > > Hast du mal ein Video (oder Audio) von einem Konferenzvortrag, den > du gehalten hast? Klingt er denn viel besser? > >> Für mich wieder mal ein Beispiel für die vielen nahezu >> unzumutbaren "Tutorials" (um es mal so zu nennen) die eher abschrecken >> als motivieren. > > Thread nicht gelesen, aber rummaulen. Kannst es ja überlesen wenn es dir nicht passt. > Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit > zugemutet werden soll. Folglich ist das Video auch kein „Tutorial“, > sondern eine Darstellung des Arbeitsstandes. Es wird auch später niemandem nutzen, weil der Ersteller bereits mit dem Vortrag selbst überfordert ist. Sorry, aber so wirkt das nun mal auf mich. > Wenn du hier nur als Nutzer daherkommen willst, bist du wohl mehr > als ein Jahr zu früh. Man sein, aber auch in einem Jahr wird sich daran nichts ändern. Ist meine Prognose. Du brauchst sie nicht zu teilen. >> Abgesehen davon, brauchbare EDA-Software zu schreiben gehört nach meiner >> Erfahrung (als Nutzer) mit zum Schwierigsten was man sich vornehmen kann >> und ist unmöglich als One-Man-Show erfolgreich umzusetzen. > > Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt aber dabei > sofort, dass das als One-Man-Show nicht zu machen ist. Ja, ich schreibe keine EDA SW. So verrückt kann ich gar nicht sein. Schau dir doch mal an was z.B. Abacom als EDA so anbietet. Wieviele Leute haben an deren SW nun seit wie vielen Jahren geschrieben und noch immer wird deren SW mehr als "Platinenmaler" angesehen, als als echte EDA-SW. Glaubst du der Threadersteller wird es jemals schaffen auch nur auf deren Niveau aufzuschließen? > Das leuchtet sofort ein. Deine Erfahrungen als Nutzer ermöglichen > dir natürlich einen grundlegenden Rundumblick dafür, wie ein Entwickler > in diesem Bereich so arbeiten muss … Darum geht es nicht. Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. Hier werden womöglich falsche Hoffnungen geweckt oder warum wurde dieser Thread hier eröffnet? Irgendwann soll die SW hier doch mal benutzbar sein oder etwa nicht? Schau dir doch nur mal den Mist bei gEDA an. Wer will denn sowas benutzen? Das Netz strotzt nur so von halbgaren Projekten, gerade im Bereich der SW-Entwicklung. Wer will denn seine Platinen mit einer SW layouten, deren Möglichkeiten extrem beschnitten sind und Schicksal ungewiss ist? Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich einigermaßen leben.
Miesepeter schrieb: > Leute, Leute schrieb: >> Was bleibt ist später eines der unzähligen angefangenen und >> verwaisten Projekte, bei denen der Ersteller schlicht die Lust daran >> verloren hat. > > Na und? Selbst wenn es so kommen würde, was gibts daran auszusetzen? Anscheinend bist du noch nie auf schlechte SW hereingefallen. > Wer > was macht hat recht, wie man in der Szene sagt. "Die Szene"? Was soll das sein? Leute die auf die schnelle was zusammencodieren und meinen dann das Ei des Kolumbus neu erfunden zu haben? Davon gibt es mehr als genug. Nach ein paar Jahren ist die Lust dann weg und zurück bleibt eine Baustelle, die keiner mehr braucht bzw. verprellte Nutzer. > Ich meine die Kritik war > ja nicht mal konstruktiv... Doch ist sie. Lass es sein! Verbessere meinetwegen lieber KiCAD aber versuche die nicht an Dingen die in die Hose gehen müssen. > Whatever - dem TO viel Erfolg und hört nicht auf Miesepeter. Wer macht, > hat recht! Wer das falsche macht gerät in seine Sackgasse. Wer das überdies nicht erkennt ist doof. Sorry, aber so ist es. Wer einfach mal ein bisschen herumcodieren möchte darf das natürlich tun. Aber dann den Ball flach halten und nicht falsche Hoffnungen wecken.
Jörg W. schrieb: > Das Teil ist absolut noch nichts, was irgendwie Nutzern derzeit > zugemutet werden soll. Hast du dir's in der aktuellen Version mal angesehen? Inzwischen hat's einige Annehmlichkeiten, die man so in anderer EDA-Software (z.B. KiCad) doch sehr vermisst: - Schaltplaneditor, der mehr als nur ein Malprogramm ist - Sinnvolles Bauteilmanagement - Flexible Regeln für Abstände, Leiterbahnbreite, etc. Im Gegensatz zu vor 9 Monaten kann man nun auch alles aus der GUI machen und muss keine Shell mehr anfassen. (Für dich wahrscheinlich weniger ein Problem) https://github.com/carrotIndustries/horizon/wiki/Feature-overview
Leute, Leute schrieb: > Kannst es ja überlesen wenn es dir nicht passt. Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen. In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen, mehr auch nicht. Vom TE haben wir im Gegensatz zumindest durchaus verwertbare Dinge sehen können, einschließlich des Auftritts auf einer Konferenz. Er hat eine Software geschaffen, die zumindest in gar nicht so kleinen Teilen das tut, was sie soll. Das ist deutlich mehr als die Miesmacherei, die du hier ablässt. (Dabei bestreite ich keineswegs, dass es noch ein langer Weg bis zum fertigen "Produkt" ist, > Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das zu erkennen? Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“). Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst, aber verschon diesen Thread einfach mit deiner Miesepeterei.
Jörg W. schrieb: >> Abgesehen davon, brauchbare EDA-Software zu schreiben >> gehört nach meiner Erfahrung (als Nutzer) mit zum >> Schwierigsten was man sich vornehmen kann und ist >> unmöglich als One-Man-Show erfolgreich umzusetzen. > > Aha. Du erklärst, dass du selbst nur Nutzer bist, weißt > aber dabei sofort, dass das als One-Man-Show nicht zu > machen ist. Das ist ein Umkehrschluss, der naheligend -- und meiner Meinung nach auch zutreffend -- ist: Wäre es als One-Man-Show machbar, dann hätte es schon jemand gemacht. EDA-Software gibt es schließlich reichlich. Was mich verzweifeln lässt, das ist der Eindruck, dass niemand -- wirklich NIEMAND -- Interesse daran hat, eine echt modularisierte Software auf die Beine zu stellen. Mit "modularisiert" meine ich nicht "Quelltext besteht aus mehreren Teilen", sondern: alle missionskritischen Interfaces (Dateiformate, ggf. auch APIs) sind offengelegt und werden aktiv gepflegt. Das würde natürlich voraussetzen, dass reichlich Arbeit in das Entwickeln eines tragfähigen Datenmodelles geht, und diese Zeit steht dann natürlich nicht mehr dafür zur Verfügung, sich über die "modernste" Grafik-Bibliothek die Köpfe einzuschlagen... Der Vorteil dieser Modularisierung liegt auf der Hand: Es sind alle Abstufungen von All-in-one-Mammutsoftware bis hin zu einzelnen Werkzeugen für jeden Zweck machbar, und der Anwender müsste keine exclusive Entscheidung für EIN Werkzeug treffen, die dann alle anderen ausschließt. Das kommerzielle Anbieter das nicht wollen (weil es den "Vendor- lock-in" verhindert), ist mir ohne weiteres klar. Warum aber die FOSS-Gemeinde nicht in der Lage ist, das hinzubekommen, wird mir auf Dauer ein Rätsel bleiben.
Lukas K. schrieb: > Hast du dir's in der aktuellen Version mal angesehen? Nein, sorry, ich fürchte, dass ich schon auf zu vielen Hochzeiten selbst tanze. :) Ich wünsche dir aber auf jeden Fall viel Erfolg damit, und es würde mich durchaus freuen, wenn das Projekt an Fahrt aufnimmt (einschließlich weiterer Mitwirkender).
Possetitjel schrieb: > Mit "modularisiert" meine ich nicht "Quelltext besteht aus mehreren > Teilen", sondern: alle missionskritischen Interfaces (Dateiformate, ggf. > auch APIs) sind offengelegt und werden aktiv gepflegt. Leute, die Opensource Datenmodelle abstrahieren, sind halt noch deutlich dünner geseht als Opensource-Programmierer. Programmieren macht Spaß, diejenigen, denen das Pflegen von Datenmodellen so viel Spaß macht, dass sie dies auch noch in ihrer Freizeit tun, dürfte es nur wenige geben.
Leute, Leute schrieb: > Wer das falsche macht gerät in seine Sackgasse. Wer das > überdies nicht erkennt ist doof. Sorry, aber so ist es. > Wer einfach mal ein bisschen herumcodieren möchte darf > das natürlich tun. Aber dann den Ball flach halten und > nicht falsche Hoffnungen wecken. Könnte es sein, dass Du Deine Prioritäten etwas merkwürdig setzt? Ist Dir das Diffamieren fremder Leistungen tatsächlich SO wichtig, dass am Ende keine Energie mehr über bleibt, ein Sachargument zu formulieren?
Jörg W. schrieb: > Leute, Leute schrieb: >> Kannst es ja überlesen wenn es dir nicht passt. > > Genauso gut könntest du deinen Beitrag zu Thema auch bleiben lassen. Und das bestimmst du also? > In der dargebotenen Form mag dein Beitrag deinem Ego vielleicht helfen, > mehr auch nicht. Ach Gott, spar dir deine persönliche Agitation. > Vom TE haben wir im Gegensatz zumindest durchaus > verwertbare Dinge sehen können, einschließlich des Auftritts auf einer > Konferenz. Die ziemlich unerträglich ist. Für meine Ohren jedenfalls. > Er hat eine Software geschaffen, Nö. Er hat mal was zusammencodiert, das niemand braucht und auch niemand benutzen wird. Ginge das alles so einfach hätten wird zig gute EDA Pakete. Haben wird aber nicht. Warum wohl?! > die zumindest in gar nicht > so kleinen Teilen das tut, was sie soll. Das reicht nicht. Nicht mal ansatzweise. > Das ist deutlich mehr als > die Miesmacherei, die du hier ablässt. (Dabei bestreite ich keineswegs, > dass es noch ein langer Weg bis zum fertigen "Produkt" ist, DU Bist es der auf Mies macht mein lieber. Nur mal zu deiner Erinnerung. Hier hat jemand einen Thread aufgemacht und zum BENUTZEN seines Programms aufgefordert. Zitat "Viel Spaß damit," Welcher Spaß??? Wer Platinen erstellt braucht keine Spaßbaustelle, sondern ein ZUVERLÄSSIGES Programm. Alles andere ist Mumpitz. Und Beta Tester einer Pre-Alpha-Software spielen ist auch kein Spaß. >> Es geht darum zu erkennen, wann man sich mit einer Aufgabe übernimmt. > > Wer bist du denn, dass ausgerechnet du dazu berufen sein mögst, das > zu erkennen? Das ist inhärent mit der ausgesuchten Aufgabe verknüpft. Dazu brauche ich keine Berufung um das zu erkennen. Mir genügt meine Erfahrung bisheriger EDA-SW, um zu beurteilen, wie viel wichtige aber oft schlecht umgesetzte Details einen zur Weißglut bringen können. Es braucht nicht noch mehr halbgare EDA. Gerade Leiterplattenprojekte sind wenig geeignet um mit SW gepflegt zu werden, die das Schicksal verwaister Projekte in wenigen Jahren teilen werden. Besser man bedenkt das vorher als hinterher dumm dazustehen. > Im Gegensatz zum TE bist du einfach nur ein anonymer Forenposter. Wenn > es an der Substanz fehlt, muss man sich dann an Äußerlichkeiten > aufziehen („Mein Gott, diese abhackte [sic] Sprechweise …“). Ja, ich bin es leid auf diese YouTube Videos hereinzufallen, die keinen Mehrwert beeinhalten, weil sie ziemlich unerträglich sind. Wenn ich nicht tanzen kann gehe ich auch nicht auf die Bühne zum vortanzen. > Geh bitte wieder zurück irgendwo hin, wo du produktiver wirken kannst, > aber verschon diesen Thread einfach mit deiner Miesepeterei. Spare dir diese billige Polemik. Mit falschem Schulterklopf erweist du dem TE nur einen Bärendienst.
Possetitjel schrieb: > Ist Dir das Diffamieren fremder Leistungen tatsächlich SO > wichtig, dass am Ende keine Energie mehr über bleibt, ein > Sachargument zu formulieren? Ich diffamiere hier niemandem. Hier wird aber wie schon im Mittelalter der Überbringer der Nachricht mal wieder gesteinigt und somit ein Forum wie des Öfteren ad absurdum geführt. Mal abgesehen davon, was erwartest du? Das ich meine Zeit damit verbringe eine SW zu testen, die ich nie benutzen werde? Wozu? Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht doch hoffentlich noch oder etwa nicht mehr?! Speichere den Thread hier ab, hole ihn in 5 Jahren wieder heraus und schaue, ob die SW dann beispielsweise KiCAD überholt hat. Ich sage dir voraus, in 5 Jahren (oder deutlich früher) wird diese SW in der Versenkung verschwunden sein und mit sowas verschwende ich nicht meine kostbare Zeit. Vergleiche einfach mal mit der Verbesserung über die Zeit bei anderer EDA SW, wie wenig wirklich neues hinzukommt und wieviel Bugs ausgeräumt werden müssen, die die Anwender nerven. Das willst du dir nicht freiwillig antun. Und achte mal darauf, wer welche Ausreden benutzt, um die SW des TE erst gar nicht anzufassen.
Jörg W. schrieb: > Possetitjel schrieb: >> Mit "modularisiert" meine ich nicht "Quelltext besteht >> aus mehreren Teilen", sondern: alle missionskritischen >> Interfaces (Dateiformate, ggf. auch APIs) sind offengelegt >> und werden aktiv gepflegt. > > Leute, die Opensource Datenmodelle abstrahieren, sind halt > noch deutlich dünner geseht als Opensource-Programmierer. > Programmieren macht Spaß, diejenigen, denen das Pflegen > von Datenmodellen so viel Spaß macht, dass sie dies auch > noch in ihrer Freizeit tun, dürfte es nur wenige geben. Das ist eine sehr interessante Antwort. Bitte korrigiere mich, wenn ich Dich missverstehe. -- Ich lese aus Deiner Anwort drei Gedanken heraus (oder inter- pretiere sie hinein -- wie man will): 1. Du bietest eine Erklärung für den von mir geschilderten Sachverhalt an. Das bedeutet implizit, dass Du meine Darstellung (dass sich nämlich niemand wirklich um die Interoperabilität über Projektgrenzen hinweg schert) im Kern für zutreffend hältst. 2. Du widersprichst meinem Wunsch nach mehr Interoperabilität nicht. Das heißt für mich: Hier spricht nicht (nur) meine subjektive, völlig fehlgeleitete Wahrnehmung, sondern hier steckt möglicherweise ein WIRKLICHES Problem, mit dem noch andere Leute außer mir kämpfen. 3. Im Grunde hast Du ja nur die Binsenweisheit "FOSS- Programmierer programmieren genau das, was sie selbst haben und benutzen wollen" auf den konkreten Fall angewendet. (Die Formel scheint mir im Großen und Ganzen auch zuzutreffen; sie erklärt zumindest, warum es deutlich mehr Compiler als fehlerfreie WYSIWYG-Bürosoftware gibt.) Daraus ergibt sich: Die Chancen, Mitglieder des Kernteams eines Projektes zu mehr Interoperabilität zu überreden, sind begrenzt. Dinge, die fehlen, werden eher ins eigene Projekt aufgenommen, als die Möglichkeit zu schaffen, sie "außerhalb" zu erledigen. Man müsste also von außen her, d.h. als Nicht-Projektmitglied sehen, was man tun kann.
Leute, Leute schrieb: > Possetitjel schrieb: >> Ist Dir das Diffamieren fremder Leistungen tatsächlich SO >> wichtig, dass am Ende keine Energie mehr über bleibt, ein >> Sachargument zu formulieren? > > Ich diffamiere hier niemandem. Hmm. Lass mich bitte als Vorrede folgendes feststellen: Ich bin infolge gewisser Akkumulation von Lebenserfahrung inzwischen ein Verfechter des Prinzips "Erkläre nichts durch bösen Willen, was durch Blödheit hinreichend erklärt ist". Daher bemühe ich mich weiterhin, Dir keine pure Lust an der Beleidigung zu unterstellen, sondern gehen davon aus, dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz von Dir eine Unverschämtheit ist. > Mal abgesehen davon, was erwartest du? Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen": Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen Frust auf der einen und den Sachargumenten auf der anderen Seite zu unterscheiden. > Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht > doch hoffentlich noch oder etwa nicht mehr?! Die Meinungsfreiheit besteht aber "leider" auch für die Leute, die Dich für einen Rüpel und Pöbelmeier halten und dies auch deutlich zum Ausdruck bringen. > Vergleiche einfach mal mit der Verbesserung über die Zeit > bei anderer EDA SW, wie wenig wirklich neues hinzukommt und > wieviel Bugs ausgeräumt werden müssen, die die Anwender > nerven. Das willst du dir nicht freiwillig antun. Das ist ja eine durchaus zutreffende Beobachtung. Auch wenn ich den Frust (vermutlich besser, als Du glaubst) verstehen kann -- bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn Du ihn im Wesentlichen mit Beleidigungen überschüttest? Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein Projekt vorzustellen. > Und achte mal darauf, wer welche Ausreden benutzt, um die > SW des TE erst gar nicht anzufassen. Schon wieder: "Ausreden". Du unterstellst SOFORT Unredlichkeit, ohne auch nur den Versuch zu unternehmen, den Gegenüber zu verstehen (nein, ich meine nicht "auf nette Weise Verständnis heucheln", ich meine: Echtes Verstehen. Ganz altmodisch.) So -- abseits der Formfragen: Du machst meiner Meinung nach einen Fehler, wenn Du kommerzielle und freie Software in einen Topf wirfst. Natürlich sind die Probleme für den Anwender in beiden Fällen dieselben -- nämlich mangelnde Interoperabilität unterschiedlicher Produkte. Die Ursachen sind aber verschieden: Bei kommerzieller Software ist der "Vendor-lock-in" gewolltes und erklärtes Ziel; man umschreibt das höflich als "Kunden- bindung". Bei freier Software ist es lediglich die Folge der Mentalität der Programmierer. Ich halte diesen kleinen, aber feinen Unterschied für wichtig: Es ist eine Sache, wenn Programmierer nicht unbedingt von sich aus auf Interoperabilität hinarbeiten -- wer in einem Projektteam mitarbeitet, will ja DIESES Projekt voranbringen, und nicht dafür sorgen, dass der Anwender ebensogut auch eine andere Software benutzen kann :) Eine völlig andere Geschichte wäre es aber, sich der Zusammen- arbeit mit dem "EDA Interoperability Project" zu verweigern, wenn es denn ein solches gäbe. Das ist meiner Meinung nach der Punkt, an dem man ansetzen muss.
Stefan S. schrieb: > Possetitjel schrieb: >> Ich spiele gelegentlich damit herum. -- Das Projekt [gEDA] >> scheint sich totgelaufen zu haben. Kennt jemand Hintergründe? > > Da gibt es eine vielzahl von Gründen. [...] Danke; ungefähr so etwas hatte ich vermutet. > Wobei es seit gut einem Jahr wohl ein neues Project PCB-RND > bzw. gEDA-RND gibt. Tausend Dank für diesen Hinweis. Es scheint so zu sein, dass es das Projekt faktisch seit ungefähr 2013 gibt, nur "offiziell" ist der Fork erst seit Kurzem. Verblüffend: Für pcb-rnd gibt's ein Debian-Paket (ab 9.x). Das Kernteam ist zwar mit 8 Leuten ziemlich klein, scheint aber aktiv zu sein. Noch ist also nicht alles verloren :) Mal schauen.
Possetitjel schrieb: > Lass mich bitte als Vorrede folgendes feststellen: Ich > bin infolge gewisser Akkumulation von Lebenserfahrung > inzwischen ein Verfechter des Prinzips "Erkläre nichts > durch bösen Willen, was durch Blödheit hinreichend erklärt > ist". Deine Lebensweisheiten behalte bitte für dich. > Daher bemühe ich mich weiterhin, Dir keine pure Lust an > der Beleidigung zu unterstellen, sondern gehen davon aus, > dass Du TATSÄCHLICH NICHT MERKST, dass jeder zweite Satz > von Dir eine Unverschämtheit ist. Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an die eigene Nase. >> Mal abgesehen davon, was erwartest du? Hier in diesem Forum erwarte ich absolut nichts mehr. Ich gebe hier dann und wann nur noch meine Meinung zum besten. > Reden wir mal nicht von "erwarten", bleiben wir bei "wünschen": > > Ich wünsche mir, dass Du beginnst, zwischen Deinem persönlichen > Frust auf der einen und den Sachargumenten auf der anderen > Seite zu unterscheiden. Schon wieder eine Unterstellung. Merkst du eigentlich, dass du hier anderen den Umgangston anmahnst und selber zu Unverschämtheiten greifst? >> Ich gab meine Meinung dazu ab und Meinungsfreiheit besteht >> doch hoffentlich noch oder etwa nicht mehr?! > > Die Meinungsfreiheit besteht aber "leider" auch für die > Leute, die Dich für einen Rüpel und Pöbelmeier halten und > dies auch deutlich zum Ausdruck bringen. Ich will dir mal was sagen, wenn man hier nicht mal mehr feststellen kann, dass gewisse YouTube Videos einfach eine Zumutung sind, dann ist es traurig um uns alle bestellt. Seid ihr inzwischen so vergutmenschelt, so empfindlich geworden, dass man euch das nicht mehr sagen darf? Ist dieses Land mittlerweile total verweichlicht? Auf der anderen Seite reagieren Gutmenschen wie ihr bei jeder kleinen Kritik dann sofort mit Schaum vorm Mund und Beleidigungen. Wie reagierst du denn beispielsweise, wenn ein talentloser Sänger auf der Bühne meint er sei ein toller Hecht. In Wahrheit aber ist der Kerl nur eine akustische Zumutung. Lobst du ihn dann vor deinen Kumpels über Klee, weil er's "doch irgendwie probiert hat und dafür Anerkennung verdient"? Meinst du, du tust so einem Menschen damit einen Gefallen? > bist Du WIRKLICH der Meinung, Lukas hört Dir zu, wenn > Du ihn im Wesentlichen mit Beleidigungen überschüttest? Nochmal zum Mitschreiben für dich, ich habe hier niemanden beleidigt. Ich habe bloß zwei Dinge angemerkt, nämlich 1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten Youtuber können keine gescheiten Vorträge abliefern) 2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist EDA-Software einfach zu komplex. Wo ist da bitte jetzt die Beleidigung? > Vergessen wir nicht: Er hat diesen Faden aufgemacht, um sein > Projekt vorzustellen. Und wozu dann, wenn ihn Kommentare nicht interessieren? Geht's ihm dann um Lobhudelei? Wir sind hier nun mal nicht auf bzw. in der Walldorfschule. Zwischen gut gemeint und gut gemacht liegt oftmals ein großer und entscheidender Unterschied. Wer so viel Zeit und Power über hat sollte die besser für sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht gut finden oder?!). Da es aber wie meistens völlig sinnlos ist hier weiter zu kommentieren beenden wir das Thema halt. Die Zeit wird zeigen wer recht behält. Hier ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW erstellen wollte. Daraus wurde auch nix.
Leute, Leute schrieb: >> Lass mich bitte als Vorrede folgendes feststellen: Ich >> bin infolge gewisser Akkumulation von Lebenserfahrung >> inzwischen ein Verfechter des Prinzips "Erkläre nichts >> durch bösen Willen, was durch Blödheit hinreichend erklärt >> ist". > > Deine Lebensweisheiten behalte bitte für dich. Aber Deine eigene Lebenserfahrung soll hier als guter Rat taugen? Warum nur Deine, aber nicht die von Possetitjel oder Jörg? Doppelmoral? > Deine Unterstellung ist eine Unverschämtheit. Greife dir bitte mal an > die eigene Nase. Der Ton macht die Musik, und Du hast den Ton zuerst angeschlagen. > 1. der Vortrag tut mir in den Ohren weh (zu deinem Trost, die meisten > Youtuber können keine gescheiten Vorträge abliefern) Ich tue mir Videos nur im Notfall an. Text/Grafik ist mir lieber. Videos erfordern eine zu hohe Konzentration. > 2. ein 1-Mann-EDA-Projekt wird NIEMANLS was werden. Dazu ist > EDA-Software einfach zu komplex. Als Projekt sicher nicht. Trozdem wird derjenige, der sich in dieser Form damit befasst, eine Menge lernen. 1) Über Programmieren 2) Darüber, wie Schaltungen entwickelt werden, und wie man Platinen layoutet. 3) Wie Platinen in der Fabrik hergestellt werden 4) Über sich selber. Unter diesen Aspekten sehr sinnvoll. > Wo ist da bitte jetzt die Beleidigung? Die steckt im Tonfall und in Deiner Missachtung der Tatsache, dass es noch andere als die von Dir angeführten Gründe gibt. ;O) > Wir sind hier nun mal nicht auf bzw. in der Walldorfschule. Und das ist auch gut so <grusel> ....trozdem macht auch hier der Ton die Musik, und wenn Du halt als testosteronschwangerer Vollmacho rumtrötest, musst Du Dich wegen des Zurücktrötens nicht wundern. Wenn ein Hirsch im Wald röhrt, wird schon ein anderer antworten. ;O) Nicht das mich der Krach stört, aber konstruktiv ist halt was anderes. > Wer so viel Zeit und Power über hat sollte die besser für > sinnvolleres einsetzen (was er natürlich darf, aber ich muss es ja nicht > gut finden oder?!). Es steht Dir nicht an, darüber zu Urteilen, wie andere Leute ihr Leben einrichten. Abgesehen davon, das es viele verschiedene gleichberechtigte Ansichten geben wird, spielt da viel zu viel Zufall und Kompromiss hinein, um ein Hineinreden zu rechtfertigen. Wir alle kennen die Deteils der Hintergründe und Randbedingungen des TO nicht. Dein Rat könnte zwar möglicherweise willkommen sein, aber wer in diesem Tonfall rät, will in wirklichkeit Kommandieren. Persönlich sehe ich es eher als Hybris, wenn man den Versuch macht, sein Leben zu planen. > Die Zeit wird zeigen wer recht behält. Hier > ist übrigens schon mal einer erschienen der (angeblich) eine EDA SW > erstellen wollte. Daraus wurde auch nix. Na und? Ich habe auch mal mit sowas herumgespielt. Ist stecken geblieben. War aber lehrreich und hat Spass gemacht. Jetzt habe ich es auch seit Jahren nicht mehr angefasst, obwohl es mich hin und wieder kitzelt. Und, wenn die Umstände günstiger (oder ungünstiger, interpretationsfrage) sind, mache ich das vieleicht auch wieder. Ich habe aber auch nie erwartet, dass etwas grossartiges dabei heraus kommt.**) Damit Du nicht meinst, ich wüsste nicht, wovon ich spreche, hier der Link darauf: https://www.mikrocontroller.net/wikifiles/5/5a/PyGerberAnalyse_B5_13Jun2013.zip Leute, Leute schrieb: > Mir reichen übrigens meine Quirks bei Diptrace. Mit denen kann ich > einigermaßen leben. Liegt hier der Hase im Pfeffer? Machst Du in Wirklichkeit Werbung auf eine unterschwellige Art und Weise? ;O) Irgendwie habe ich aber den Verdacht, als Werbung ist das auch ein Schuss in den Ofen. ;O) **) Immerhin hätte ich durch die Beschäftigung damit zweimal fast eine Stelle bekommen. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Lukas, Ich habe mit WIN7 und WIN10 getestet. Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe. Im Layout werden dadurch pads und traces in planes nicht mehr ausgespart. Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die Mitte der Traces zu nehmen statt deren Rand. Das ist jetzt für mich nicht tragisch, weil ich eh nur die Bedienung teste. Gibt es eine Liste welche Funktionen nicht gehen aber bereits ein Fenster öffnen? Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die Fehlermeldung: Error opening project parse error - unexpected '<' OK Gruß Helmut
> Ich wollte in Rules -> Copper Clearance die 0,1mm ändern. Seit dem
Versuch sind da nur noch 0.000mmm egal welche Zahl ich eintippe.
Hab mal nochmals versucht den Wert zu ändern. Ergebins: Man kann nur
ganze Millimeter eingeben, z. B. 1, 2... bis 100mm. 1mm will ich
natürlich da nie haben. Scheint ein echter Bug zu sein.
Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt.
Rufus Τ. F. schrieb: > Ins Blaue gefragt: Könnte das ein Dezimalpunkt ./. Dezimalkomma-Problem > sein? Versuch mal, statt "0.1" "0,1" einzugeben, oder umgekehrt. Hallo Rufus, danke, das hat geholfen. Wenn ich 0,2 eintippe statt 0.2, dann funktioniert es. Angezeigt wird dann 0.200.
Angehängte Dateien:
-
trace_on_polygon.PNG
3,2 KB
1. > Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die Mitte der Traces zu nehmen statt deren Rand. Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet. Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten screenshot ein Update Planes mache, dann bleibt von dem gefüllten Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen. Was mache ich da falsch? 2. > KiCad's awesome push'n shove router Bei mir schiebt wird da nichts geschoben. Wo schaltet man den in horizon ein?
Das mit den Dezimaltrenner ist nun repariert. Helmut S. schrieb: > 1. > >> Übrigens scheint die eingebaute Abstandsfunktion fälschlicher Weise die > Mitte der Traces zu nehmen statt deren Rand. > > > Diese Aussage ziehe ich zurück. Der Abstand wird richtig berechnet. > > Dafür habe ich ein anderes Problem. Wenn ich in dem Fall im angehängten > screenshot ein Update Planes mache, dann bleibt von dem gefüllten > Polygon nur noch eine einzige vertikale Linie an dessen ursprünglich > linkem Rand übrig. Auch ein erhöhen der Priorität hat da nicht geholfen. > Was mache ich da falsch? > Ich kann jetzt auf dem Bild nicht erkennen, zu welchen Netzen der Track da rechts und die Plane gehören. Gehören die zum selben Netz? Wenn ja, muss die Mittellinie das Tracks (derzeit) innerhalb (nicht auf der Kante) des Polygons liegen, damit die als verbunden erkannt werden. Wenn die Plane sonst nirgendwo angeschlossen ist, wird die nicht gefüllt, wenn orphans deaktiviert sind. > 2. > >> KiCad's awesome push'n shove router > > Bei mir schiebt wird da nichts geschoben. > Wo schaltet man den in horizon ein? Die Shove-Funktionalität wird derzeit von horizon noch nicht unterstützt, ich hab' mal die Doku angepasst... Helmut S. schrieb: > Dein Demo-Projekt funktioniert nicht in WIN7,10. Da kommt die > Fehlermeldung: > Error opening project > parse error - unexpected '<' Seltsam, in der Projektdatei ist kein '<' enthalten: https://github.com/carrotIndustries/horizon-test-project/blob/master/pic32-eth.hprj Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir doch nach einer HTML-Datei aus.
Hallo, welche Abhängigkeit bringt die profile.h Datei mit?
1 | [ 118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No such file or directory |
2 | [ 118s] #include <profile.h> |
3 | [ 118s] ^~~~~~~~~~~ |
Gruß, Frank
Frank K. schrieb: > Hallo, > > welche Abhängigkeit bringt die profile.h Datei mit? > >
1 | > [ 118s] router/router/pns_shove.cpp:44:10: fatal error: profile.h: No |
2 | > such file or directory |
3 | > [ 118s] #include <profile.h> |
4 | > [ 118s] ^~~~~~~~~~~ |
5 | > |
> > Gruß, > Frank Ist entfernt, war ein Überbleibsel aus dem KiCad-Tree, der auf meinem System dann wohl von Kerberos bereitgestellt wurde...
Hallo Lukas, 1. Das mit dem Update Planes funktioniert jetzt auch mit den traces entlang und in der plane. Am Anfang ging es nicht. Vielleicht habe ich einfach etwas falsch bedient. 2. > Seltsam, in der Projektdatei ist kein '<' enthalten: https://github.com/carrotIndustries/horizon-test-p... Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir doch nach einer HTML-Datei aus. Ich habe das Demo-Projekt als Einzeldateien heruntergeladen. Wo gibt es da einen zip-file? 2. Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es nicht.
Helmut S. schrieb: > Hallo Lukas, > > 1. > Das mit den Update Planes funktioniert jetzt auch mit den traces entlang > und in der Plane. Am Anfang ging es nicht. Vielleicht habe ich einfach > etwas falsch bedient. Ist in der aktuellsten Version auch repariert ;) > > 2. >> Seltsam, in der Projektdatei ist kein '<' enthalten: > https://github.com/carrotIndustries/horizon-test-p... > Hast du auch das Zip heruntergeladen und entpackt? Das '<' sieht mir > doch nach einer HTML-Datei aus. > > > Ich habe das Demo-Projekt als Einzeldateien heruntergeladen. > Wo gibt es da einen zip-file? https://github.com/carrotIndustries/horizon-test-project Bei dem grünen Knopf "Clone or Download" gibt es die Option "Download ZIP". > > 2. > Wo ist eigentlich das GND-Symbol im Schaltplaneditor? Ich finde es > nicht. Die GND-Symbole sind deutlich anders gelöst als in anderen Applikationen: https://github.com/carrotIndustries/horizon/wiki/Schematic-editor#power-symbols
Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu erstellen da noch ein paar Warnings im Code sind:
1 | [ 313s] I: Program is using uninitialized variables. |
2 | [ 313s] Note the difference between "is used" and "may be used" |
3 | [ 313s] W: horizon uninitialized-variable dxflib/dl_entities.h:1449 |
4 | [ 313s] |
5 | [ 313s] I: Program returns random data in a function |
6 | [ 313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90 |
7 | [ 313s] |
8 | [ 313s] I: Program returns random data in a function |
9 | [ 313s] E: horizon no-return-in-nonvoid-function rules/rule_match.cpp:90 |
Gruß, Frank
Horizon is a free EDA package ... Nach Monaten des Schweigens kommt dieses Horizon wieder in die Diskussion. Na fein, sagt unsereiner sich... ..aber wenn man sich mal die zugehörige Seite "https://github.com/carrotIndustries/horizon"; anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details überfrachteten Seite. Wo ist da der Anfang? Wo ist da die nötige Struktur? Erwartet der Autor, daß man sich als eventueller Interessent durch alle Details (block, board, canvas, canvas3d, clipper, ...) durchwühlt? Nee, Leute. So wird das nix bis ewig. Ein simples blinky.c kann jeder auch ohne jegliche Projektplanung schreiben, aber bei einem Projekt wie ein komplettes EDA-System es darstellt, braucht es ganz am Anfang ein gut durchdachtes und schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht formulieren will oder kann, der wird unweigerlich scheitern. Und wenn man dann sowas lesen darf: "Seems like people really want to have Windows binaries, so I made some: horizon-zip" ...dann vergeht einem die Lust, die 34 MB herunterzuladen und eventuell sogar auch noch auszuprobieren. Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit persönlicher Beleidigtheit reagieren. Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht. Auch eine echte Darstellung, wie Horizon denn überhaupt funktioniert, also wie das Zusammenspiel zwischen Schematics, Layout und anderen Teilen wie Bibliotheken, Rulechecks (erc, drc, hf, therm, usw.) organisiert ist, glänzt durch vollständige Abwesenheit. Von einem User-Manual will ich erst garnicht reden. Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren Windows-Ecke... Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat, den ich hier geben könnte würde lauten: der/die Autoren täten besser, wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre zielführender. W.S.
Frank K. schrieb: > Compilieren geht soweit, jedoch weigert sich rpmbuild ein Package zu > erstellen da noch ein paar Warnings im Code sind: Sind repariert.
Hallo Lukas, mit dem zip-download funktioniert das Demo-design. Das Power-Symbol für GND bekomme ich jetzt auch hin nach deinem letzten Hinweis. Die clearance rules werden jetzt mit',' angezeigt. Ich möchte bei einigen traces die Breite ändern. Warum ist eigentlich im Layout das Feld für Track->width grau(nicht änderbar)? Gruß Helmut
Helmut S. schrieb: > Warum ist eigentlich im Layout das Feld für Track->width grau(nicht > änderbar)? Das liegt daran, dass der Schalter "Width from rules" an ist. Damit werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width" gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als erstes zutrifft.
Lukas K. schrieb: > Helmut S. schrieb: >> Warum ist eigentlich im Layout das Feld für Track->width grau(nicht >> änderbar)? > > Das liegt daran, dass der Schalter "Width from rules" an ist. Damit > werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width" > gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als > erstes zutrifft. Danke, darauf hätte ich selber kommen sollen. :-) Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane verkleinert werden oder gibt es eine "routing outline"?
Für Windows-Benutzer Hier loslegen https://github.com/carrotIndustries/horizon Ganz unten auf der Seite "Getting Started" > See the "wiki" Dann ist man hier. https://github.com/carrotIndustries/horizon/wiki/Getting-started "Get Horizon" Windows -> "here" -> horizon.zip -> neueste Version nehmen. Die zip-Datei in einem beliebigen Verzeichnis entpacken, z. B. C:\horizon Wieder auf diese Seite gehen: https://github.com/carrotIndustries/horizon/wiki/Getting-started Get the pool -> download the zipped pool Auch in C:\horizon speichern und dort entpacken. https://github.com/carrotIndustries/horizon/wiki/Getting-started "Open the project manager" C:\horizon\horizon\horizon-prj-mgr.exe starten. Siehe Wiki wie man den "pool" anlegt. Dabei dort pool.json in C:\horizon\horizon-pool-master wählen. C:\horizon\horizon-pool-master Jetzt kann man entweder mit einem Schaltplan starten. Am besten erst noch das Demo-Design laden. Den Link zum Demo-Design gibt es unter "Example project". https://github.com/carrotIndustries/horizon-test-project "Clone or download" wählen -> Download zip Den in C:\horizon speichern und auspacken. Open Project -> C:\horizon\horizon-test-project-master\pic32-eth.hprj Jetzt auf Top Schematic und/oder Board klicken.
W.S. schrieb: > Ein simples blinky.c kann jeder auch ohne jegliche > Projektplanung schreiben, aber bei einem Projekt wie > ein komplettes EDA-System es darstellt, braucht es > ganz am Anfang ein gut durchdachtes und schriftlich > fixiertes Konzept und die Struktur des Ganzen. Naja, was hältst Du von folgender Interpretation: Du brauchst (genauso wie ich) für alles, was komplizierter als blinky.c ist, ein durchdachtes Konzept. Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code geschrieben (und brauchte offenbar kein Konzept). Also ist "horizon" für Lukas nicht komplizierter als für uns blinky.c. Betrüblich für uns, aber erfreulich für Lukas :) > Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja > bereits bei Diptrace angemahnt, später ebenfalls bei Kicad. Niemand will Probleme. Alle wollen Lösungen. Gilt auch für Programmierer. Und im Hobby will man sich ganz sicher von niemandem mahnen lassen. > Aber es ist wohl immer so bei hochambitionierten > Programmierern, daß sie ihr Baby nur nach ihren eigenen > Gesichtspunkten bepflegen, keinen wirklichen Blick für > die eventuellen Anwender haben Entschuldigung: Hat Lukas IRGENDWO zugesichert, dass er Dich, mich oder die Welt mit seinem Programm glücklich machen will? Ich wüsste nicht, wo. Er sagt in seinem Vortragsvideo nur: Er sei mit den vorhandenen EDA-Programmen nicht zufrieden gewesen und hätte daher begonnen, sein eigenes zu schreiben. Genau das tut er. Jetzt braucht er Tester, und deswegen bittet er darum, das Programm zu testen. > Auch eine echte Darstellung, wie Horizon denn überhaupt > funktioniert, Wozu? Hat Lukas IRGENDWO um Hilfe beim Programmieren gebeten? > Nein, Horizon ist keineswegs "a free EDA package", sondern > bislang nur ne Art Fingerübung die so tut, als ob sie sowas > wäre. Hältst Du es für denkbar, dass Deine Ansicht darüber, was ein "free EDA package" können muss, NICHT die einzig richtige ist? > Der einzigen Rat, den ich hier geben könnte würde lauten: > der/die Autoren täten besser, wenn sie ihre Arbeitskraft > einsetzen würden, um Kicad vom Kopf auf die Füße zu stellen, > also dessen Geburtsfehler ausmerzen. Das wäre zielführender. Habe ich das richtig verstanden: Es wäre das Beste für Lukas, wenn er die Software programmieren würde, die W.S. gerne haben will? Nee, also ganz ehrlich: Für die Software, die DU gerne haben willst, musst schon DU SELBST das Projekt auf die Beine stellen. (Das bedeutet nicht zwingend, dass Du auch alles selbst programmieren musst.)
Helmut S. schrieb: > Das Kupfer geht ja bis zur Boardkante bei dem Demoboard. Das solltest > mal ändern und z. B. 0,8mm Abstand einbauen. Muss dazu die GND-plane > verkleinert werden oder gibt es eine "routing outline"? Genau da bin ich gerade dran ;) Aus der "Clearance Copper - NPTH"-Regel wird eine "Copper - Non copper Regel", die dann den Abstand von Kupferdingen, wie Track, Plane, etc. zu Nicht-Kupferdingen wie NPTH-Löchern und eben Boardkante beschreibt.
Possetitjel schrieb: > Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen Code > geschrieben (und brauchte offenbar kein Konzept). Wer sagt denn, dass er kein Konzept hat? Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein, vor allem dann nicht, wenn man es als One-Man-Show startet. Dafür reicht ein Konzept im Kopf völlig aus. Auch KiCad ist mal als One-Man-Show gestartet worden … Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe, schau ich mir Horizon auf jeden Fall auch mal an. Vermutlich wird Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten. :-)
Jörg W. schrieb: > Auch KiCad ist mal als One-Man-Show gestartet worden … Das wollte ich gerade schreiben. Bis auf sehr wenige Teile, die von seinen Studenten beigesteuert wurden, hat der gute Jean-Pierre das bis 2006 ganz alleine aus dem Boden gestampft. Und 2006 war es definitiv benutzbar, denn zu dem Zeitpunkt bin ich damals von Eagle zu Kicad gewechselt (u.a. wegen fehlender Hierarchie-Möglichkeiten) und habe nicht wirklich etwas vermisst - insbesondere nicht die Einschränkungen bei Eagle ;-) Es ist wie immer: viele reden und haben überall Bedenken - und die anderen fangen einfach mal an. Also: dass man für eine brauchbare ECAD-Software ein vielköpfiges, permanentes Entwicklerteam benötigt, ist offenbar falsch. > Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe, > schau ich mir Horizon auf jeden Fall auch mal an. Vermutlich wird > Lukas dann von mir als erstes einen Satz Patches für FreeBSD erhalten. > :-) Wir sind mit Kicad zufrieden, aber trotzdem ist das ein tolles Projekt. Hut ab vor Deiner Leistung, Lukas!
Jörg W. schrieb: > Wer sagt denn, dass er kein Konzept hat? > > Ein solches muss ja nicht zwingend irgendwo aufgeschrieben sein, > vor allem dann nicht, wenn man es als One-Man-Show startet. Dafür > reicht ein Konzept im Kopf völlig aus. Genau so ist's. Das "Konzept" ist ja auch nichts feststehendes, sondern mehr etwas, das sich im Laufe der Zeit an neue Gegebenheiten und Gelerntes anpasst. Was aufgeschriebenes wäre derzeit eh nach kürzester Zeit veraltet. Führt halt dazu, dass man einige Dinge mehrfach grundlegend überarbeiten muss. Ganz ohne Plan läuft die Entwicklung auch nicht ab, siehe eine der letzten Folien aus dem Vortrag: Aktuelle / Zeitnahe Entwicklungen ================================= • DRC, Verbesserung des Routers Insb. ersteres ist geschehen. Ohne mir jetzt alle Opensource-EDA Applikationen im Detail angesehen zu haben, behaupte ich mal, mittlerweile, das leistungsfähigste und flexibelste Regelsystem zu haben. • Netzklassen aufräumen Ist geschen. • Layer erweitern Ebnefalls. • Kupferflächen füllen Auch. Zukunft ======= • ERC Gibt's noch nicht wirklich, ist auch mehr Arbeit als kompliziert zu implementieren. • 3D-Export/Darstellung 3D-Darstellung (ohne Bauteile) gibt's. Seit gestern auch mit Innenlagen. 3D-Export wird darauf hinauslaufen kicad2step zu portieren: https://github.com/KiCad/kicad-source-mirror/tree/master/utils/kicad2step • GUI für Pool, Entities, etc. Gibt's. • Parametrische Suche War noch nicht wichtig genug, ist aber auch mehr ein nice-to-have. • Integration des KiCAD-Routers Ist geschehen, wenn auch noch Dinge wie Routen von diffpairs und length-tuning noch nicht unterstützt werden. (Shove ist so gut wie fertig) Chris D. schrieb: > Hut ab vor Deiner Leistung, Lukas! Danke an dich und einige andere für die netten Worte!
Jörg W. schrieb: > Possetitjel schrieb: > >> Lukas hat (nach eigener Aussage) bisher 26'000 Zeilen >> Code geschrieben (und brauchte offenbar kein Konzept). > > Wer sagt denn, dass er kein Konzept hat? Och, Menno. Das sagt niemand -- das war nur eine notwendige Annahme, damit mein boshafter Vergleich funktioniert.
Angehängte Dateien:
-
HORIZON-IMP.PNG
97 KB
Hallo Lukas, in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update Planes" ab. Bitte wieder lauffähig machen. Version: horizon-2017-10-23-1433.zip Gruß Helmut
Helmut S. schrieb: > in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update > Planes" ab. Bitte wieder lauffähig machen. Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin stehen, damit auch was sinnvolles verwendet wird.
Lukas K. schrieb: > Helmut S. schrieb: >> in deiner neuesten Version für WIN stürzt horizon-imp.exe bei "Update >> Planes" ab. Bitte wieder lauffähig machen. > > Bis die neue Version kompiliert ist, reicht's wenn du in den Rules bei > Copper - Non-Copper Clearance was einträgst. Ohnehin sollte da was drin > stehen, damit auch was sinnvolles verwendet wird. Hallo Lukas, danke. Damit funktioniert "Update Planes" wieder. Gruß Helmut
W.S. schrieb: > Horizon is a free EDA package ... > > Nach Monaten des Schweigens kommt dieses Horizon wieder in die > Diskussion. Na fein, sagt unsereiner sich... > > ..aber wenn man sich mal die zugehörige Seite > "https://github.com/carrotIndustries/horizon"; > anschaut, dann landet man in einer hoffnungslos mit LowLevel-Details > überfrachteten Seite. Links oben auf der Seite gibt's den Punkt Issues... > ... bei einem Projekt wie ein komplettes EDA-System es > darstellt, braucht es ganz am Anfang ein gut durchdachtes und > schriftlich fixiertes Konzept und die Struktur des Ganzen. Wer das nicht > formulieren will oder kann, der wird unweigerlich scheitern. Allumfassende, am besten noch perfekte Konzepte? Viel Spaß in der Realität... Im besten Fall gibt's genügend Zeit/Geld, um mehrere Iterationen zu machen, die sich dem annähern > Also: Es fehlt das Konzept. Mal wieder. Ich hatte dies ja bereits bei > Diptrace angemahnt, später ebenfalls bei Kicad. Aber es ist wohl immer > so bei hochambitionierten Programmierern, daß sie ihr Baby nur nach > ihren eigenen Gesichtspunkten bepflegen, keinen wirklichen Blick für die > eventuellen Anwender haben und auf die Frage nach ihrem Konzept mit > persönlicher Beleidigtheit reagieren. 1. Muss jemand die genannten Programme verwenden? 2. Gibt's Alternativen? 3. Wo ist dann das Problem? > Also Horizon ist offenbar dediziert NICHT für Windows-Benutzer gedacht. s.o. > ... > Auch von angedachten Interfaces zu Dingen, die über den gewöhnlichen > Kram hinausgehen, wie z.B. distributed elements, Feldanalysen usw. kann > man nichts lesen. Jaja, unsereiner wäre durchaus an einem ECAD > interessiert, das wenigstens ansatzweise die Dinge, die man mit Ansoft > oder Sonnet sich gestalten kann, importieren oder wenigstens nachbilden > kann. Aber das wären ja wieder Dinge aus der vernachlässigbaren > Windows-Ecke... 1. Seit wann sind Ansys bzw. Ansoft oder Sonnet Windows-only? 2. "It's far from finished" heißt, zumindest für mich, vielleicht Alpha-Version. Ob man noch Alpha dazuschreiben muss? Vielleicht gar nicht so verkehrt... 3. Ist das ganze Open Source und etwas Hilfe bspw. mit Links zu den Dateiformaten der genannten Systeme oder zu Libraries/Kovertierern, die damit umgehen können, wären vielleicht nicht schlecht. 4. In einer Alpha-Version würde ich so was nicht implementieren, da gibt's wichtigeres. Ansonsten siehe 3. und vielleicht einen netten Feature Request schreiben. > Nein, Horizon ist keineswegs "a free EDA package", sondern bislang nur > ne Art Fingerübung die so tut, als ob sie sowas wäre. Der einzigen Rat, > den ich hier geben könnte würde lauten: der/die Autoren täten besser, > wenn sie ihre Arbeitskraft einsetzen würden, um Kicad vom Kopf auf die > Füße zu stellen, also dessen Geburtsfehler ausmerzen. Das wäre > zielführender. Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte man dann dort Zeit investieren?
Arc N. schrieb: > Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte > man dann dort Zeit investieren? Den allerwenigsten gefällt GAR NICHTS an KiCAD. Wer aber den Schaltplaneditor von gEDA, den Layouteditor von KiCAD und die Bauteilverwaltung von Horizon verwenden will, ist angeschissen.
Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich Simulation? Ich habe da leider überhaupt nichts -- das ist auch einer der Gründe warum ich in den letzten Jahren an meinen Programmen nicht weitergearbeitet habe. Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh. Ich vermute mal KiCad und sämtliche kommerziellen Programme unterstützen jetzt Simulation. Tina-Ti hatte ich mal kurz verwendet, das war schon recht gut nutzbar. (Leider war das Ergebnis völlig falsch, weil das Modell eines OP falsch war.) Ich vermute mal, dass Simulation heute ein entscheidendes Kriterium für eine EDA Software ist.
Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit KiCAD weiterzutreiben und dort zu investieren, als noch ein neues Programm aufzuziehen.
Ich würde das nicht zu sehr in den Vordergrund stellen. Es wäre natürlich nett, wenn man einen Simulator andocken könnte, aber mal ehrlich, sowie da ein Mikrocontroller oder sowas im Spiel ist, kannst du sowieso nie mehr alles simulieren, weil die Gesamtfunktion der Schaltung massiv von der Software abhängt. Dafür müsste man dann jeweils wieder Modelle in die Simulation einklinken können. Da hat es eher Sinn, einzelne Teilbaugruppen gelegentlich zu simulieren. Simulation ist ohnehin ein weites Feld. Der Anfänger will seinen Colpitts-Oszillator simulieren, der UHF-Entwickler dagegen wird das fertige Layout auf einem HF-Material simulieren wollen …
Stefan S. schrieb: > Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich > Simulation? Simulation ist wohl nicht geplant, siehe Vortrag: https://www.youtube.com/watch?v=OpwMhz_3Tbs&feature=youtu.be&t=18m35s 18:35
Stefan S. schrieb: > Sag mal Lukas, hast Du eigentlich schon eine Idee bezüglich > Simulation? Worauf zielt die Frage? Klassische Schaltungssimulation (konzentrierte Bauelemente) oder Simulation parasitärer Elemente im Layout? > Mit gEDA war Simulation mit Spice oder GnuCap ja sehr zäh. Was bedeutet das? > Ich vermute mal, dass Simulation heute ein entscheidendes > Kriterium für eine EDA Software ist. Also irgendwie verstehe ich die Welt nicht mehr... ist vemutlich eine Altersfrage... Ich verlange doch von meinem Oszi auch nicht, dass er Kaffee kocht, Kinderlieder singt, Bratkartoffeln brät und eine Bandbreite von 1GHz hat. Wenn ich einen Schaltplan zeichnen will, möchte ich ein Schaltplanzeichenprogramm nehmen. Wenn ich ein Layout entwickeln will, möchte ich einen Layouteditor starten. Wenn ich simulieren will, starte ich einen Simulator.
Possetitjel schrieb: > Wenn ich simulieren will, starte ich einen Simulator. Naja, es ist natürlich schon hübsch, wenn man den Schaltplan für eine Simulation nicht nochmal zeichnen muss, sondern den bereits im EDA-Tool gezeichneten dafür nehmen kann. Gleiches fürs Layout bezüglich einer EM-Feld-Simulation. Aber ich halte das auch eher für ein untergeordnetes Argument. Eine Simulation steht und fällt ohnehin mit den Modellen.
Possetitjel schrieb: > Wenn ich einen Schaltplan zeichnen will, möchte ich ein > Schaltplanzeichenprogramm nehmen. > Wenn ich ein Layout entwickeln will, möchte ich einen > Layouteditor starten. > Wenn ich simulieren will, starte ich einen Simulator. full ack! vor allem ist das schematic für die simulation sicher nicht ident mit dem für's layout. 73
Jörg W. schrieb: > Possetitjel schrieb: >> Wenn ich simulieren will, starte ich einen Simulator. > > Naja, es ist natürlich schon hübsch, wenn man den Schaltplan > für eine Simulation nicht nochmal zeichnen muss, sondern den > bereits im EDA-Tool gezeichneten dafür nehmen kann. Gleiches > fürs Layout bezüglich einer EM-Feld-Simulation. Na klar. Kompatible DATEIFORMATE setze ich eigentlich voraus; notfalls tut's ein funktionierender Export/Import. Aber genau DAS ist ja offensichtlich nicht gegeben. > Aber ich halte das auch eher für ein untergeordnetes Argument. > Eine Simulation steht und fällt ohnehin mit den Modellen. Naja... ich gehe schon soweit mit, dass Software, die praktisch anwendbar sein will, auch die in der Praxis auftretenden Arbeits- abläufe unterstützen muss. Ich vertrete aber die -- offenbar völlig veraltete -- Meinung, dass die Software MIR dienen soll, und nicht umgekehrt ich die Software loben, preisen und ihre Schlingen und Windungen besser und besser studieren muss.
Jörg W. schrieb: > aja, es ist natürlich schon hübsch, wenn man den Schaltplan für > eine Simulation nicht nochmal zeichnen muss, Das ist mit Verlaub nicht nur "hübsch" sondern essenziell! Bei einer größeren Schaltung möchte Ich nicht alles zweimal eingeben. Zumindest eine Netzliste muss exportierbar sein und dabei müssen vor allem die leeren, nicht vorhanden Bautteile als dummies mit verdrahtet sein, damit man sie in der Simulation direkt ersetzen kann.
Hans schrieb: > vor allem ist das schematic für die simulation sicher > nicht ident mit dem für's layout. Ja. Und das geht noch weiter. Viele Schaltpläne, die hier auf µC.net so vorgestellt werden, sehen einfach besch***en aus und sind eine Zumutung. Ich habe mal darüber nachgedacht, warum das so oft so ist, und bin zu dem Ergebnis gekommen, dass der klassische Schaltplan aus der Zeit der diskreten Bauelemente stammt: Relativ viele Bauteile, einfache, klar erkennbare Funktion für jedes Bauteil, wenige Anschlüsse an jedem Bauteil. Mikrocontroller oder FPGAs sind aber das genaue Gegenteil von diskreten Bauelementen. Der klassische Schaltplan ist also für diese Schaltungsteile vielleicht gar nicht die optimale Darstellungsform. Wünschenswert wäre vielleicht, dass man auch Daten in tabellarischer Form (Pinbelegungen z.B.) in die Software hineinfüttern kann. Aber damit ist natürlich NICHT gemeint, dass die EDA-Software ein "Spreadsheet-Plugin" bekommt, das sich selbstverständlich ganz anders bedient als Excel oder OOCalc und dessen Datenformat selbstverständlich zu nichts anderem auf der Welt kompatibel ist. Notwendig wäre, dass Daten, die heutzutage sowieso schon irgendwo (außerhalb der EDA-Software) anfallen, vernünftig weiterverarbeitet werden können.
Mar. W. schrieb: > Jörg W. schrieb: >> aja, es ist natürlich schon hübsch, wenn man den Schaltplan >> für eine Simulation nicht nochmal zeichnen muss, > > Das ist mit Verlaub nicht nur "hübsch" sondern essenziell! > Bei einer größeren Schaltung möchte Ich nicht alles zweimal > eingeben. Genau mein Reden. Nur muss das auch für die Schaltung gelten, die der Kollege vor fünf Jahren mit KiCAD entwickelt hat und die ich heute mit Horizon weiterentwickeln muss. Jeder Koch hat einerseits Bratpfannen und andererseits das Schnitzel. Nur die so moderne und fortschrittliche Software-Branche hält es für normal, dass man natürlich Meier-Schnitzel nur mit Meier-Eiern und Meier-Semmelbröseln verfeinern und auch NUR in Meier-Bratpfannen auf Meier-Herden mit Meier-Gas braten darf, wobei die Flamme mit Meier-Hölzern angezündet worden sein muss.
Possetitjel schrieb: > notfalls tut's ein funktionierender Export/Import. Darauf wird's hinauslaufen.
Simulation unmittelbar in horizon will ich in der Tat nicht haben. Horizon soll in erster Linie ein gutes Programm werden um Schaltpläne zu zeichnen und damit Boards zu machen. Erstmal nicht mehr. Warum schreit keiner, dass ERC noch vollständig fehlt, man keine differentiellen Leitungen routen kann, es keine Thermals in Flächen gibt, oder die Darstellung von Pad-Namen im Board noch sehr zu wünschen Übrig lässt? Was ich sagen will: Es mag sinnvoll sein, Simulation in das Tool, mit dem man auch Boards macht integriert zu haben. Derzeit gibt es aber noch unzählige andere Baustellen, Simulation wäre dann ein doch sehr aufwändiges I-Tüpfelchen. Daher spreche ich mich derzeit aktiv gegen jegliche Art von Simulations-Integration in horizon aus. Siehe auch: Wenn andere Programme (z.B. KiCad) nachwievor einen Schaltplaneditor haben, der keine Ahnung von Netzen hat und den Anwender Junctions nach Gutdünken platzieren lässt, aber schon dabei sind SPICE-Integration zu entwickeln liegt meines Erachtens der Fokus bei der Entwicklung falsch. Ja, Standards wären in der Tat schön, doch abgesehen von recht primitiven Spice-Netzlisten und Gerber gibt es in der Branche nichts wirklich brauchbares, was auch Anwendung findet. Possetitjel schrieb: > Wünschenswert wäre vielleicht, dass man auch Daten in > tabellarischer Form (Pinbelegungen z.B.) in die Software > hineinfüttern kann. Geht schon: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard#create-all-new-part Verbindungen nicht nur im Schaltplan zu zeichnen ist in der Architektur schon seit Anfang an vorgesehen, da in Horizon die Netzliste und nicht der Schaltplan die Primärquelle ist. Wenn z.B. an einem Netz ein Label hängt, drückt dieses Label nicht etwa dem Netzegment den eingetippten Namen auf, sondern zeigt eben den Name des Netzes an.
Lukas K. schrieb: > Simulation unmittelbar in horizon will ich in der Tat > nicht haben. Was bedeutet das? Also: Was soll "unmittelbar in horizon" bedeuten? 1. Interpretation: "Horizon bringt eigenen Simulator mit". Naja... also ich weiss nicht, wie KiCAD das tatsächlich macht, aber wenn die KiCAD-Leute in Anbetracht von gnucap, qucs, Spice, LTSpice... ihre eigene Numerik schreiben, dann haben sie nicht mehr alle Tassen im Schrank. Meine Meinung. Die Numerik komplett neu zu entwickeln, wenn es Simulatoren mit bereits etablierten und akzeptierten Schnittstellen gibt, die man integrieren kann, ist komplett dämlich. 2. Interpretation: "Keine Möglichkeit, externen Simulator auf Knopfdruck aufzurufen". ??? Warum nicht? Das bekomme ja sogar ich mit Tcl/Tk hin, wenn ich mir Mühe gebe. Wo ist das Problem? > Horizon soll in erster Linie ein gutes Programm werden um > Schaltpläne zu zeichnen und damit Boards zu machen. Erstmal > nicht mehr. Warum schreit keiner, dass ERC noch vollständig > fehlt, man keine differentiellen Leitungen routen kann, es > keine Thermals in Flächen gibt, oder die Darstellung von > Pad-Namen im Board noch sehr zu wünschen Übrig lässt? Weil Du auf technische Details fixiert bist, die vom Standpunkt eines Selbständigen bzw. einer kleinen Klitsche aus völlig nebensächlich sind. > Ja, Standards wären in der Tat schön, Tja, das sehen wir offenbar etwas verschieden. Meiner Meinung nach sind Standards im industriellen Zeitalter und im Zeichen des weltweiten Handels nicht "schön", sondern eine absolute Notwendigkeit. Was glaubst Du, wie der Maschinenbau ohne Normteile und ohne Standards für die technischen Zeichnungen aussähe? Richtig: Wie im Mittelalter. Jetzt weisst Du auch, welche Meinung ich zum Stand der EDA- Software habe (nicht DEINER EDA-Software, sondern DER EDA- Software ganz allgemein). > doch abgesehen von recht primitiven Spice-Netzlisten > und Gerber gibt es in der Branche nichts wirklich > brauchbares, was auch Anwendung findet. Richtig. Warum das bei kommerziellen Programmen so ist, ist augen- scheinlich: Der Wunsch nach "Kundenbindung" bewirkt das. (Es gibt da einen hübschen Wikipädie-Artikel dazu. Sinn- gemäßes Zitat: "Die Hersteller von EDA-Software waren erst nach massiver Intervention durch große Kunden bereit, Exportschnittstellen in ihrer Software vorzusehen.") Warum aber machen FOSS-Programmierer, die frei von vielen Zwängen der kommerziellen Anbieter sind, diesen Scheissdreck nach? > Possetitjel schrieb: >> Wünschenswert wäre vielleicht, dass man auch Daten in >> tabellarischer Form (Pinbelegungen z.B.) in die Software >> hineinfüttern kann. > > Geht schon: Um so besser. Ändert aber nichts am grundsätzlichen Problem. > Verbindungen nicht nur im Schaltplan zu zeichnen ist in der > Architektur schon seit Anfang an vorgesehen, da in Horizon > die Netzliste und nicht der Schaltplan die Primärquelle ist. Ich hatte schon damals herausgelesen, dass Du einige sehr sinnvolle Ansätze verfolgst, die ich von anderen Projekten nicht kenne. Trotzdem sehe ich Dein Projekt wie Baumgartners Stratosphären- sprung: Ich bewundere die persönliche Leistung aufrichtig -- aber es ist letztlich für mich uninteressant, weil nichts konkret für mein eigenes Leben, mein eigenes Tun daraus folgt. Bitte nicht falsch versehen: Das ist keine Kritik an Deinem Tun oder Deinen Entscheidungen. Es ist Dein Projekt (und schätzungsweise ein Hobby und kein Broterwerb), und Du bist völlig frei in Deinem Tun und Lassen. Meine Worte sind keine Kritik an Dir, sondern sollen nur eine Erklärung meines Verhaltens sein: Obwohl ich auf der Suche nach für mich geeigneter EDA-Software bin, habe ich (bis jetzt) nicht den Eindruck, dass Deine Software für mich in Frage kommt. Die Schwerpunkte, die Du in Deiner Arbeit setzt, scheinen mir mit meinen Wünschen in keiner Weise kompatibel.
Hi, ich wollte die aktuelle Version auch mal wieder testen, unter
Xubuntu 16.04. Problem: imp.cpp bricht ab. Zur Info habe ich noch die
Versionen der Abhängokgeiten angehängt. Geclont habe ich heute.
tester@HPi7:~/src/horizon/horizon$ sudo apt install libyaml-cpp-dev
libsqlite3-dev util-linux librsvg2-dev libcairomm-1.0-dev
libepoxy-dev libgtkmm-3.0-dev uuid-dev libboost-dev libzmq5
libzmq3-dev libglm-dev
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
»libboost-dev« ist bereits die neuste Version (1.58.0.1ubuntu1).
»libcairomm-1.0-dev« ist bereits die neuste Version (1.12.0-1).
»libglm-dev« ist bereits die neuste Version (0.9.7.2-1).
»libgtkmm-3.0-dev« ist bereits die neuste Version (3.18.0-1).
»librsvg2-dev« ist bereits die neuste Version (2.40.13-3).
»libsqlite3-dev« ist bereits die neuste Version (3.11.0-1ubuntu1).
»libyaml-cpp-dev« ist bereits die neuste Version (0.5.2-3).
»libzmq3-dev« ist bereits die neuste Version (4.1.4-7).
»libzmq5« ist bereits die neuste Version (4.1.4-7).
»libepoxy-dev« ist bereits die neuste Version (1.3.1-1ubuntu0.16.04.2).
»util-linux« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
»uuid-dev« ist bereits die neuste Version (2.27.1-6ubuntu3.3).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 47 nicht
aktualisiert.
g++ -c -I. -Iblock -Iboard -Icommon -Iimp -Ipackage -Ipool -Ischematic
-Iutil -Iconstraints -g3 -D_USE_MATH_DEFINES -fdata-sections
-ffunction-sections -pthread -std=c++11 -pthread -I/usr/include/uuid
-I/usr/include/gtkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gtkmm-3.0/include
-I/usr/include/atkmm-1.6 -I/usr/include/gtk-3.0/unix-print
-I/usr/include/gdkmm-3.0 -I/usr/lib/x86_64-linux-gnu/gdkmm-3.0/include
-I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include
-I/usr/include/pangomm-1.4
-I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include
-I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0
-I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient
-I/usr/include/mircore -I/usr/include/mircookie -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/cairomm-1.0
-I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include
-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include
-I/usr/include/cairo -I/usr/include/librsvg-2.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12
-I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12 -MP -MMD -pthread -Wall
-Wshadow -std=c++14 -O3 imp/imp.cpp -o imp/imp.o
imp/imp.cpp: In member function ‘bool
horizon::ImpBase::handle_click(GdkEventButton*)’:
imp/imp.cpp:498:20: error: ‘class Gtk::Menu’ has no member named
‘popup_at_pointer’
context_menu->popup_at_pointer((GdkEvent*)button_event);
^
imp/imp.cpp:516:19: error: ‘class Gtk::Menu’ has no member named
‘popup_at_pointer’
context_menu->popup_at_pointer((GdkEvent*)button_event);
^
Makefile:419: die Regel für Ziel „imp/imp.o“ scheiterte
make: *** [imp/imp.o] Fehler 1
Hm... das Problem ist wohl, dass
1 | context_menu->popup_at_pointer((GdkEvent*)button_event); |
erst ab libgtkmm 3.22 dabei ist. Ich hab' nur libgtkmm3.18.
Selbes Problem habe ich auch, ich versuche es auf openSUSE Leap42.3 zu bauen.
Hoppla, hab ich das wohl übersehen. Sollte nun funktionieren.
Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet: GtkFileChooserNative ist erst ab 3.20 dabei
1 | imp/imp_schematic.cpp: In member function ‘void horizon::ImpSchematic::handle_export_pdf()’: |
2 | imp/imp_schematic.cpp:123:3: error: ‘GtkFileChooserNative’ was not declared in this scope |
3 | GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF", |
4 | ^
|
5 | imp/imp_schematic.cpp:123:25: error: ‘native’ was not declared in this scope |
6 | GtkFileChooserNative *native = gtk_file_chooser_native_new ("Save PDF", |
7 | ^
|
8 | imp/imp_schematic.cpp:127:13: error: ‘gtk_file_chooser_native_new’ was not declared in this scope |
9 | "_Cancel"); |
10 | ^
|
11 | imp/imp_schematic.cpp:137:54: error: ‘GTK_NATIVE_DIALOG’ was not declared in this scope |
12 | if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) { |
13 | ^
|
14 | imp/imp_schematic.cpp:137:55: error: ‘gtk_native_dialog_run’ was not declared in this scope |
15 | if(gtk_native_dialog_run (GTK_NATIVE_DIALOG (native))==GTK_RESPONSE_ACCEPT) { |
16 | ^
|
17 | Makefile:419: die Regel für Ziel „imp/imp_schematic.o“ scheiterte |
18 | make: *** [imp/imp_schematic.o] Fehler 1 |
Brauche wohl ein Ubuntu 17.04 oder 17.10...
Ich baue grade openSUSE rpms, Tumbleweed geht schon, leap 42.3 baut gerade, und auch für Raspi (ARM). Unter openSUSE können die Binaries mit
1 | zypper ar https://download.opensuse.org/repositories/home:/frank_kunz/openSUSE_Tumbleweed/ horizon_repo |
2 | zypper ref |
3 | zypper in horizon |
installiert werden. Oder einfach yast nehmen. Zudem versuche ich mich an einem Appimage. Damit soll es möglich sein das Programm auf (nahezu) beliebigen Distros auszuführen, also so was ähnliches wie das Windows Package für Linux. Mal sehen ob es klappt. Die rpm Packages enthalten nur die kompilierten Binaries, der Pool und das Beispielprojekt muss separat von github geladen werden (wie im wiki beschrieben). Gruß, Frank ps: Benutzung auf eigene Gefahr.
tester schrieb: > Brauche wohl ein Ubuntu 17.04 oder 17.10... Ja ist natürlich etwas schade dass es für dich nun nicht funktioniert hat. Aber GTK 3.20 oder 3.22 sollte man schon haben, wenn man denn testen will. Viele Dinge waren vor 3.20 unspezifiziert, und 3.22 ist ja wohl nun auch schon seit ca. einem Jahr erhältlich und das ist ja praktisch auch die Langzeitversion, bis dann GTK4 kommt. Einen Hinweis welche GTK Version nötig ist hatte ich auf Lukas Seite so auf den ersten Blick auch nicht gesehen.
Läuft es bei dir durch? Ich habe noch mehr Probleme. Ist mein gcc zu alt? gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
1 | core/tool_move.cpp: In constructor ‘horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)’: |
2 | core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMove::ToolHelperMove()’ |
3 | ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) { |
4 | ^
|
5 | In file included from core/tool_move.hpp:3:0, |
6 | from core/tool_move.cpp:1: |
7 | core/tool_helper_move.hpp:5:8: note: ‘horizon::ToolHelperMove::ToolHelperMove()’ is implicitly deleted because the default definition would be ill-formed: |
8 | class ToolHelperMove : public virtual ToolBase { |
9 | ^
|
10 | core/tool_helper_move.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’ |
11 | In file included from core/tool_move.hpp:2:0, |
12 | from core/tool_move.cpp:1: |
13 | core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
14 | ToolBase(class Core *c, ToolID tid); |
15 | ^
|
16 | core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
17 | core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
18 | class ToolBase { |
19 | ^
|
20 | core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
21 | core/tool_move.cpp:14:58: error: use of deleted function ‘horizon::ToolHelperMerge::ToolHelperMerge()’ |
22 | ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) { |
23 | ^
|
24 | In file included from core/tool_move.hpp:4:0, |
25 | from core/tool_move.cpp:1: |
26 | core/tool_helper_merge.hpp:5:8: note: ‘horizon::ToolHelperMerge::ToolHelperMerge()’ is implicitly deleted because the default definition would be ill-formed: |
27 | class ToolHelperMerge: public virtual ToolBase { |
28 | ^
|
29 | core/tool_helper_merge.hpp:5:8: error: no matching function for call to ‘horizon::ToolBase::ToolBase()’ |
30 | In file included from core/tool_move.hpp:2:0, |
31 | from core/tool_move.cpp:1: |
32 | core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
33 | ToolBase(class Core *c, ToolID tid); |
34 | ^
|
35 | core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
36 | core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
37 | class ToolBase { |
38 | ^
|
39 | core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
40 | core/tool_move.cpp: In member function ‘void horizon::ToolMove::expand_selection()’: |
41 | core/tool_move.cpp:74:22: warning: unused variable ‘itv’ [-Wunused-variable] |
42 | for(const auto &itv: poly->vertices) { |
43 | ^
|
44 | Makefile:419: die Regel für Ziel „core/tool_move.o“ scheiterte |
45 | make: *** [core/tool_move.o] Fehler 1 |
gcc5 hat bei mir auch nicht funktioniert, mit gcc6-c++-6.2.1+r239768-6.19 geht es. Gruß, Frank
Mar. W. schrieb: > Das ist ein gutes Argument. Ich bin auch ehe dafür die Simulation mit > KiCAD weiterzutreiben und dort zu investieren, als noch ein neues > Programm aufzuziehen. Eine Simulation die aus dem PCB-Programm kommt und nicht alle benötigten SPICE-Modelle bereits kennt hat verloren. Die Pin-Reihenfolge in einem SPICE-Modell(subcircuit) hat überhaupt nichts mit der Pin-Reihenfolge des realen Bauteils zu tun. Selbst die Anzahl der Pins ist unterschiedlich. Ohne dieses Wissen, kann das PCB-Programm keine vernünftige Netzliste für SPICE generieren. Man müsste bereits beim Aufsetzen der Symbole im Schaltplan-Programm auch die Pins des SPICE-Modells definieren. Daran scheitern schon die meisten die wenig über SPICE wissen. So etwas kann man z. B. in der Software von Cadence und Mentor machen. KiCad hat dazu vermutlich überhaupt nichts vorgesehen. Lukas sollte die komplette Zeit in das PCB-Programm, den Schaltplaneditor und in den Bauteileeditor investieren und besser keine Zeit für Simulationstools investieren.
Hallo, mit gcc6-c++-6.2.1+r239768-6.19 bekomme ich den Fehler:
1 | [ 341s] core/tool_move.cpp: In constructor 'horizon::ToolMove::ToolMove(horizon::Core*, horizon::ToolID)': |
2 | [ 341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMove::ToolHelperMove()' |
3 | [ 341s] ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
|
4 | [ 341s] ^ |
5 | [ 341s] In file included from core/tool_move.hpp:3:0, |
6 | [ 341s] from core/tool_move.cpp:1: |
7 | [ 341s] core/tool_helper_move.hpp:5:8: note: 'horizon::ToolHelperMove::ToolHelperMove()' is implicitly deleted because the default de |
8 | finition would be ill-formed: |
9 | [ 341s] class ToolHelperMove : public virtual ToolBase {
|
10 | [ 341s] ^~~~~~~~~~~~~~ |
11 | [ 341s] core/tool_helper_move.hpp:5:8: error: no matching function for call to 'horizon::ToolBase::ToolBase()' |
12 | [ 341s] In file included from core/tool_move.hpp:2:0, |
13 | [ 341s] from core/tool_move.cpp:1: |
14 | [ 341s] core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
15 | [ 341s] ToolBase(class Core *c, ToolID tid); |
16 | [ 341s] ^~~~~~~~ |
17 | [ 341s] core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
18 | [ 341s] core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
19 | [ 341s] class ToolBase {
|
20 | [ 341s] ^~~~~~~~ |
21 | [ 341s] core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
22 | [ 341s] core/tool_move.cpp:14:58: error: use of deleted function 'horizon::ToolHelperMerge::ToolHelperMerge()' |
23 | [ 341s] ToolMove::ToolMove(Core *c, ToolID tid): ToolBase(c, tid) {
|
24 | [ 341s] ^ |
25 | [ 341s] In file included from core/tool_move.hpp:4:0, |
26 | [ 341s] from core/tool_move.cpp:1: |
27 | [ 341s] core/tool_helper_merge.hpp:5:8: note: 'horizon::ToolHelperMerge::ToolHelperMerge()' is implicitly deleted because the default |
28 | definition would be ill-formed: |
29 | [ 341s] class ToolHelperMerge: public virtual ToolBase {
|
30 | [ 341s] ^~~~~~~~~~~~~~~ |
31 | [ 341s] core/tool_helper_merge.hpp:5:8: error: no matching function for call to 'horizon::ToolBase::ToolBase()' |
32 | [ 341s] In file included from core/tool_move.hpp:2:0, |
33 | [ 341s] from core/tool_move.cpp:1: |
34 | [ 341s] core/core.hpp:86:4: note: candidate: horizon::ToolBase::ToolBase(horizon::Core*, horizon::ToolID) |
35 | [ 341s] ToolBase(class Core *c, ToolID tid); |
36 | [ 341s] ^~~~~~~~ |
37 | [ 341s] core/core.hpp:86:4: note: candidate expects 2 arguments, 0 provided |
38 | [ 341s] core/core.hpp:84:8: note: candidate: horizon::ToolBase::ToolBase(const horizon::ToolBase&) |
39 | [ 341s] class ToolBase {
|
40 | [ 341s] ^~~~~~~~ |
41 | [ 341s] core/core.hpp:84:8: note: candidate expects 1 argument, 0 provided |
42 | [ 341s] core/tool_move.cpp: In member function 'void horizon::ToolMove::expand_selection()': |
43 | [ 341s] core/tool_move.cpp:74:22: warning: unused variable 'itv' [-Wunused-variable] |
44 | [ 341s] for(const auto &itv: poly->vertices) {
|
45 | [ 341s] ^~~ |
46 | [ 343s] Makefile:419: recipe for target 'core/tool_move.o' failed |
47 | [ 343s] make: *** [core/tool_move.o] Error 1 |
48 | [ 343s] make: *** Waiting for unfinished jobs.... |
Gruß, Frank
Lukas K. schrieb: > Warum schreit keiner, dass ERC noch vollständig fehlt, Weil ein gut durchlaufender ERC aus Sicht eines Anwenders oft mehr Arbeit macht als er Nutzen bringt. Was ist denn ein Pin eines Steckverbinders, ist es eine Signalquelle, eine Signalsenke, oder ist es vielleicht eine daran zugeführte Versorgungsspannung? Ist ein Pin an einem Mikrocontroller eine Signalquelle oder -senke, oder vielleicht beides? Solange ein 7400 zwei Eingänge und einen Ausgang pro Gatter hatte, war die Welt da noch einfach. Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch tatsächlich an die Verbindung angeschlossen worden ist oder nicht. Aus der Zeit, in der ich mal mit Eagle gearbeitet habe, habe ich noch in Erinnerung, dass man das dort nicht richtig gesehen hatte und es einem daher passieren konnte, dass man ein „in der Luft hängendes“ Pin produziert hat. (Das ist aber sehr lange her, ich hoffe mal, dass neuere Eagle-Versionen da besser geworden sind.) Das war eigentlich einer der wesentlichen Punkte, wo der ERC mal hilfreich war, einem die gar nicht angeschlossenen Pins zu benennen.
Angehängte Dateien:
-
2017-10-24-223943_222x139_scrot.png
801 Bytes
Das mit den Konstruktoren ist repariert, kommt wohl davon, wenn man nur auf Arch Linux und MSYS2 baut, die beide doch recht "bleeding edge" sind. Mit gcc 7.2 und clang 5 baute es auch schon so... tester schrieb: > Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet: > GtkFileChooserNative ist erst ab 3.20 dabei Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt... Du könntest mal versuchen, den commit bei dir zu reverten: https://github.com/carrotIndustries/horizon/commit/28779193432251564b054de65118561d3575ce84 Re DRC: Mir Schwebte vor im Zuge von DRC zu Implementieren, dass man die elektrische Richtung von Pins im Schaltplan überschreiben kann, eben für Mikrocontroller und Steckverbinder. Steht und fällt natürlich mit der Sorgfalt und Motivation des Anwenders... Frank K. schrieb: > Ich baue grade openSUSE rpms, Tumbleweed geht schon, leap 42.3 baut > gerade, und auch für Raspi (ARM). Schick, auch wenn es meines Erachtens noch ein wenig zu früh für RPM-Pakete ist, aber jeder so wie er will :) Horizon wird wahrscheinlich nicht auf dem Raspberry PI laufen, da der Renderer OpenGL 3 braucht. Jörg W. schrieb: > Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch > tatsächlich an die Verbindung angeschlossen worden ist oder nicht. Siehe Anhang, sollte deutlich genug sein ;) Eagle, KiCad und bestimmt einige andere Programme stellen Verbindung im Schaltplan her, indem Pin und Linie auf dem selben Punkt liegen. Damit öffnet man natürlich solchen Problemen Tür und Tor. Bei horizon kann das prinzipiell nicht auftreten, da die Linie "weiß", mit welchen Pin von welchem Symbol sie verbunden ist.
Lukas K. schrieb: >> Wichtig ist, dass man ordentlich erkennt, ob ein Bauteilpin auch >> tatsächlich an die Verbindung angeschlossen worden ist oder nicht. > > Siehe Anhang, sollte deutlich genug sein ;) Eagle, KiCad und bestimmt > einige andere Programme stellen Verbindung im Schaltplan her, indem Pin > und Linie auf dem selben Punkt liegen. Damit öffnet man natürlich > solchen Problemen Tür und Tor. Naja, solange da so ein kleines Viereck ist, welches beim Anschließen der Linie verschwindet, funktioniert das durchaus (so kenne ich es von BAE, so macht es auch KiCad). Bei Eagle erinnere ich mich dran, dass es da irgendwie (damals) kein derartiges Kennzeichen gab, damit war das immer problematisch. > Bei horizon kann das prinzipiell nicht auftreten, da die Linie "weiß", > mit welchen Pin von welchem Symbol sie verbunden ist. Naja, aber irgendwoher muss die Linie das ja "wissen", also irgendwann muss der Benutzer sie das erste Mal mit dem Pin verbunden haben. Da ist ja der springende Punkt.
Ich habe früher mit Protel Advanced Schematic einiges gemacht, da gab es eine direkte Integration des PLD-Entwurfs mit Verbindung des Pinnings zwischen PLD und PSB, Übergabe an das design tool / den PLD-Compiler und vor allem einen Netzlisten-Export im SPICE-Format. Simuliert wurde das in MicroSIM pSPICE. Sicher hat es nicht für alles ein Modell gegeben und nicht bei jeder Schaltung macht eine Simulation Sinn, aber der Vorteil eines integrierten tools mit Schnittstellen an die einschlägigen Simulatoren ist sehr vorteilhaft im Sinne eines Master-Designs. Du konntest also die digitale Schaltung komplett in einem tool bauen und Dich dann entscheiden, was davon ins PLD gezogen wird. Unschätzbar nützlich, um vorhandene Digitalschaltungen zu importieren und auf PLDs zu bringen. Das war der Stand Mitte/Ende der 90er! Etwas später wurde dann MicroSIM von Orchad gekauft und die haben ihr eigenes SCH drübergestülpt, allerdings ohne einen PLD Entwurf. Parallel ist Protel in Altium aufgegangen, wieder ohne PLD oder gar FPGA tool. Ab da haben sich auch die FPGA tools losgelöst und verselbständigt und ihre eigenen Editoren gehabt. Ich erinnere mich noch gut an mein erstes Xilnx4000 design. Possetitjel schrieb: > Mikrocontroller oder FPGAs sind aber das genaue Gegenteil von > diskreten Bauelementen. Der klassische Schaltplan ist also für > diese Schaltungsteile vielleicht gar nicht die optimale > Darstellungsform. Da bin Ich ganz bei Dir und das propagieren FPGA-Entwickler schon seit einer Dekade! FPGA Entwicklung passiert 1 Abstraktionsebene und damit mindestens einen Layer weiter oben als der Schaltplan. Von daher sind Schaltplantools immer eine Beschränkung. > Wünschenswert wäre vielleicht, dass man auch Daten in > tabellarischer Form (Pinbelegungen z.B.) in die Software > hineinfüttern kann. Genau das passiert auch. Mentor's HDL-Designer unterstützt das z.B. - nennt sich "interface based design", man beginnt mit den Ports. Leider ist das nicht integral in beide Richtungen mit der Entity-Verwaltung verknüpft. Da bräuchte man schon was anderes. Da ist Simulink z.B. weiter, indem es alle denkbaren Blöcke, wie C, embedded MATLAB / VHDL jeweils als Design halten kann. Leider hat das wieder andere Einschränkungen.
Lukas, ich hatte gestern abend auch mal versucht es zu kompilieren. Leider lässt sich bei mir derzeit zmqpp wegen https://bugs.gentoo.org/628200 nicht installieren. Ich werde demnächst da mal nachfragen und es dann später erneut versuchen.
Stefan S. schrieb: > Lukas, ich hatte gestern abend auch mal versucht es zu kompilieren. > > Leider lässt sich bei mir derzeit zmqpp wegen > > https://bugs.gentoo.org/628200 > > nicht installieren. Ich werde demnächst da mal nachfragen und es dann > später erneut versuchen. Das sind die falschen C++-Bindings. Ich brauche nur die zmq.hpp aus https://github.com/zeromq/cppzmq Bei Arch ist die schon im zeromq-Paket mit drin.
Weiter vorne im Thread hatte ja schonmal jemand bemängelt, dass keine Binary-Pakete verfügbar sind. Mach bitte nicht den Fehler wie viele andere OSS Entwickler, dass die zu sehr auf die Inputs von anderen Entwicklern geben, anstatt die Anwender von vorneherein im Focus zu haben. Ein potentieller Anwender braucht aber niederschwelligen Zugang zu dem Programm, indem er sich einfach ein Binärpaket ziehen kann. GitHub bietet Integration von TravisCI, etc., da kann man leicht automatische Builds und Bereitstellung als "Releases" (im Github-Sinne) realisieren. Tu deiner tollen Entwicklungsarbeit diesen Gefallen.
Lukas K. schrieb: > Das sind die falschen C++-Bindings. Ach. Erfolgreich installiert hatte ich schon net-libs/zeromq-4.2.2-r2:0/5::gentoo und net-libs/cppzmq-0_pre150606::gentoo Aber damit bekomme ich
1 | imp/imp.cpp: In constructor ‘horizon::ImpBase::ImpBase(const string&)’: |
2 | imp/imp.cpp:24:42: error: no matching function for call to ‘zmq::socket_t::connect(std::__cxx11::basic_string<char>&)’ |
3 | sock_broadcast_rx.connect(ep_broadcast); |
4 | ^ |
5 | In file included from imp/imp.hpp:18:0, |
6 | from imp/imp.cpp:1: |
7 | /usr/include/zmq.hpp:405:21: note: candidate: void zmq::socket_t::connect(const char*) |
8 | inline void connect (const char *addr_) |
9 | ^~~~~~~ |
10 | /usr/include/zmq.hpp:405:21: note: no known conversion for argument 1 from ‘std::__cxx11::basic_string<char>’ to ‘const char*’ |
11 | imp/imp.cpp:36:43: error: expected primary-expression before ‘int’ |
12 | int fd = sock_broadcast_rx.getsockopt<int>(ZMQ_FD); |
13 | ^~~ |
14 | imp/imp.cpp: In lambda function: |
15 | imp/imp.cpp:41:40: error: expected primary-expression before ‘int’ |
16 | while(sock_broadcast_rx.getsockopt<int>(ZMQ_EVENTS) & ZMQ_POLLIN) {
|
17 | ^~~ |
18 | imp/imp.cpp:41:40: error: expected ‘)’ before ‘int’ |
19 | imp/imp.cpp:41:43: error: expected unqualified-id before ‘>’ token |
20 | while(sock_broadcast_rx.getsockopt<int>(ZMQ_EVENTS) & ZMQ_POLLIN) {
|
21 | ^ |
22 | imp/imp.cpp:645:1: error: expected ‘}’ at end of input |
23 | } |
24 | ^ |
25 | imp/imp.cpp: In constructor ‘horizon::ImpBase::ImpBase(const string&)’: |
26 | imp/imp.cpp:645:1: error: expected ‘)’ at end of input |
27 | imp/imp.cpp:645:1: error: expected ‘}’ at end of input |
28 | imp/imp.cpp:645:1: error: expected ‘}’ at end of input |
29 | imp/imp.cpp: At global scope: |
30 | imp/imp.cpp:645:1: error: expected ‘}’ at end of input |
31 | make: *** [Makefile:419: imp/imp.o] Error 1 |
Deshalb dachte ich, dass vielleicht net-libs/zmqpp-4.1.2::gentoo fehlt, welches ich nicht installieren konnte. Mit c++ Fehlermeldungen habe ich so meine Probleme, was da z.B. bei CGAL kam war für mich nicht nachvollziehbar. Aber ich will dich nicht von der Arbeit abhalten, ich habe im moment eh nicht die Zeit mich mit Horizon näher zu beschäftigen.
Stefan S. schrieb: > net-libs/cppzmq-0_pre150606::gentoo In dieser doch recht alten Version ist connect noch nicht für std::string überladen, das kam erst in diesem commit: https://github.com/zeromq/cppzmq/commit/34c8e4395c94d34a89bbeaaf2b8f9c94a8293c84 Da musst du wohl den Maintainer anstupsen, dass der das mal aktualisiert... me@example.com schrieb: > Weiter vorne im Thread hatte ja schonmal jemand bemängelt, dass keine > Binary-Pakete verfügbar sind. Für Windows gibt es welche, siehe wiki. Bei den Linuxen scheitert's ja mehr daran, dass einige Distros zu alte Versionen von Abhängigkeiten mitbringen, da helfen auch Binärpakete nicht viel.
Lukas K. schrieb: > tester schrieb: >> Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet: >> GtkFileChooserNative ist erst ab 3.20 dabei > Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative > umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei > Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt... Das war jetzt eher ein Feedback und keine Kritik. Ich finde es ja toll, dass du so ein Projekt stemmst und weiter machst. Feedback halt nur, dass z.Zt. die Benutzer von 16.04 LTS außen vor sind, da ich jetzt keine sinnvolle Möglichkeit gefunden habe, gtk 3.22 parallel zu installieren. Und das ganze gtk Subsystem auszutauschen ist mir zu riskant. Mein Hauptrechner hat eigentlich immer die LTS drauf, mein Hauptnotebook z.Zt. Mint 18.2. Leider ist das auch nicht aktuell genug. Ich habe noch ein Core2Duo mit 2 GB, denn könnte ich mal updaten, evtl. sogar mal Arch. Aber meine beiden Hauptrechner (beide i7, einmal Desktop und einmal Notebook, da will ich nicht unbedingt viel mit dem Core2Duo rummachen) sind halt im Moment nicht in der Lage horizon zu kompilieren. Gut ich könnte die Windows Version von horizon probieren, aber eigentlich will ich das nicht... Linux ist halt meine Hauptarbeitsplatform.
tester schrieb: > Lukas K. schrieb: >> tester schrieb: >>> Es werden wohl noch mehr Funktionen von >gtkmm3.18 verwendet: >>> GtkFileChooserNative ist erst ab 3.20 dabei >> Uff, ich hatte erst vor kurzem alle Filechooser auf GtkFileChooserNative >> umgebaut, damit die Windows-Fraktion auch ihren gewohnten "Datei >> Öffnen"-Dialog bekommt. Gtk 3.20 ist jetzt auch schon über 1 Jahr alt... > > Das war jetzt eher ein Feedback und keine Kritik. Ich finde es ja toll, > dass du so ein Projekt stemmst und weiter machst. Feedback halt nur, > dass z.Zt. die Benutzer von 16.04 LTS außen vor sind, da ich jetzt keine > sinnvolle Möglichkeit gefunden habe, gtk 3.22 parallel zu installieren. > Und das ganze gtk Subsystem auszutauschen ist mir zu riskant. Probier mal den Patch im Anhang anzuwenden, dann sollte es auch mit Gtk 3.18 funktionieren. Oder du wartest einfach bis zum nächsten LTS, dann ist horizon auch schon weiter ;)
Hallo, Ich habe da noch mal ein build Problem:
1 | [ 497s] widgets/parameter_set_editor.cpp: In lambda function: |
2 | [ 497s] widgets/parameter_set_editor.cpp:135:80: error: 'class Gtk::Popover' has no member named 'popdown' |
3 | [ 497s] dynamic_cast<Gtk::Popover*>(popover_box->get_ancestor(GTK_TYPE_POPOVER))->popdown(); |
4 | [ 497s] ^~~~~~~ |
5 | [ 499s] Makefile:419: recipe for target 'widgets/parameter_set_editor.o' failed |
6 | [ 499s] make: *** [widgets/parameter_set_editor.o] Error 1 |
7 | [ 499s] make: *** Waiting for unfinished jobs.... |
Gruß, Frank
Frank K. schrieb: > dynamic_cast<Gtk::Popover*>(popover_box->get_ancestor(GTK_TYPE_POPOVER)) ->popdown(); > [ 497s] Ist repariert.
Ja, für cppzmq hatte ich ein aktuelles ebuild gefunden. Aber nun kommt
1 | canvas/canvas_gl.cpp:243:42: warning: already captured ‘this’ in lambda expression |
2 | auto dfn = [this, target_in_selection, this](const Target &ta) -> float{
|
3 | ^~~~ |
4 | canvas/canvas_gl.cpp: In instantiation of ‘horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> [with auto:2 = horizon::Target]’: |
5 | /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/predefined_ops.h:241:11: required from ‘bool __gnu_cxx::__ops::_Iter_pred<_Predicate>::operator()(_Iterator) [with _Iterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)>]’ |
6 | /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:104:42: required from ‘_InputIterator std::__find_if(_InputIterator, _InputIterator, _Predicate, std::input_iterator_tag) [with _InputIterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = __gnu_cxx::__ops::_Iter_pred<horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> >]’ |
7 | /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:161:23: required from ‘_Iterator std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = __gnu_cxx::__ops::_Iter_pred<horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)> >]’ |
8 | /usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/include/g++-v6/bits/stl_algo.h:3817:28: required from ‘_IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = std::_Rb_tree_const_iterator<horizon::Target>; _Predicate = horizon::CanvasGL::cursor_move(GdkEvent*)::<lambda(const auto:2&)>]’ |
9 | canvas/canvas_gl.cpp:208:139: required from here |
10 | canvas/canvas_gl.cpp:208:109: error: cannot call member function ‘bool horizon::Canvas::layer_is_visible(int) const’ without object |
11 | const auto &f = std::find_if(targets.begin(), targets.end(), [t, this](const auto &a)->bool{return a.p==t && layer_is_visible(a.layer);});
|
12 | |
13 | make: *** [Makefile:419: canvas/canvas_gl.o] Error 1 |
Keine Ahnung was das genau ist. Und eigenlich ist mein Gentoo-Linux schon recht aktuell.
Selbiges Problem habe ich auch, mit der 34fc55078949d3b2989deb5abf0b0c27fe355a82 ging es noch. Gruß, Frank Edit: Hatte ich, mit 8e1f6aa geht kompilieren wieder.
Hallo Lukas, ich habe Probleme beim Leitungverlegen mit Vias. Ich bekomme es gerade nicht (mehr) hin an einem Stück Leitung - via - Leitung zu ziehen.. x Leitung ziehen v Via setzen 2 auf Lage 2 gehen Wie jetzt auf Lage 2 weiter machen? Bei mir fliegt mit LMB oder RMB das Via weg. Das wars dann leider. Gruß Helmut
Possetitjel schrieb: > Hältst Du es für denkbar, dass Deine Ansicht darüber, was ein > "free EDA package" können muss, NICHT die einzig richtige ist? Nö. > Habe ich das richtig verstanden: Es wäre das Beste für Lukas, > wenn er die Software programmieren würde, die W.S. gerne haben > will? Richtig. Sowas ist nicht wahlfrei - im Gegensatz zu persönlichen Vorlieben, also ob man z.B. Brünette mehr mag als Blondinen. Hier geht's um Softwarequalität und Benutzbarkeit - und die richtet sich danach, wie die Anwender damit klarkommen und was sie damit alles machen können ohne an die Grenzen zu stoßen. Also am tragfähigen und richtig umgesetzten Konzept. Das ist ein absolutes MUSS, sonst wird bis zu Lukas' Rente nix rechtes draus. Mich graust es bei der Gelegenheit lesen zu müssen, daß Lukas selber schreibt, daß er kein Konzept hat, weil dieses ja mit der Zeit veralten würde. Arc N. schrieb: > Warum? Wenn einem Kicad bspw. nicht gefällt, warum sollte man dann dort > Zeit investieren? Weil dort bereits einiges an Konzept und Software vorhanden ist, selbiges jedoch noch immer auf falsch gelegten Fundamenten steht. Es wäre allerdings abzuwägen, wieviel Arbeit inzwischen nötig ist, um Kicad in die richtige Richtung zu bringen und ob es nicht evtl. einfacher ist, selbiges einfach abzureißen und die Baugrube neu auszubaggern. Das ist eventuell dann doch ein Grund, was Neues aufzuziehen - aber dazu braucht's mehrere Leute oder nen fetten Sponsor - und natürlich das festgenagelte Konzept, sonst ist keine Zusammenarbeit möglich und jeder macht, was ihm grad einfällt. Possetitjel schrieb: > Ich vertrete aber die -- offenbar völlig veraltete -- Meinung, > dass die Software MIR dienen soll, und nicht umgekehrt ich die > Software loben, preisen und ihre Schlingen und Windungen besser > und besser studieren muss. Nun, ganz meine Ansicht. In diesem Punkt treffen wir uns. Lukas K. schrieb: > Warum schreit > keiner, dass ERC noch vollständig fehlt, man keine differentiellen > Leitungen routen kann, es keine Thermals in Flächen gibt, oder die > Darstellung von Pad-Namen im Board noch sehr zu wünschen Übrig lässt? Ganz einfach: Weil derartige Details einer späteren Maneuverkritik vorbehalten sind. Hier geht es (zumindest mir) zu allererst um die wirkliche Basis des Ganzen. Wenn man die systematische Herangehensweise nicht einhält, geht es einem wie Kicad: katastrophale Bibliotheks-Konzeption, keine Annotationen vor oder zurück, aber nen Push&Shove-Router basteln wollen. Lukas K. schrieb: > Wenn andere Programme (z.B. KiCad) nachwievor einen Schaltplaneditor > haben, der keine Ahnung von Netzen hat und den Anwender Junctions nach > Gutdünken platzieren lässt, aber schon dabei sind SPICE-Integration zu > entwickeln liegt meines Erachtens der Fokus bei der Entwicklung falsch. Sag ich doch! Sag ich doch die ganze Zeit. Ein wirklich gutes Konzept hingegen hält locker 20 Jahre. Man sieht das bei Eagle, wo selbst krassesten Einflußnahmen von Farnell und AD es schwer haben, das Programm kaputt zu machen. OK, AD hat es auf nichttechnische Weise jetzt wohl geschafft. Aber das ist ne andere Baustelle. Laß dir das Konzept von Eagle ruhig nochmal ganz gründlich durch den Kopf gehen: die innere Datenbank, die Skript/Kommandozeile, die Tool-Funktionalität. Ja, das sind alles keine Dinge, die an der sichtbaren Oberfläche glänzen, aber sie sind wesentlich für die gute Funktionalität. W.S.
W.S. schrieb: > Weil dort bereits einiges an Konzept und Software vorhanden ist, > selbiges jedoch noch immer auf falsch gelegten Fundamenten steht. Wenn du das logisch zu Ende denkst, würde es bedeuten, dass man das, was da ist, sowieso komplett einreißen müsste, um eben neue Fundamente zu setzen. Was ist da eigentlich dann der Unterschied zu einem neuen Programm? Ach ja, wenn schon neues Programm, dann könnte man ihm ja auch einen neuen Namen geben … wie wär's eigentlich mit "Horizon"? :-))
Angehängte Dateien:
Helmut S. schrieb: > Bei mir fliegt mit LMB oder RMB das Via weg. Das wars dann leider. Ah, das passiert wenn du in den Via-Rules keine Regel oder keine Regel mit Padstack hast. Du solltest mindestens eine Via-Regel haben, die auf alles matcht, so wie im Anhang.
Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-) Es kann hier herunter geladen werden: https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/ dann ausführbar machen und starten. Ich konnte es nicht auf verschiedenen Linux Distributionen testen daher keine Garantie dass es überall startet. Das AppImage ist dazu gedacht um horizon testen zu können ohne die Software selber kompilieren zu müssen, also nicht für den Produktiveinsatz. Gruß, Frank
Hallo Lukas, danke es klappt jetzt. Ich denke so ungefähr habe ich den "Dreh" jetzt heraus. Mist, gerade ESC gedrückt und "alles" ist weg. Ich glaube ich sollte diese ESC-Taste wegmachen. :-) Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft. Gruß Helmut
W.S. schrieb: > Possetitjel schrieb: >> Hältst Du es für denkbar, dass Deine Ansicht darüber, >> was ein "free EDA package" können muss, NICHT die einzig >> richtige ist? > > Nö. Naja, an Selbstbewusstsein mangelt es Dir jedenfalls nicht... :) >> Habe ich das richtig verstanden: Es wäre das Beste für >> Lukas, wenn er die Software programmieren würde, die W.S. >> gerne haben will? > > Richtig. > Sowas ist nicht wahlfrei - im Gegensatz zu persönlichen > Vorlieben, also ob man z.B. Brünette mehr mag als Blondinen. Doch -- aber auf einer anderen Ebene. > Hier geht's um Softwarequalität und Benutzbarkeit - und die > richtet sich danach, wie die Anwender damit klarkommen [...] Ja -- aber wo hat Lukas proklamiert, dass Du seine Software anwenden können sollst? Solange Lukas der einzige maßgebliche Anwender ist, ist seine Ansicht bindend. Das muss weder Dir noch mir gefallen, aber das ist einfach Fakt. > Mich graust es bei der Gelegenheit lesen zu müssen, daß > Lukas selber schreibt, daß er kein Konzept hat, weil > dieses ja mit der Zeit veralten würde. Naja ... ICH würde es auch anders machen. Lukas macht es eben so. Ich stimme Dir ja in der Sache zu -- aber das alles wird erst dann interessant, wenn Lukas explizit erklärt, dass seine Software für die Benutzung durch andere Leute gedacht ist. In seinem Vortrag gibt er als Motivation nur an: IHM gefiel die existierende Software nicht, und deshalb hat er angefangen, seine eigene zu schreiben. Da ist keine Rede davon, dass Horizon auch FÜR ANDERE LEUTE irgendwie nützlich und zweckmäßig sein soll. > Es wäre allerdings abzuwägen, wieviel Arbeit inzwischen > nötig ist, um Kicad in die richtige Richtung zu bringen > und ob es nicht evtl. einfacher ist, selbiges einfach > abzureißen und die Baugrube neu auszubaggern. Ich denke, dass diese Radikalität der falsche Ansatz ist. Die Welt ist nicht schwarz/weiss. > - und natürlich das festgenagelte Konzept, Konzept: Ja. Festgenagelt: Nein. Das Konzept sollte das Rückgrat des Ganzen sein: Tragfähig, aber dennoch flexibel. Das kann man nicht "vorher" ein für alle mal festlegen; das ist ein "moving target". > sonst ist keine Zusammenarbeit möglich und jeder macht, > was ihm grad einfällt. Hmm. Das kenne ich anders. > Ganz einfach: Weil derartige Details einer späteren > Maneuverkritik vorbehalten sind. Hier geht es (zumindest > mir) zu allererst um die wirkliche Basis des Ganzen. Ja. Der Punkt ist: Ich vermute, dass Lukas und Du die "wirkliche Basis des Ganzen" an völlig verschiedenen Stellen seht. Für mich wäre entscheidend, ob die Software für den Einsatz in einem Kleinunternehmen geeignet ist. Ausgangspunkte wären der Datenfluss und die Arbeitsabläufe. Konnektivität nach außen ("Interoperabilität") wäre für mich viel wichtiger als jeder Komfort innerhalb der Software. > Ein wirklich gutes Konzept hingegen hält locker 20 Jahre. Ich fürchte, Programmierer und Anwender verstehen unter "Konzept" VÖLLIG unterschiedliche Dinge. Ich glaube, dass hier das Grundübel liegt.
Helmut S. schrieb: > Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft. In der aktuellen Version tut nun ESC genau dasselbe wie Rechtsklick in Tools.
Lukas K. schrieb: > Helmut S. schrieb: >> Bitte diese Taste entschärfen. Die macht mehr kaputt als sie hilft. > > In der aktuellen Version tut nun ESC genau dasselbe wie Rechtsklick in > Tools. Hallo Lukas, danke habe es gleich ausprobiert. So gefällt mir die Funktion von ESC. Die nun mögliche Änderung der Farbe der Lagen und die Wahl zwischen Umrandung, schraffiert und gefüllt gefällt mir. Ist es beabsichtigt, dass beim verlegen von Leitungen die Zählweise 1 top, 2 bot, 3 inner-1 und 4 inner-2 ist? Ich habe damit kein Problem. Gruß Helmut
Helmut S. schrieb: > Ist es beabsichtigt, dass beim verlegen von Leitungen die Zählweise 1 > top, 2 bot, 3 inner-1 und 4 inner-2 ist? Ich habe damit kein Problem. Jep, das war so beabsichtigt, damit man Top und Bottom immer gleich bequem und schnell erreichen kann.
Hallo Lukas, ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen. Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert? Gruß Helmut
Helmut S. schrieb: > Hallo Lukas, > > ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen. > Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert? > > Gruß > Helmut Das ist momentan hardcoded. War nur eine Frage der Zeit, bis sich das jemand wünscht. Ich hab' mir das auch schon gelegentlich gewünscht, war bis jetzt aber immer zu faul das zu implementieren. Im EEVBlog-Forum wünschte man sich auch noch einstellbare Tastenkürzel. Wird so langsam wohl mal Zeit, dass der interaktive Manipulator einen Einstellungsdialog und Config-Datei bekommt...
Lukas K. schrieb: > Helmut S. schrieb: >> Hallo Lukas, >> >> ich würde gerne mal im PCB die Hintergrundfarbe auf schwarz stellen. >> Kann ich das in einer Config-Datei einstellen oder ist das hart kodiert? >> >> Gruß >> Helmut > > Das ist momentan hardcoded. > ... > War nur eine Frage der Zeit, bis sich das jemand wünscht. Hallo Lukas, Ich wünsche mir die Möglichkeit eine schwarzen Hintergrund zu haben. Ich finde den blauen Hintergrund anstrengend. Außerdem wünsche ich mir die die Möglichkeit Punkte statt '+' für das Grid zu wählen. Der erste Punkt mit dem schwarzen Hintergrund wäre mir jetzt erstmal wichtiger als der mit den Gridpunkten. Gruß Helmut
Helmut S. schrieb: > Ich wünsche mir die Möglichkeit eine schwarzen Hintergrund zu haben. Ich > finde den blauen Hintergrund anstrengend. Du verwechselst das hier womöglich mit einem Wunschkonzert? Was Lukas sich wünscht ist wahrscheinlich eher konstruktive Mitarbeit -- muss ja nicht gleich perfekter C++ Code sein, ein paar gute, ausformulierte Ideen und Algorithmen könnten wir auch gebrauchen...
Stefan S. schrieb
> Du verwechselst das hier womöglich mit einem Wunschkonzert?
Ich finde die Tester und Anwender sollten auch ihre Erfahrungen und
Wünsche einbringen dürfen. Natürlich habe ich erst mal kein Problem,
wenn Lukas seiner Vision die er für dieses Programm hat treu bleibt.
Ja gut, ich sollte in der Tat auch nicht für Lukas sprechen... Allerdings, bevor Dinge wie Farbwünsche wirklich Sinn machen sind wohl noch einige Tausend Stunden Arbeit nötig. Und Du hattest ja noch einige andere Wünsche geäussert. Was meinst Du Helmut, sollte man Bauteile tatsächlich in einer Datenbank verwalten, oder doch besser als einzelne Dateien? Die Frage stelle ich mit gerade, da ich die Kompatibilität mit dem gEDA/PCB Format wohl aufgeben werde. Und dann ist da natürlich die Frage, wie man Bauteile am besten definiert. Wie bei gEDA, wo alles mit einem Symbol startet, dem man dann u.a. den Footprint hinzufügt -- das gefiel mir nie so recht. Momentan denke ich an etwas, wo man mit den "Pins" beginnt, also etwa "VCC", "VEE", "+", "-", "Out" für einen OP. Dann irgendein Mapping um die Pins auf Schaltplansymbole und Footprints abzubilden., wobei natürlich Symbol- und Footprint-Varianten möglich sind. Etwa auch Symbole mit und ohne Power Pins. Ah -- Horizon hat gerade erfolgreich zuende kompiliert, hat aber ein paar Minuten dedauert. Mal sehen ob ich es starten kann.
Jörg W. schrieb: > Wenn du das logisch zu Ende denkst, würde es bedeuten, dass... Tja. Irgendwann ist quasi der PONR überschritten - jedenfalls bei der Fliegerei. Auch bei C sieht man das deutlich. Ich hatte das bei Kicad schon vor geraumer Zeit angemahnt, denk mal an die ewigen Diskussionen mit Bernd Wiebus, der noch immer nicht einsehen will, daß man in Schaltplänen logische Symbole hat und nicht Abbilder von DIL-Gehäusen und der partout nicht einsehen will, daß die Konsistenz zwischen SCH und BRD sowie Symbolen und Footprints was ganz Essenzielles ist. Kann jeder nachlesen in der Historie dieses Boards. Aber gehe du mal lieber nicht einfach nur mal so mit "Wenn..Dann"-Sätzen an das Problem heran. Womöglich kann man ne Menge mittleren Zeuges grad bei Kicad durchaus retten - aber dazu müßte man die Nase tief in die Quellen stecken - und ich tu's nicht, ich hab ja Eagle. Andererseits hat man durchaus ein Gefühl von Verantwortung dahingehend daß man den Leuten, die grad dabei sind Bockmist zu bauen, der hinterher nur noch schwer bis garnicht korrigierbar ist, SAGEN muß, daß sie grad Bockmist bauen. OK, manche fühlen sich dabei in ihrer Genialität auf den Schlips getreten - aber da muß unsereiner halt durch. W.S.
Possetitjel schrieb: > Ich fürchte, Programmierer und Anwender verstehen unter > "Konzept" VÖLLIG unterschiedliche Dinge. Ich glaube, dass > hier das Grundübel liegt. DAS ist eigentlich schon seit langem völlig klar und eigentlich auch jedermann bekannt. Geht mir im Prinzip als Programmierer und Anwender auch so: Die Sichtweise als Programmierer unterscheidet sich diametral von der Sichtweise des Anwenders. Und ganz besonders dann, wenn die Logiken auseinanderfallen. Siehe die Programmiersprache C oder der "WISSENSCHAFTLICHE" Sozialismus. Wenn man die Fundamente erstmal schief und falsch gelegt hat, kann man ganz wunderbar ein ganz schiefes und falsches, aber in sich konsistentes und schein-logisches Gebäude drauf errichten. Als Anwender (oder Bewohner) sieht man das anschließend sehr sehr SEHR viel anders. Was meinst du, weswegen ich hier so penetrant darauf herumhacke daß es allen anderen graust, zu allererst ein wirklich tragfähiges Konzept auszuarbeiten und schriftlich zu fixieren? Das ist überhaupt kein Spaß! W.S.
Und es läuft, Lukas! Ich sehe es mir dann in den nächsten Wochen mal genauer an. Ich bin gestern übrigens mal angefangen meinen Schaltplaneditor von Ruby nach Nim zu portieren. Sind leider doch ganze 6000 Zeilen, wird also etwas dauern.
Lukas K. schrieb: > Das ist momentan hardcoded. > > War nur eine Frage der Zeit, bis sich das jemand wünscht. Ich hab' mir > das auch schon gelegentlich gewünscht, war bis jetzt aber immer zu faul > das zu implementieren. Im EEVBlog-Forum wünschte man sich auch noch > einstellbare Tastenkürzel. > > Wird so langsam wohl mal Zeit, dass der interaktive Manipulator einen > Einstellungsdialog und Config-Datei bekommt... Merkst du jetzt was? Mit meinem Rufen nach dem Konzept komme ich mir inzwischen vor wie Cato d.Ä. W.S.
Stefan S. schrieb: > Was meinst Du Helmut, sollte man Bauteile tatsächlich in > einer Datenbank verwalten, oder doch besser als einzelne > Dateien? In einzelnen Dateien. Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien im Filesystem liest, gibt es eine Chance, eine externe Datenbank zu basteln, die die Bauteildaten verwaltet und passend für mehrere EDA-Pakete exportieren kann. Wenn jede EDA-Software seine eigene Datenbank mitbringt, ist Austauschbarkeit der Daten noch weiter erschwert. > Die Frage stelle ich mit gerade, da ich die Kompatibilität > mit dem gEDA/PCB Format wohl aufgeben werde. Schade. Noch jemand, dem Interoperabilität egal ist. Naja.
Im YT-Video erwähnt er eine SQLlite-Datenbank, die er aufbaut aus JSON-Dateien. Hm, also wenn Helmut sich die Sache näher ansieht, scheint es interessant zu sein und einen gewissen ersten Fortschritt inne zu haben. Nur wie lange wird die Sache weiterentwickelt? Lukas ist 23 und in dem Alter hat man abwechselnde Interessen. Ansonsten kann ich nur sagen, zumindest im Video sieht es schon gut aus. SkyOS war auch mal erwartungsvoll, da scheint die Frau mit Kind alles gestoppt zu haben. Ansonsten ist Entwiclung als Einmann-Team immer die effizienteste Form. Bis es dann eine gewisse Größe überschreitet. Falls es zu diesem Zeitpunkt dann zu unstruktiert ist, stirbt es unmittelbar.
Possetitjel schrieb: > In einzelnen Dateien. > > Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien > im Filesystem liest, gibt es eine Chance, eine externe > Datenbank zu basteln, die die Bauteildaten verwaltet und > passend für mehrere EDA-Pakete exportieren kann. > > Wenn jede EDA-Software seine eigene Datenbank mitbringt, > ist Austauschbarkeit der Daten noch weiter erschwert. > Ich hätte jetzt eher erwartet, dass die meisten eine Datenbank bevorzugen. Wobei ich bisher wenig Erfahrung mit Datenbanken habe, aber so schwierig ist deren Nutzung wohl nicht. >> Die Frage stelle ich mit gerade, da ich die Kompatibilität >> mit dem gEDA/PCB Format wohl aufgeben werde. > > Schade. Noch jemand, dem Interoperabilität egal ist. Naja. Nein, Interoperabilität war mir schon wichtig, daher hatte meine Ruby Version des Schaltplaneditors ja das gEDA-Format verwendet, und der Rubberband-Router das gEDA/PCB Format. Blos, wer benutzt denn momentan noch gEDA/PCB? Und selbst den gEDA/PCB Leuten gefiel ihr Format nicht wirklich. Mit einem bestimmten Dateiformat kompatibel zu bleiben ist nunmal ein Mehraufwand und eine Einschränkung. Als ich mit den Programmen vor einigen Jahren anfing, da gab es noch einige mehr gEDA/PCB Nutzer und ich hatte gedacht, dass von deren Seite auch etwas Interesse vorhanden wäre. Das KiCad Format kenne ich nicht. Lukas Dateiformate werde ich mir aber mal ansehen. Und Konverter kann man ja immer Schreiben, wenn es ein offenes Format ist. Das können sogar Leute mit wenig Programmierkenntnissen in der Sprache ihrer Wahl tun. Bei dem PCB-Format frage ich mich, wie weit man sich am XGerber-Format orientieren sollte. Natürlich nicht 1:1, XGerber ist ein LowLevel Format. Aber so ganz grundsätzlich kann man sich schon daran orientieren. Dass es etwa im wesentlichen Linien, Kreisbögen und Polygone gibt.
W.S. schrieb: > ich tu's nicht, ich hab ja Eagle Dann bleib doch einfach dabei. Ob andere „Bockmist“ bauen, diese Einschätzung darfst du gern mehr als nur dir überlassen. Auch wenn ich Horizon im Moment noch nicht selbst ausprobiert habe, scheint mir die Menge an Diskussion, die hier mittlerweile entsteht, keineswegs in diese Richtung zu gehen … An deinen Ansprüchen gemessen, würdest du vermutlich auch Altium Designer als „Bockmist“ abtun, weil es sich nicht so verhält wie Eagle.
Abdul K. schrieb: > Ansonsten ist Entwiclung als Einmann-Team immer die effizienteste Form. > Bis es dann eine gewisse Größe überschreitet. Falls es zu diesem > Zeitpunkt dann zu unstruktiert ist, stirbt es unmittelbar. Man sollte den Code unbedingt klein halten, dann können sich andere im Prinzip einarbeiten. KiCad und LibreCad haben wohl etwa beide ca. eine Million Zeilen C++ Code. Das ist schon fast Wahnsinn. Weiter oben hatte wohl jemand geschieben, dass Lukas momentan 27k Zeilen hat. Ich denke das geht noch, aber viel mehr sollte es auch nicht werden.
Da wird ganz sicher Faktor 10 noch rein gehen. Ein solches Programm ist schon heftig, wenn es denn auch die ganzen Feinheiten implementiert.
Stefan S. schrieb: > Weiter oben hatte wohl jemand geschieben, dass Lukas momentan 27k Zeilen > hat. Ich denke das geht noch, aber viel mehr sollte es auch nicht > werden. Wie soll das denn bitte funktionieren, wenn man die Funktionalität erweitern will?
Ratzfatz schrieb: > Wie soll das denn bitte funktionieren, wenn man die Funktionalität > erweitern will? Aufräumen!
Uff, so viel auf einmal: Irgendeine Art von "Einstellungen" war früher oder später eh geplant. Im letzten Jahr Entwicklung, in dem einziger "Anwender" ich war, war das eben nicht so wichtig. Jetzt wo auch andere Leute mit anderen Vorlieben das Programm benutzen wollen, braucht's das eben. Wenn Dialog und Infrastruktur erstmal da sind, finden sich auch recht schnell weitere Zwecke, die sinnvoll zu nutzen. Einzeldateien oder Datenbank? Beides! Einzeldateien sind gut geeignet um versionskontrolliert verwaltet zu werden, allerdings sucht's sich darin schlecht. Mit Datenbanken ist es genau umgekehrt. Daher sind die Primärquellen Einzeldateien, deren Metadaten dann lokal in eine Datenbank importiert werden. Die ganzen "Browser" im pool manager für Units, etc. sind dann eine recht dünne Schicht GUI über SQL. Das Dateiformat ist jetzt nichts besonderes. Die C++-Klassen werden einfach nach JSON serialisiert. Abdul K. schrieb: > Ansonsten kann ich nur sagen, zumindest im Video sieht es schon gut aus. Jetzt, einige Monate später, ist's noch besser ;)
Dann müßte er wohl von C++14 auf Forth umsteigen. Könnte mir vorstellen, daß er von dieser Sprache bei seinem Alter noch nie hörte.
Gute Arbeit, weiter so ... vielleicht noch die Leiterlängen dazunehmen :-)
Lukas K. schrieb: > Das Dateiformat ist jetzt nichts besonderes. Die C++-Klassen werden > einfach nach JSON serialisiert. ja, so wollte ich es jetzt auch machen. Damit macht man sich das Leben sehr einfach -- aber das ist dann natürlich zu nichts kompatibel. Eines noch: Die executables sind ja riesig! Gut, da ist wohl sämtlicher Debugging-Code enthalten, aber trotzdem:
1 | $ ls -l ../horizon/horizon-prj-mgr |
2 | -rwxr-xr-x 1 stefan stefan 63936488 Oct 28 20:54 ../horizon/horizon-prj-mgr |
3 | stefan@nuc ~/pet $ ls -l ../horizon/horizon-imp |
4 | -rwxr-xr-x 1 stefan stefan 176220480 Oct 28 20:53 ../horizon/horizon-imp |
Stefan S. schrieb: > Die executables sind ja riesig! Frag doch mal lieber mit "size" statt "ls -l". Ansonsten bekommst du die Größe aller Debug-Symbole (Strings, Namen etc.) mit.
Ach so...
1 | $ size ../horizon/horizon-prj-mgr |
2 | text data bss dec hex filename |
3 | 2624115 9736 11344 2645195 285ccb ../horizon/horizon-prj-mgr |
4 | stefan@nuc ~/pet $ size ../horizon/horizon-imp |
5 | text data bss dec hex filename |
6 | 5954953 41376 32568 6028897 5bfe61 ../horizon/horizon-imp |
Immer noch nicht ganz klein, aber drastisch kleiner als die Binaries. ;)
W.S. schrieb: > Ich hatte das bei Kicad schon vor geraumer Zeit angemahnt, > denk mal an die ewigen Diskussionen mit Bernd Wiebus, der > noch immer nicht einsehen will, daß man in Schaltplänen > logische Symbole hat und nicht Abbilder von DIL-Gehäusen Ja, überwiegend ist das so. > und der partout nicht einsehen will, daß die Konsistenz > zwischen SCH und BRD sowie Symbolen und Footprints was > ganz Essenzielles ist. Wie das? Das (allgemeine) Symbol eines npn-Transistors hat keinen Footprint. Und -- nein, ich will NICHT wählen müssen, ob das ein BF199 oder eine 2N3904 sein soll, wenn ich den SCHALTPLAN zeichne. > Womöglich kann man ne Menge mittleren Zeuges grad bei > Kicad durchaus retten - aber dazu müßte man die Nase tief > in die Quellen stecken - und ich tu's nicht, ich hab ja > Eagle. Naja, das verstehe ich -- aber dann hat es wenig Sinn, zu meckern. > Andererseits hat man durchaus ein Gefühl von Verantwortung > dahingehend daß man den Leuten, die grad dabei sind Bockmist > zu bauen, der hinterher nur noch schwer bis garnicht > korrigierbar ist, SAGEN muß, daß sie grad Bockmist bauen. Das Problem des Rechthabers ist nicht, dass er Unrecht hätte -- das Problem des Rechthabers ist, dass ihm niemand mehr zuhört! Außerhalb akademischer Kreise will es niemand haben, dass Du (nur) ein PROBLEM aufwirfst. Entweder Du kannst die Lösung für das Problem umsetzen, oder Du spielst das Spiel mit, das andere vorgeben, egal, wie falsch Dir das scheint. Einen Mittelweg sehe ich nicht.
In der aktuellen Version funktioniert nun dank gepatchtem Gtk die 3D-Vorschau auch auf Windows. Possetitjel schrieb: > Und -- nein, ich will NICHT wählen müssen, > ob das ein BF199 oder eine 2N3904 sein soll, wenn ich den > SCHALTPLAN zeichne. Horizon kann genau das. Man kann ohne "Part" anfangen und später mit "assign Part" dem "Component" ein "Part" zuweisen. Nachträglich kann man natürlich das Part auch austauschen.
Ich habe hier nicht alles gelesen, aber bezüglich der Simulation wollte ich noch kurz was einwerfen: Obwohl ich Altium zur Verfügung habe und das auch Simulieren kann, nutze ich noch immer viel lieber LTSpice für analoge Geschichten. Man kann sowieso nur selten die komplette Schaltung simulieren - man simuliert nur die kritischen Teile davon. Das sieht dann teilweise auch ganz anders aus als im Schaltplan fürs Layout weil man viel experimentiert... Also es ist absolut nicht essentiell da Spice einzubauen. Das geht auch extern. Für HF-Kram gibts dann wieder andere Tools...
Stefan S. schrieb: > Possetitjel schrieb: >> In einzelnen Dateien. >> >> Wenn die EDA-Software die Bauteildaten aus einzelnen Dateien >> im Filesystem liest, gibt es eine Chance, eine externe >> Datenbank zu basteln, die die Bauteildaten verwaltet und >> passend für mehrere EDA-Pakete exportieren kann. >> >> Wenn jede EDA-Software seine eigene Datenbank mitbringt, >> ist Austauschbarkeit der Daten noch weiter erschwert. >> > > Ich hätte jetzt eher erwartet, dass die meisten eine Datenbank > bevorzugen. Das tue ich ja auch. Ich will nur keine Datenbank, die spezifisch für DIESE EDA-SOFTWARE ist! Ich will genausowenig, dass die EDA-Software eine eigene Versions- verwaltung mitbringt. Ich will, dass die Userdaten, die ich mit der EDA-Software produziere, mit DER externen Versionsverwaltung verwaltet werden können, die ICH auswähle. > Nein, Interoperabilität war mir schon wichtig, daher hatte > meine Ruby Version des Schaltplaneditors ja das gEDA-Format > verwendet, Ohh. Deinen Schaltplaneditor habe ich irgendwie übersehen. > Mit einem bestimmten Dateiformat kompatibel zu bleiben ist > nunmal ein Mehraufwand und eine Einschränkung. Ja: Kompatibilität ist eine Einschränkung für den Programmierer. Inkompatibilität ist eine Einschränkung für den Nutzer. Wenn wir uns die Unmenge inkompatibler Software ansehen, wissen wir, wer das Sagen hat. > Als ich mit den Programmen vor einigen Jahren anfing, da gab > es noch einige mehr gEDA/PCB Nutzer und ich hatte gedacht, > dass von deren Seite auch etwas Interesse vorhanden wäre. Ja... das war wohl einfach Pech. > Und Konverter kann man ja immer Schreiben, wenn es ein > offenes Format ist. Das können sogar Leute mit wenig > Programmierkenntnissen in der Sprache ihrer Wahl tun. Ja, das ist ein Anfang, und darauf wird es wohl vorläufig hinauslaufen. Der nächste Schritt wäre aus meiner Sicht, dass es eine generische Software gibt, die z.B. Schaltplansymbole und Footprints verwaltet und diese in allen in Frage kommenden Formaten exportieren kann (gEDA, KiCAD, horizon, Fritzing...:) > Bei dem PCB-Format frage ich mich, wie weit man sich am > XGerber-Format orientieren sollte. Natürlich nicht 1:1, > XGerber ist ein LowLevel Format. Aber so ganz grundsätzlich > kann man sich schon daran orientieren. Dass es etwa im > wesentlichen Linien, Kreisbögen und Polygone gibt. Hauptpunkt ist mMn das abstrakte Datenmodell, das dahinter- steht. Wenn die einen eine turing-vollstände Beschreibungs- sprache nehmen und die anderen Bitmaps, dann werden auch Konverter zur Herausforderung.
Jörg W. schrieb: > Ob andere „Bockmist“ bauen, diese Einschätzung darfst du > gern mehr als nur dir überlassen. Nun... W.S. steht zumindest nicht völlig allein mit seiner Meinung. Auch Lukas scheint dieser Ansicht zu sein -- sonst hätte er sein Projekt ja nicht angefangen... :) > An deinen Ansprüchen gemessen, würdest du vermutlich auch > Altium Designer als „Bockmist“ abtun, Zum Teil, ja. > weil es sich nicht so verhält wie Eagle. Nee, deshalb nicht.
Possetitjel schrieb: > Auch Lukas scheint dieser Ansicht zu sein -- sonst hätte er sein Projekt > ja nicht angefangen... :) W.S. bezog diese seine Kritik allerdings auf Lukas. > Nee, deshalb nicht. Bei W.S. schon, ist ja nicht das erste Mal, dass er das propagiert. Alles, was nicht den gleichen Workflow hat wie Eagle ist bei ihm halt „Bockmist“. Das ist zumindest der Eindruck, den ich über die Jahre gewonnen habe.
Angehängte Dateien:
-
3D.jpg
74 KB
Lukas schrieb:
> In der aktuellen Version funktioniert nun dank gepatchtem Gtk die
3D-Vorschau auch auf Windows.
Hallo Lukas,
das sieht ja richtig gut aus. Speziell das "Explode" finde ich cool. Auf
diese Art, kann man sehr anschaulich zeigen was in der Leiterplatte
passiert. Eine echte Bereicherung speziell auch für den
Ausbildungsbereich. Auf dem Bildschirm sieht das durch die Möglichkeit
die Platine in 3D zu drehen/kippen/schieben noch viel schöner aus.
Danke nochmals für die Bereitstellung von Binaries für Windows. Damit
bist du anderen Open-Source Projekten weit voraus. Bei Octave hat es 15
Jahr gedauert bis es offizielle Windows-Binaries gab.
Gruß
Helmut
Frank K. schrieb: > Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-) > > Es kann hier herunter geladen werden: > https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/ > > dann ausführbar machen und starten. Ich konnte es nicht auf > verschiedenen Linux Distributionen testen daher keine Garantie dass es > überall startet. > > Das AppImage ist dazu gedacht um horizon testen zu können ohne die > Software selber kompilieren zu müssen, also nicht für den > Produktiveinsatz. > > Gruß, > Frank Hallo Frank, Ich habe heute eines deiner Iamges auf Ubuntu 17.10 gestart. Es geht ein Fenster von horizon auf und dann kommt in einer box die Fehlermeldung Gtk-Message: Failed to load module "canberra-gtk-module". Kann jemand einem Linux-Laien wie mir sagen wie und von wo ich das fehlende Gtk installieren kann. Auf der Entwickler-Webseite von Gtk gibt es nur "sourcen" zum selber kompilieren. Gruß Helmut
Ubuntu 17.10 Bin jetzt einen Schritt weiter. GTK3 von hier installiert. https://launchpad.net/ubuntu/bionic/amd64/gir1.2-gtk-3.0/3.22.25-0ubuntu1 Die Fehlermeldung ist jetzt weg.Ich kann das Demo-Layout von Lukas laden und bearbeiten. Neue Probleme: 1. Die Planes werden trotz "Update Planes" nicht gefüllt dargestellt. Ist das ein Problem meiner Grafikkarte (GTX260)? 2. 3D Ansicht Beim Anklicken von 3D zerbröselt es die Grafik im Layoutfenster. Fehlt dafür noch eine weitere Software?
Hallo Helmut, Die Idee der AppImages ist dass Du nichts zusätzlich installieren musst, das Image sollte alle nötigen libs, etc. enthalten. Ich habe canberra-gtk-module noch hinzugefügt, der Build lauft gerade. Sollte so bis in ein paar Minuten fertig sein falls Du es noch mal testen möchtest. Zu den neuen Problemen (update planes, 3D zerbröseln) kann ich noch nicht viel sagen, vielleicht fehlt noch eine lib welche für die korrekte Darstellung benötigt wird. Ich versuche das noch mal mit einem ubuntu 17.10 in einer virtualbox nachzustellen. Gruß, Frank
Leute, Leute schrieb: > Nach ein paar Jahren ist die Lust > dann weg und zurück bleibt eine Baustelle ... so wie es auch bei Eagle ist. Ich dachte echt dass die irgend wann mal ein paar Features hinzutun werden, aber da ist ja seit Jahren nichts mehr wirklich passiert. Die wollen das aktuelle Programm so verkaufen wie es ist weil ihnen die Lust fehlt etwas zu verändern. (die Veränderungen seit 4.16 sind lächerlich) Ich würde mir gerne auf zwei Monitoren jeweils eine Ebene anzeigen lassen und wenn ich auf einer etwas verschiebe, dann sehe ich das auf beiden Monitoren. Wenn man mehrere Lagen hat wäre das eindeutig übersichtlicher. Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste drückt vorher aufleuchten, dann sieht man schon vorher welche Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick markiert ist.
Mike J. schrieb: > ... so wie es auch bei Eagle ist. Bitte: das gehört nun wirklich nicht hierher. Zu Eagle gibt's genug Threads.
Mike J. schrieb: > Ich würde mir gerne auf zwei Monitoren jeweils eine Ebene anzeigen > lassen und wenn ich auf einer etwas verschiebe, dann sehe ich das auf > beiden Monitoren. > Wenn man mehrere Lagen hat wäre das eindeutig übersichtlicher. > Ja, so ist es ja bei vielen Texteditoren, etwa auch bei meinem Nim Editor: Man kann den gleichen Text in mehreren Fenstern darstellen, ändert man in einem Fenster etwas, wird das auch in den anderen Fenstern sichtbar. Das kann man ja auch bei der Platinenansicht machen. Ob man da zwei Monitore braucht? Bei den aktuellen 4k Monitoren hat man ja schon viel Inhalt auf einem Bildschirm, etwa drei Fenster nebeneinander. Ich denke GTK unterstützt auch Mehrmonitorbetrieb, so dass man das machen kann. Ich habe momentan aber nur einen 4K Monitor. Bei mehr als einem muss man den Kopf immer so viel drehen, das behagt mir persönlich nicht so sonderlich. > Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die > entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste > drückt vorher aufleuchten, dann sieht man schon vorher welche > Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick > markiert ist. Ja, das würde ich wohl auch so machen. Bei meinem Schaltplaneditor war es ja schon so, dass Elemente angehoben mit Schatten dargestellt werden, wenn der Mauszeiger über ihnen schwebt.
Frank K. schrieb: > Es ist mir nun endlich gelungen mein erstes AppImage zu erstellen :-) Kannst Du ein kleines Beispielprojekt in dem Appimage versenken, so dass man direkt spielen kann ohne sich zunaechst mit den Pools auseinandersetzten zu muessen? Danka
:-D Hab das Programm gerade getestet. Habe nur den Pool hinzugefügt und dann mein erstes Projekt angefangen. Es wäre schön wenn dieser Pool sich beim Start automatisch in das Verzeichnis lädt aus dem ECAD ausgeführt wird. home.../Programme/ecad/ In dem Verzeichnis habe ich die App "horizon-...-x86_64.AppImage" und den Pool abgelegt. - Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man gerade in der Hand hält. - Es ist etwas komisch dass bei den Widerständen schon Werte stehen. - Die Bauteilliste könnte in Baugruppen unterteilt sein, zum Beispiel Transistoren, LEDs, Versorgungssymbole (GND, Vcc, +3.3V ...), Steckverbinder, Chips, Widerstände usw. - Jetzt fehlt die Leiste (mit dem Stift, spiegeln des Bauteils, Move, Copy usw.) welche es bei Eagle gibt, momentan verbinde ich die Pins im Schaltplan indem ich die Pins aneinander führe. Habe ich da etwas übersehen? - Es ist etwas nervig dass man zum bewegen der Bauteile immer den "Move"-Knopf drücken muss. - Es wäre besser wenn sich das Bauteil nach einem Klick auf Move im Schaltungseditor direkt unter dem Mauszeiger befindet. (also die Mitte des Bauteils direkt unter dem Mauszeiger plazieren) Momentan ist das Bauteil dann teilweise noch sehr weit verschoben zum Mauszeiger.
Uwe B. schrieb: > Danka Are you not able to open the example project? See bottom of this page: https://github.com/carrotIndustries/horizon/wiki/Getting-started
Mike J. schrieb: > - Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung > des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man > gerade in der Hand hält. Ja, aber wie macht man das konkret? Wo soll die Preview-Area angeordnet sein? Bei gschem hatten sie den Preview zum Schluss in den Dateiauswahldialog integriert, das gefiel mir auch nicht sonderlich. > > - Es ist etwas nervig dass man zum bewegen der Bauteile immer den > "Move"-Knopf drücken muss. Ist das wirklich noch so? Nach meiner Meinung sollte möglist alles funktionieren, ohne das man spezielle Tools anwählen muss. Verschieben z.B. einfach: Maus über Bauteil, Knopf Drücken und Bewegen. Oder neue Leitung: Maus über Pin, Knopf drücken und loslassen, und die Leitung hängt an der Maus. Maus über Text, Mausrad dreht den Text. Maus über Bauteil, Mausrad dreht Bauteil. Maurad über freier Fläche: Zoom. Usw. Beim Schaltplaneditor hatte ich soweit alles hinbekommen, dass man praktisch fast nie das Tool wechseln muss. Beim Layouteditor sollte es möglichst ähnlich sein, da müsste man aber über die Konketisierung nachdenken.
Wobei ich gerade sehe, ich hatte ja sogar die Bedienung aufgeschrieben: Unter Usage: http://ssalewski.de/PetEd.html.en Soweit ich mich errinnere ging das wirklich recht gut. Die Programmierung war zwar etwas kniffelig, aber das sollte Lukas hinbekommen.
Stefan S. schrieb: > Wobei ich gerade sehe, ich hatte ja sogar die Bedienung > aufgeschrieben: > Unter Usage: > > http://ssalewski.de/PetEd.html.en > > Soweit ich mich errinnere ging das wirklich recht gut. Ich bin gerade dabei, das mal auszuprobieren. Allerdings habe ich das Problem, dass GTK3 notwendig, aber auf meiner Kiste nicht verfügbar ist; das dauert also noch. Die Version von 2012 startet.
Possetitjel schrieb: > Ich bin gerade dabei, das mal auszuprobieren. Das würde ich jetzt nicht unbedingt machen. Gut, bei mir läuft es noch, ruby-gnome2 gibt aber einige Debugging-Meldungen. Und ich kann auch keinen Schaltplan öffnen, da ich gEDA nicht mehr installiert habe, und damit die Symbole nicht vorhanden sind. Start mit leerem Plan einfach mit "ruby peted.rb" geht bei mir, oder auch mit einem der beiliegenden Symbole. Nun ja, geschrieben hatte ich es 2011 oder 2012 -- ist eben schon lange her...
Helmut S. schrieb: > 3D Ansicht > Beim Anklicken von 3D zerbröselt es die Grafik im Layoutfenster. Fehlt > dafür noch eine weitere Software? Kannst du mal einen Screenshot davon machen? Die OpenGL-Unterstützung von Gtk ist noch recht neu und recht wenig Software verwendet die derzeit ernsthaft. Insofern sind da bugs nicht verwunderlich... Mike J. schrieb: > Wenn ich mit der Maus irgend wo lang gehe wäre es schön wenn die > entsprechenden Teile, welche reagieren wenn man dann auf die Maustaste > drückt vorher aufleuchten, dann sieht man schon vorher welche > Leitung/Bauteil der Mauszeiger im Fokus hat und welche dann beim Klick > markiert ist. Ist bei horizon so, wenn du im "hover select"-Modus (esc-Taste drücken) bist. Uwe B. schrieb: > Kannst Du ein kleines Beispielprojekt in dem Appimage versenken, so dass > man direkt spielen kann ohne sich zunaechst mit den Pools > auseinandersetzten zu muessen? Derzeit speichern Projekte ihre Bauteile nicht lokal zwischen, ohne Pool kann man das Beispielprojekt nicht aufmachen. Mike J. schrieb: > - Bei der Auswahl der Bauteile wäre es schön wenn man eine Darstellung > des entsprechenden Schaltsymbols sehen könnte, damit man weiß was man > gerade in der Hand hält. Das könnte ich dem Part Browser in der Tat noch spendieren. > - Es ist etwas komisch dass bei den Widerständen schon Werte stehen. > - Die Bauteilliste könnte in Baugruppen unterteilt sein, zum Beispiel > Transistoren, LEDs, Versorgungssymbole (GND, Vcc, +3.3V ...), > Steckverbinder, Chips, Widerstände usw. Man will keinen generischen 10kOhm-Widerstand im Schaltplan haben, den kann man nirgendwo kaufen. Jedes Bauteil im Schaltplan hat Hersteller und Teilenummer, sodass man (in Zukunft) direkt die Stückliste bei octopart einwerfen kann. Für Hühnerfutter werden die Teilenummern aus der CPL von octopart verwendet. Zur suche gibt es die tags. Versorgungssymbole sind keine "normalen" Symbole, die sind fest eingebaut. Derzeit gibt es nur "GND". Siehe https://github.com/carrotIndustries/horizon/wiki/Schematic-editor#power-symbols > - Jetzt fehlt die Leiste (mit dem Stift, spiegeln des Bauteils, Move, > Copy usw.) welche es bei Eagle gibt, momentan verbinde ich die Pins im > Schaltplan indem ich die Pins aneinander führe. Habe ich da etwas > übersehen? Leertaste drücken, dann kommt ein Menü mit allen verfügbaren Tools, da stehen auch die Tastenkürzel dran. Oder auf "Help" klicken, da steht auch was jede Taste macht. > - Es ist etwas nervig dass man zum bewegen der Bauteile immer den > "Move"-Knopf drücken muss. Einfach "m" drücken. > - Es wäre besser wenn sich das Bauteil nach einem Klick auf Move im > Schaltungseditor direkt unter dem Mauszeiger befindet. (also die Mitte > des Bauteils direkt unter dem Mauszeiger plazieren) > Momentan ist das Bauteil dann teilweise noch sehr weit verschoben zum > Mauszeiger. Da unterscheiden sich wohl die Geschmäcker. So lange das Bauteil relativ dem Mauszeiger folgt passt für mich alles.
Stefan S. schrieb: > Ist das wirklich noch so? Nach meiner Meinung sollte möglist alles > funktionieren, ohne das man spezielle Tools anwählen muss. Verschieben > z.B. einfach: Maus über Bauteil, Knopf Drücken und Bewegen. Oder neue > Leitung: Maus über Pin, Knopf drücken und loslassen, und die Leitung > hängt an der Maus. Maus über Text, Mausrad dreht den Text. Maus über > Bauteil, Mausrad dreht Bauteil. Maurad über freier Fläche: Zoom Ich nutze das AppImage (unter XUbuntu 17.10): horizon-1509392238.1462df3-Build44.1.glibc2.14-x86_64.AppImage
Frank K. schrieb: > Hallo Helmut, > > Die Idee der AppImages ist dass Du nichts zusätzlich installieren musst, > das Image sollte alle nötigen libs, etc. enthalten. Ich habe > canberra-gtk-module noch hinzugefügt, der Build lauft gerade. Sollte so > bis in ein paar Minuten fertig sein falls Du es noch mal testen > möchtest. Zu den neuen Problemen (update planes, 3D zerbröseln) kann ich > noch nicht viel sagen, vielleicht fehlt noch eine lib welche für die > korrekte Darstellung benötigt wird. Ich versuche das noch mal mit einem > ubuntu 17.10 in einer virtualbox nachzustellen. > > Gruß, > Frank Hallo Frank, Ich habe gerade mal deine neueste Version auf 17.10 gestartet obwohl ich da schon GTK 3 installiert hatte. Die Planes werden immer noch nicht gefüllt dargestellt! Beim drücken auf 3D erscheint eine Messagebox: OpenGL context creation failed Danach ist die Grafik im Layoutfenster korrupt/unbrauchbar. Man hat Mühe das Layoutfenster im Blindflug zu schließen. Gruß Helmut
Helmut S. schrieb: > Ich habe gerade mal deine neueste Version auf 17.10 gestartet obwohl ich > da schon GTK 3 installiert hatte. > > Die Planes werden immer noch nicht gefüllt dargestellt! Ich konnte es nicht lassen und habe auf einem Rechner Xubuntu 17.10 installiert. Damit konnte ich die aktuelle Version von horizon problemlos (nach ein paar apt install ...) übersetzen. Ich musste kein gtk aus fremden Quellen (PPA) nachinstallieren, den o.g. Fehler sehe ich nicht, ganz fehlerfrei ist die 3d Darstellung aber auch nicht.
tester schrieb: > ganz fehlerfrei ist die 3d Darstellung aber auch nicht. Kannst du mal einen Screenshot machen? So hilft mir diese Aussage recht wenig...
Jörg W. schrieb: > Dann bleib doch einfach dabei. > > Ob andere „Bockmist“ bauen, diese Einschätzung darfst du gern mehr als > nur dir überlassen. Manchmal frag ich mich, warum ausgerechnet DU es partout nicht fertig bringst, sachlich zu bleiben und dich darum zu bemühen, einen Nutzwert in die Diskussionen einzubringen. Ständig wirst du an der unpassendsten Stelle persönlich. Brauchst du das mental? Also: es gibt ne Menge Leute, die ebenso viele Projekte planen und anfangen - und nur ein kleiner Teil davon wird sein Zeugs zu Ende kriegen und damit einen Erfolg haben. Das ist so und es war schon immer so. Die viele Arbeit, die all die anderen in ihr Zeugs gesteckt haben ist hingegen für die Katz, denn aus deren Projekten wird zum Schluß nichts. UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht schadenfroh daneben steht um zuzugucken wie sich jemand verrennt und dann scheitert. Jedenfalls mir geht das so und deswegen sag ich jemandem, der grad Bockmist baut, daß er es tut. Der Rest liegt dann bei ihm, entweder kapiert er es und reißt sein Steuer herum oder er rümpft die Nase und macht weiter so wie bisher. Aber das ist was ganz anderes als deine ständigen Unterstellungen wie z.B. hier bezüglich Altium Designer. Abgesehen davon kannst du in den Untiefen dieses Forums ne Einschätzung des AD nachlesen, die ich vor geraumer Zeit nach einer Vorführ-Erfahrung auf der Embedded verfaßt habe. Du hättest nachlesen und schlichtweg sachlich bleiben können. W.S.
Angehängte Dateien:
-
horizon.png
120 KB -
horizon1.png
32 KB
Hm... mit nicht ganz fehlerfrei meinte ich, dass die Darstellung der Solder Mask nach schwarz abgesoffen ist, wenn man die Platine zu sehr in die waagrechte gedreht hat. Schaut man mehr aus der Senkrechten drauf, wird sie wieder grün. Nichts, was jetzt wirklich entscheidend wäre.
Angehängte Dateien:
-
horizon_fehler2_Win7m.png
21 KB -
horizon_fehler_Win7.png
19 KB
Was fehlt bei mir dass das unter Win7 nicht funktioniert? Fehler: - Exited with exit status 3 - Runtime Library
Angehängte Dateien:
Lukas K. schrieb: > tester schrieb: >> ganz fehlerfrei ist die 3d Darstellung aber auch nicht. > > Kannst du mal einen Screenshot machen? So hilft mir diese Aussage recht > wenig... Nach dem Drücken auf 3D kommt ja erstmal eine Fehlermeldung: OpenGL context creation failed Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des Layoutfensters macht sieht das aus wie im Anhang (2. Bild, Screenshot_from_2017-10-31_19-04-30.png) Neueste AppImage: Siehe drittes Bild, Screenshot_from_2017-10-31_19-10-55.png Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen waagrechten Strichen versteckt. Vermutlich wurde das Image mit einer anderen Bilschirmauflösung generiert. Ich habe hier HD-Auflösung (1920...). AppImage von gestern und von heute Im Layoutfenster werden die Planes nicht gefüllt. Ich weiß immer noch nicht ob das an meiner Grafikkarte liegt. Ich werde mich jetzt wohl wieder der Windows-Version widmen. Die läuft ohne Probleme. Gruß Helmut
Lukas K. schrieb: > Man will keinen generischen 10kOhm-Widerstand im > Schaltplan haben, Doch, unbedingt. Es ist in Ordnung, wenn Du Deine Software ausschließlich an DEINEM Arbeitsablauf ausrichtest. Aber BITTE sieh von unzutreffenden Verallgemeinerungen ab. Ich habe ziemlich oft Bedarf nach "abstrakten" Schaltplänen. Das Auswählen der (abstrakten) Bauteile und das Definieren der Schaltungstopologie ist bei mir der erste Schritt. Die Dimensionierung ist der zweite, und die endgültige Festlegung der Bauteiltypen (=kaufbare Produkte) der dritte. --> Deine Software ist für mich nicht geeignet. (Das ist kein Problem; Du machst nichts falsch. Ich wollte es nur explizit feststellen.) > Jedes Bauteil im Schaltplan hat Hersteller und Teilenummer, Super. Wenn ich den Hersteller wechsle, müsste ich den Schaltplan anpassen :/
@helmut: Verwendest du Wayland oder X11? Xubuntu 17.10 verwendet standardmäßig X11, während das "normale" Ubuntu Wayland nimmt. Lt c't liegt da noch manches im argen, evtl. rühren hier die Probleme her. @Lukas: Wie stellt man beim routen die Leiterbahngröße ein?
Possetitjel, sehe ich auch so. Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein.
W.S. schrieb: > UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht > schadenfroh daneben steht um zuzugucken wie sich jemand > verrennt und dann scheitert. Jedenfalls mir geht das so > und deswegen sag ich jemandem, der grad Bockmist baut, daß > er es tut. Dein Fehler liegt in Deiner (unausgesprochenen) Voraussetzung, dass DEINE Einschätzung für irgend etwas relevant ist, was LUKAS tut. Ist es aber nicht (zumindest nicht automatisch). > Der Rest liegt dann bei ihm, entweder kapiert er es und > reißt sein Steuer herum oder er rümpft die Nase und macht > weiter so wie bisher. Der Punkt ist, dass es von Lukas' Standpunkt aus kein Bockmist IST. Jedes Werturteil (wie Deinst: "Bockmist") setzt einen Wertmaßstab voraus. Nicht Dein Urteil an sich ist der Fehler -- sondern die Tatsache, dass Du Deinen eigenen Wertmaßstab als richtig, objektiv gegeben und nicht diskutabel ansiehst. Auf dieser Basis kannst Du natürlich nicht vestehen, was Lukas tut.
Abdul K. schrieb: > Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast > du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein. Das ist das Demo-Projekt.
tester schrieb: > Abdul K. schrieb: >> Helmut, du baust ein Ethernet-Interface mit einer Alpha-Software? Hast >> du so viel Zuversicht oder zu viel Freizeit? Soll kein Vorwurf sein. > > Das ist das Demo-Projekt. So ist es. Damit kann man einfach mal Leitungen und Planes zeichnen, verschieben und probieren. Das ist keine Schaltung die man jetzt aufbauen soll. Ich finde das ist eine gute Sache.
Oben stand, man könne keine Demos mit in die Auslieferung einbinden. Daher hat mich das gewundert ich folgerte, Helmut hat gleich mal richtig reingehauen.
@Lukas: Das mit den "Zero lenght track" ist ja ganz nett. Aber warum verhinderst du die Entstehung solcher Tracks nicht komplett?
W.S. schrieb: > UND DAS IST DERART SCHADE DRUM, daß unsereiner eben nicht schadenfroh > daneben steht um zuzugucken wie sich jemand verrennt und dann scheitert. Im Moment bist du der Einzige hier, der das, was da gerade mit Horizon passiert, als „Scheitern“ deklariert. Im Gegenteil, Lukas hat den Thread Anfang des Jahres gestartet, danach war es recht lange eher still. Jetzt dagegen hat zumindest die Diskussion auch von Leuten, die es getestet haben, doch gut Fahrt aufgenommen. > Aber das ist was ganz anderes als deine ständigen Unterstellungen wie > z.B. hier bezüglich Altium Designer. Das ist einfach mein Eindruck, den ich nach deinen wiederholten Eagle-Lobpreisungen bekommen habe. Ich bin weit davon entfernt, Eagle irgendwie als unbenutzbar hinzustellen, aber dass es im Bereich der EDA-Programme eher eins ist mit ziemlich vielen Ecken und Kanten, ist meist auch denjenigen klar, die es aktiv benutzen. Das ist dann eher eine „ist gut genug für mich“-Entscheidung als eine „so und nur so hätte ich mir ein EDA-Programm vorgestellt“. > Abgesehen davon kannst du in den > Untiefen dieses Forums ne Einschätzung des AD nachlesen, die ich vor > geraumer Zeit nach einer Vorführ-Erfahrung auf der Embedded verfaßt > habe. Du hättest nachlesen und schlichtweg sachlich bleiben können. Sorry, nach einem Anonymus im Forum zu suchen ist ja schlimmer als nach einer Nadel im Heuhaufen. Falls du einen Link hast, lese ich es mir gern durch und korrigiere diese meine Meinung.
Oha... der "Interactive Router" kann schon (etwas) Push'n'Shove. Im "router" Unterverzeichnis ist einiges an Quelltext vom KiCad PnS Router. Ist ja kein Problem, beides ist GPL3.
Geht ja richtig rund hier, ich hoff' jetzt nichts wichtiges vergessen zu haben: tester schrieb: > dass die Darstellung der > Solder Mask nach schwarz abgesoffen ist, wenn man die Platine zu sehr in > die waagrechte gedreht hat. Das ist schlechtes flat shading bei der Arbeit ;) Die 3D-Vorschau entstand durch halbes implementieren einiger OpenGL-Tutorials, da ist in der Tat noch Luft nach oben. Wenn sich wer da austoben und das schöner machen will, oder einfach umsetzbare Vorschläge hat, gerne doch. Possetitjel schrieb: > Super. > Wenn ich den Hersteller wechsle, müsste ich den Schaltplan > anpassen :/ Nein. Am Beispiel Widerstand mal erklärt, wie ich mir das vorgestellt hab: Horizon unterscheidet "Part" und "Entity". Jeder Widerstand mit zwei Beinen, egal welcher Wert und Hersteller ist durch die Entity "Two-terminal Resistor" definiert. Das Part fügt dem dann Hersteller, Wert, Teilenummer und Package hinzu. Wichtig für die Netzliste ist die Entity. Mit dem Tool "Assign Part" kann man ohne den Schaltplan anderweitig anzufassen z.B. aus einem 1k 0603 einen 10k 0402 Widerstand machen. tester schrieb: > @Lukas: Wie stellt man beim routen die Leiterbahngröße ein? Dazu gibt es zwei Optionen: Zu bevorzugen ist es die Leiterbahnbreite in den Regeln festzulegen. Wie bei Altium auch werden die Reglen von oben nach unten abgearbeitet und die erste zutreffende wird appliziert. Wenn die Leiterbahnen mal anders werden sollen, kann man im Property Editor rechts im Bild "Width from Rules" aus machen und eine Leiterbahnbreite eintippen. Oder man drückt während des Routens "w" um die Größe einzutippen. Mit "W" wird wieder die aus den Regeln ausgewählt. (Hab wohl vergessen, das in den Tooltip aufzunehmen, kommt gleich) tester schrieb: > @Lukas: Das mit den "Zero lenght track" ist ja ganz nett. Aber warum > verhinderst du die Entstehung solcher Tracks nicht komplett? Mit dem Kicad-Router sollten die eigentlich nicht allzu oft entstehen. Bis jetzt war der Leidensdruck nicht groß genug, mich darum zu kümmern, dass die auch verschwinden. tester schrieb: > Oha... der "Interactive Router" kann schon (etwas) Push'n'Shove. Im > "router" Unterverzeichnis ist einiges an Quelltext vom KiCad PnS Router. > Ist ja kein Problem, beides ist GPL3. Ja, ich hab den Router von den CERN-Leuten eingebaut. War einiges an Aufwand, hat sich aber definitiv gelohnt. War auch nur möglich, weil der Router selber recht unabhängig von KiCad gehalten ist und sein eigenes Datenmodell mitbringt. Ich behaupte jetzt mal, dass der Router in horizon erst sein wahres Potential entfalten kann, da das was KiCad unter "Design Rules" versteht doch sehr zu wünschen übrig lässt. Helmut S. schrieb: > Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen > waagrechten Strichen versteckt. Das ist Absicht ;) In https://github.com/carrotIndustries/horizon/commit/1462df3376afdfab499fcf60aaa4c89fe56fa840 hab ich die Oberflächen der grafischen Editoren ein wenig aufgeräumt und nicht allzu oft benötigt Tools in das Hamburger-Menü gestopft. Helmut S. schrieb: > Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des > Layoutfensters macht sieht das aus wie im Anhang (2. Bild, > Screenshot_from_2017-10-31_19-04-30.png) Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit X11/Wayland die Ubuntu beiliegt... Dass das nicht-füllen der Planes an der GPU liegt kann ich mir gerade nicht so richtig ausmalen, da diese (aus OpenGL-Sicht) genau so wie gefüllte Pads gezeichnet werden.
>> Helmut S. schrieb: >> Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des >> Layoutfensters macht sieht das aus wie im Anhang (2. Bild, >> Screenshot_from_2017-10-31_19-04-30.png) > > Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit > X11/Wayland die Ubuntu beiliegt... > Dieses Problem habe ich bei dem selben Rechner auch in Ubuntu 16.04 und da ist kein Wayland drin. Kann natürlich auch an der doch älteren Grafikkarte liegen. Müsste mal schauen ob ich noch eine Festplatte opfere und Ubuntu 17.10 auf einenm anderen Rechner testen kann. Helmut S. schrieb: >> Da sind ein Teil der Toolbuttons in dem Button rechts mit den 3 kleinen >> waagrechten Strichen versteckt. > Das ist Absicht ;) In > https://github.com/carrotIndustries/horizon/commit... > hab ich die Oberflächen der grafischen Editoren ein wenig aufgeräumt und nicht allzu oft benötigt Tools in das Hamburger-Menü gestopft. Mir hatte die ältere Version besser gefallen. Bin da aber flexibel. Wer weiß schon wieviel "Knöpfe" da noch kommen. :-)
Lukas K. schrieb: > Possetitjel schrieb: >> Super. >> Wenn ich den Hersteller wechsle, müsste ich den Schaltplan >> anpassen :/ > > Nein. Am Beispiel Widerstand mal erklärt, wie ich mir das > vorgestellt hab: Horizon unterscheidet "Part" und "Entity". > Jeder Widerstand mit zwei Beinen, egal welcher Wert und > Hersteller ist durch die Entity "Two-terminal Resistor" > definiert. Das Part fügt dem dann Hersteller, Wert, > Teilenummer und Package hinzu. Wichtig für die Netzliste > ist die Entity. Kein schlechter Ansatz, aber nicht zu Ende gedacht.
Possetitjel schrieb: > Kein schlechter Ansatz, aber nicht zu Ende gedacht. Was fehlt? Man kann auch erstmal generische Bauteile (nur Entity) ohne Part platzieren und erst gegen Ende Parts zuweisen, wenn einem das so besser gefällt.
Lukas K. schrieb: > Possetitjel schrieb: >> Kein schlechter Ansatz, aber nicht zu Ende gedacht. > > Was fehlt? Der Wille zur Beschränkung :) Ich denke seit einigen Monaten über eine Bauteildatenbank nach und weiss daher, dass die Relation von Herstellern, Typen, Footprints usw. kompliziert ist. Datenblätter (in unterschiedlichen Versionen), SPICE- Modelle und Lieferanten wollen auch noch verwaltet sein, von (firmeninternen) Bauteilnummern, Stücklisten und Bestellungen gar nicht zu reden... Der Kern einer Layoutsoftware ist, dass man Footprints platzieren und Leiterzüge verlegen kann. Über den ganzen Rest soll sie mir so wenig Vorschriften machen wie möglich.
Possetitjel schrieb: > Über den ganzen Rest soll sie mir so wenig Vorschriften machen wie > möglich. Vorschriften nicht, aber den Rest mitverwalten ist nicht schlecht. Bei Altium kann man eine externe Datenbank für die Teileverwaltung reinhängen, das kann bspw. eine Excel-Tabelle sein. Die enthält dann außer Symbol und Footprint noch beliebig weitere Spalten, die man beim Erstellen der BOM rausdumpen kann. Damit bekommt man eine BOM, die man direkt dem Fertiger in die Hand drücken kann. Excel ist dabei (leider) offenbar ein ziemlicher de-facto-Standard. Wenn man das nicht direkt erzeugen will, kann man natürlich allemal auch CSV rauswerfen und das hernach in Excel oder Openoffice Calc reinziehen. Als Datenbank sollte sicher auch eine SQL-DB gehen, aber sowas hat halt nicht jeder, und bis auf sqlite brauchen sie einen Server. Gibt's für sqlite ein gescheites Frontend zum Editieren? Das scheint mir ansonsten der wesentliche Grund zu sein, warum die Leute da eine Excel-Tabelle nehmen. Die ist ansonsten ja eher nachteilig, bspw. kann man sie nicht im Excel schreibend öffnen, wenn Altium sie gerade in den Fingern hat.
>>> Helmut S. schrieb: >>> Von 3D ist dann nichts zu sehen. Wenn amn dann ein resize des >>> Layoutfensters macht sieht das aus wie im Anhang (2. Bild, >>> Screenshot_from_2017-10-31_19-04-30.png) >> >> Dann ist das Wohl ein Bug in der Gtk-Version bzw. dem Zusammenspiel mit >> X11/Wayland die Ubuntu beiliegt... >> >Dieses Problem habe ich bei dem selben Rechner auch in Ubuntu 16.04 und da ist kein Wayland drin. Kann natürlich auch an der doch älteren Grafikkarte liegen. Müsste mal schauen ob ich noch eine Festplatte opfere und Ubuntu 17.10 auf einenm anderen Rechner testen kann. Ich habe jetzt das AppImage auf einem Rechner mit neuerer Grafikkarte(GTX560) mit Ubuntu 17.10 (Wayland, X) getestet. https://download.opensuse.org/repositories/home:/frank_kunz/AppImage/ Die Flächen werden jetzt wie gewünscht auch gefüllt dargestellt. Der Aufruf von 3D wirft eine Fehlermeldung, aber keine 3D Ansicht. Fenster: Erstellen des OpenGL-Kontetxts ist gescheitert. Anschließend kann man auch mit dem PCB nicht mehr vernünftig weiterarbeiten da ab da massive Grafikfehler im PCB-Fenster auftreten. Schade. Für mich steht fest, dass da irgend eine Bibliothek fehlt. Da werde ich wohl endgültig auf einem WIN-PCB weitertesten. Auspacken -> funktioniert. Hallo Lukas, bitte die WIN-Version aktuell halten. http://0x83.eu/horizon-zip/ Gruß Helmut
Helmut S. schrieb: > Schade. Für mich steht fest, dass da irgend eine Bibliothek fehlt. Das zieht sich doch schon durch den ganzen Thread. Eine typische FOSS-Geschichte - einfach alles an Abhängigkeiten reinziehen, was irgendwie sexy ist, kost ja nix. Und sich dann wundern, wieso das Ergebnis ausschließlich auf dem Dev-Rechner läuft. Und natürlich bleeding edge, damit man LTS-Anwendern mal gepflegt zeigen kann, wie verwerflich es schon rein moralisch ist, einen Linuxrechner für etwas anderes als Systemupdates und Alphatests nutzen zu wollen.
Nop schrieb: > Das zieht sich doch schon durch den ganzen Thread. Nörgeltanten wie du ziehen sich leider auch schon durch den ganzen Thread. Ich denke, darauf könnten nicht nur Lukas sondern auch seine Tester gern verzichten.
Jörg W. schrieb: > Ich denke, darauf könnten nicht nur Lukas sondern auch seine > Tester gern verzichten. So, das denkst Du. Shoot the messenger, was? Und was denkst Du sonst noch so? Daß die Problematik besser wird, wenn keiner sie anspricht?
Nop schrieb: > Daß die Problematik besser wird, wenn keiner sie anspricht? Dass bis dann, wenn das Programm für die Massen spruchreif wird, die derzeit als „verfrüht“ betitelten Versionen irgendwelcher Bibliotheken sowieso Standard sein werden. Das schrieb ich übrigens auch schon zu Beginn des Threads. Über einen Teil dessen, was damals noch „bleeding edge“ war, diskutiert nun schon keiner mehr. Aber Hauptsache, man kann pauschal auf „typisch FOSS“ meckern. Etwas Substanzielles beitragen – ничего, nada, wozu auch?
Jörg W. schrieb: > Dass bis dann, wenn das Programm für die Massen spruchreif wird, die > derzeit als „verfrüht“ betitelten Versionen irgendwelcher Bibliotheken > sowieso Standard sein werden. Es ist aber nicht nur ein Problem für die Massen, sondern schon fürs Testing. Wie man leicht mitlesen kann, wenn man nicht in einer primitiven "shoot the messenger"-Denke festklebt. > Aber Hauptsache, man kann pauschal auf „typisch FOSS“ meckern. Diese Problematik IST nunmal typisch für FOSS. > Etwas Substanzielles beitragen Substantieller als Du mit "shoot the messenger" wäre ich ja schon, wenn ich auch nur die Uhrzeit ansagen würde. Wenn EINES jeder Art von vernünftigem testen abträglich ist, dann Jubelperser, die um Himmels Willen keine Probleme hören wollen. Von Profizeug wie Erwägungen, inwieweit Testergebnisse ohne jedes Config-Management überhaupt irgendeine Aussage haben, will ich gar nicht erst anfangen. Aber gut, ich bin ja schon ruhig. Keiner hat was gesagt, keiner hat was gesehen, HURRAAAAA alles gut. Jetzt zufrieden?!
Jörg W. schrieb: > Vorschriften nicht, aber den Rest mitverwalten ist nicht > schlecht. Hmmja. Der Knackpunkt dabei sind letztlich die Projektdaten: Kann ich mit denen unabhängig von DIESER konkreten Software etwas anfangen oder nicht? Für Datenblätter, SPICE-Modelle und SPICE-Files ist das gewährleistet; für Gerber-Daten auch. Aber dazwischen? Ja, gut... Netzlisten. Und sonst? > Bei Altium kann man eine externe Datenbank für die > Teileverwaltung reinhängen, das kann bspw. eine > Excel-Tabelle sein. Altium scheint allgemein ziemlich viel richtig zu machen, will mir scheinen. Nach meinem Eindruck ist das eine zwei-Klassen-Gesellschft: Einerseits die Anwender, die mehrere Tausend Euro für die ECAD-Software raushauen können, und andererseits alle die, die das nicht können und mit Target, Eagle &Co. leben müssen. > Excel ist dabei (leider) offenbar ein ziemlicher > de-facto-Standard. Wenn man das nicht direkt erzeugen > will, kann man natürlich allemal auch CSV rauswerfen > und das hernach in Excel oder Openoffice Calc reinziehen. Ein schlechter Standard ist besser als gar keiner. Schlecht für die Programmierer, gut für die Anwender. Excel verwenden die Leute sowieso, das ist also erstens vorhanden, und das können die Leute zweitens halbwegs bedienen. > Als Datenbank sollte sicher auch eine SQL-DB gehen, aber > sowas hat halt nicht jeder, So ganz blicke ich da sowieso nicht durch. Selbst OpenOffice bringt OOBase mit. Es wäre doch das Logischste von der Welt, dass man die Daten, die zu komplex für Excel sind, damit verwaltet. Das scheint aber im großen und ganzen nicht üblich zu sein. An der Datenmenge kann's nicht liegen. Selbst heftig produzierende Kleinunternehmen kommen mit 10'000 Datensätzen in der Bauteildatenbank aus; da lacht jede Datenbank drüber. Mysteriös...
Helmut S. schrieb: > Der Aufruf von 3D wirft eine Fehlermeldung, aber keine 3D Ansicht. > Fenster: Erstellen des OpenGL-Kontetxts ist gescheitert. Selbiges Problem sehe ich auch, interessanterweise auch auf meinem System auf dem die lokal kompilierten Binaries problemlos laufen. > Anschließend kann man auch mit dem PCB nicht mehr vernünftig > weiterarbeiten da ab da massive Grafikfehler im PCB-Fenster auftreten. Das habe ich auch mit Ubuntu 17.10 beobachtet. Könnte was mit Wayland zu tun haben, ist aber nur Spekulation. Ab diesem Punkt (OpenGL/3D) wird es wohl kompliziert AppImages zu bauen. Etwas Google Suche hat da auch mehr Beiträge mit Problemen als Lösungen gefunden. Vielleicht könnte Softrendering erzwungen werden, dann würde die Arbeit mit horizon aber wohl keinen Spaß mehr machen. Zur Not hilft nur selber kompilieren, zum Glück ist das mit FOSS möglich... ;-) Gruß, Frank
> Zur Not hilft nur selber kompilieren, zum Glück ist das mit FOSS möglich... ;-) Das habe ich gleich mal probiert. Anleitung von hier: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Linux sudo apt install libyaml-cpp-dev libsqlite3-dev util-linux librsvg2-dev \ libcairomm-1.0-dev libepoxy-dev libgtkmm-3.0-dev uuid-dev libboost-dev \ libzmq5 libzmq3-dev libglm-dev Dann zip-Datei mit "clone or download" geholt und ausgepackt. Dann make. make Das compiliert eine Menge Files und bricht dann ab mit Fehlermeldung siehe unten. make: *** Keine Regel vorhanden, um das Ziel „.git/HEAD“, benötigt von „gitversion.cpp“, zu erstellen. Schluss. Was muss man da mit "git" vorher machen/installieren?
Hast Du git installiert? Wenn ja, dann versuch mal
1 | 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. Gruß, Frank
Wenn man nicht mit git herumhantieren will tut es auch ein
1 | mkdir .git |
2 | touch .git/HEAD .git/index |
Gruß, Frank
Hallo Frank, vielen Dank für deine Hilfe. Ohne deine Anleitung hätte ich das nicht geschafft. Git hatte ich hier schon geholt. Wusste aber dann nicht weiter. https://www.howtoforge.com/tutorial/install-git-and-github-on-ubuntu-14.04/ git clone https://github.com/carrotIndustries/horizon.git Gerade ist der Compiler fertig geworden. Habe dann im Dateimanager auf horizon-prj-mgr Doppelklick gemacht. Dann kam eine Fehlermeldung: "horizon-pool-mgr" konnte nicht angezeigt werden. Irgendwas mit fehlendem MIME Type kam dann auch noch. Ich habe dann das Ganze aus einem Terminal gestartet. ./horizon-prj-mgr Hurra. Es geht, auch 3D geht fehlerlos. (Inzwischen ist aus meiner Ubuntu 17.10 Wayland zwangsweise ein Ubuntu 17.10 X geworden nachdem ich versuchsweise den NVIDIA Grafiktreiber installiert hatte.) Ich glaube da bekomme ich jetzt so etwas wie eine Äquatortaufe wie bei den Seefahrern, wenn sie das erste Mal den Äquator erreicht haben. Gruß Helmut
Mac G. schrieb: > Obwohl ich Altium zur Verfügung habe und das auch Simulieren kann, nutze > ich noch immer viel lieber LTSpice für analoge Geschichten. Hast Du die Möglichkeiten von Altium und pSpice voll ausgenutzt? > Man kann sowieso nur selten die komplette Schaltung simulieren - man > simuliert nur die kritischen Teile davon. Gut, das ist wahr. > Für HF-Kram gibts dann wieder andere Tools... Hyper-Lnyx?
Hallo Lukas, erstmal Danke für die Energie, die du in horizon steckst. Ich habe bisher nicht viele EDA Programme genutzt, muss aber sagen, das horizon spätestens auf den zweiten Blick recht gut bedienbar ist. Vorallem, weil du einige gute Konzepte von Blender übernommen hast. Ich habe mal Debian-Pakete erstellt, was insgesamt ganz reibungslos klappte. Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann und wo die erstellte Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter /usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in seinem Home ablegen? Uwe PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder?
Ah, du warst also der mit den Issues, auf github letztens. Danke fürs Testen, gibt doch immer wieder Dinge die einem durch die Lappen gehen. Uwe S. schrieb: > erstmal Danke für die Energie, die du in horizon steckst. Ich habe > bisher nicht viele EDA Programme genutzt, muss aber sagen, das horizon > spätestens auf den zweiten Blick recht gut bedienbar ist. Vorallem, weil > du einige gute Konzepte von Blender übernommen hast. Danke für die Blumen :) Schön dass das mal jemandem auffällt. Ich hatte nur mal kurz Blender benutzt und Dinge wie das Leertaste-Menü und dass der Cursor am Canvas-Rand wieder zurückspringt haben mir gefallen und waren recht einfach einzubauen. > Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei > ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann > und wo die erstellte > Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter > /usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur > Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte > die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer > in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in > seinem Home ablegen? Den Pool zu paketieren halte ich für nicht sinnvoll. Mir schwebte der Pool in der Anwendung so vor: Der Anwender klont sich den Pool irgendwo in sein Home und macht regelmäßig git pull. Eigene Bauteile sollen dann auch in dem Pool angelegt und mit Pull request eingepflegt werden. Derzeit ist das ein muss wenn man sein Projekt veröffentlichen will, da Projekte die verwendeten Bauteile nicht zwischenspeichern. Steht aber auch noch auf meiner todo-Liste, dass sich das ändert. Mal sehen, wie die Idee mit dem globalen Pool so in der Praxis bewährt, falls tatsächlich mal eine signifikante Anzahl von Leuten horizon ernsthaft benutzt. > PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder? Für's Erste müssen der Thread hier und die Issues auf github reichen. So groß war der Andrang bis jetzt noch nicht, dass sich das lohnen würde. Inzwischen gibt's auch einige neue potentiell nützliche Features: - Man kann Canvas-Farbe und Grid-Darstellung einstellen - "Dimensions" um im Board Abstände zu kennzeichnen - Beim Routen wird nun wie bei KiCad oder Altium das Netz hervorgehoben - Cross-Probing von Schaltplan zu Board und umgekehrt
Lukas K. schrieb: > > Uwe S. schrieb: >> Den Pool habe ich auch in ein eigenes Paket gesteckt und dabei >> ist die Frage aufgekommen, ob man mehrere Pools gleichzeitig nutzen kann >> und wo die erstellte >> Pool-Datenbank abgelegt wird? Kann man die .json Dateien read-only unter >> /usr/share/horizon ablegen und diesen Pool damit allen Nutzern zur >> Verfügung stellen? Muss die pool.db dann auch dort liegen oder könnte >> die auch unter /var/lib/horizon oder möglicherweise für jeden Benutzer >> in ~/.horizon/ abgelegt werden? Kann ein Benutzer einen eigenen Pool in >> seinem Home ablegen? > > Den Pool zu paketieren halte ich für nicht sinnvoll. Mir schwebte der > Pool in der Anwendung so vor: Der Anwender klont sich den Pool irgendwo > in sein Home und macht regelmäßig git pull. Eigene Bauteile sollen dann > auch in dem Pool angelegt und mit Pull request eingepflegt werden. > Derzeit ist das ein muss wenn man sein Projekt veröffentlichen will, da > Projekte die verwendeten Bauteile nicht zwischenspeichern. Steht aber > auch noch auf meiner todo-Liste, dass sich das ändert. Mal sehen, wie > die Idee mit dem globalen Pool so in der Praxis bewährt, falls > tatsächlich mal eine signifikante Anzahl von Leuten horizon ernsthaft > benutzt. Dann wird es in der Tat kritisch, wenn Andere Anwender Bauteile ändern und ich mir diese Änderungen auf mein Board hole. Für diesen Fall müsste man die verwendeten Bauteile auch im Projekt ablegen und nur auf Wunsch aus dem Pool auf den aktuellen Stand bringen. Ich glaube, dass man auf Dauer nicht um einen lokalen Pool herumkommt. Auch, weil für viele Anwender der Umgang mit git eine zu große Hürde ist. Ein globaler Pool erfordert vorallen genaue Regeln für die Vergabe von Bezeichnern und Dateinamen sowie eine sinnvolle Ordnerstruktur, sonst endet das schnell im Chaos. Eine grundsätzliche Frage zur Erstellung von Bauteilen haben ich auch noch. Wenn man z.B. ein DIP8 Package für einen ATtiny85 erstellt, dann kann so ein Package durchaus unterschiedliche Padstacks verwenden. Beispielsweise durchgängig runde Padstacks oder 7 runde und einen eckigen für Pin 1, oder auch ovale Padstacks. Dem Part ordnet man genau ein Package zu. Was ist, wenn der Anwender dieses Parts ein anderes Package verwenden möchte, das sich nur in den Padstacks unterscheidet? Braucht man dann mehrere Parts? In dem Zusammenhang noch eine Frage. Kann man die Zuordnung des Packages zum Part nachträglich ändern? Mir scheint als wird diese Zuordnung mit der Erstellung des Parts vorgenommen und kann nicht mehr geändert werden (es sei denn, man ändert direkt die .json Datei) > >> PS: Ein eigenes Forum oder eine Mailingliste hat horizon nicht, oder? > Für's Erste müssen der Thread hier und die Issues auf github reichen. So > groß war der Andrang bis jetzt noch nicht, dass sich das lohnen würde. > > Inzwischen gibt's auch einige neue potentiell nützliche Features: > - Man kann Canvas-Farbe und Grid-Darstellung einstellen > - "Dimensions" um im Board Abstände zu kennzeichnen > - Beim Routen wird nun wie bei KiCad oder Altium das Netz hervorgehoben > - Cross-Probing von Schaltplan zu Board und umgekehrt Stoße ich bestimmt noch drauf, wenn ich mich mal an ein Board mache. Uwe
Es wäre schön wenn sich die Nutzer mit Benutzernummer und Passwort in der Bibliothek einloggen würden. Wenn sie dann im Programm sind können sie dann ein Bauteil anklicken und es auf ihren Account im Internet laden. Alle anderen Nutzer sehen diese Bauteile dann ebenfalls und können darunter Kommentare schreiben oder dieses Bauteil bewerten. Es wäre schön wenn das alles aus der Anwendung heraus funktionieren würde, also ohne Browser. Für die Bauteile bräuchte man auch eine Versionierung und Mods müssten verhindern dass Unfug getrieben wird. Schön wäre es wenn man eine Favoritenliste anlegen kann in der nur die Bauteile sind die man so braucht. z.B. Widerstände, Kondensatoren, generell den Atmel-Chips-Ordner oder man wählt sogar nur den ATmega328P. Wenn ich nur SMD-Widerstände der Bauform 0603 verwende, dann sollte dieser Typ wenn man einen Widerstand einfügt als Voreinstellung gespeichert werden. Wie verändert ihr eigentlich die Breite der Leitungen?
Mike J. schrieb: > Mods müssten verhindern dass Unfug getrieben wird. Ziemlich viel Aufwand, meinst du nicht? Industrielle Anwender (falls die jemals im Blickfeld sein sollten) brauchen das alles nicht. Die wollen in den meisten Fällen sowieso alles von A bis Z selbst machen. OK, Symbole für Widerstände und Transistoren nimmt man sicher gern mit, aber alles, was nennenswert komplexer ist, gibt man da nicht aus der Hand.
Uwe S. schrieb: > Dem Part ordnet man genau ein Package zu. Was ist, > wenn der Anwender dieses Parts ein anderes Package verwenden möchte, das > sich nur in den Padstacks unterscheidet? Braucht man dann mehrere Parts? Derzeit ja, mal nachdenken wie man das am sinnvollsten handhaben kann. > In dem Zusammenhang noch eine Frage. Kann man die Zuordnung des Packages > zum Part nachträglich ändern? Eigentlich ist es nicht vorgesehen bereits im Pool vorhandene Bauteile zu Verändern. Zeitnah wird es noch ein "Deprectated"-Flag geben. Rein technisch gibt es hingegen keinen Grund weshalb das Package nicht änderbar ist. In einer früheren Version des Part Editors ging das auch mal, aber die Logik wurde mir dann für den Nutzen zu komplex und ist dann als der Pool Manger kam rausgeflogen. Mike J. schrieb: > Es wäre schön wenn sich die Nutzer mit Benutzernummer und Passwort in > der Bibliothek einloggen würden. [...] Gibt es doch schon, nennt sich github. Das deckt so ziemlich alle der Punkte ab, bis auf vielleicht Integration in die Anwendung. Wem die cli von git nicht gefällt, der soll eben einen der Zahlreichen GUI-Clients verwenden. Auf Server-Krams mit Benutzerverwaltung hab ich keinen Bock, das können und machen andere schon besser. Wenn jemand git-Integration in den Pool Manger einbauen will, gerne doch. Mike J. schrieb: > Schön wäre es wenn man eine Favoritenliste anlegen kann in der nur die > Bauteile sind die man so braucht. Gibt es schon im "Part Browser" im Projektmanager. Mike J. schrieb: > Wie verändert ihr eigentlich die Breite der Leitungen? Wurde von mir schon weiter oben im Thread ausführlich beantwortet. Jörg W. schrieb: > Industrielle Anwender (falls die jemals im Blickfeld sein sollten) > brauchen das alles nicht. Genau. Auch wenn das jetzt ein wenig arg ambitioniert klingen mag, sehe ich als Zielgruppe Entwickler von Projekten ca. dieser Größenordnung: http://hforsten.com/third-version-of-homemade-6-ghz-fmcw-radar.html Damit könnte es vielleicht auch für so manche Firma in ferner Zukunft interessant werden. Im Firmeneinsatz ist dann in der Tat vorgesehen, dass man sich seinen eigenen Pool pflegt. Der "Community"-Fall ist dann ähnlich, nur dass wir eben alle bei der selben Firma sind ;)
Lukas K. schrieb: > Gibt es doch schon, nennt sich github. Das deckt so ziemlich alle der > Punkte ab, bis auf vielleicht Integration in die Anwendung. Bezüglich der Integration würde es ausreichen einen visuellen diff für Schaltplan, Board und Packages zu haben. Also einen Viewer der zwei Board|Schematic|Package Dateien laden und diese vergleicht indem z.B. beide in unterschiedlichen Farben übereinander gelegt werden. Ich habe so etwas für KiCAD gabastelt, allerdings ist das recht unhandlich. Für den Schaltplan checke ich (in git) exportierte PDF Dateien mit ein, diese vergleiche ich dann mit diffpdf. Für Board Dateien generiere ich Gerber Dateien welche ich mit einchecke, diese lege ich dann auf zwei separate Layer (grün/rot) in gerbv, diese werden dann, bei Überlappung, gelb angezeigt, sonst in rot oder grün.
Ich habe ein Problem die neueste Version zu kompilieren:
1 | [ 478s] imp/imp_schematic.cpp: In lambda function: |
2 | [ 478s] imp/imp_schematic.cpp:252:27: error: 'void Gio::SimpleAction::set_state(const Glib::VariantBase&)' is protected within this context |
3 | [ 478s] cp_action->set_state(v); |
4 | [ 478s] ^ |
5 | [ 478s] In file included from /usr/include/giomm-2.4/giomm/actionmap.h:27:0, |
6 | [ 478s] from /usr/include/giomm-2.4/giomm.h:27, |
7 | [ 478s] from /usr/include/gtkmm-3.0/gtkmm.h:88, |
8 | [ 478s] from imp/main_window.hpp:2, |
9 | [ 478s] from imp/imp.hpp:2, |
10 | [ 478s] from imp/imp_schematic.hpp:2, |
11 | [ 478s] from imp/imp_schematic.cpp:1: |
12 | [ 478s] /usr/include/giomm-2.4/giomm/simpleaction.h:424:8: note: declared protected here |
13 | [ 478s] void set_state(const Glib::VariantBase& value); |
14 | [ 478s] ^~~~~~~~~ |
Mike J. schrieb: > Wie verändert ihr eigentlich die Breite der Leitungen? Helmut S. schrieb: > Warum ist eigentlich im Layout das Feld für Track->width grau(nicht > änderbar)? Das liegt daran, dass der Schalter "Width from rules" an ist. Damit werden die Leiterbahnbreiten entsprechend der Regeln unter "Track Width" gesetzt. Wie bei allen anderen Regeln auch wird die angewendet, die als erstes zutrifft.
Das Makefile (eines der ersten Dinge auf die ich schaue) sieht schonmal ordentlich aus. Problem: es wird eine neuere gtkmm-Version benötigt, die in vielen LTS-Distros nicht drin ist (bitte nicht immer auf bleeding-edge verlassen - das macht grade im Industrie-Bereich Schmerzen ;-)). Wäre schön, wenns auch ohne GLArea ginge. gtk(mm) hochziehen macht man auch nicht gerade in der Kaffepause, zieht einen ziemlich langen Rattenschwanz nach sich.
Enrico W. schrieb: > bitte nicht immer auf bleeding-edge > verlassen Diese Diskussion hatten wir schon ganz am Anfang. Kannst du da nachlesen, bevor du versuchst, sie hier neu aufzurollen.
Enrico W. schrieb: > Wäre schön, wenns auch ohne GLArea ginge. Und das schon gar nicht. GLArea kam mit GTK 3.16 -- darauf hatten viele gewartet, da es die Interaktion mit GL stark vereinfachen sollte. Und GTK 3.16 ist ja schon jetzt extrem alt, GTK3.20 oder 22 sollte heute eigentlich jeder haben. Wenn Horizon fertig ist, haben wir eh längst GTK4.
Enrico W. schrieb: > Problem: es wird eine neuere gtkmm-Version benötigt, die in vielen > LTS-Distros nicht drin ist Ich habe extra ein Xubuntu 17.10 aufgesetzt, damit compiliert Horizon (nach ein paar apt install) out-of-the-box. Selbst der Fehler von Frank K. (am 8.11.) kam bei mir nicht. 17.10 hat gcc 7.2. Ich bin inzwischen davon abgewichen, hier Backports zu fordern, weil 1) wenn Horizon für Endanwender benutzbar wird, sind eh die nächsten LTS Versionen da. Allerdings hoffe ich, dass dann Horizon nicht immer noch bleding edge ist, sondern z.B. mit der Ubuntus LTS 18.4 kompilierbar. Darauf sollte man achten 2) so sehr ich KiCad schätze, so nervt mich dann doch auch die verschiedenen Canvases. Horizon setzt gleich auf OpenGL, und dass ist gut. Ich habe gestern mit der neusten Version (von Horizon) mal eine Stunde gelayoutet. Der interaktive Router mit walk-around und PnS ist wirklich schon brauchbar! 3) Lukas scheint echt fähig zu sein! (Lob!) Ich will, dass er seine Zeit in die Weiterentwicklung (neue Features, Bugfixes) von Horizon steckt, nicht in Backports. Mir macht das Benutzen von Horizon inzwischen fast mehr Spaß als KiCad. Abgestürzt ist es mir gar nicht. Auch der Bauteileeditor scheint brauchbar zu sein. Alles wichtige scheint da zu sein! Lob! Wenn ich mehr Zeit habe, werde ich ein paar Bauteile anlegen und mal ein Projekt durchziehen. Das Pool Konzept ist (wenn man glaubt, es halbwegs verstanden zu haben) von der Idee her nicht schlecht. https://github.com/carrotIndustries/horizon/wiki/The-Pool Allerdings wird man wohl für (fertige) Projekte einen lokalen Pool haben wollen, oder man freezed die verwendeten Bauteile in der entsprechenden Version. Merkt sich der Pool die verwendete Version? Github sollte dies ja tun, aber auch der Pool auf meinem Rechner? Was ich beim layouten am meisten vermisst haben, war eine Option, verbundenen Leiterbahnsegmente auf einmal zu selektieren. Aber nochmal Lob an Lukas, bisher gute Arbeit!
tester schrieb: > Merkt sich der Pool die verwendete Version? Github sollte dies > ja tun, aber auch der Pool auf meinem Rechner? Dazu noch was: Wenn man ein Bauteil einsetze, dann prüft man ja, ob es für die Verwendung im Projekt geeignet, das "Richtige" ist. Nach diesem Vorgang möchte man ja keine Änderungen mehr. Wenn nun "jemand" im Github Pool das Bauteil ändert, hat man ja möglicherweise ein Problem. Auch wenn man ein Projekt weitergibt, sollte der Empfänger ja genau das "richtige" Bauteil verwenden. Mögliche Lösungsansätze: 1) Ein lokaler Pool, der zum Projekt abgespeichert bzw. mitgegeben wird Problem: Jetzt hat man durch die Hintertür das Libs Konzept wieder eingeführt, was zum Chaos führen kann 2) Horizon holt sich vom Github Pool genau das passende Bauteil in der damals verwendeten Version. Das sollte möglich sein. Problem: Wenn der Server nicht mehr erreichbar ist. Lösung: Auch der lokale Pool (als Clone von Github Pool) hat alle Versionen, nicht nur die aktuellste. Kann dann natürlich mit der Zeit sehr groß werden. 3) Horizon speichert zusätzlich alle verwendeten Bauteile im Projekt mit ab Bei einer Änderung des Bauteils kommt eine Nachricht, die die Unterschiede des lokalen Bauteils und des aktuellen aufzeigt (diff). Unterschied zur Lösung 1: Der "lokale" Pool für das Projekt ist hier versteckt. Er tritt nur auf, wenn explizit von Horizon eine Veränderung in einem bereits verwendeten Bauteil entdeckt wird. Ach ja: Im Moment sollte man in dieses Problem wohl noch keine größere Zeit investieren, es aber im Hinterkopf behalten.
tester schrieb: > Dazu noch was: Wenn man ein Bauteil einsetze, dann prüft man ja, ob es > für die Verwendung im Projekt geeignet, das "Richtige" ist. Nach diesem > Vorgang möchte man ja keine Änderungen mehr. Wenn nun "jemand" im Github > Pool das Bauteil ändert, hat man ja möglicherweise ein Problem. Auch > wenn man ein Projekt weitergibt, sollte der Empfänger ja genau das > "richtige" Bauteil verwenden. Sorry aber genau dieser Absatz sollte dir doch zeigen wie abstrus die Idee ist, quasi live auf öffentliche Bauteil-Repos zuzugreifen. NIEMAND der auch nur fortgeschrittener Hobbist ist, tut oder will so was. Ohne lokale Libs ist das ganze im (Semi) Prof. Bereich TOT. Hat von euch denn so gar niemand Erfahrung in diesem Bereich?
Cyblord -. schrieb: > Sorry aber genau dieser Absatz sollte dir doch zeigen wie abstrus die > Idee ist, quasi live auf öffentliche Bauteil-Repos zuzugreifen. Witzbold! Warum schrieb ich denn den Beitrag? Warum habe ich darauf hingewiesen und sogar mögliche Lösungsansätze gebracht? > NIEMAND der auch nur fortgeschrittener Hobbist ist, tut oder will so > was. Im Moment interessiert es aber nicht! Außerdem kann man jetzt schon Lösung 1 verwenden, also einen lokalen Pool zum Projekt betreiben. > Ohne lokale Libs ist das ganze im (Semi) Prof. Bereich TOT. Hat von euch > denn so gar niemand Erfahrung in diesem Bereich? Du bist wohl wie ein Tierarzt, der bei der geringsten Wunde beim Hund als einzige Lösung "einschläfern" bleibt.
Beitrag #5203516 wurde von einem Moderator gelöscht.
Beitrag #5203532 wurde von einem Moderator gelöscht.
Beitrag #5203536 wurde von einem Moderator gelöscht.
Lukas, wirst Du auf der FOSDEM im EDA Devroom vortragen?
Lukas K. schrieb: > Horizon kann genau das. Man kann ohne "Part" anfangen und später mit > "assign Part" dem "Component" ein "Part" zuweisen. Nachträglich kann man > natürlich das Part auch austauschen. Lukas K. schrieb: > Man will keinen generischen 10kOhm-Widerstand im Schaltplan haben, den > kann man nirgendwo kaufen. Jedes Bauteil im Schaltplan hat Hersteller > und Teilenummer, sodass man (in Zukunft) direkt die Stückliste bei > octopart einwerfen kann. Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts plazieren, z.B. den "base 0805 resistor", kann dem aber keine Werte zuweisen, also z.B. "10k". So macht das aber IMHO wenig Sinn. Ich will ja gerade beim Schaltplanzeichnen erst mal die Grundfunktionalität darstellen, ohne mich jetzt schon beim Hühnerfutter um die Bestellnummern kümmern zu müssen. Beim "basteln" kümmere ich mich eh nicht darum, da wird der vorhandene 0805 10k Widerstand aufgelötet. Lukas K. schrieb: > Was fehlt? Man kann auch erstmal generische Bauteile (nur Entity) ohne > Part platzieren und erst gegen Ende Parts zuweisen, wenn einem das so > besser gefällt. Wie geht das? Oder anders formuliert: Wie kann ich im Schaltplaneditor einem generischen Bauteil einen Wert zuweisen? Auch würde dieses Vorgehen die Bauteilebibliotheken gewaltig aufblähen. Grad bei Widerständen wird wird oft eine ganze Serie in dem Datenblatt über einen Kamm geschert und oft noch nicht mal genaue Abmessungen der Lötpads angegeben nur z.B. 0805.
tester schrieb: > Hm... Gut, dann hast Du es auch noch nicht verstanden :-) Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst z.B. nur "Diode", "Widerstand" oder "OpAmp" wähle. Weil ich ja oft noch gar nicht genau weiss was ich später genau haben will. Nachteil ist, dass man später sämtliche Elemente exakt spezifizieren muss, also etwa für alle Kondensatoren den Footprint eintragen. Wenn man gleich eine Kondensator mit Footprint gewäht hätte, hätte man diesen einfach nur kopieren können und wäre fertig -- etwa für die Abblockkondensatoren. Und dann möchte ich, dass man zunächst etwa "Widerstand" wählt, und erst dann das Bildchen dazu, also Kästchen oder ZickZack. Und dieses Bildchen soll man später auch ändern können. Bei OpAmp möchte ich OpAmpSingle wählen können, und dann entweder ein Bildchen mit VCC/VEE oder zwei separate Bildchen, eins für In+/In-/Out und eins für Power. Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das durch seine Pins spezifiziert ist. Jeder Pin hat einen Namen wie etwa Vcc oder ARef. Dann die Bildchen wählen, wobei eine Map_Datei die ursprünglichen Pins den Pins des Bildchens zuordnet. Eine weitere Map_Datei ordnet den Pins die Pads im Footprint zu. Ja, wenn man selbst überlegt statt irgendeine andere EDA Software abzukupfern, dann ist es nicht ganz so einfach. Na ich werde demnächst erst mal meinen Ruby Schaltplaneditor nach Nim portieren, vorläufig bleibe ich beim gEDA Fileformat. Später lese ich dann noch mal Lukas Ideen nach.
tester schrieb: > Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts > plazieren, z.B. den "base 0805 resistor" Du kannst auch Components platziern, "place component" heißt das tool dazu. Da ist dann weder Package noch Part noch Wert daran. Die Netzliste kennt nur Components mit Entities. Optional kann dann dem Component ein Part zugewiesen werden, wobei die Entity des Parts gleich der Entity des Components sein muss. tester schrieb: > Auch würde dieses Vorgehen die Bauteilebibliotheken gewaltig aufblähen. Jedes Part im Pool braucht eine MPN, damit man einfach die BOM erzeugen kann. Stefan S. schrieb: > Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst z.B. nur > "Diode", "Widerstand" oder "OpAmp" wähle. Weil ich ja oft noch gar nicht > genau weiss was ich später genau haben will. Genau so ist es. Siehe oben. Stefan S. schrieb: > Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das durch seine > Pins spezifiziert ist. Jeder Pin hat einen Namen wie etwa Vcc oder ARef. So ist es hier auch. > Dann die Bildchen wählen, wobei eine Map_Datei die ursprünglichen Pins > den Pins des Bildchens zuordnet. Theoretisch können einer Unit mehrere Symbole zugeordnet sein. > Eine weitere Map_Datei ordnet den Pins > die Pads im Footprint zu. Ist bei horizon im Part mit drin.
Hallo Lukas, was macht denn "smash" mit einem Bauteil im Schaltplan bzw. im PCB-Layout? Ich sehe da keinerlei Änderung des Bauteils, wenn ich "smash" wähle.
Lukas K. schrieb: > tester schrieb: >> Hm... irgendwie widersprichst du dir da. Ich kann zwar generische Parts >> plazieren, z.B. den "base 0805 resistor" > > Du kannst auch Components platziern, "place component" heißt das tool > dazu. Da ist dann weder Package noch Part noch Wert daran. Die Netzliste > kennt nur Components mit Entities. Optional kann dann dem Component ein > Part zugewiesen werden, wobei die Entity des Parts gleich der Entity des > Components sein muss. Ok, jetzt wird mir die Vorgehensweise klarer. Aber ist das "zuweisen" nicht eher ein "ersetzen"? Wenn ich meinem Component "two terminal resistor" ein "base 0805 resistor" zuweise, ist mein Value Wert "10k" wieder weg. Also muss letzten Endes genau ein Part mit den nötigen Werten existieren. Ok, das geht schnell, mit "Create Part from Part" im Pool Manager. Ok, verstanden, nicht die schnellste Lösung aber machbar.
Helmut S. schrieb: > Ich sehe da keinerlei Änderung des Bauteils, wenn ich "smash" wähle. Da hat wohl einer nie EAGLE benutzt ;) Smash macht, dass man im Schaltplan und Board die einem Symbol/Package zugeordneten Texte verschiebbar werden. Braucht man also spätestens wenn man auf dem Board die Silkscreen-Texte verschieben will. tester schrieb: > Also muss letzten Endes genau ein Part mit den nötigen > Werten existieren. Genau, einen Widerstand mit einem Wert den man eintippt kann man nicht bei Digikey kaufen. > Ok, das geht schnell, mit "Create Part from Part" im Pool Manager. Ok, > verstanden, nicht die schnellste Lösung aber machbar. Es ist Leuten auch freigestellt, Parts mit Skripten en masse zu erzeugen, wenn man z.B. eine ganze Serie von Widerständen einpflegen will.
Lukas K. schrieb: > Braucht man also spätestens wenn man auf dem Board die Silkscreen-Texte > verschieben will. Eigentlich eins der Features, die ich nach dem Weggang von Eagle nie vermisst habe – jetzt, wo du es sagst. Wenn man einen Text verschieben will, fasst man ihn einfach an und schiebt ihn. Während des Schiebens wird sinnvoller Weise eine Linie dargestellt, zu welchem Bauteil der Text denn gehört. Dabei ist es ziemlich egal, ob ich nun gerade im Layout oder im Schaltplan bin; Texte aus dem Weg zu schieben, braucht man in beiden. Wenn überhaupt, dann braucht man eher das Gegenteil mal: für ein bestimmtes Bauteil die Texte auf Standardanordnung zurücksetzen. Habe ich aber, ehrlich gesagt, auch höchst selten Bedarf dafür. Könnte eigentlich Horizon in einer VMware laufen? Das wäre eine Variante, wie ich mir mal sowas wie das genannte Xubuntu 17.10 parallel zu Produktivsystemen installieren könnte, um Horizon zu testen. Bezüglich 3D in der VM: Altium Designer hat kein Problem damit, und läuft durchaus flüssig.
Angehängte Dateien:
-
horizon2.png
160 KB
Ok, jetzt zum Pool Manager. Ich habe versucht, einen 2x2- Pin Header anlegen (für den RPi). Es gab ja nur einen Padstack mit Loch, der war mir zu klein. Ich wollte einen neuen anlegen, habe aber nicht geschafft, ihm einen Namen zuzuweisen. Edit: Ok, gefunden, man muss im Editor auf den "Pfeil nach unten" klicken. Ok, wenn man es nicht weiß... die Menüzeilen von Horizon sind nicht gerade intuitiv. Ich hätte jetzt eher in einem Menü Datei gesucht, z.B. "Set Name". Dort könnte man auch das "Save" unterbringen. Aber: wie werde ich meine missglückten Versuche wieder los?
Angehängte Dateien:
-
horizon4.png
56 KB
Jetzt hänge ich. Was muss ich wo eintragen, damit ich das Part erfolgreich speichern kann?
Jörg W. schrieb: > Lukas K. schrieb: >> Braucht man also spätestens wenn man auf dem Board die Silkscreen-Texte >> verschieben will. > > Eigentlich eins der Features, die ich nach dem Weggang von Eagle nie > vermisst habe – jetzt, wo du es sagst. Schön ist's nicht so hat sich das leider ergeben... Mal sehen ob mir in Zukunft da noch was besseres einfällt. Man kann ja auch einfach alles markieren und smash drücken. > Könnte eigentlich Horizon in einer VMware laufen? Das wäre eine > Variante, wie ich mir mal sowas wie das genannte Xubuntu 17.10 parallel > zu Produktivsystemen installieren könnte, um Horizon zu testen. > Bezüglich 3D in der VM: Altium Designer hat kein Problem damit, und > läuft durchaus flüssig. Könnte gut funktionieren wenn VMWare OpenGL 3 kann. tester schrieb: > Aber: wie werde ich meine missglückten Versuche wieder los? Im Dateimanager dies JSON-Dateien löschen. Wie oben geschrieben, soll was einmal im Pool ist eigentlich drin bleiben, daher kann der Pool Manager nichts löschen. tester schrieb: > Ok, gefunden, man muss im Editor auf > den "Pfeil nach unten" klicken. Seit gerade eben gibt es da nun einen Platzhaltertext. tester schrieb: > Der interaktive Router mit walk-around und PnS ist > wirklich schon brauchbar! Ich will mich hier jetzt nicht mit fremden Federn schmücken, das ist einfach der Router, den Leute am CERN für KiCad gebaut haben. Ich hab' den nur eingebaut. tester schrieb: > Aber nochmal Lob an Lukas, bisher gute Arbeit! Danke für die Blumen :) Uwe B. schrieb: > wirst Du auf der FOSDEM im EDA Devroom vortragen? Ist eingereicht, mal sehen ob's akzeptiert wird ;) tester schrieb: > Jetzt hänge ich. Was muss ich wo eintragen, damit ich das Part > erfolgreich speichern kann? Okay, jetzt wo ich das so seh' ist "Location" der falsche Name für die Felder. Filename wäre besser, weil da der volle Dateiname mit .json-Endung rein muss.
Stefan S. schrieb: > Ich würde einen Auswahlprozess bevorzugen, wo ich zunächst > z.B. nur "Diode", "Widerstand" oder "OpAmp" wähle. Weil > ich ja oft noch gar nicht genau weiss was ich später genau > haben will. Ahh. Ich bin also doch nicht GANZ allein. Danke, Stefan. > Nachteil ist, dass man später sämtliche Elemente exakt > spezifizieren muss, also etwa für alle Kondensatoren den > Footprint eintragen. Um diese Zuordnung zu erleichtern, kann man vom User wählbare Standardannahmen vorsehen. So kenne ich das auch aus der Praxis: "Wenn nix anderes gesagt wird, ist Hühnerfutter immer 0805" -- nur als Beispiel. > Wenn man gleich eine Kondensator mit Footprint gewäht > hätte, hätte man diesen einfach nur kopieren können > und wäre fertig -- etwa für die Abblockkondensatoren. Naja, das entspricht nicht meiner Denk- und Arbeitsweise. Wenn ich einen Schaltplan male, will ich nicht darüber nachdenken müssen, welche Prüfspannung und welche Belast- barkeit der Widerstand haben muss -- da will ich nur einen abstrakten, idealen Widerstand in die Schaltung einfügen. Wenn die Schaltung dimensioniert ist, guckt man sowieso häufig nochmal durch, ob sich das benötigte Bauelemente- sortiment verkleinern lässt. > Und dann möchte ich, dass man zunächst etwa "Widerstand" > wählt, und erst dann das Bildchen dazu, also Kästchen > oder ZickZack. Und dieses Bildchen soll man später auch > ändern können. Genau. Das ärgert mich auch immer. -- Dazu braucht man aber eine Taxonomie für die Bauteile; die Symbole müssten entsprechende Tags mitbringen, die angeben, in welche Äquivalenzklasse sie gehören. Rein elektrisch ist ja scheissegal, ob da ein Ami- oder ein DIN-Widerstand drin ist. Eigentlich wünsche ich mir, dass man einen Schaltplan mit Ami-Symbolen laden und per Knopfdruck alles auf Euro-Symbole umstellen kann. > Bei OpAmp möchte ich OpAmpSingle wählen können, und dann > entweder ein Bildchen mit VCC/VEE oder zwei separate Bildchen, > eins für In+/In-/Out und eins für Power. Ahh. Die Idee ist gut. Man bräuchte einen DRC für den Schalt- plan und entsprechende Entwurfsregeln, die angeben, dass jeder "abstrakte" OPV auch eine Stromversorgung braucht. Eigentlich bräuchte man zwei Schaltpläne bzw. zwei Ansichten: Eine mit der "abstrakten" Schaltung, und eine, aus der die Zuordnung hervorgeht, welcher abstrakte OPV zusammen mit welchen anderen in einem Gehäuse steckt. Hier müsste man festlegen (können), wo Pinswap/Gateswap zugelassen ist und wo nicht. > Grundsätzlich wäre der Dialog bei mir: Bauteil wählen, das > durch seine Pins spezifiziert ist. Ja -- wobei das "abstrakte" Pins sind, nicht die greifbaren Anschlüsse am Gehäuse. > Jeder Pin hat einen Namen wie etwa Vcc oder ARef. Dann die > Bildchen wählen, wobei eine Map_Datei die ursprünglichen > Pins den Pins des Bildchens zuordnet. Eine weitere Map_Datei > ordnet den Pins die Pads im Footprint zu. Angewandte Graphentheorie. Die (topologische) Struktur des Schaltplans ändert sich nicht, wenn ein Bauteil durch ein äquivalentes oder verträgliches Bauteil ersetzt wird. Ein Festwiderstand lässt sich (topologisch) äquivalent durch einen anderen Festwiderstand oder einen ungepolten Kondensator ersetzen; verträgliche Ersetzung geht durch einen Elko oder eine Diode; Ersetzung durch einen Transistor geht nicht. Konkrete Bauteile oder gar Footprints kommen erst viel später ins Spiel. > Na ich werde demnächst erst mal meinen Ruby Schaltplaneditor > nach Nim portieren, Warum? Ist dir Ruby nicht mehr exotisch genug? > vorläufig bleibe ich beim gEDA Fileformat. Schön. -- Totgesagte leben übrigens länger: Im Chat sagte der Boss von pcb-rnd, dass auch ein Fork für gschem in Arbeit ist.
Possetitjel schrieb: > Warum? Ist dir Ruby nicht mehr exotisch genug? Ruby mit seinem Bytecode-Interpreter und dynamischer Typisierung wäre heute wie auch Python eben nicht mehr meine erste Wahl. 2010 als ich mit Ruby anfing war das noch anders, da gab es all die interessanten neuen Sprachen noch nicht. Und die GTK3-Unterstützung von Ruby ist wohl auch nicht mehr ganz so toll, Ruby-GTK scheint auch kaum jemand noch zu verwenden. Und Ruby ist in den letzten Jahren ja (leider) vom Python weitgehend abgehängt worden. Aber bei den neuen Sprachen hat man nahezu die Geschwindigkeit von C und die Einfachheit bzw. das Abstraktionsniveau von Ruby/Python. Und für grössere Projekte bietet die statische Typisierung Vorteile. Ob nun Nim die beste Wahl war wird man dann in 10 Jahren sehen -- mir scheint es momentan die universellste Sprache zu sein, und ich habe auch schon einige Zeit in die GTK Bindings investiert. Aber ich wüsste fast ein Dutzend weiterner sehr interessanter Sprachen -- Crystal hätte sich vielleicht noch eher angeboten, da es Ruby sehr ähnlich ist.
Stefan S. schrieb: > Possetitjel schrieb: >> Warum? Ist dir Ruby nicht mehr exotisch genug? > > Ruby mit seinem Bytecode-Interpreter und dynamischer > Typisierung wäre heute wie auch Python eben nicht mehr > meine erste Wahl. Dynamische Typisierung sehe ich ein -- aber wen interessiert der Bytecode? Wenn es WIRKLICH nicht schnell genug läuft, muss man über einen besseren Algorithmus nachdenken oder die kritischen Teile in eine "richtige" Programmiersprache übertragen. Scriptsprachen sehe ich als Werkzeug für "Rapid Prototyping". > Und die GTK3-Unterstützung von Ruby ist wohl auch nicht > mehr ganz so toll, Ruby-GTK scheint auch kaum jemand noch > zu verwenden. Und Ruby ist in den letzten Jahren ja (leider) > vom Python weitgehend abgehängt worden. Die Logik erschließt sich mir nicht. Wer auf der Suche nach seiner ersten Scriptsprache ist, ist natürlich ziemlich frei in seiner Entscheidung -- und wird sich auch bei sehr neuen Sprachen umsehen. Wer eine Sprache halbwegs beherrscht und ein konkretes Problem lösen will -- warum sollte der freiwillig wechseln? Was der Anwendungssoftware fehlt, ist doch nicht technischer Schnickschnack, sondern echte Integration in die Arbeits- abläufe. Das hängt nicht von der Programmiersprache ab. > Aber bei den neuen Sprachen hat man nahezu die Geschwindigkeit > von C Wann braucht man das? Was C vor 20 Jahren konnte, kann heute eine Scriptsprache. > Und für grössere Projekte bietet die statische Typisierung > Vorteile. Ja -- den Punkt kann ich nachvollziehen. (Bei dynamischer Typisierung weiss man nicht, wo man die Kommentare hinschreiben soll -- SCNR) > Ob nun Nim die beste Wahl war wird man dann in 10 Jahren > sehen -- mir scheint es momentan die universellste Sprache > zu sein, und ich habe auch schon einige Zeit in die GTK > Bindings investiert. Gerade im Kontext dieses Threads verstehe ich das nicht. Ich konnte von Deinem Schaltplaneditor nur eine uralte Version ausprobieren, weil bei mir zufälligerweise nur GTK2 (und nicht GTK3) installiert ist. Als Grund für GTK habe ich das Anti-Aliasing beim Rendering herausgelesen. Also habe ich experimentiert. Die gEDA-Symbole sehen ohne Antialiasing übel aus. Man kann Antialiasing mit Standard-Tk emulieren, wenn man Symbole mit unterschiedlichen Linienbreiten grau und schwarz übereinanderdruckt. Nicht gerade elegant, aber es sieht VIEL besser aus -- und funktioniert mit Standard-Tk. Wozu nochmal genau brauche ich GTK3?
Angehängte Dateien:
-
horizon5.png
32 KB
Noch was zu den Padstacks: Bei den Parametern habe ich den "Text" einfach von vorhanden TH Pad kopiert. Das sieht alles nach RPN aus, Forth? Was ist der Hintergrund, hier ein Script einzubauen?
Possetitjel schrieb: >Als Grund für GTK habe ich das Anti-Aliasing beim Rendering >herausgelesen. Nein. GTK hat mit dem Rendering nichts zu tun. Ich zeichne derzeit mit Cairo, da es einfach zu nutzen ist und sehr gute Qualität liefert. Auch Bezier-Kurven, und Backends wie PDF. Vor GTK 3.16 gab es noch keine GL-Area, da war die Nutzung von OpenGl in GTK Anwendungen schwierig und aufwendig. Ich werde erstmal bei Cairo bleiben. Wirklich schöne Grafiken sind mit GL nicht so einfach realisierbar. > Wozu nochmal genau brauche ich GTK3? Woher soll ich wissen was Du brauchst. Vielleicht kommst Du ja auch ganz ohne Computer aus? Wenn Du jetzt meinst gegenüber GTK2? Das wird ja seit Jahren nicht mehr gepflegt -- will das noch irgendwer nutzen? Und ob Ruby mit GTK2 besser funktioniert, weiss ich nicht -- 2011 ging Ruby 1.8 mit GTK2 in der Tat recht gut. Aber Sprachen wie Ruby/Python mit Bytecode-Interpreter sind halt eher etwas langsam. Da ist selbst Go und Haskell weit schneller. Tatsächlich gibt es nur wenige Fälle, wo Performance egal ist. Bei EDA braucht man schon etwas Leistung, und man möchte halt nicht immer den neuesten Rechner kaufen müssen, der einem dann mit Volllast den Akku leersaugt.
tester schrieb: > Was ist der Hintergrund, hier ein Script einzubauen? Horizon kann Padstacks die aus mehreren Shapes zusammengesetzt sind, z.B. "SMD half obround". Um Dinge wie Größe, Abstand der Lötstopmaske, etc. anzupassen müssen Position und Größe der einzelnen Shapes entsprechend angepasst werden. Die simpelste Lösung, die mir dazu einfiel, war eben Padstacks ein Skript beizulegen was dies anhand der Parameter macht. Eine "richtige" Skriptsprache wie Python oder TCL wollte ich an der Stelle nicht haben, da die Skripte nicht beliebig lange laufen dürfen. Dokumentiert ist die Sprache an dieser Stelle: https://github.com/carrotIndustries/horizon/wiki/Parameter-programs
Stefan S. schrieb: > Possetitjel schrieb: > >>Als Grund für GTK habe ich das Anti-Aliasing beim >>Rendering herausgelesen. > > Nein. GTK hat mit dem Rendering nichts zu tun. Dann verstehe ich's nicht. >> Wozu nochmal genau brauche ich GTK3? > [...] > > Wenn Du jetzt meinst gegenüber GTK2? Nein, ich meine z.B. gegenüber Tk. Tcl/Tk ist der historische Ursprung; Tkinter (Python) ist mW Standard; Perl/Tk und Ruby/Tk sind zumindest verfügbar. Wenn man eine ausgesprochene Nischenanwendung (wie EDA) im Sinn hat, wäre es doch logisch, die rein technischen Hürden niedrig zu halten, damit von den ohnehin wenigen potenziellen Mitstreitern nicht auch noch welche durch vermeidbare Komplikationen abgeschreckt werden. Davon ist z.B. beim Original-gEDA auch nix zu merken (Scheme?! Warum denn nicht gleich Brainfuck?); pcb-rnd proklamiert aber, es besser zu machen. Du schriebst, Du habest reichlich "Zeit in die GTK-Bindings investiert" (was immer das heissen mag). Entschuldige mein tiefgreifendes Unwissen, aber ich habe (mangels Wissen und mangels Bedarf) noch nie Zeit in irgend welche Tcl-Bindings investiert. In meinem Script steht etwas wie "canvas .c; pack .c", und dann kann ich loszeichnen. Das geht, soweit ich gehört habe, so ähnlich auch in python, ruby oder perl. Was fehlt noch? > Aber Sprachen wie Ruby/Python mit Bytecode-Interpreter sind > halt eher etwas langsam. Ja und? Das Problem bei dem ganzen EDA-Krempel liegt doch nicht in der internen Verwaltung der Daten, sondern in der Wechselwirkung von GUI und Arbeitsablauf. Da man sowieso eine Trennung von GUI und Geschäftslogik haben will, kann man die Datenhaltung auch in irgendwas compiliertes auslagern, wenn die Zeit dafür reif ist. (Schätzungsweise könnte man das sogar einer SQL-Datenbank beibringen.) Niemand sagt, dass die Anwendung vollständig und auf Dauer in einer Scriptsprache geschrieben sein muss -- aber es ist ein guter Startpunkt, um das GUI und die eigene Arbeitsweise aneinander anzupassen. > Da ist selbst Go und Haskell weit schneller. Mich würde mal ein detailierter Vergleich zwischen Ruby und Tcl interessieren -- nicht wegen "Meiner ist länger", sondern um eine sachliche Entscheidungsgrundlage zu haben. Da ich ausschließlich Tcl verwende, kann ich nicht vergleichen. > Tatsächlich gibt es nur wenige Fälle, wo Performance egal > ist. Du möchtest doch jetzt nicht ernsthaft behaupten, dass Graphikkarten mit Füllraten im GPixel/s-Bereich und Prozessoren mit GFLOPS/s nicht schnell genug sind, ein paar Dutzend zweidimensionale (!) schwarz-weisse (!) Symbole anständig auf den Bildschirm zu bringen? > Bei EDA braucht man schon etwas Leistung, Das wäre erst noch zu beweisen. Was schätzungsweise wirklich Leistung braucht, ist diese schreckliche Zoomerei mit dem Mausrad, die ja leider Standard ist. Die Schaltplansymbole rendern könnte auch ein Z80, die Verbindungen legen und auf Mausereignisse reagieren auch. > und man möchte halt nicht immer den neuesten Rechner kaufen > müssen, der einem dann mit Volllast den Akku leersaugt. Natürlich, da sind wir einer Meinung. Die Kernfrage ist aber, was man mit der verfügbaren Leistung anfängt. Beim Herumlesen auf Deiner Homepage hatte ich (schon vor Jahren) Hoffnung geschöpft, weil Du einige aus meiner Sicht ziemlich kluge Entscheidungen getroffen hast: - Du hast Dich auf einen Schaltplaneditor beschränkt, - Du hast gute Ergonomie als ausdrückliches Ziel formuliert, - Du hast Dich aus dem Symbolvorrat von gEDA bedient und - Du hast rapid-prototyping-mäßig eine Scriptsprache verwendet. Leider ist programmiertechnisch unsere Schnittmenge leer; Du verwendest Ruby/GTK3 (mit Kurs auf Nim/GTK3), ich bin bei Tcl/Tk. Bis Ruby/Tk oder Tcl/GTK könnte ich Dir wahrscheinlich auf längere Sicht entgegenkommen, aber mehr kann ich nicht leisten. GUI-Toolkit UND Sprache wechseln kann ich nicht. Also wird es wohl auf dem Stand bleiben, den Du enttäuscht beklagt hast: Es interessiert sich (scheinbar) niemand für Deine Software.
>Du schriebst, Du habest reichlich "Zeit in die GTK-Bindings >investiert" (was immer das heissen mag). >Entschuldige mein tiefgreifendes Unwissen, aber ich habe >(mangels Wissen und mangels Bedarf) noch nie Zeit in irgend >welche Tcl-Bindings investiert. Solche Bindings fallen ja nicht so einfach vom Himmel. Für Nim gibt es zwar das Tool c2nim das einem für low-level Bindings viel Arbeit abnimmt, aber es bleibt doch viel Arbeit. Und auch mit gobject-introspection, mit dessen Hilfe ich die High-Level Bindings gemacht habe, bleibt es viel Arbeit. Aber die Leute, die Bindings für andere Sprachen wie Python, Ruby, Perl, C++ usw. gemacht haben hatten wohl noch weit mehr Arbeit. >Du möchtest doch jetzt nicht ernsthaft behaupten, dass >Graphikkarten mit Füllraten im GPixel/s-Bereich und Prozessoren >mit GFLOPS/s nicht schnell genug sind, ein paar Dutzend >zweidimensionale (!) schwarz-weisse (!) Symbole anständig auf >den Bildschirm zu bringen? Ja bei Linux ist das leider so, sofern die CPU das Rendering macht. Cairo wie auch Skia und andere CPU Rendering Bibliotheken sind nicht besonders schnell. Daher hat Lukas ja auch gleich OpenGL verwendet. Wobei auch OpenGl für hochqualitative Liniengraphiken nicht so sonderlich schnell ist. Für Cairo gibt es ein OpenGL Backend, das aber langsamer als das CPU Backend ist. Intel werkelt ja gerade an FastUIDraw, und GTK4 hat ein Vulkan Backend. Zusammen mit Wayland wird es dann hoffentlich alles deutlich schneller. >Was schätzungsweise wirklich Leistung braucht, ist diese >schreckliche Zoomerei mit dem Mausrad, die ja leider Standard >ist. Die Schaltplansymbole rendern könnte auch ein Z80, die >Verbindungen legen und auf Mausereignisse reagieren auch. Auch wenn Du Dinge verschiebst musst Du ja die aufgedeckte Fläche neu Zeichnen, für jeden Maustick neu, also bis zu 60 mal pro Sekunde. Und wenn man sich das Leben sehr einfach machen will, zeichnet man jeweils den kompletten Screen komplett neu. Mit OpenGL kann man das machen, mit CPU-Rendering stösst man da aber schnell an Grenzen. Man kann dann aber für Objekte Bounding-Boxen definieren und zeichnet jeweils nur das, was unter dem sich bewegenden Object ist neu. Ist aber etwas mehr Programmierarbeit. >ich bin bei Tcl/Tk. Gibt es denn überhaupt noch ernsthafte Software mit grösserem Anwenderkreis die das verwendet? Mir fällt da nicht viel ein.
Stefan S. schrieb: >>Du schriebst, Du habest reichlich "Zeit in die GTK- >>Bindings investiert" (was immer das heissen mag). >>Entschuldige mein tiefgreifendes Unwissen, aber ich >>habe (mangels Wissen und mangels Bedarf) noch nie >>Zeit in irgend welche Tcl-Bindings investiert. > > Solche Bindings fallen ja nicht so einfach vom Himmel. Nein, natürlich nicht. Mir dämmert aber langsam, dass wir möglicherweise in verschiedenen Welten leben. In Tcl hat man von Hause aus Zugriff auf das Tk, dessen Canvas komplette Graphik (inklusive PostScript-Export) bietet. Im Prototyp-Stadium ist also ohnehin klar, dass die Graphikausgabe von Tk erledigt wird; damit kann man das GUI, die Benutzerführung usw. erproben und schon kleinere Projekte bearbeiten. Falls man später schnellere Graphik braucht (was bisher bei mir noch nie der Fall war), muss man zu einer externen Bibliothek übergehen oder die Anwendung portieren -- aber dann ist die Grundstruktur des Programmes schon in der Praxis getestet. Deswegen sind mir die "richtungsweisenden" Diskussionen über die beste Graphikbibliothek bisher verschlossen geblieben -- man will sowieso zuerst einen Prototypen in einer Scriptsprache bauen, und welche Graphik der verwendet, steht bei mir sowieso fest. >>Du möchtest doch jetzt nicht ernsthaft behaupten, dass >>Graphikkarten mit Füllraten im GPixel/s-Bereich und >>Prozessoren mit GFLOPS/s nicht schnell genug sind, ein >>paar Dutzend zweidimensionale (!) schwarz-weisse (!) >>Symbole anständig auf den Bildschirm zu bringen? > > Ja bei Linux ist das leider so, sofern die CPU das > Rendering macht. Cairo wie auch Skia und andere CPU > Rendering Bibliotheken sind nicht besonders schnell. Naja, wie schon gesagt: Tk bietet einen komplett graphik- fähigen Canvas; um die Benutzerführung usw. zu testen, war der mir bisher schnell genug. Da man Programmlogik und Userinterface sowieso programm- technisch trennen will, sollte die Einbindung einer externen Graphikbibliothek kein Hexenwerk sein, wenn das notwendig wird. Habe ich aber noch nie gemacht. > Auch wenn Du Dinge verschiebst musst Du ja die aufgedeckte > Fläche neu Zeichnen, für jeden Maustick neu, also bis zu > 60 mal pro Sekunde. Naja. > Und wenn man sich das Leben sehr einfach machen will, > zeichnet man jeweils den kompletten Screen komplett neu. Ja -- jetzt kommen wir der Wahrheit näher: Schonender Umgang mit der Rechenleistung macht den Programmierern einfach keinen Spaß. Es ist ja auch viel leichter, die Schuld auf die schlechten APIs zu schieben, als Algorithmen zu entwickeln, die mit wenig Rechen-/Graphikleistung auskommen. > Mit OpenGL kann man das machen, mit CPU-Rendering > stösst man da aber schnell an Grenzen. Ja -- wie der Zyniker in mir schon sagte: Software zu schreiben, die TROTZ beschränkter Ressourcen gut bedienbar ist, ist einfach nicht hipp. Also macht es keiner. >>ich bin bei Tcl/Tk. > > Gibt es denn überhaupt noch ernsthafte Software Vereinzelt bin ich über solche gestolpert; kann aber aus dem Hut keine Namen nennen. Tcl/Tk wird aktiv weiterentwickelt; Version 8.6 bringt ziemlich viele Erweiterungen. Ich sehe das auch nicht als Werkzeug, um auf Dauer größere Applikationen zu entwickeln. Für rapid prototyping finde ich es ideal. > mit grösserem Anwenderkreis die das verwendet? Mir fällt > da nicht viel ein. Mir auch nicht -- aber ich gestehe, dass mir das VOLLSTÄNDIG egal ist. Tcl/Tk kann (fast) alles, was ich brauche, um zu einem für mich akzeptablen Ergebnis zu kommen. (Numerik geht nicht gut; das ist ein Furunkel am Arsch. Umgang mit Binär- dateien ist grenzwertig.) In der alten Firma gab's eine recht lustige Arbeitsteilung: Unser Programmierer hat kein Tcl verwendet, fand es aber einfach genug zu lesen, um die von mir zusammengenagelten Prototypen verstehen und in die offizielle Applikation integrieren zu können. Das war ziemlich cool.
Angehängte Dateien:
-
horizon5.png
58 KB -
horizon6.png
2,8 KB -
horizon7.png
5,1 KB
So, ich habe mir jetzt mal die Mühe gemacht und einen Schaltplan gezeichnet. Dazu noch ein paar Anmerkungen: - Im Prinzip ist alles da! Manches ist nur etwas umständlich. Horizon ist mir dabei aber nicht abgestürzt. Ist also schon relativ stabil! - Im Schaltplan Editor erkennt Horizon nicht, wenn zwei Pins von Bauteilen auf einer Junction liegen. Im angehängten Beispiel ist z.B. C5 und C6 nicht verbunden. Wenn man das Bauteil verschiebt (vom Juction weg), erkennt Horizon, dass es nicht verbunden ist. - Ich habe ein paar Bauteile angelegt. Am einfachsten geht Hühnerfutter, die kann man sehr schön im Horizon Pool Manager durch "Make Part from Part" anlegen. Dabei kann man sowohl den Pool Manager als auch den Projekt Manager mit Schema und PCB offen lassen. Nach dem Anlegen bzw. einem "Update Pool" sind die Bauteile vorhanden - Etwas komplizierter sind ganz neue Bauteile. Ich bin meist so vorgegangen, dass ich erst im Pool Manager ein Package angelegt und dann den Part Wizard gestartet habe. Das funktioniert soweit. Nervig sind nur die vielen Eintragungen am Ende des Managers. Siehe Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" Oft trägt man doch immer die gleichen Verzeichnisse ein. Z.b. für den Wolfson WM8731 Codec:
1 | tester@Yoga:~/horizon/horizon-pool$ find . -iname "*8731*" |
2 | ./units/ic/codec/wolfson/WM8731.json |
3 | ./symbols/ic/codec/wolfson/WM8731.json |
4 | ./entities/ic/codec/wolfson/wm8731.json |
5 | ./parts/ic/codec/wolfson/WM8731.jsonn |
Evtl. könnte man das sinnvoll vorbelegen. Wenn man z.B. des Filenamen für die Entity eingegeben hat, dass für Untits, Symbols und Parts das automatisch übernommen wird. Wichtig ist dann noch, die Units und Entities durchzugehen, um fehlende Einträge zu ergänzen, wie z. B. den Prefix bei Entities. - Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt. Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu skalieren kann. Trifft das zu? - Raster: Beim Bearbeiten von Schaltplänen und Packages kann ich kein Raster (mehr) einstellen. Dachte, dass dies schon mal ging. Wenn man Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das Raster ausschalten, aber beim Versuch, mit der linken Maustaste die neue Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht angenommen. - Auch das Ausrichten eines neuen Objekts an bestehenden Objekten nervt manchmal, z.b. wenn man im Schaltplan Objekte dicht nebeneinander platzieren möchte. Kann man dies ausschalten? - Variabler Text: Gibt es neben $RD bei den Packages und $REFDES und $VALUE bei den Symbolen weitere? - Neue Bauelemente: Ich habe ja nun ein paar angelegt, bin mir aber unsicher, ob ich die hochladen soll, da die sicher noch Fehler haben. Fazit: Auch wenn es noch nicht ganz rund läuft, kann man mit Horizon schon arbeiten. Lob!
Noch was: Horizon meckert ja, wenn man zwei Netze den selben Namen gibt. Man muss ja den Namen, wenn er schon mal vorhanden ist, per "Move net segment to other net" oder "Move net segment to new net" zuweisen. Was spricht dagegen, Horizon dies implizit machen zu lassen, wenn ein Netzname eingegeben wird der schon mal vorhanden ist? Weil der Netzname intern an einer UUID hängt? Powersymbole habe ich gar nicht verwendet, sondern bin nur über die Netznamen gegangen. Irgend welche Nachteile?
tester schrieb: > So, ich habe mir jetzt mal die Mühe gemacht und einen Schaltplan > gezeichnet. Dazu noch ein paar Anmerkungen: Vielen, vielen Dank! > - Im Prinzip ist alles da! Manches ist nur etwas umständlich. Horizon > ist mir dabei aber nicht abgestürzt. Ist also schon relativ stabil! > > - Im Schaltplan Editor erkennt Horizon nicht, wenn zwei Pins von > Bauteilen auf einer Junction liegen. Im angehängten Beispiel ist z.B. C5 > und C6 nicht verbunden. Wenn man das Bauteil verschiebt (vom Juction > weg), erkennt Horizon, dass es nicht verbunden ist. Okay, die Verbindung so wie im Bild 6 sind in horizon nicht sinnvoll möglich. Pins von Symbolen können nur mit Netzlinien verbunden sein, nicht direkt mit Junctions oder anderen Pins. Einfach ein bisschen vertikal auseinanderschieben, dass an dem Pin ein bisschen Linie dranhängt. Aber ja, dass in Bild 6 keine Warnung kommt ist ein bug. > - Ich habe ein paar Bauteile angelegt. Am einfachsten geht Hühnerfutter, > die kann man sehr schön im Horizon Pool Manager durch "Make Part from > Part" anlegen. Dabei kann man sowohl den Pool Manager als auch den > Projekt Manager mit Schema und PCB offen lassen. Nach dem Anlegen bzw. > einem "Update Pool" sind die Bauteile vorhanden Genau so war das gedacht :) > - Etwas komplizierter sind ganz neue Bauteile. Ich bin meist so > vorgegangen, dass ich erst im Pool Manager ein Package angelegt und dann > den Part Wizard gestartet habe. Das funktioniert soweit. Sehr schön :) > Evtl. könnte man das sinnvoll vorbelegen. Wenn man z.B. des Filenamen > für die Entity eingegeben hat, dass für Untits, Symbols und Parts das > automatisch übernommen wird. Wichtig ist dann noch, die Units und > Entities durchzugehen, um fehlende Einträge zu ergänzen, wie z. B. den > Prefix bei Entities. Bald kommt ein Knopf, damit man die Einträge vom Part zum Symbol, etc kopieren kann. > - Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt. > Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu > skalieren kann. Trifft das zu? Genau. Padstacks sind parametrierbar. Wenn du z.B. einen rechteckiges SMD-Pad brauchst, kannst du den "SMD rectangular" Padstack verwenden und dann mit dem Tool "Edit pad parameter set" Höhe und Breite festlegen. Derzeit fehlen noch einige wichtige übliche Padstacks, in Zukunft sollte man dann für die Mehrzahl aller Bauteile die vorhandenen parametriert verwenden können. > - Raster: Beim Bearbeiten von Schaltplänen und Packages kann ich kein > Raster (mehr) einstellen. Dachte, dass dies schon mal ging. Beim Schaltplan ist das Raster festgenagelt, damit's auch zu den Symbolen passt. Beim Package funktioniert es bei mir. > Wenn man > Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das Raster > ausschalten, aber beim Versuch, mit der linken Maustaste die neue > Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem > Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht > angenommen. Im Schaltplan/Board/Package? > - Auch das Ausrichten eines neuen Objekts an bestehenden Objekten nervt > manchmal, z.b. wenn man im Schaltplan Objekte dicht nebeneinander > platzieren möchte. Kann man dies ausschalten? Derzeit noch nicht. Die aktuelle Lösung ist es weiter ran zu zoomen. > - Variabler Text: Gibt es neben $RD bei den Packages und $REFDES und > $VALUE bei den Symbolen weitere? Nein, geplant ist es aber, Werte aus den parametrischen Daten, wie z.B. die Spannungsfestigkeit von Kondensatoren hier verfügbar zu machen. > - Neue Bauelemente: Ich habe ja nun ein paar angelegt, bin mir aber > unsicher, ob ich die hochladen soll, da die sicher noch Fehler haben. Kannst die ja mal irgendwo hochladen, dann kann ich mir's mal ansehen. tester schrieb: > Noch was: Horizon meckert ja, wenn man zwei Netze den selben Namen gibt. > Man muss ja den Namen, wenn er schon mal vorhanden ist, per "Move net > segment to other net" oder "Move net segment to new net" zuweisen. Was > spricht dagegen, Horizon dies implizit machen zu lassen, wenn ein > Netzname eingegeben wird der schon mal vorhanden ist? Das sind zwei paar Schuhe: Bei "Move net segment to..." werden keine Netze zusammenlegt. Wie der Name des Tools sagt, werden lediglich alle Pins auf dem ausgewählten Netzsegment auf das neue Netz verschoben. Beim Netz umbenennen müsste ein Net merge, ähnlich wie beim Verbinden von zwei Netzen mit Netzlinien durchgeführt werden. Es sind dann im Gegensatz zu oben alle Netzsegmente betroffen. Von der Architektur her ist es nicht schön machbar beim Netz Umbenennen Netze zusammenzulegen. > Powersymbole habe ich gar nicht verwendet, sondern bin nur über die > Netznamen gegangen. Irgend welche Nachteile? Powersymbole gibt es derzeit eh nur für GND, da würden sie ein wenig schöner ausschauen als die Labels. Nachteile ergeben sich daraus keine, ist der Netzliste egal. tester schrieb: > Fazit: Auch wenn es noch nicht ganz rund läuft, kann man mit Horizon > schon arbeiten. Lob! Schön zu hören, dass auch andere Leute ohne, dass ich direkt daneben steh was mit horizon anfangen könnnen ;)
Angehängte Dateien:
tester schrieb: > 3) Horizon speichert zusätzlich alle verwendeten Bauteile im Projekt mit > ab Seit gerade eben gibt es das. Windows-Builds dauern noch ein bisschen. Mit Fenster im Anhang (zu Erreichen aus dem Projektmager) kann man sich dann ansehen, welche Teile sich im Pool gegenüber dem Projekt-Cache geändert haben oder im Pool fehlen (z.B. weil man ein Projekt von wem anders bekommen hat, der seine Bauteile nicht in den globalen Pool merged hat). Derzeit gibt es als diff nur einen json-Patch. Dass das nicht wirklich optimal ist, ist mir klar. Kann in Zukunft ja noch besser werden :)
Lukas K. schrieb: > Ah, das passiert wenn du in den Via-Rules keine Regel oder keine Regel > mit Padstack hast. Du solltest mindestens st eine Via-Regel haben, die auf > alles matcht, so wie im Anhang. Ist mir jetzt auch passiert. Evtl. koennte man die Via-Rule als default einbauen.
Lukas K. schrieb: > Im Schaltplan/Board/Package? [Alt Taste + linke Maustaste] Gebraucht hätte ichs bei den Symbols. Ich wollte kleine Pfeile an das 3,5mm Klinkenbuchsensymbol anbringen.
Lukas K. schrieb: >> Wenn man Objekte mit gedrückter ALT Taste verschiebt, kann man zwar das >> Raster ausschalten, aber beim Versuch, mit der linken Maustaste die neue >> Position festzulegen, hüpft dann das Objekt trotzdem wieder auf einem >> Rastpunkt. Wenn man ALT gedrückt hält, wird der Mausklick nicht >> angenommen. > > Im Schaltplan/Board/Package? Generell: ALT ist ein unglücklicher Modifier für die Maus. Im fvwm wird der seit Jahren dafür benutzt, dass man Fenster manipulieren kann, ohne über den Fensterrahmen gehen zu müssen. ALT+LMB beispielsweise verschiebt dort ein Fenster. Damit sieht die Applikation ein solches Event dann nie.
Jörg W. schrieb: > Generell: ALT ist ein unglücklicher Modifier für die Maus. Jetzt wo du es sagst, fällt mir auch wieder ein, dass so ziemlich jeder X11-Fenstermanager ALT als Modifier zum Fenster verschieben verwendet. Ich verwende schon des längeren i3wm, da hab' ich mir den Modifier auf Super eingestellt. Seit gerade eben kann man den Modifier für feines Grid auch auf Ctrl umstellen.
tester schrieb: > Ist mir jetzt auch passiert. Evtl. koennte man die Via-Rule als default > einbauen. War ein bisschen mehr Aufwand, als die anderen Rules, ist aber nun drin. Pool musst auch noch aktualisieren, damit das tut.
Lukas K. schrieb: > tester schrieb: >> - Padstack. Ich habe mir alle Pads, die ich benötige, neu angelegt. >> Später bin ich dann drauf gekommen, dass man wohl vorhandene Pads neu >> skalieren kann. Trifft das zu? > > Genau. Padstacks sind parametrierbar. Wenn du z.B. einen rechteckiges > SMD-Pad brauchst, kannst du den "SMD rectangular" Padstack verwenden und > dann mit dem Tool "Edit pad parameter set" Höhe und Breite festlegen. > Derzeit fehlen noch einige wichtige übliche Padstacks, in Zukunft sollte > man dann für die Mehrzahl aller Bauteile die vorhandenen parametriert > verwenden können. Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button "Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das eine Einstellung für den Parameter. Egal was ich mache, ein Pad im gleichen Package verändert sich nicht. Uwe
Uwe S. schrieb: > Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button > "Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das > eine Einstellung für den Parameter. Egal was ich mache, ein Pad im > gleichen Package verändert sich nicht. Mit "All" sind alle alle Pads gemeint, die ausgewählt waren, als du das tool gestartet hast. Also alle, die in der Combobox oben im Fenster auswählbar sind. Der Knopf macht erstmal nichts weiter, als den Wert auch für alle anderen Pads im Fenster einzutragen.
Lukas K. schrieb: > Uwe S. schrieb: >> Was mir in diesem Zusammenhang noch nicht einleutet, ist der Button >> "Apply to all pads". Wirkt das mit dem Klick auf den Button oder ist das >> eine Einstellung für den Parameter. Egal was ich mache, ein Pad im >> gleichen Package verändert sich nicht. > > Mit "All" sind alle alle Pads gemeint, die ausgewählt waren, als du das > tool gestartet hast. Also alle, die in der Combobox oben im Fenster > auswählbar sind. Der Knopf macht erstmal nichts weiter, als den Wert > auch für alle anderen Pads im Fenster einzutragen. Danke. Jetzt habe ich es verstanden und es funktioniert.
Angehängte Dateien:
-
move_without_drc.PNG
7,9 KB
PCB-Layout Warum werden bei m(ove) die DRCs nicht beachtet? Vias und Leitungen lassen sich beliebig in Pads schieben obwohl die zu einem anderen Netz gehören. So war das doch bestimmt nicht gedacht oder doch? Siehe Bild.
Helmut S. schrieb: > So war das doch bestimmt nicht gedacht oder > doch? Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben, mal sehen wie man das am besten eingebaut bekommt.
Lukas K. schrieb: > Helmut S. schrieb: >> So war das doch bestimmt nicht gedacht oder >> doch? > > Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der > Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben, OK. Mit "Run Checks" werden die Fehler angezeigt, aber schöner wäre es schon wenn beim verschieben die "design rules" beachtet würden. Ich bin wohl zu verwöhnt von einem extrem teuren PCB-Programm. Gegenüber dem "move" bei Kicad sieht dein "move" ja schon jetzt mächtiger aus. > mal sehen wie man das am besten eingebaut bekommt. Vielleicht das Ganze dann noch ein/ausschaltbar.
Helmut S. schrieb: > wohl zu verwöhnt von einem extrem teuren PCB-Programm. Na das sollte man ja hinbekommen. Boundingbox (Rechteck) für Pads, Traces usw. RTree aus CGAL um Überlappungen grob zu finden, und dann ein wenig Geometrie für die sich überlappenden Boxen.
oder war rtree aus der Boost Bibliothek? Na ja, einer von beiden...
Ich habe mich jetzt mal angemeldet (tester). Mein Demoprojekt habe ich soweit fertig gestellt und wollte mal Gerber erstellen lassen, dabei ist der Layout Editor dann abgestürzt und jetzt kann ich das Layout nicht mehr öffnen. Es kommt die Fehlermeldung
1 | create proc |
2 | spawn /home/klaus/horizon/horizon/horizon-imp -b /home/klaus/horizon/proj/rpi-codec/board.json /home/klaus/horizon/proj/rpi-codec/top_block.json /home/klaus/horizon/proj/rpi-codec/vias |
3 | terminate called after throwing an instance of 'std::runtime_error' |
4 | what(): [Unsupported] Opposing point on constrained edge |
5 | end proc 4244 |
6 | exit stat 134 |
Evtl. liegt es auch daran, dass ich unmittelbar davor viel geSmashed habe. Ich habe das Projekt mal angehängt...
Angehängte Dateien:
-
horizon9.png
41 KB
Habe jetzt selbst etwas experimentiert. Durch rausschmeißen der folgenden Zeilen (try and error) aus dem via-block von board.json konnte ich die Datei wieder laden:
1 | klaus@Yoga:~/rpi-codec$ diff board.json ../horizon/proj/rpi-codec/board.json |
2 | 7945,7953d7944 |
3 | < "b1107bbe-b51a-4565-9970-b313ae9b559e": {
|
4 | < "from_rules": true, |
5 | < "junction": "775a3034-7b80-4c8c-a222-a02a2e99eb66", |
6 | < "padstack": "3c4a52fe-3ae0-4c3e-a108-824b53d6d6da", |
7 | < "parameter_set": {
|
8 | < "hole_diameter": 200000, |
9 | < "via_diameter": 500000 |
10 | < } |
11 | < }, |
Das Via zeigt auf folgende junction
1 | "775a3034-7b80-4c8c-a222-a02a2e99eb66": {
|
2 | "position": [ |
3 | -600000, |
4 | 12000000 |
5 | ] |
6 | }, |
Was ist hier falsch?
Gerber-Export funktioniert nun, lag daran, dass in einem von deinen Padstacks Polygone mit 0 Ecken waren. Die müssen wohl entstanden sein beim Löschen von Polygonen mit runden ecken, sollte nun auch nicht mehr passieren. Dass es sich gar nicht mehr öffnen lassen wollte kam daher, das mit der 3D-Vorschau bereits beim Laden berechnet wurde. Dabei ist poly2tri hingefallen, weil beim Quarz ein Loch direkt auf der Kante des Silkscreens liegt und dabei ein für poly2tri unverträgliches Polygon bei rauskommt. Mal sehen, was sich da machen lässt... Jetzt stürzt es erst beim Öffnen der 3D-Vorschau ab wenn das Via so liegt.
Angehängte Dateien:
-
horizon10.png
42 KB -
horizon11.png
35 KB -
horizon12.png
21 KB
Ja, läuft! Super! Anbei das Projekt + ein paar Bilder.
Noch ein paar Vorschläge: 1) Schaltplan + Layout als .png exportieren (so werden mehr Details als bei Bildschirmfotos sichtbar) 2) Die Fenster sollten sich ihre Größe merken 3) Im Layout wäre es sehr hilfreich, wenn man nicht nur ein einzelnes Segment sondern ein ganze Kette von Segmenten (Leiterbahnzug) selektieren könnte. Wenn man merkt, dass ein Leiterbahnzug völlig falsch liegt und man ihn komplett löschen muss, nervt es, wenn man jedes Segment einzeln anwählen muss. 4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den Ursprung des Zeichenblattes verlegen kann. Aber bis jetzt eine super Arbeit. Beim letzten "git pull" kam neuer Programmcode für differentielle Leiterbahnen mit...
Klaus R. schrieb: > Ja, läuft! Super! Anbei das Projekt + ein paar Bilder. Ich muss sagen, ich bin beeindruckt :) Klaus R. schrieb: > 4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den > Ursprung des Zeichenblattes verlegen kann. Jau, diese Funktion braucht man ständig! Bau auch noch gleich ein, dass man einen selektierten Block um genau x/y verschieben kann^^
Klaus R. schrieb: > Noch ein paar Vorschläge: > > 1) Schaltplan + Layout als .png exportieren (so werden mehr Details als > bei Bildschirmfotos sichtbar) Den Schaltplan kann man bereits als mehrseitiges PDF exportieren. Board-als-PDF kommt dann im Zuge mit Assembly Diagram export. > 2) Die Fenster sollten sich ihre Größe merken Du meinst die Fenster des interaktiven Manipulators? (Schaltplan/Board/...-Editor) Mal nachdenken, wie das am Sinnvollsten umsetzbar ist. Für jede Datei einzeln merken? Für jeden Dateityp? > 3) Im Layout wäre es sehr hilfreich, wenn man nicht nur ein einzelnes > Segment sondern ein ganze Kette von Segmenten (Leiterbahnzug) > selektieren könnte. Wenn man merkt, dass ein Leiterbahnzug völlig falsch > liegt und man ihn komplett löschen muss, nervt es, wenn man jedes > Segment einzeln anwählen muss. Seit soeben gibt es zwei Tools dazu: Select More: Wählt alle Tracks bis zum nächsten Pad aus Select net segment: Wählt alle zusammenhängenden Tracks aus > 4) Was ich an KiCad zu schätzen gelernt habe, war, dass man temporär den > Ursprung des Zeichenblattes verlegen kann. Mir wollte nie so recht einleuchten, wozu das im Detail gut sein soll. Kannst mir auf die Sprünge helfen? Mampf F. schrieb: > Bau auch noch gleich ein, dass man einen selektierten Block um genau x/y > verschieben kann^^ Gibt's schon: "Move exactly" Klaus R. schrieb: > Aber bis jetzt eine super Arbeit. Beim letzten "git pull" kam neuer > Programmcode für differentielle Leiterbahnen mit... Erwarte nicht zu viel, der Router ist ein wenig hakelig zu bedienen, aber iirc. war das auch schon in KiCad so.
Lukas K. schrieb: > Mir wollte nie so recht einleuchten, wozu das im Detail gut sein soll. > Kannst mir auf die Sprünge helfen? Der Ursprung des Zeichenblatts legt auch fest, wo das Grid beginnt. Beispielweise möchte man eine LED-Platine designen und die 10*10 LEDs sollen alle im Abstand 400mil sein, während aber die Platinenkante selbst in mm gezeichnet ist. Irgendwas passt ja dann zwangsläufig nicht ins Raster ... Man würde dann einfach den Ursprung auf die Mitte der Platine setzen und auf 100mil umstellen und alles wäre super :) Das geht nicht mit Relativ-Koordinaten direkt - da müsste man die Platine sonst wirklich um den Ursprung herum zeichnen, weil relativ-Koordinaten nicht das Grid ändern - bzw den Grid-*Ursprung*
Angehängte Dateien:
-
horizon13.png
76 KB
Lukas K. schrieb: > Den Schaltplan kann man bereits als mehrseitiges PDF exportieren. > Board-als-PDF kommt dann im Zuge mit Assembly Diagram export. PNG wäre interessant wegen den "Screenshots" fürs Forum :-). Dank FullHD Monitor gehen schon echte Screenshots, aber wenn man einen Schaltplan detailliert zwecks Diskussion einstellen möchte... PDF sind ja nur b/w. > Du meinst die Fenster des interaktiven Manipulators? Ja... anbei zwei Std Fenster Größen, wie sie bei mir aufgehen. Man beachte das Symbol Fenster... > Mal nachdenken, wie das am Sinnvollsten umsetzbar ist. Für jede Datei > einzeln merken? Für jeden Dateityp? Ja... eine .horizon Datei im Home Directory? > Select More: Wählt alle Tracks bis zum nächsten Pad aus > Select net segment: Wählt alle zusammenhängenden Tracks aus Ja super! Danke! > [diff pairs] Erwarte nicht zu viel, der Router ist ein wenig hakelig zu > bedienen, aber iirc. war das auch schon in KiCad so. Ich wollte es nur erwähnen. Diff-Pairs brauche ich eher selten.
Angehängte Dateien:
-
horizon14.png
75 KB
Noch eine Frage: Während ich langsam eine Idee von den "Rules" bekomme (und die meisten Fehler wegbekommen habe), sind mir die Fehler mit den NTPH Löchern noch ein Rätsel.
Klaus R. schrieb: > sind mir die Fehler mit den > NTPH Löchern noch ein Rätsel. Das Problem ist, dass die Löcher NPTH, also nicht platiert sind. Solche Löcher werden üblicherweise für mechanische Befestigungsbohrungen verwendet. Die Löcher für Pads sind normalerweise immer platiert. (Kann im Padstack in den Eigenschaften vom Loch eingestellt werden) Du hast dir ja eigene Padstacks für deine Pads gemacht? Warum hast du nicht die vorhanden benutzt und parametriert? Mit dem Tool "Edit Pad" (war mal "Edit Pad parameter set") kannst du nun auch den Padstacks von Pads austauschen. Pad löschen und neu anlegen wird nicht funktionieren, da sich dann die UUID vom Pad ändert.
Lukas K. schrieb: > (Kann im Padstack in den Eigenschaften vom Loch eingestellt werden) Danke, das war's. > Du hast dir ja eigene Padstacks für deine Pads gemacht? Warum hast du > nicht die vorhanden benutzt und parametriert? Zum Zeitpunkt des Erstellens wusste ich das schlicht nicht!
Klaus R. schrieb: > Lukas K. schrieb: >> Du hast dir ja eigene Padstacks für deine Pads gemacht? Warum hast du >> nicht die vorhanden benutzt und parametriert? > > Zum Zeitpunkt des Erstellens wusste ich das schlicht nicht! Ich habe es auch erst später verstanden. Wenn man es dann aber konsequent umsetzt, kommt man recht wenigen Padstacks aus. Das Konzept ist gut! Uwe
Noch ein kleiner Bug: Im Packages Editor nutzt "Draw Line Rectangle" immer den Top Copper Layer, unabhängig davon, welcher Layer gerade ausgewählt ist. Ein Hotkey dafür wäre schön.
Angehängte Dateien:
-
horizon15.png
73 KB
Und noch einer: Am Ende des Part Wizards wird beim anlegen der Verzeichnisse für Entites, Units, Symbols und Parts nicht geprüft, ob die Verzeichnisse schon vorhanden sind.
Klaus R. schrieb: > Und noch einer: Am Ende des Part Wizards wird beim anlegen der > Verzeichnisse für Entites, Units, Symbols und Parts nicht geprüft, ob > die Verzeichnisse schon vorhanden sind. Auch repariert.
Angehängte Dateien:
-
Layer-bottom-error.PNG
19 KB -
Layer-bottom.PNG
18 KB
Hallo, erst mal danke an Klaus für das komplette Beispiel "rpicodec-2017-11-13.tgz". Ich habe mal die Gerber Files von dem Projekt erzeugt und mit einem Gerber Viewer - ViewMate (Pentalogix) - angeschaut. Beim Import des "bottom-layer" .gbl kommt eine Fehlermeldung. Ich habe dann "Ja" gedrückt. Das Ergebnis sieht aber auf den ersten Blick korrekt aus. Was könnte da der Fehler sein? Meine Version von horizon ist von ca. 23Uhr (heute).
Hallo Lukas. Da ich mehr Anwender bin und weniger Programmierer: Gibt es fertige Windows Versionen (32bit)? Also Installer oder auch Portabel (entpacken und starten). Wäre es möglich diese und auch für andere (Win 64Bit / Linux 32/64) gleich immer mit zu machen. Von mir aus auch nur jede Woche oder nach schweren Fehlern. Grüße, Uli
Uli schrieb: > Wäre es möglich diese und auch für andere (Win 64Bit / Linux 32/64) > gleich immer mit zu machen. Von mir aus auch nur jede Woche oder nach > schweren Fehlern. Vielleicht hilft dir das schon mal zum Einstieg. Windows Versionen gibt es hier. Die Neueste dort ist von gestern. https://github.com/carrotIndustries/horizon/wiki/Getting-started Die Startseite. https://github.com/carrotIndustries/horizon Ziemlich unten auf "wiki" klicken. Da geht es dann weiter. Obwohl ich kein Programmierer bin, kompiliere ich jetzt selbst in Windows. #Einmalig mysys2 installieren Anleitung siehe Webseite von Lukas. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows #Im home/user Verzeichnis von mysys2 ein Verzeichnis anlegen. mkdir horizonxyz mysys2 starten. Ein Terminal geht auf. In dem Terminal wird dann gearbeitet. #Vom home-Verzeichnis in dieses Verzeichns wechseln. cd horizonxyz #Die Source-Files herunterladen. git clone http://github.com/carrotIndustries/horizon #In das von clone angelegte Unterverzeichnis horizon wechseln. cd horizon #Kompilieren mit allen logischen cores des Prozessors. Beispiel i7 mit 4 cores + hyperthreading. make -j 8 Die debug-Symbole aus den Files löschen. strip horizon-* #Die WIN-Version im Ordner "dist" ablegen ./make_bindist.sh Im Unter-Ordner "dist" ist dann ein Verzeichnis horizon. Das ist das Programmverzeichnis für die Windows-Version.
Helmut S. schrieb: > Das Ergebnis sieht aber auf > den ersten Blick korrekt aus. Was könnte da der Fehler sein? War wohl persönliches Unvermögen, Dinge richtig aus der Gerber-Spezifikation abzutippen. Ist repariert. Helmut S. schrieb: > Die debug-Symbole aus den Files löschen. > > strip horizon-* Das macht auch schon die ./make_bindist.sh beim Erstellen des dist-Verzeichnisses.
Also Lukas, ich muss es doch noch mal schreiben, ich bin schon sehr beeindruckt wie weit Du schon gekommen bist. Ich nehme mal stark an dass Du bisher nur einige tausend Stunden, vielleicht maximal 5000, an dem Programm gearbeitest hast. Und dann schon einen funktionierenden Schaltplaneditor, einen Layouteditor, Gerber Export und OpenGL. Wenn man das Vergleicht mit der elend langsamen Weiterentwicklung etwa von gEDA/PCB. Oder auch KiCad, wo sich ja auch über viele Jahre nur sehr wenig getan hatte. Dein Beispielil zeigt also, dass komplette Neuentwicklungen wirklich Sinn machen.
...schließe mich meinem Vorredener an, habs zwar bisher nicht angeguckt,
aber beeindruckt gelesen was hier diskutiert wird.
>Sinn machen.
^Sinn machen^Sinn haben^
Gruß,
Holm
Stefan S. schrieb: > Dein Beispielil zeigt also, dass komplette Neuentwicklungen wirklich > Sinn machen. Ja, mir geht es auch so ... Und die Code-Qualität und das Wissen das dahinter steckt ... Schon sehr beeindruckend. Leider leider entwickeln sich 90% eines Programms in 10% der Zeit ... Die anderen 10% benötigen dann 90% Zeit. Die zeitaufwändigen Sachen kommen vermutlich erst ... Bug-fixing und Usability ... Das ist dann immer das Stadium, in dem ich die Lust an etwas verliere und mir etwas neues zum Basteln suche :/
Hallo Lukas, ich habe nochmal eine Frage zu den Swap-Groups der Unit's. Wozu braucht man die? Können etwas pins einer Swap-Group getauscht werden? Hat die Nummer der Swap-Group eine Bedeutung? Uwe
Uwe S. schrieb: > Können etwas pins einer Swap-Group getauscht werden? Hat die > Nummer der Swap-Group eine Bedeutung? Für Pins soll die Swap group in Zukunft für's Pinswapping verwendet werden: 0 bedeutet nicht tauschbar, für alle anderen Nummern sind Pins mit gleicher Nummer tauschbar. (So wie bei EAGLE auch) Für Gates in Entities analog dazu. (Gateswapping) Bis jetzt kam mir nur noch keine zündende Idee, wie man das elegant implementieren kann. Was die Entwicklung anbetrifft: An einigen Stellen habe ich mir das Leben (vielleicht zu) einfach gemacht: 1. Schematic::expand() und Board::expand() Diese Methoden befüllen Schaltplan und Board mit Informationen aus der Netzliste, Räumen im Schaltplan Linien und Junctions auf, wenden im Board die Parameter auf Packages an, Berechnen airwires, etc. Alles das geschieht nach jedem Tool. D.h. auch wenn man nur eine Kleinigkeit angefasst hat, wird alles neu berechnet. Aktuell scheint das von der Geschwindigkeit her noch kein Problem zu sein, mal sehen wie lange das noch so bleibt. 2. Canvas::render() Rendert (macht aus Packags, Pads, etc. Linien und Dreiecke) immer alles neu und Trianguliert auch die Planes damit die von der GPU gerendert werden könnnen. Das geschieht, wenn ein Tool aktiv ist nach jeder Benutzereingabe. Durch den KiCad-Router hat das Canvas Möglichkeiten bekommen, bereits gerenderts zu löschen und Dinge nachträglich zum gerenderten hinzufügen. Vielleicht wird diese Funktionalität in Zukunft auch noch von mehr Tools genutzt werden, wenn Canvas::render zum Flaschenhals wird. 3. DRC hat quadratische Komplexität. DRC ist in sich recht abgeschlossen, d.h. man kann dort einfach ohne weitere Umbauten optimieren. Die Idee dabei war: Erstmal Komplexität vermeiden und machen, dass es funktioniert. Schneller bekommt man es später immer noch.
Nachtrag zum Kompilieren der WIN version auf einem WIN-PC. Einmalig mysys2 installieren. Anleitung siehe Webseite von Lukas. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows Gtk-Bug, Grafikfehler nach dem 3D Aufruf -- In dem zip von mir ist eine gepatchte libgdk (ja, gdk, kein Tippfehler) Kopier' mal die libgdk-3-0.dll aus meinem zip nach C:\msys64\mingw64\bin --Lukas --- WIN version erzeugen In WIN mysys2 starten. Ein Terminal geht auf. In dem Terminal wird dann gearbeitet. #Im home/user Verzeichnis von mysys2 ein Verzeichnis anlegen. $ mkdir horizonxyz #Vom home-Verzeichnis in dieses Verzeichns wechseln. $ cd horizonxyz #Die Source-Files herunterladen. $ git clone http://github.com/carrotIndustries/horizon #In das von clone angelegte Unterverzeichnis horizon wechseln. $ cd horizon #Kompilieren mit allen logischen cores des Prozessors. Beispiel i7 mit 4 cores + hyperthreading. $ make -j 8 #Die WIN-Version im Ordner "dist" erzeugen. $ ./make_bindist.sh Im Unter-Ordner "dist" ist dann ein Verzeichnis horizon. Das ist das Programmverzeichnis für die Windows-Version.
Helmut S. schrieb: > In dem zip von mir ist eine gepatchte libgdk (ja, gdk, kein Tippfehler) > Kopier' mal die libgdk-3-0.dll aus meinem zip nach C:\msys64\mingw64\bin Mittlerweile braucht man kein gepatchtes Gtk/gdk mehr, letzte Woche gab es ein Bugfix-release von Gtk mit dem Patch drin, das es auch schon in msys2 geschafft hat. Einfach in der mingw64-shell "pacman -Syu" eingeben, damit alle Pakete auf den aktuellen Stand gebracht werden.
Danke Lukas, nach dem update von mysys2 geht es jetzt ohne den Austausch der libgdk-3-0.dll. ----------------------------------------------------------- Aleitung zum Kompilieren der WIN version auf einem WIN-PC. Einmalig mysys2 installieren. Anleitung siehe Webseite von Lukas. https://github.com/carrotIndustries/horizon/wiki/B... --- WIN version erzeugen In WIN mysys2 starten. Ein Terminal geht auf. In dem Terminal wird dann gearbeitet. #Im home/user Verzeichnis von mysys2 ein Verzeichnis anlegen. $ mkdir horizonxyz #Vom home-Verzeichnis in dieses Verzeichns wechseln. $ cd horizonxyz #Die Source-Files herunterladen. $ git clone http://github.com/carrotIndustries/horizon #In das von clone angelegte Unterverzeichnis horizon wechseln. $ cd horizon #Kompilieren mit allen logischen cores des Prozessors damit es schnell geht. Beispiel CPU mit 4 cores + hyperthreading -> -j 8. $ make -j 8 #Die WIN-Version im Ordner "dist" erzeugen. $ ./make_bindist.sh Im Unter-Ordner "dist" ist dann ein Verzeichnis horizon. Das ist das Programmverzeichnis für die Windows-Version.
Ich wollte die Zoom-Stufen bei Bedarf kleiner machen (damit z.B. ein Schaltplan gut den Bildschirm ausfüllt). Wenn man jetzt Shift drückt, dann wir der Zoom-Faktor (bzw. Exponent) statt 1.5 auf 1.1 gesetzt.
1 | klaus@Yoga:~/horizon/horizon/canvas$ diff -u pan.cpp pan.cpp.new
|
2 | --- pan.cpp 2017-11-17 22:03:48.259871554 +0100
|
3 | +++ pan.cpp.new 2017-11-17 22:02:05.363867717 +0100
|
4 | @@ -73,16 +73,23 @@
|
5 | float sc = this->scale; |
6 | |
7 | float scale_new=1; |
8 | +
|
9 | + float factor = 1.5;
|
10 | +
|
11 | + if (pan_dragging == true) {
|
12 | + factor = 1.1;
|
13 | + }
|
14 | +
|
15 | if(scroll_event->direction == GDK_SCROLL_UP) {
|
16 | - scale_new = sc*1.5;
|
17 | + scale_new = sc*factor;
|
18 | } |
19 | else if(scroll_event->direction == GDK_SCROLL_DOWN) {
|
20 | - scale_new = sc/1.5;
|
21 | + scale_new = sc/factor;
|
22 | } |
23 | else if(scroll_event->direction == GDK_SCROLL_SMOOTH) {
|
24 | gdouble sx, sy; |
25 | gdk_event_get_scroll_deltas((GdkEvent*)scroll_event, &sx, &sy); |
26 | - scale_new = sc * powf(1.5, -sy);
|
27 | + scale_new = sc * powf(factor, -sy);
|
28 | } |
29 | if(scale_new < 1e-7 || scale_new > 1e-2) {
|
30 | return; |
Klaus R. schrieb: > Wenn man jetzt Shift drückt, > dann wir der Zoom-Faktor (bzw. Exponent) statt 1.5 auf 1.1 gesetzt. Danke für die Idee, ich hab das gerade mal in leicht anderer Form eingebaut.
Angehängte Dateien:
-
drag.jpg
300 KB
Klaus R. schrieb: > Oh, gut. Frage: Was macht "g drag and keep slope"? Damit bleiben beim schieben der schrägen Leitung die vertikalen Segmente immer vertikal. Das hilft um ein schönes 45° Routing zu erhalten.
Hallo Lukas ich bin jetzt auch neugierig geworden und wollte mir dein Programm anschauen. Compilieren war nach der Aktualisierung der benötigten Pakete kein Problem. Die Ausgabe in den GL Canvas scheint es aber mit meiner Hardware nicht zu gehen: Diese Meldungen tauchen in der Konsole auf:
1 | helmut@otto:~$ /home/data/Downloads/horizon/horizon-prj-mgr |
2 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
3 | col 2 |
4 | create proc |
5 | spawn /home/data/Downloads/horizon/horizon-imp -c /home/helmut/CAD/Horizon/HB test 1/top_sch.json /home/helmut/CAD/Horizon/HB test 1/top_block.json |
6 | Linking failure: Vertex info |
7 | ----------- |
8 | 0(2) : warning C7568: #version 330 not fully supported on current GPU target profile |
9 | 0(13) : error C5108: unknown semantics "INSTANCEID" specified for "gl_InstanceID" |
10 | |
11 | Fragment info |
12 | ------------- |
13 | 0(2) : warning C7568: #version 330 not fully supported on current GPU target profile |
14 | |
15 | gl error 1281 in canvas/canvas_gl.cpp:98 |
16 | end proc 19270 |
17 | exit stat 6 |
18 | helmut@otto:~$ |
Ich habe eine ältere Nvidia Karte
1 | helmut@otto:~$ nvidia-detect |
2 | Detected NVIDIA GPUs: |
3 | 00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 6100 nForce 405] [10de:03d1] (rev a2) |
4 | |
5 | Checking card: NVIDIA Corporation C61 [GeForce 6100 nForce 405] (rev a2) |
6 | Your card is only supported up to the 304 legacy drivers series. |
7 | It is recommended to install the |
8 | nvidia-legacy-304xx-driver |
9 | package. |
Ich habe die Treiber Version 304.137 installiert. Ausgabe von glxinfo:
1 | helmut@otto:~$ /usr/bin/glxinfo |
2 | name of display: :0.0 |
3 | display: :0 screen: 0 |
4 | direct rendering: Yes |
5 | server glx vendor string: NVIDIA Corporation |
6 | server glx version string: 1.4 |
7 | server glx extensions: |
8 | GLX_ARB_create_context, GLX_ARB_create_context_profile, |
9 | GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, |
10 | GLX_ARB_multisample, GLX_EXT_create_context_es2_profile, |
11 | GLX_EXT_create_context_es_profile, GLX_EXT_swap_control, |
12 | GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, |
13 | GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_float_buffer, |
14 | GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, |
15 | GLX_SGI_video_sync |
16 | client glx vendor string: NVIDIA Corporation |
17 | client glx version string: 1.4 |
18 | client glx extensions: |
19 | GLX_ARB_create_context, GLX_ARB_create_context_profile, |
20 | GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, |
21 | GLX_ARB_get_proc_address, GLX_ARB_multisample, |
22 | GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float, |
23 | GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, GLX_EXT_swap_control, |
24 | GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, |
25 | GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_copy_image, |
26 | GLX_NV_float_buffer, GLX_NV_multisample_coverage, GLX_NV_present_video, |
27 | GLX_NV_swap_group, GLX_NV_video_capture, GLX_NV_video_out, |
28 | GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, |
29 | GLX_SGI_video_sync |
30 | GLX version: 1.4 |
31 | GLX extensions: |
32 | GLX_ARB_create_context, GLX_ARB_create_context_profile, |
33 | GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, |
34 | GLX_ARB_get_proc_address, GLX_ARB_multisample, |
35 | GLX_EXT_create_context_es2_profile, GLX_EXT_swap_control, |
36 | GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, |
37 | GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_NV_float_buffer, |
38 | GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, |
39 | GLX_SGI_video_sync |
40 | OpenGL vendor string: NVIDIA Corporation |
41 | OpenGL renderer string: GeForce 6100 nForce 405/integrated/SSE2 |
42 | OpenGL version string: 2.1.2 NVIDIA 304.137 |
43 | OpenGL shading language version string: 1.20 NVIDIA via Cg compiler |
44 | OpenGL extensions: |
45 | GL_ARB_ES2_compatibility, GL_ARB_color_buffer_float, |
46 | GL_ARB_compressed_texture_pixel_storage, GL_ARB_conservative_depth, |
47 | GL_ARB_copy_buffer, GL_ARB_depth_clamp, GL_ARB_depth_texture, |
48 | GL_ARB_draw_buffers, GL_ARB_explicit_attrib_location, |
49 | GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, |
50 | GL_ARB_fragment_shader, GL_ARB_framebuffer_object, |
51 | GL_ARB_get_program_binary, GL_ARB_half_float_pixel, |
52 | GL_ARB_half_float_vertex, GL_ARB_imaging, GL_ARB_internalformat_query, |
53 | GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multisample, |
54 | GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_occlusion_query2, |
55 | GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, |
56 | GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, |
57 | GL_ARB_separate_shader_objects, GL_ARB_shader_objects, |
58 | GL_ARB_shading_language_100, GL_ARB_shading_language_420pack, |
59 | GL_ARB_shading_language_include, GL_ARB_shadow, GL_ARB_sync, |
60 | GL_ARB_texture_border_clamp, GL_ARB_texture_compression, |
61 | GL_ARB_texture_cube_map, GL_ARB_texture_env_add, |
62 | GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, |
63 | GL_ARB_texture_env_dot3, GL_ARB_texture_float, |
64 | GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, |
65 | GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_storage, |
66 | GL_ARB_texture_swizzle, GL_ARB_timer_query, GL_ARB_transpose_matrix, |
67 | GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, |
68 | GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, |
69 | GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, |
70 | GL_ATI_texture_mirror_once, GL_EXT_Cg_shader, GL_EXT_abgr, GL_EXT_bgra, |
71 | GL_EXT_blend_color, GL_EXT_blend_equation_separate, |
72 | GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, |
73 | GL_EXT_compiled_vertex_array, GL_EXT_depth_bounds_test, |
74 | GL_EXT_direct_state_access, GL_EXT_draw_range_elements, GL_EXT_fog_coord, |
75 | GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, |
76 | GL_EXT_framebuffer_object, GL_EXT_gpu_program_parameters, |
77 | GL_EXT_import_sync_object, GL_EXT_multi_draw_arrays, |
78 | GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, |
79 | GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, |
80 | GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, |
81 | GL_EXT_separate_shader_objects, GL_EXT_separate_specular_color, |
82 | GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, |
83 | GL_EXT_texture3D, GL_EXT_texture_compression_dxt1, |
84 | GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, |
85 | GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, |
86 | GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, |
87 | GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA8888, |
88 | GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, |
89 | GL_EXT_texture_object, GL_EXT_texture_sRGB, GL_EXT_texture_sRGB_decode, |
90 | GL_EXT_texture_storage, GL_EXT_texture_swizzle, GL_EXT_timer_query, |
91 | GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_EXT_x11_sync_object, |
92 | GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, |
93 | GL_KTX_buffer_region, GL_NVX_conditional_render, |
94 | GL_NV_ES1_1_compatibility, GL_NV_alpha_test, GL_NV_blend_minmax, |
95 | GL_NV_blend_square, GL_NV_complex_primitives, GL_NV_copy_depth_to_color, |
96 | GL_NV_depth_clamp, GL_NV_fbo_color_attachments, GL_NV_fence, |
97 | GL_NV_float_buffer, GL_NV_fog_distance, GL_NV_fragdepth, |
98 | GL_NV_fragment_program, GL_NV_fragment_program2, |
99 | GL_NV_fragment_program_option, GL_NV_framebuffer_multisample_coverage, |
100 | GL_NV_half_float, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, |
101 | GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, |
102 | GL_NV_point_sprite, GL_NV_primitive_restart, GL_NV_register_combiners, |
103 | GL_NV_register_combiners2, GL_NV_texgen_reflection, GL_NV_texture_barrier, |
104 | GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, |
105 | GL_NV_texture_expand_normal, GL_NV_texture_lod_clamp, |
106 | GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2, |
107 | GL_NV_texture_shader3, GL_NV_vertex_array_range, |
108 | GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, |
109 | GL_NV_vertex_program2, GL_NV_vertex_program2_option, |
110 | GL_NV_vertex_program3, GL_OES_compressed_paletted_texture, GL_OES_depth24, |
111 | GL_OES_depth32, GL_OES_depth_texture, GL_OES_element_index_uint, |
112 | GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, |
113 | GL_OES_packed_depth_stencil, GL_OES_point_size_array, GL_OES_point_sprite, |
114 | GL_OES_read_format, GL_OES_rgb8_rgba8, GL_OES_standard_derivatives, |
115 | GL_OES_texture_3D, GL_OES_texture_float, GL_OES_texture_float_linear, |
116 | GL_OES_texture_half_float, GL_OES_texture_half_float_linear, |
117 | GL_OES_texture_npot, GL_OES_vertex_array_object, GL_OES_vertex_half_float, |
118 | GL_S3_s3tc, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod, |
119 | GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum |
120 | |
121 | OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 304.137 304.137 |
122 | OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.00 |
123 | OpenGL ES profile extensions: |
124 | GL_EXT_Cg_shader, GL_EXT_bgra, GL_EXT_framebuffer_object, |
125 | GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, |
126 | GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA8888, |
127 | GL_EXT_unpack_subimage, GL_NV_alpha_test, GL_NV_blend_minmax, |
128 | GL_NV_complex_primitives, GL_NV_draw_buffers, GL_NV_fbo_color_attachments, |
129 | GL_NV_fragdepth, GL_NV_fragment_program, GL_NV_fragment_program2, |
130 | GL_NV_get_tex_image, GL_NV_read_buffer, GL_NV_texture_lod_clamp, |
131 | GL_NV_unpack_subimage, GL_NV_vertex_program, GL_NV_vertex_program1_1, |
132 | GL_NV_vertex_program2, GL_NV_vertex_program2_option, |
133 | GL_NV_vertex_program3, GL_OES_compressed_paletted_texture, GL_OES_depth24, |
134 | GL_OES_depth32, GL_OES_depth_texture, GL_OES_element_index_uint, |
135 | GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, |
136 | GL_OES_packed_depth_stencil, GL_OES_point_size_array, GL_OES_point_sprite, |
137 | GL_OES_read_format, GL_OES_rgb8_rgba8, GL_OES_standard_derivatives, |
138 | GL_OES_texture_3D, GL_OES_texture_float, GL_OES_texture_float_linear, |
139 | GL_OES_texture_half_float, GL_OES_texture_half_float_linear, |
140 | GL_OES_texture_npot, GL_OES_vertex_array_object, GL_OES_vertex_half_float |
Ist meine Hardware zu alt? Oder siehst du noch einen Ansatzpunkt, dein Programm zum laufen zu bringen? Helmut
Helmut B. schrieb: > Ist meine Hardware zu alt? Oder siehst du noch einen Ansatzpunkt, dein > Programm zum laufen zu bringen? Scheint so als sei die zu alt: Laut Wikipedia kann die GeForce 6100 wohl nur OpenGL 2.1, das reicht nicht. Die Karte ist aber auch schon deutlich über 10 Jahre alt... So spontan fällt mir da nichts ein, wie es ohne OpenGL 3-GPU funktionieren könnte.
Hallo Helmut, falls du noch einen neueren WIN7/WIN10 PC hast, kannst du ja mal die kompilierte WIN-Version herunterladen und damit testen. Die Neueste ist vom 18.11.2017. http://0x83.eu/horizon-zip/
Hallo Lukas, warum haben Vias keinen Netznamen? Damit könnte man die in eine Plane setzen und denen den Netznamen der Plane geben. Gruß Helmut
Auf Wiki steht was von Softwareemulation. Hm, also kann man deine Software nur auf neuen Geräten verwenden?
Helmut S. schrieb: > warum haben Vias keinen Netznamen? Aktuell erhalten Vias ihr Netz durch den Track, der mit der Junction verbunden ist. Unverbundenen Vias Netze zuordnen zu können steht aber auch auf meiner zeitnahen Todo-Liste. Abdul K. schrieb: > Hm, also kann man deine Software nur auf neuen Geräten verwenden? Neuer im Sinne von Jünger als ~8 Jahre, ja. Horizon ist aber auch mehr ein Projekt für die Zukunft, bis es denn mal "ausgereift" ist, haben auch mehr Leute eine GPU, die OpenGL 3 kann. OpenGL 3 ist jetzt auch schon ~8 Jahre alt und mit OpenGL 2 will man heutzutage nichts mehr neu anfangen...
Du steigst also nicht so bald auf V4 um.
Lukas K. schrieb: > Unverbundenen Vias Netze zuordnen zu können steht aber > auch auf meiner zeitnahen Todo-Liste. Wenn das geht, wärst du zumindest in diesem Punkt dem KiCad schon voraus^^ Via-Stitching geht zwar mit KiCad auch, aber nur umständlich ... Braucht man aber oft und ist daher eine eigentlich recht wichtige Funktion.
Mampf F. schrieb: > Wenn das geht, wärst du zumindest in diesem Punkt dem KiCad schon > voraus^^ Ist drin: Man kann nun Vias mit dem "Set via net"-Tool Vias, die ohne Netz auf dem Board liegen ein Netz zuweisen.
Lukas K. schrieb: > Mampf F. schrieb: >> Wenn das geht, wärst du zumindest in diesem Punkt dem KiCad schon >> voraus^^ > > Ist drin: Man kann nun Vias mit dem "Set via net"-Tool Vias, die ohne > Netz auf dem Board liegen ein Netz zuweisen. Danke, dass man gleich mehrere Vias selektieren kann und denen auf einen Schlag das gleiche Netz, z. B. GND, zuweisen kann.
Hallo Lukas, als ich heute das Board eines kleinen Beispielprojekts öffnen wollte, stürzte mir horizon-imp mit status code 6 ab. Das hier mal gepostete Raspberrypi Projekt zeigt dieses Verhalten nicht. Bei meinem Projekt tritt der Fehler auch dann auf, wenn ich Versionen von horizon der letzten Tage verwende. Es muss also irgendwo in meinem Projekt oder meinem lokalen Pool begründet sein. Wie kreise ich den Fehler am besten ein? Uwe
Vielleicht hilft es , das Programm im Debugger zu starten. Debug-Builds sind auch hilfreich.
Uwe S. schrieb: > ich den Fehler am besten ein? Am besten mit dem gdb: Dazu den imp im gdb "von Hand" starten, siehe https://github.com/carrotIndustries/horizon/wiki/CLI-usage. Wenn's dann hinfällt, mit "bt" den Stack anzeigen lassen.
Lukas K. schrieb: > Helmut S. schrieb: >> So war das doch bestimmt nicht gedacht oder >> doch? > > Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der > Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben, > mal sehen wie man das am besten eingebaut bekommt. Jetzt gibt es das Tool "Drag track interactive" (g), um einen Track zu verschieben. Mehrere Tracks kann das Tool nicht, dafür werden andere Tracks automatisch aus dem Weg geschoben.
Lukas K. schrieb: > > Jetzt gibt es das Tool "Drag track interactive" (g), um einen Track zu > verschieben. Mehrere Tracks kann das Tool nicht, dafür werden andere > Tracks automatisch aus dem Weg geschoben. Das heißt, du hast jetzt schon einen Push&Shove Router eingebaut, den KiCad erst seit kurzem hat und Eagle noch garnicht? Kranker scheiß :D
Hm, wollte auch mal testen, kann es Compilieren aber starten tut es leider nicht.
1 | ...$ ./horizon-imp |
2 | wrong invocation |
3 | ...$ ./horizon-prj |
4 | terminate called after throwing an instance of 'std::out_of_range' |
5 | what(): vector::_M_range_check: __n (which is 1) >= this->size() (which is 1) |
6 | Abgebrochen (Speicherabzug geschrieben) |
Lukas K. schrieb: > Uwe S. schrieb: >> ich den Fehler am besten ein? > > Am besten mit dem gdb: Dazu den imp im gdb "von Hand" starten, siehe > https://github.com/carrotIndustries/horizon/wiki/CLI-usage. Wenn's dann > hinfällt, mit "bt" den Stack anzeigen lassen. Sieht dann etwa so aus
1 | (gdb) bt |
2 | #0 0x00007ffff22cba70 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
|
3 | #1 0x00007ffff22cd19a in __GI_abort () at abort.c:89
|
4 | #2 0x00007ffff28e3b85 in __gnu_cxx::__verbose_terminate_handler() ()
|
5 | at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 |
6 | #3 0x00007ffff28e1956 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
|
7 | #4 0x00007ffff28e19a1 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
|
8 | #5 0x00007ffff28e1be4 in () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
|
9 | #6 0x00007ffff290a15f in std::__throw_out_of_range(char const*) ()
|
10 | at /usr/lib/x86_64-linux-gnu/libstdc++.so.6 |
11 | #7 0x000000010025f524 in std::map<horizon::UUID, horizon::BoardPackage, std::less<horizon::UUID>, std::allocator<std::pair<horizon::UUID const, horizon::BoardPackage> > >::at(horizon::UUID const&) (__k=..., this=<optimized out>) at /usr/include/c++/7/bits/stl_map.h:533
|
12 | #8 0x000000010025f524 in horizon::Track::Connection::Connection(nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> const&, horizon::Board&) (this=0x7fffffffcf88, j=..., brd=...) at board/track.cpp:15
|
13 | #9 0x00000001002641ca in horizon::Track::Track(horizon::UUID const&, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> const&, horizon::Board&) (this=0x7fffffffcf30, uu=..., j=..., brd=...) at board/track.cpp:151
|
14 | #10 0x000000010025856f in horizon::Board::Board(horizon::UUID const&, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> const&, horizon::Block&, horizon::Pool&, horizon::ViaPadstackProvider&) (this=0x100810580, uu=..., j=..., iblock=..., pool=..., vpp=...) at board/board.cpp:83
|
15 | #11 0x000000010025a6d2 in horizon::Board::new_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, horizon::Block&, horizon::Pool&, horizon::ViaPadstackProvider&) (filename="/home/steinm/AVR/horizon/attiny-ir-receiver/board.json", block=..., pool=..., vpp=...) at board/board.cpp:149
|
Mampf F. schrieb: > Das heißt, du hast jetzt schon einen Push&Shove Router eingebaut, den > KiCad erst seit kurzem hat Ich hab den von KiCad eingebaut. K. J. schrieb: > ber starten tut es > leider nicht. Du startest auch die falschen Binaries. Unmittelbar startbar sind nur horizon-prj-mgr und horizon-pool-mgr, siehe https://github.com/carrotIndustries/horizon/wiki/Getting-started Uwe S. schrieb: > #8 0x000000010025f524 in > horizon::Track::Connection::Connection(nlohmann::basic_json<std::map, > std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, > std::allocator<char> >, bool, long, Ich hab gerade mal was gepushed, funktioniert's nun?
Lukas K. schrieb: > Ich hab den von KiCad eingebaut. Das geht so einfach? Oo Ist ja schon fast unglaublich ... :)
Hat schonmal auf einem Kubuntu 17.10 kompiliert. Diese Pakete musste ich nachinstallieren: uuid-dev gtkmm-3.0-dev libcairomm-1.0-dev libzmqpp-dev Und das hier: libglm-dev Bei den 4 Paketen oben hat das Makefile schon gemeckert. Bei libglm-dev erst der Compiler. Jetzt muss ich mal kucken, wie man das Programm startet ;)
Mampf F. schrieb: > Das geht so einfach? Oo Der interaktive Router von KiCad ist von KiCad recht unabhängig mit eigenen Datenstrukturen implementiert. Alle Interaktion mit der Host-Applikation ist in einer eigenen Klasse gekapselt. Man muss daher 'nur' das Interface zwischen Router und Applikation wirklich anfassen. Bei mir sind das https://github.com/carrotIndustries/horizon/blob/master/router/pns_horizon_iface.cpp und https://github.com/carrotIndustries/horizon/blob/master/core/tool_route_track_interactive.cpp Das Canvas musste ich auch noch ein bisschen anfassen. Alles in allem überschaubarer Aufwand und auch ohne wirkliche Dokumentation gut machbar gewesen.
Lukas K. schrieb: > Alles in allem > überschaubarer Aufwand und auch ohne wirkliche Dokumentation gut machbar > gewesen. Wer kann der kann... Mein tiefer Reepekt vor dem ganzen Projekt Lukas!
Kastanie schrieb: > Wer kann der kann... > Mein tiefer Reepekt vor dem ganzen Projekt Lukas! Jau, der Lukas ist ein kluger Kopf :) http://fichte-gymnasium.de/Joomla_15/index.php?option=com_content&view=article&id=113%3Ajtf-lukas-2011&Itemid=160 Puh, muss sagen, in dem damaligen Alter hätte ich das noch nicht können ...
Lukas K. schrieb: > Uwe S. schrieb: >> #8 0x000000010025f524 in >> horizon::Track::Connection::Connection(nlohmann::basic_json<std::map, >> std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> >, bool, long, > > Ich hab gerade mal was gepushed, funktioniert's nun? Und wie! Danke.
Hallo Lukas, noch eine Frage. Bisher konnte man mit Shift und Bewegen der Maus den Canvas verschieben. Jetzt klappt das nur noch mit gleichzeitigem Maus-Links-Klick. Vermutlich hattest du deine Gründe dafür. Blöd ist allerdings, dass dieser Links-Klick dann nicht nur die Verschiebung startet, sondern z.B. auch den Start einer Linie oder eines Tracks setzt. Etwas konkreter: Geöffnet ist das Board und ich möchte einen Track routen, drücke also 'x'. Jetzt stelle ich fest, dass der Canvas verschoben werden muss, betätige als Shift, linke Maustaste und schiebe den Canvas passend. Leider habe ich damit aber auch gleichzeitig das Routen des Tracks gestartet. Also erstmal ESC, dann verschieben und nochmal 'x'. Mache ich was falsch? Uwe
Lukas K. schrieb: > Lukas K. schrieb: >> Helmut S. schrieb: >>> So war das doch bestimmt nicht gedacht oder >>> doch? >> >> Leider ja, das Move-Tool hat weiß nichts von Design Rules. Der >> Kicad-Router kann wohl Tracks unter Beachtung von Abständen verschieben, >> mal sehen wie man das am besten eingebaut bekommt. > > Jetzt gibt es das Tool "Drag track interactive" (g), um einen Track zu > verschieben. Mehrere Tracks kann das Tool nicht, dafür werden andere > Tracks automatisch aus dem Weg geschoben. Hallo Lukas, habe es gerade mal ausprobiert. Diese neue Funktion ist schon richtig gut. Jetzt muss ich nur noch lernen wie man neue Bauteile definiert. :-)
Beitrag #5216803 wurde von einem Moderator gelöscht.
Beitrag #5216805 wurde von einem Moderator gelöscht.
Beitrag #5216807 wurde von einem Moderator gelöscht.
Uwe S. schrieb: > Jetzt klappt das nur noch mit gleichzeitigem > Maus-Links-Klick. Vermutlich hattest du deine Gründe dafür. Blöd ist > allerdings, dass dieser Links-Klick dann nicht nur die Verschiebung > startet, sondern z.B. auch den Start einer Linie oder eines Tracks > setzt. Mir hatte das mit dem Shift ohne klicken nicht gefallen, weil das kaputt ging, wenn shift außerhalb des Canvas losgelassen wurde. Jetzt wird shift-click für Tools ignoriert.
Jörg W. schrieb: > Wenn ich mal mein OS (und damit auch den Compiler) aktualisiert habe, > schau ich mir Horizon auf jeden Fall auch mal an. Vermutlich wird Lukas > dann von mir als erstes einen Satz Patches für FreeBSD erhalten. :-) Ich mach' mal wieder einen Versuch, nachdem ich das FreeBSD auf das letzte 10-stable hochgezogen habe (11.x wird demnächst auch noch werden). OS-native Clang (3.4.1) macht noch kein C++14, aber ich habe ohnehin noch einen GCC 6 daliegen, der compiliert das zumindest erst einmal. Ein bisschen seltsam sind die vielen
1 | -pthread -D_THREAD_SAFE |
beim Compilieren; in jeder Zeile taucht dieses Konstrukt mehrere tausend(!) Mal auf. ØMQ hat mich ein Weilchen gekostet: die FreeBSD-Ports folgen hier der offiziellen Strategie von ØMQ und trennen die Bibliothek von den C++-Bindings, die man in cppzmq findet. Erst damit hat man dann zmq.hpp. Der Compiler läuft damit dann durch, aber der Linker wirft noch viele Fehler. Manches sieht mir recht seltsam aus, aber es ist Mitternacht, und ich geh' dann erstmal ins Bett. Ich hänge das Logfile vom Linker mal an.
Jörg W. schrieb: > Ich hänge das > Logfile vom Linker mal an. So auf den ersten Blick fällt mir auf, dass du mit gcc linkst. Versuch's doch mal mit dem g++
Lukas K. schrieb: > So auf den ersten Blick fällt mir auf, dass du mit gcc linkst. Ja, ich hatte mit
1 | gmake CC=gcc6 CXX=g++6 |
gebaut. Offenbar benutzt du aber nicht CXX sondern CC. Mit
1 | gmake CC=g++6 |
verschwinden die Fehler bezüglich der C++-Standardbibliothek, aber es bleiben viele Fehler für Glib unt Gtk. glibmm ist 2.50.1, gtkmm ist 3.22.0. Zu alt? Ich habe diese beiden gerade für alle Fälle auch nochmal mit dem GCC 6 (statt des Clang aus dem Basis-OS) neu compiliert und baue Horizon nochmal. Mal sehen, ob das was ändert.
Lukas K. schrieb: > K. J. schrieb: >> ber starten tut es >> leider nicht. > > Du startest auch die falschen Binaries. Unmittelbar startbar sind nur > horizon-prj-mgr und horizon-pool-mgr, siehe > https://github.com/carrotIndustries/horizon/wiki/Getting-started Ja danke das war es, jetzt scheitert es am OpenGL3, ok das kann meine Grafikkarte nicht, schade werde aber trotzdem das Projekt von dir weiterverfolgen, macht schon einen guten eindruck, mal schauen bin eh auf der suche nach einer neuen Grafikkarte.
Jörg W. schrieb: > Ich habe diese beiden gerade für alle Fälle auch nochmal mit dem GCC 6 > (statt des Clang aus dem Basis-OS) neu compiliert und baue Horizon > nochmal. Mal sehen, ob das was ändert. Ja, war schon besser. Hatte dann noch Linkerfehler für Cairo und YAML, sodass ich cairomm und yaml-cpp ebenfalls mit GCC 6 neu compiliert habe. (Ich vermute, bei yaml-cpp hätte der Upgrade an sich genügt.) Damit lässt es sich nun linken. Weiß nicht, ob der Clang in FreeBSD 11 dann C++14 bereits beherrscht; wenn, dann wären damit alle Versionsvoraussetzungen „aus der Dose raus“ erfüllt. Damit zeigt sich eigentlich, dass Lukas' Strategie, zu Beginn der Entwicklung „bleeding edge“ zu benutzen und davon auszugehen, dass diese in hinreichend kurzer Zeit ohnehin mainstream werden, offenbar funktioniert. Leider werde ich erst morgen abend wieder vor der FreeBSD-Kiste sitzen, um zu testen, ob's auch funktioniert. Im Moment bin ich mir noch nicht ganz sicher bezüglicher der GL-Version – in der Ausgabe von glxinfo sind so viele verschiedene Versions-Strings drin. :/
Hab's geschafft, via VNC auf die Maschine zuzugreifen. Wenn ich den Schaltplaneditor aus dem Project Manager starten will, bekomme ich:
1 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
2 | col 2 |
3 | create proc |
4 | |
5 | (<unknown>:7194): glibmm-ERROR **: |
6 | unhandled exception (type std::exception) in signal handler: |
7 | what: can't find executable |
8 | |
9 | |
10 | [3] Trace/BPT trap env LD_LIBRARY_PATH=/usr/local/lib/gcc6 ./horizon-prj-mgr (core dumped) |
(Weiß nicht, ob die SELECT-Ausschrift eventuell schon davor dort stand.) Stack trace im Coredump zeigt auf das Release-Event des GTK-Buttons, scheint sonst nicht wirklich interessante zu sein.
Jörg W. schrieb: > what: can't find executable Der Projektmanager muss rausfinden, wo der "interaktive Manipulator" (Schaltplan/Boardeditor) liegt und guckt dazu in dem Verzeichnis nach, indem auch er selber liegt: https://github.com/carrotIndustries/horizon/blob/master/util/util.cpp#L45 FreeBSD kann wohl kein /proc/self/exe Ich freue mich über Patches :) Jörg W. schrieb: > in der Ausgabe von glxinfo > sind so viele verschiedene Versions-Strings drin. :/ "OpenGL core profile version string" ist was du brauchst. Das muss >= 3 sein.
Lukas K. schrieb: > FreeBSD kann wohl kein /proc/self/exe Es gibt ein /proc/curproc/file, welches ein Symlink auf das eigene Executable ist. Darüber müsste sich das arrangieren lassen, wenn ich das richtig sehe. > Ich freue mich über Patches :) Schau' ich mir an. > "OpenGL core profile version string" ist was du brauchst. Das muss >= 3 > sein. OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.4 Sieht also gut aus. :)
Lukas K. schrieb: > Ich freue mich über Patches :) OK, der war einfach. :) Funktioniert offenbar wirklich genauso wie Linux, heißt halt nur anders. Fliegt dann aber trotzdem 'raus:
1 | create proc |
2 | spawn /home/joerg/src/horizon/horizon-imp -c /home/joerg/txt/drawings/horizontest/top_sch.json /home/joerg/txt/drawings/horizontest/top_block.json |
3 | terminate called after throwing an instance of 'std::runtime_error' |
4 | what(): locale::facet::_S_create_c_locale name not valid |
5 | end proc 11632 |
6 | exit stat 134 |
Jörg W. schrieb: > Funktioniert offenbar wirklich genauso wie Linux, heißt halt nur anders. ps: /proc-Filesystem ist unter FreeBSD nicht verpflichtend vorhanden. Sollte man vielleicht irgendwo im Wiki vermerken. Wenn es jemand nicht hat, kann er diese Zeile in /etc/fstab hinzufügen:
1 | proc /proc procfs rw 0 0 |
und mit "mount /proc" (als root) aktivieren.
1 | diff --git a/imp/imp_main.cpp b/imp/imp_main.cpp
|
2 | index 7ba90aa..aa217a4 100644
|
3 | --- a/imp/imp_main.cpp
|
4 | +++ b/imp/imp_main.cpp
|
5 | @@ -92,7 +92,7 @@ int main(int argc, char *argv[]) {
|
6 | std::locale::global(std::locale(std::cout.getloc(), new comma)); |
7 | } |
8 | #else |
9 | - std::locale::global(std::locale(""));
|
10 | + std::locale::global(std::locale("C"));
|
11 | #endif |
Damit stürzt es an dieser Stelle nicht ab und startet. Viel mehr an Tests ist über VNC hier gerade nicht drin.
Jörg W. schrieb: > + std::locale::global(std::locale("C")); Hm, das ist nicht so schön, dann geht's auf deutschen FreeBSDs kaputt. Probier's mal mit std::locale::global(std::locale(std::setlocale(LC_ALL, "")));
Ich verstehe noch nicht ganz, was du damit erreichen willst. Nur das Dezimalzeichen zurücksetzen?
Angehängte Dateien:
Ich bin schwer beeindruckt. Das Programm gefällt mir sehr. Ich bin gerade dabei, mich etwas einzuarbeiten und möchte ein kleines Projekt damit umsetzen. Es sieht ja schon sehr gut benutzbar aus. Das Konzept der Pools gefällt mir vor allem sehr gut. Das meiste, was ich in den 1 bis 2 Stunden, die ich jetzt davor sitze, entdeckt habe, wirkt sehr durchdacht! Zwei kleines Sachen sind mir aufgefallen: 1. Rechtecke mit abgerundeten Ecken versagen leider, wenn die Rundungen überlappen. Hintergrund ist, dass ich einen kleinen Punkt als Pin-1-Indikator setzen wollte. Dafür schien ein Rechteck mit runden Ecken die einfachste Lösung. Leider funktioniert der Grenzfall Eckradius gleich halber Kantenlänge nicht. Mit größerem Radius wird es nicht besser (siehe Anhang). 2. Es wäre schön, wenn es eine Möglichkeit gäbe, Ecken von Linien zu entfernen oder Linien aufzutrennen. Ich wollte einen komplizierteren Platinenumriss zeichnen und habe dafür zuerst das grobe Rechteck gemalt, was sehr bequem ging. Nur leider sehe ich keinen Weg, wie ich an einer Ecke noch etwas „wegschneiden” kann, weil die Linien immer als Rechteck verbunden sind und ich dieses nicht auftrennen kann, oder einen weiteren Knick einfügen kann. Ich hoffe das war so weit einigermaßen verständlich ;)
Jörg W. schrieb: > Ich verstehe noch nicht ganz, was du damit erreichen willst. Nur das > Dezimalzeichen zurücksetzen? Das Problem war, dass ich zum Einlesen von Zahlen strtod verwende, was locale-Abhängig ist und die Formatierung mit streams machen. strtod benutzt automatisch die System-Locale, nur die streams stehen standardmäßig auf "C". Ziel davon ist es, dass wenigstens der Dezimaltrenner gleich der System-Locale ist. Jonas F. schrieb: > Das meiste, was ich in den 1 > bis 2 Stunden, die ich jetzt davor sitze, entdeckt habe, wirkt sehr > durchdacht! Sehr schön :) > Zwei kleines Sachen sind mir aufgefallen: > > 1. Rechtecke mit abgerundeten Ecken versagen leider, wenn die Rundungen > überlappen. Hintergrund ist, dass ich einen kleinen Punkt als > Pin-1-Indikator setzen wollte. Dafür schien ein Rechteck mit runden > Ecken die einfachste Lösung. Leider funktioniert der Grenzfall Eckradius > gleich halber Kantenlänge nicht. Mit größerem Radius wird es nicht > besser (siehe Anhang). Das passiert, da das entstehende Polygon dann sich selbst schneidet bzw. berührt. Das gefällt der Library, die das Polygon trianguliert nicht so gut und die gibt dann komische Dinge aus. Ich bau noch ein, dass das wenigstens mit dem Tool nicht passieren kann. Als Pin1-Markierung ist es zu bevorzugen, die vorhandenen Linien zu kürzen/verlängern wie in http://www.ocipcdc.org/archive/What_is_New_in_IPC-7351C_03_11_2015.pdf beschrieben. > > 2. Es wäre schön, wenn es eine Möglichkeit gäbe, Ecken von Linien zu > entfernen oder Linien aufzutrennen. Ich wollte einen komplizierteren > Platinenumriss zeichnen und habe dafür zuerst das grobe Rechteck gemalt, > was sehr bequem ging. Nur leider sehe ich keinen Weg, wie ich an einer > Ecke noch etwas „wegschneiden” kann, weil die Linien immer als Rechteck > verbunden sind und ich dieses nicht auftrennen kann, oder einen weiteren > Knick einfügen kann. Horizon unterscheidet zwischen Linien und Polygonen. Linien sind für Dinge zu verwenden, die keine geschlossene Fläche darstellen, z.B. Linien auf dem Silkscreen. Alles was eine Fläche (z.B. Board-Outline) wird mit Polygonen dargestellt. Polygone sind prinzipiell immer geschlossen. Aber ja, du hast recht, man kann derzeit nur Ecken löschen und keine neuen einfügen. Das kommt noch recht zeitnah.
Lukas K. schrieb: > Ziel davon ist es, dass wenigstens der Dezimaltrenner gleich der > System-Locale ist. Hmm. Geänderte Dezimaltrenner ist das, was ich an diesem ganzen l16n-Kram am meisten hasse. Ich ärgere mich regelmäßig darüber, dass FreeCAD auf meinem Linux-Laptop ein "57.6 mm" völlig missinterpretiert, weil dort halt die komplette Umgebung auf deutsch steht (und ich zu faul war, das bislang zu ändern). An deutsche Menüs und Fehlermeldungen könnte ich mich ja zur Not noch gewöhnen, an geänderte Dezimaltrenner aber gar nicht. Auf meinem FreeBSD habe ich daher nur LC_CTYPE überhaupt auf deutsch stehen, der Rest ist nicht gesetzt. Ich wäre ja dafür, den Dezimaltrenner in den Preferences durch den Nutzer überschreibbar zu machen … Ich hoffe mal, der wird dann nicht für das Einlesen deiner JSON-Daten benutzt. ;-) OK, ich werde mir morgen mal anschauen, welche Variante auf FreeBSD da funktioniert. Bin ja auch gespannt, mit dem Programm dann mal real ein bisschen zu spielen, nach alldem, was die anderen inzwischen hier geschrieben haben.
Sodele, das Tool zum Hinzufügen von Ecken in Polygonen ist drin und das Tool zum malen von Polygonen mit runden ecken erzeugt keine ungültigen Polygone mehr. Jörg W. schrieb: > Ich wäre ja dafür, den Dezimaltrenner in den Preferences durch den > Nutzer überschreibbar zu machen … Hört sich sinnvoll an, mal drüber nachdenken... > Ich hoffe mal, der wird dann nicht für das Einlesen deiner JSON-Daten > benutzt. ;-) Da haben schon andere dran gedacht ;)
Mit diff --git a/Makefile b/Makefile index 077c01c..c5b6baf 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -CC=g++ +CC?=g++ PKGCONFIG=pkg-config kann man den benötigten Kompiler über eine Umgebungsvariable setzen.
Paralleles Bauen auf Mehrkernmaschinen wäre schön...
Uwe B. schrieb: > kann man den benötigten Kompiler über eine Umgebungsvariable setzen. Mal ne frage in die Runde: Müsste da nicht eigentlich CXX verwendet werden? Uwe B. schrieb: > Paralleles Bauen auf Mehrkernmaschinen wäre schön... make -j 8, etc. funktioniert
Okay, mein Fehler. Ich hatte env CC="g++-6" CFLAGS=-j9 make in der tcsh
versucht. env CC="g++-6" make -j9 kommt deutlich schneller zum nächsten
Problem:
Wshadow -std=c++14 -O3 imp/tool_popover.cpp -o imp/tool_popover.o
In file included from imp/imp.cpp:1:0:
imp/imp.hpp:19:19: fatal error: zmq.hpp: Datei oder Verzeichnis nicht
gefunden
#include <zmq.hpp>
^
compilation terminated.
Das ganze auf Opensuse 42.2 und gcc6.
Lukas K. schrieb: > Uwe B. schrieb: >> kann man den benötigten Kompiler über eine Umgebungsvariable setzen. > > Mal ne frage in die Runde: Müsste da nicht eigentlich CXX verwendet > werden? Ja, wäre sinnvoll.
Uwe B. schrieb: > In file included from imp/imp.cpp:1:0: > imp/imp.hpp:19:19: fatal error: zmq.hpp: Datei oder Verzeichnis nicht > gefunden > #include <zmq.hpp> > ^ > compilation terminated. > > Das ganze auf Opensuse 42.2 und gcc6. Auf FreeBSD war zeromq-cpp separat vom allgemeinen zeromq zu installieren. Vielleicht ja bei Opensuse auch?
Jörg W. schrieb: > Auf FreeBSD war zeromq-cpp separat vom allgemeinen zeromq zu > installieren. > Vielleicht ja bei Opensuse auch? Unter opensuse sollte das cppzmq-devel Paket installiert werden, doch unter Leap 42.2 gibt es das nicht, oder heisst anders. Gruß, Frank
Nachdem ich noch die Binutils-Gold installiert habe, lande ich bei ... Wshadow -std=c++14 -O3 pool-mgr/pool_notebook.cpp -o pool-mgr/pool_notebook.o pool-mgr/pool_notebook.cpp: In function ‘void horizon::send_msg(zmq::socket_t&, horizon::PoolUpdateStatus, const string&)’: pool-mgr/pool_notebook.cpp:826:30: error: no matching function for call to ‘zmq::message_t::message_t(horizon::pool_update_msg_t*&, size_t&)’ zmq::message_t zmsg(msg, sz);
Uwe B. schrieb: > Nachdem ich noch die Binutils-Gold installiert habe, lande ich bei Hmm, das gab's wohl damals noch nicht. Ich hab gerade mal was gepushed, damit's auch ohne diesen Konstruktor funktioniert.
Danke, jetzt kompiliert es unter Leap 42.2 und 42.3 durch.
Lukas K. schrieb: > Jörg W. schrieb: >> + std::locale::global(std::locale("C")); > > Hm, das ist nicht so schön, dann geht's auf deutschen FreeBSDs kaputt. > Probier's mal mit std::locale::global(std::locale(std::setlocale(LC_ALL, > ""))); Gerade getestet: funktioniert auch nicht, locale::facet::_S_create_c_locale name not valid Das dürfte übrigens keineswegs an FreeBSD selbst liegen, sondern daran, dass ich eben ansonsten keine "native locale" habe (für die der leere String ja steht). Wenn ich das Programm mit "env LANG=de_DE.UTF-8" starte, dann geht auch dein originaler Code. Ich vermute, dass das auch unter Linux kracht, wenn man keinerlei Notation einer "native locale" hat. Daher neuer Vorschlag: deinen originalen Code benutzen, aber die ggf. geworfene Exception abfangen und ignorieren. Jörg W. schrieb: > Viel mehr an Tests ist über VNC hier gerade nicht drin. Das lag allerdings gar nicht so sehr an VNC, sondern daran, dass sich die Grafik verklemmt hatte. :-( Das X-Server-Log war dann voller "EQ overflow", und es konnte danach alles mögliche passieren zwischen "Monitor geht in Standby, alles fängt sich nach paar Sekunden wieder" bis zu einem spontanen Reboot. Das Ganze war ein Onboard-ARUBA-Chipsatz. Ich habe jetzt mal eine andere Karte reingesteckt. Die hat bei meinem Sohn zwar Probleme bereitet, weshalb wir die Hardware in Verdacht hatten, aber bislang funktioniert sie hier und damit geht nun auch Horizon – hurra! Wirklich testen mag ich allerdings um diese Uhrzeit nichts mehr. Edit: sorry, habe nur "git diff" gemacht. Da sind jetzt beide Patch-Vorschläge in einem drin, der für die Locale und der für FreeBSD's procfs.
Jörg W. schrieb: > Lukas K. schrieb: >> Uwe B. schrieb: >>> kann man den benötigten Kompiler über eine Umgebungsvariable setzen. >> >> Mal ne frage in die Runde: Müsste da nicht eigentlich CXX verwendet >> werden? > > Ja, wäre sinnvoll. Da fällt mir ein: du müsstest lediglich das Makefile so umbauen, dass ${CXX} benutzt wird und nicht ${CC}. Die beanstandete Zeile kann dann komplett entfallen, da die Voreinstellung für CXX "c++" ist, was auf einem Linux typischerweise ein Symlink auf g++ ist. Ohne explizite Zuweisung von CXX im Makefile wiederum kann man es immer übers Environment überschreiben.
Angehängte Dateien:
-
simple-layout.png
76 KB
Wenn ich im angehängten äußerst simplen Mini-"Projekt" (ein R und ein C, nur an einer Stelle verbunden) versuche, mit "dt" einen neuen Track zu zeichnen, der einen Knotenpunkt auf dem existierenden hat (startend auf Pin2 von R?, mithin eine Netz-Kollision), und ich zeichne von da weiter, dann crasht es beim Drücken der rechten Maustaste mit:
1 | unhandled exception (type: std::exception) in signal handler: |
2 | what: map::at |
3 | |
4 | end proc 6243 |
5 | exit stat 133 |
Jörg W. schrieb: > Ohne explizite Zuweisung von CXX im Makefile wiederum kann man es > immer übers Environment überschreiben. https://github.com/carrotIndustries/horizon/blob/master/Makefile#L1 Sollte doch eigentlich auch mit "?=" funktionieren? Jörg W. schrieb: > mit "dt" einen neuen Track > zu zeichnen Wozu? Benutzen willst du eigentlich "Route Track Interactive" (x), das macht keine DRC-Fehler, etc. Aber ja, abstürzen sollte es nicht.
Lukas K. schrieb: > Jörg W. schrieb: >> Ohne explizite Zuweisung von CXX im Makefile wiederum kann man es >> immer übers Environment überschreiben. > > https://github.com/carrotIndustries/horizon/blob/master/Makefile#L1 > Sollte doch eigentlich auch mit "?=" funktionieren? Ja, aber diese Zuweisung braucht man eben gar nicht, wenn man ${CXX} zum Compilieren benutzt (machst du ja inzwischen), denn die Variable CXX ist passend voreingestellt. Allerdings heißen die Optionen dazu natürlich dann auch CXXFLAGS, nicht CFLAGS. > Jörg W. schrieb: >> mit "dt" einen neuen Track >> zu zeichnen > > Wozu? Weil ich überhaupt erstmal die Kommandos kennenlernen wollte. > Benutzen willst du eigentlich "Route Track Interactive" (x), das > macht keine DRC-Fehler, etc. OK, hatte ich schon gedacht. > Aber ja, abstürzen sollte es nicht. Yep, das war mein einziger Punkt hierbei. Stacktrace kann ich liefern, aber der ist ziemlich nichtssagend (finde ich).
Gute Nachrichten für die Benutzer von nicht-tiling-Fenstermanagern: Horizon speichert nun die Position von Fenstern. Jörg W. schrieb: >> Aber ja, abstürzen sollte es nicht. > > Yep, das war mein einziger Punkt hierbei. Ist repariert.
Lukas K. schrieb: > Gute Nachrichten für die Benutzer von nicht-tiling-Fenstermanagern: > Horizon speichert nun die Position von Fenstern. Zwar nicht sonderlich wichtig für mich, aber kann bestätigen, dass es funktioniert (fvwm2). > Jörg W. schrieb: >>> Aber ja, abstürzen sollte es nicht. >> >> Yep, das war mein einziger Punkt hierbei. > > Ist repariert. Auch das klappt, danke! Habe mir mal den Gerber-Output angesehen. Wenn man ganz unbedarft einfach auf "Generate" drückt, bekommt man eine Ladung Dateien mit den Namen ".gbl", ".gbo", ".txt" usw. Richtig, das wurde vorher auch so angezeigt – ich finde es aber trotzdem verwirrend. Irgendwie sollte in der Voreinstellung da meiner Meinung nach der Projektname als Dateinamens-Teil vorgegeben sein, und der Rest dann nur als Suffix benutzt. Die einzige Möglichkeit, den Nicht-Suffix-Anteil für alle generierten Dateien zugleich zu ändern, hat man derzeit mit dem "Präfix"-Feld. Weiß nicht, ob das so gedacht war. Wenn, dann fände ich es gut, wenn alles, was man in dieses Eingabefeld tippt, auch in den Dateinamen automatisch mit auftaucht, und natürlich dass dieses Feld dann mit dem Projektnamen vorbelegt ist. Für Lagen (oder Bohrungsgruppen), die aktuell keine Daten enthalten, sollten m. E. auch keine Dateien erzeugt werden. Ansonsten meckert bspw. gerbv, dass es damit jetzt nichts anfangen kann, weil es vermeintlich RS-274-D-Dateien wären und sowas. Das Nichtgenerieren dieser Lagen könnte man ja unten im Statusfenster dokumentieren. Schließlich hatte ich im Layout noch so eine sinnlose Struktur drin, wie oben im Screenshot gezeigt: ein Leiterzug ohne Breite, der daraus entstanden war, dass da einfach kein Netz definiert ist, welches man hätte routen können. Während die 3D-Vorschau diese Linie ordentlich ausblendet, taucht sie in der Gerberlage auf. Bin mir noch nicht ganz schlüssig, wie man sinnvoll damit umgeht. Vielleicht sollte man einfach in Kupferlagen keine Linien mit einer Breite von 0 zulassen, sondern generell die DRC-mäßige Mindestbreite setzen, auch wenn es jetzt kein Netz dafür gibt? (Wenn du für irgendwas lieber Patches sehen würdest als Prosa, kannst du mir das gern sagen. Ich würde dann versuchen, was zu basteln.)
Offtopic: kann man das Look&Feel von Gtk3 eigentlich von diesem "Tablet"-Aussehen irgendwie auch auf "normal" trimmen? Ich sitze an einem Computer und brauch' da keine riesigen Schaltflächen, auf die man mit den Fingern tatschen kann …
Hast du eigentlich Ambitionen, das alles auch auf MacOS lauffähig zu bekommen? Habe mir nur der Neugierde halber mal kurz angesehen, wie man dort zum Pfadnamen des aktuellen Prozesses gelangen würde. Scheint da über proc_pidpath() zu gehen. https://stackoverflow.com/questions/14805896/how-do-i-get-the-full-path-for-a-process-on-os-x
Hallo Lukas. Auf einem aktuellen Debian 9 (stretch) gelingt der Build (ca. 25 Minuten) problemlos. Ok, ein paar Warnungen wegen unbenutzter Variablen und sowas. Aber dann weiss ich nicht weiter. Ich bin weder Programmierer noch sonstwie ein IT Wissender. ;O) Sollte ich anschliessend ldconfig darüberlaufen lassen? Anmerkung: Habe ich gemacht. Das Ergebnis ist das gleiche. Was genau muss ich dann überhaupt wo und wie starten? Ich erhalte eine Reihe von ausführbaren Dateien. Unter anderem "horizon-prj-mgr" mit was 53,4Mb. Aber die lässt sich nicht starten. Auch nicht aus einer Konsole. Ich bin Eigentümer und habe Lese, Schreib- und Ausführungsrechte darauf. Aber auch als root geht es nicht. Die Konsole gibt mir als Fehlermeldung: "command not found", was auf fehlende Rechte oder eine unausführbare Datei hindeutet. Der Krusader öffnet ein Fenster und fragt, mit was ich die Datei geöffnet haben will. Info zum Debian hier: Linux 4.9.0-4-686-pae i686, 32 bit, Little endian, wxGTK Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Jörg W. schrieb: > Hast du eigentlich Ambitionen, das alles auch auf MacOS lauffähig > zu bekommen? Für Quartz gibt es (noch) keinen GdkGLContext. Wenn es den gibt, sollte dem nichts im Wege stehen. Jörg W. schrieb: > Für Lagen (oder Bohrungsgruppen), die aktuell keine Daten enthalten, > sollten m. E. auch keine Dateien erzeugt werden. Einige Hersteller geben an, dass sie gerne jede Lage hätten, auch wenn sie leer ist. Jörg W. schrieb: > weil es > vermeintlich RS-274-D-Dateien wären und sowas Der Code, der nachsieht, ob es eine RS-274X ist schaut einfach nur nach Substrings, die nach 274-X ausschauen. Wenn ein Layer eben leer ist, fällt das hin. Andere Gerber-Viewer hatten da nicht gemeckert. Jörg W. schrieb: > Die einzige Möglichkeit, den > Nicht-Suffix-Anteil für alle generierten Dateien zugleich zu ändern, > hat man derzeit mit dem "Präfix"-Feld. Weiß nicht, ob das so gedacht > war. Ja > Wenn, dann fände ich es gut, wenn alles, was man in dieses > Eingabefeld tippt, auch in den Dateinamen automatisch mit auftaucht, > und natürlich dass dieses Feld dann mit dem Projektnamen vorbelegt > ist. Ok, Projektname als Vorbelegung beim Erzeugen eines neuen Projektes ist drin. Die Idee mit dem zweiteiligen Dateinamen war, wirklich jedem Fertigerwunsch gerecht werden zu können und nicht den Projektnamen für jedes Layer einzeln eingeben zu müssen. Jörg W. schrieb: > Wenn, dann fände ich es gut, wenn alles, was man in dieses > Eingabefeld tippt, auch in den Dateinamen automatisch mit auftaucht Ideen, wie das konkret sinnvoll aussehen könnte? Logik wie: "gucken, ob noch mein Prefix im Dateiname ganz vorne drin ist, wenn ja anpassen, wenn nicht, nichts tun" scheint mir ein wenig fragil. Jörg W. schrieb: > Vielleicht sollte > man einfach in Kupferlagen keine Linien mit einer Breite von 0 > zulassen, sondern generell die DRC-mäßige Mindestbreite setzen, auch > wenn es jetzt kein Netz dafür gibt? Im DRC wird das dann auch beanstandet, dass der Track dünn ist. Tracks ohne Netz sollten ohnehin zukünftig einen DRC-Fehler geben. Jetzt nimmt's auch die default-Breite. Jörg W. schrieb: > Offtopic: kann man das Look&Feel von Gtk3 eigentlich von diesem > "Tablet"-Aussehen irgendwie auch auf "normal" trimmen? Das Aussehen von Gtk3 ist vollständig durch CSS anpassbar. Andere Themes gehen vielleicht ein wenig sparsamer mit padding um...
Bernd W. schrieb: > Aber die lässt sich nicht starten. > Auch nicht aus einer Konsole.
1 | ./horizon-prj-mgr |
Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. Ich hab's im Wiki mal angepasst.
Lukas K. schrieb: > Jörg W. schrieb: >> Hast du eigentlich Ambitionen, das alles auch auf MacOS lauffähig >> zu bekommen? > > Für Quartz gibt es (noch) keinen GdkGLContext. Wenn es den gibt, sollte > dem nichts im Wege stehen. Davon abgesehen, dass für Richard Stallman Apple der historische „Hauptfeind“ ist, so recht verstehe ich deren Policy da nicht. Im Jahr 2014 postet jemand offenbar zumindest teilweise funktionable Patches für Quartz: https://mail.gnome.org/archives/gtk-devel-list/2014-November/msg00017.html Im Jahr 2015 schaffen sie es dann gerade mal, eine “non-implementation” zu committen: https://mail.gnome.org/archives/commits-list/2015-May/msg01780.html > Jörg W. schrieb: >> Für Lagen (oder Bohrungsgruppen), die aktuell keine Daten enthalten, >> sollten m. E. auch keine Dateien erzeugt werden. > > Einige Hersteller geben an, dass sie gerne jede Lage hätten, auch wenn > sie leer ist. OK. > Jörg W. schrieb: >> Die einzige Möglichkeit, den >> Nicht-Suffix-Anteil für alle generierten Dateien zugleich zu ändern, >> hat man derzeit mit dem "Präfix"-Feld. Weiß nicht, ob das so gedacht >> war. > Ja Wenn ich mir das nochmal ansehe und ein wenig drüber nachdenke, würde ich das Layout etwas anders organisieren: Erstens linke und rechte Seite tauschen. Dann stehen Verzeichnisname und Dateiname auf der linken Seite. Das Feld "Prefix" würde ich in "Base Filename" umbenennen, die Beschriftung "Filename" in "Suffix". Ich denke, damit ist es dann eindeutig, wie sich die endgültigen Namen zusammensetzen, und dieser Vorschlag: >> Wenn, dann fände ich es gut, wenn alles, was man in dieses >> Eingabefeld tippt, auch in den Dateinamen automatisch mit auftaucht, >> und natürlich dass dieses Feld dann mit dem Projektnamen vorbelegt >> ist. … ist hinfällig. > Ok, Projektname als Vorbelegung beim Erzeugen eines neuen Projektes ist > drin. Die Idee mit dem zweiteiligen Dateinamen war, wirklich jedem > Fertigerwunsch gerecht werden zu können und nicht den Projektnamen für > jedes Layer einzeln eingeben zu müssen. Das ist durchaus sinnvoll. Das bringt mich drauf: diese Dateinamensendungen sind bei Gerber ja alles andere als standardisiert. Die Endungen, die du jetzt als Voreinstellung hast, sind die, die bspw. Altium benutzt. Andere Hersteller könnten da andere Vorlieben haben. In Zeiten, da die Dateinamenswelt nicht mehr aus 8+3 besteht, kann man ja auch Endungen wie .top oder .bottom benutzen statt kryptischer .gbt / .gbl. Das alles sowie die Details der generierten Dateien (Inch/Millimeter, Zahl der Dezimalstellen, Unterdrückung führender oder abschließender Nullen) ist typischerweise sehr spezifisch für einzelne Fertiger, auch wenn sich da allmählich mehr Toleranz und automatische Erkennung breit macht. Sowas müsste man eigentlich in einem “CAM Batch” als Voreinstellung hinterlegen können. Das eilt aber ganz gewiss nicht. > Jörg W. schrieb: >> Vielleicht sollte >> man einfach in Kupferlagen keine Linien mit einer Breite von 0 >> zulassen, sondern generell die DRC-mäßige Mindestbreite setzen, auch >> wenn es jetzt kein Netz dafür gibt? > > Im DRC wird das dann auch beanstandet, dass der Track dünn ist. Hätte ich auch erwartet :), den hatte ich nur für die Spielerei nicht laufen lassen. > Tracks > ohne Netz sollten ohnehin zukünftig einen DRC-Fehler geben. Finde ich schwierig: was ist der Unterschied zwischen einer Linie, die ich um Kupfer ziehe und bspw. einem Text? Der hat auch kein Netz. Einen DRC-Fehler sollte er nur bei Abstandsverletzung bringen. Eine Warnung wäre aber OK. > Jörg W. schrieb: >> Offtopic: kann man das Look&Feel von Gtk3 eigentlich von diesem >> "Tablet"-Aussehen irgendwie auch auf "normal" trimmen? > > Das Aussehen von Gtk3 ist vollständig durch CSS anpassbar. Andere Themes > gehen vielleicht ein wenig sparsamer mit padding um... OK, muss ich mir mal ansehen. Das Aussehen hatte mich schon gestört, als Evince als eines der wenigen Gtk-Programme, die ich sonst so habe, auf Gtk3 gewechselt ist.
Wenn Text kein Netz ist, dann gibts aber Krach wenn zwei verschiedene Netze von außerhalb den Buchstaben überkreuzen. Die würden dann über diesen Buchstaben bzw. Textstring kurzgeschlossen. Entweder der Text wird ein Netz (möglicherweise mit speziellen Namen), oder Text muß in der DRC extra behandelt werden, also eigene Regeln zu allen anderen Objekttypen bekommen. Was natürlich wegen O**2 rechenintensiv ist.
Hallo Lukas. Lukas K. schrieb: >> Aber die lässt sich nicht starten. >> Auch nicht aus einer Konsole. > >
1 | > ./horizon-prj-mgr |
2 | > |
> > Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. > Ich hab's im Wiki mal angepasst. <vor stirn patsch> Das wird es vermutlich gewesen sein. Irgendwie war ich wohl zu unkonzentriert. Ich werde es mal probieren, wenn ich heute Nachmittag wieder zu Hause bin. Danke für Deinen Hinweis. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Jörg W. schrieb: > Wenn ich mir das nochmal ansehe und ein wenig drüber nachdenke, > würde ich das Layout etwas anders organisieren: Hört sich sinnvoll an, mal drüber nachdenken. Jörg W. schrieb: > Die Endungen, die du jetzt als > Voreinstellung hast, sind die, die bspw. Altium benutzt. Die Motivation war mehr, dass die ganzen billigen Fertiger (mindestens Seeedstudio, Elecrow, OSHPark) die Protel-Endungen haben wollen. Ist ja aber auch nur die Vorbelegung. Jörg W. schrieb: > Das alles sowie die Details der generierten Dateien (Inch/Millimeter, > Zahl der Dezimalstellen, Unterdrückung führender oder abschließender > Nullen) ist typischerweise sehr spezifisch für einzelne Fertiger, > auch wenn sich da allmählich mehr Toleranz und automatische Erkennung > breit macht. Genau darum habe ich diese Einstellungen erstmal weggelassen. Wenn mir jemand einen Fertiger zeigt, der mit Metrisch, 6 Stellen hinterm Komma ohne führende Nullen nicht zurecht kommt, bau' ich da noch Einstellungen dazu. Jörg W. schrieb: > Finde ich schwierig: was ist der Unterschied zwischen einer Linie, > die ich um Kupfer ziehe und bspw. einem Text? Tracks, Linien und Texte sind verschiedene Dinge und werden im DRC auch anders behandelt.
Lukas K. schrieb: > Die Motivation war mehr, dass die ganzen billigen Fertiger (mindestens > Seeedstudio, Elecrow, OSHPark) die Protel-Endungen haben wollen. Ist ja > aber auch nur die Vorbelegung. Hast du eigentlich (oder wer anders) schon mal eine Platine fertigen lassen? Spiele mit dem Gedanken, mal mein Projekt bei Elecrow fertigen zu lassen um zu sehen was raus kommt ;-) Was anderes: Zu Kontrollzwecken wäre auch eine (konfigurierbare) Druckerausgabe nicht schlecht. Es soll auch noch "Bastler" geben, die selbst ätzen. Ich z.B. lege gerne mal die realen Bauteile auf einen Ausdruck, bevor ich was bestelle, hätte dabei aber gerne Löcher in den TH Pads. Gut, man könnte als Workaround die Gerber Dateien mittels gerbv ausdrucken.
Nachtrag: Bernd W. schrieb: >> Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. >> Ich hab's im Wiki mal angepasst. > > <vor stirn patsch> Das wird es vermutlich gewesen sein. Irgendwie war > ich wohl zu unkonzentriert. > > Ich werde es mal probieren, wenn ich heute Nachmittag wieder zu Hause > bin. Das war es leider nicht. Aber da sind noch andere merkwürdige Dinge. Ich such mal weiter. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Nachtrag: > > Bernd W. schrieb: > >>> Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. >>> Ich hab's im Wiki mal angepasst. >> >> <vor stirn patsch> Das wird es vermutlich gewesen sein. Irgendwie war >> ich wohl zu unkonzentriert. >> >> Ich werde es mal probieren, wenn ich heute Nachmittag wieder zu Hause >> bin. > > Das war es leider nicht. Aber da sind noch andere merkwürdige Dinge. > Ich such mal weiter. > > Mit freundlichem Gruß: Bernd Wiebus alias dl1eic > http://www.l02.de Hallo Bernd, ich habe hier einen Laptop mit zu alter Grafikkarte. Da startet zwar das erste Fenster und auch das zweite Fenster lässt sich anwählen, aber bei klicken auf "Board" tut sich nichts. Mit zu alten Grafikkarte funktioniert das Boardlayout von horizon nicht. Auf meinen Rechnern mit neuerer Grafikkarte habe ich dieses Problem nicht. Hast du genau das Problem oder erscheint bei dir gar kein Startbildschirm?
Lukas K. schrieb: > Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. > Ich hab's im Wiki mal angepasst. Nun, da gibt's durchaus noch eine Reihe ganz anderer Probleme. Ich hatte mir mal die "horizon-2017-11-21-0215.zip" heruntergeladen und versucht, dort irgend etwas zu starten. Ergebnisse: 1. libgio-2.00-0.dll wird vom Virenscanner als IDP.Generic erachtet und geblockt. 2. der "horizon-pool-mgr.exe" läßt sich zwar starten, aber außer einem leeren Fenster hat er nix aufzuweisen. Mit "Open" könnte man ja irgend ein "pool.json" laden - vorausgesetzt, man hätte sowas. In der Distri ist jedenfalls kein *.json enthalten. Erwartest du, daß ein Interessent so eine Datei vorhält? 3. auch "horizon-prj-mgr.exe" läßt sich starten, aber dort ist es fast das Gleiche wie zuvor: "No pools set up, You haven't set up any pools, add some in the preferences dialog...OK". Natürlich enthält die Distri auch kein "*.hprj" und in den Preferences ist's das Gleiche wie im vorigen Punkt, es fehlt am "pool". 4. alle anderen *.exe sind nicht startbar. So mein Freund, es ist wohl doch so, wie ich es bereits sehr viel weiter oben angedeutet habe: Während du dich mit tausenderlei "höheren" Details befaßt, fehlt es ganz krass an den simplen Fundamenten. Ich hätte erwartet, daß man als Benutzer zumindest die Chance hätte, das System erstmal irgendwie aufzusetzen, so daß es auch läuft und einen nicht vor ein zu nix brauchbares fast leeres Fenster setzt. Die penetrante und durch nichts lösbare Nachfrage nach dem ominösen Pool verhindert zuverlässig, daß man mit deinem Programm irgendwas beginnen kann. Erwarte bitte nicht, daß irgend ein Interessent eine derartige pool.json vorrätig hat. Entweder lieferst du eine derartige Datei als quasi Standard mit der Distri aus, oder du generierst per Menüpunkt "Neuer Pool" eine derartige Datei, sonst wird nix draus. Die Folge ist dann nämlich, daß dein Programm nach etwa drei Minuten wieder restlos von der Platte geputzt und abgehakt ist. Ist sowas deine Intention? Ich hatte es dir schon einmal gesagt, daß ganz am Anfang das Ausdenken, Formulieren und Festschreiben der Grundfunktionalität steht, sonst kommt man alsbaldigst in Teufels Küche. Du bist grad drauf und dran, so ziemlich ähnliche Fehler zu begehen wie die Kicad-Leute. Also nochmal: zu allererst die Fundamente und dann der Rest des Hauses - und der Innenausbau kommt nach dem Dach. W.S.
Angehängte Dateien:
Hallo W. S., das Programm horizon hat richtig Potential das neue Standardprogramm fuer die Privatanwender zu werden. Lukas kennt sich sowohl mit Hardware, PCB-Layout und mit Software aus. Deshalb habe ich da größtes Vertrauen, dass das Programm ein großer Wurf wird. Ich gebe zu, dass der Einstieg eine gewisse Hürde darstellt. Deshalb habe ich mal eine Anleitung geschrieben und ein paar screenshots dazu gemacht. Siehe nachfolgender Text. 1. Ein beliebiges Verzeichnis anlegen, z. B. C:\horizon. Das Ganze natürlich außerhalb von C:\Program .. 2. Windows Version herunterladen https://github.com/carrotIndustries/horizon/wiki/Getting-started -> 1.png Uuterhalb "Windows" auf "here" klicken." Da landet man dann hier: http://0x83.eu/horizon-zip/ Den zip-file in dem Verzeichnis C:\horizon speichern und dort auspacken - "unzip here". Das legt dann ein Unterverzeichnis horizon an. In dem sind die exe-Dateien. Damit sieht das so aus: C:\horizon\horizon 3. Pool laden. https://github.com/carrotIndustries/horizon/wiki/Getting-started "Get the pool" "download zipped pool" klicken. horizon-pool-master.zip in C:\horizon speichern. Auspacken mit "unzip here". Damit hat man ein Unterverzeihnis C:\horizon\horizon-pool-master 4. Example Project laden https://github.com/carrotIndustries/horizon/wiki/Getting-started Ziemlich unten auf der Webseite ist Example project "test project" klicken https://github.com/carrotIndustries/horizon-test-project "Clone or download" klicken "Download ZIP" klicken und in C:\horizon speichern. horizon-test-project-master.zip auspacken mit "unzip here". Damit hat man ein Unterverzeihnis mit Schaltplan und Layout. C:\horizon\horizon-test-project-master 5. Programm starten Mit dem Explorer nach C:\horizon\horizon gehen. horizon-prj-mgr.exe starten -> 2.png Links oben of das Symbol klicken und dann weiter mit "Preferences" -> 2a.png Ein neues Fenster geht auf -> Add pool klicken -> 2b.png Jetzt die .json Datei aus dem Verzeichnis "C:\horizon\horizon-pool-master" waehlen -> 2c.png OK klicken -> 2d.png In dem kleinen Fenster "Preferences" auf x klicken." -> 2e.png Jetzt sind wir wieder im Fenster wie beim Start - 2e.png "Open" klicken" um das Beispielprojekt zu waehlen, C:\horizon\horizon-test-project-master\pic32-eth.hprj -> 3.png Zum Schluss "Open" klicken in dem Fenster -> 3.png Jetzt sieht das Fenster so aus -> 4.png Hier kann man jetzt den Schaltplan(Top Schematic) und das Layout(Board) laden. Den 3D View kann man aus dem PCB-Layout starten. Gruß, Helmut
W.S. schrieb: > So mein Freund Meinst du wirklich, dass du dir mit deinem Geblubber „Freunde“ machst? Wenn du dir den Thread mal ansiehst, dann wirst du feststellen, dass es hinreichend viele Leute gibt, die selbst in dieser Phase durchaus in der Lage sind, das Dingens zum Laufen zu bekommen. Dass es noch lange nicht im "Plug&Play"-Stadium ist, nun, das steht eigentlich schon in der Threadüberschrift drin. Wenn du mit dieser Erwartungshaltung hergekommen bist: geh' einfach wieder. Komm dann wieder, wenn Lukas es nicht mehr als "halbfertig" tituliert sondern wenigstens als "Beta". Wenn dir ernsthaft daran gelegen ist, hier was zu testen und auch sinnvolles Feedback zu geben, dann wirst du ganz sicher auch die derzeitige Einstiegshürde schaffen. Viele andere haben es vor dir geschafft. Wenn du dich im Thread umsiehst, wirst du feststellen, dass Lukas konstruktiver Kritik gegenüber durchaus sehr aufgeschlossen ist. „ist eingebaut“, „ist geändert“, „klingt sinnvoll“ kannst du hier an vielen Stellen lesen. Auf Kritik der Art „du bist völlig auf dem Holzweg“ wird er jedoch sehr sicher verzichten können, da brauchst du dir also auch nicht erst die Mühe machen, sowas aufzuschreiben.
Sowas wie ne Batch-Datei wäre schon schön. Nicht das ich es jetzt in diesem Stadium persönlich installieren würde. Nur ein Vorschlag.
Abdul K. schrieb: > Sowas wie ne Batch-Datei wäre schon schön. Den Pool muss man nur einmal runterladen, danach braucht man sich darum nicht mehr kümmern. Dass das derzeitige Pool-Konzept nur ein Anfang ist, hatte Lukas ja schon geschrieben. An der Stelle wird sich also ohnehin nochmal was ändern. So schlecht dokumentiert hat er das alles gar nicht, steht halt in seinem Wiki. Da habe ich schon viel mehr Software erlebt, bei denen die Doku nur aus .cpp-Dateien bestand.
Sicher, nur du bist halt damit den ganzen Tag beschäftigt. Morgens klebt schon diverses C++ an der Kaffeetasse. Andere wollen das Programm nur einsetzen.
Abdul K. schrieb: > Andere wollen das Programm nur einsetzen. Naja, siehe Beitrag drüber: so weit ist es einfach noch nicht. Im Moment ist das praktisch nur was für Leute, die da bei der Entwicklung auch (zumindest passiv) mitmachen möchten. Das Teil wirft mit diversen Meldungen um sich, und es kann hie und da schon auch mal 'ne unhandled exception geben. Wenn man das berichtet, stellt Lukas es ab, aber wertvolle Arbeit würde ich damit nur mit ganz viel zwischendrin Speichern machen wollen im derzeitigen Stadium.
Abdul K. schrieb: > Sicher, nur du bist halt damit den ganzen Tag beschäftigt. Morgens > klebt > schon diverses C++ an der Kaffeetasse. > Andere wollen das Programm nur einsetzen. Hallo Abdul K., Man muss nicht selber kompilieren, wenn man einen WIN-PC hat. Lukas stellt sehr aktuelle exe-Dateien für Windows bereit. Das ist schon mal ein Superservice. https://github.com/carrotIndustries/horizon/wiki/Getting-started Get Horizon Windows "here" PS: Darauf musste man bei Gnu-Octave z. B. zehn Jahre warten. Achtung, nur weiterlesen, wenn man selber unter WIN kompilieren will. Die "build"-Umgebung in Windows lässt sich leichter installieren als die für Linux. Lukas hat das genau auf seiner Webseite beschrieben. Zusätzlich habe ich hier in einer meiner Antworten die notwendigen Kommandos zum erzeugen eigener WIN-exe zusammengefasst. Anleitung zum Kompilieren der WIN-exe auf einem WIN-PC. Einmalig mysys2 installieren. Anleitung siehe Webseite von Lukas. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows --- WIN version erzeugen In WIN mysys2 starten. Ein Terminal geht auf. In dem Terminal wird dann gearbeitet. #Im home/user Verzeichnis von mysys2 ein Verzeichnis anlegen. $ mkdir horizonxyz #Vom home-Verzeichnis in dieses Verzeichns wechseln. $ cd horizonxyz #Die Source-Files herunterladen. $ git clone http://github.com/carrotIndustries/horizon #In das von clone angelegte Unterverzeichnis horizon wechseln. $ cd horizon #Kompilieren mit allen logischen cores des Prozessors damit es schnell geht. Beispiel CPU mit 4 cores + hyperthreading -> -j 8. $ make -j 8 #Die WIN-Version im Ordner "dist" erzeugen. $ ./make_bindist.sh Im Unter-Ordner "dist" ist dann ein Verzeichnis horizon. Das ist das Programmverzeichnis für die Windows-Version.
Wie starte ich einen neuen Pool? Gibt's dafür ein Tool? Wenn ich im Pool ein Symbol editiere (wird vermutlich bei anderen Elementen nicht anders sein), hätte ich außer "Save" auch gern ein "Save As …", damit ich ausgehend von einem vorhandenen Element ein neues ableiten kann.
Jörg W. schrieb: > Wenn du dich im Thread umsiehst, wirst du feststellen, > dass Lukas konstruktiver Kritik gegenüber durchaus sehr > aufgeschlossen ist. Ja, durchaus. > Auf Kritik der Art „du bist völlig auf dem Holzweg“ wird > er jedoch sehr sicher verzichten können, da brauchst du dir > also auch nicht erst die Mühe machen, sowas aufzuschreiben. Das ist sicher auch richtig -- das heißt aber nicht, dass diese Kritik zwingenderweise sachlich falsch ist. Ich hätte es auch wichtiger gefunden, vorhandene Software besser und interoperabler zu machen, als ein weiteres Komplettpaket zu schaffen -- aber es lohnt nicht, das dauernd wieder aufzuwärmen.
Ah Abstürze. Achgott, PCs eben. Ich hatte ja oben mal was über RUN-EDS anno 1992 geschrieben. Also damals ist diese Software so alle 2h abgestürzt. Und es gab einen speziellen abundzu Fehler, wo das Projekt irreparabel zerstört wurde. Das heißt, es wurde die Datei zerschreddert ohne sofortige Auswirkung. Irgendwann hat sich dieser Fehler dann offenbart und alles dazwischen an Arbeit reingesteckte, war damit futsch. Da nützt also auch kein Backup! Das MacOS ging auch so 2-mal pro Tag hops... Auf einem 19" Monitor konnte man beim Scrollen zugucken. So war das damals. Nur mal so erwähnt für die jungen Hüpfer. Die letzten Versionen RUN-EDS von 2001 waren recht stabil und hatten kaum Fehler. Das MacOS lief da bereits rockstabil. Und nochwas zu Bartels Autorouter: 2001 hatten wir die letzten Vergleichstest zum Specctre-Router gemacht. Der war besser als der Bartels. Und lief schneller auf billigerer Hardware, da Windoof-PC.
Possetitjel schrieb: > Ich hätte es auch wichtiger gefunden, vorhandene Software > besser und interoperabler zu machen, als ein weiteres > Komplettpaket zu schaffen Mag sein. Andererseits – wenn Lukas für sich erkannt hat, dass die vorhandene Software einfach mal eine „verfahrene Kiste“ ist (was ja letztlich auch W.S. für Kicad immer mal wieder behauptet, und was Stefan Salewski für gEDA so konstatiert hat), dann kann die Auflösung „Fang von vorn an und mach es besser“ durchaus die richtige sein. Kommt hinzu, dass Lukas es offenbar vom Arbeitsumfang tatsächlich in der Lage ist zu stemmen.
Jörg W. schrieb: > hätte ich außer "Save" auch gern ein "Save As …" Da fällt mir gerade auf: Alle Objekte im Pool Manager haben auch einen "Create"-Button – nur Symbole nicht. Irgendwie muss Lukas ja seine Symbole wohl auch angelegt haben.
Abdul K. schrieb: > Und nochwas zu Bartels Autorouter: 2001 hatten wir die letzten > Vergleichstest zum Specctre-Router gemacht. Der war besser als der > Bartels. Und lief schneller auf billigerer Hardware, da Windoof-PC. Wobei ich BAE seit 2001 unter FreeBSD benutze (die Linux-Version), ist also nicht so, dass sie originär Mac-Edelhardware benötigt hätten. ;) Zu anderen Autoroutern kann ich nicht so viel sagen.
Das besondere am Mac war die Software, nicht die Hardware. Naja, die Kombination in manchen Bereichen, z.B. die Maus kombiniert mit vollgrafischer Oberfläche. Allerdings hatten die ersten Macs schon echte EMV-Designs. Das habe ich bei den Windows-Kisten bzw. DOS IBM-PC ziemlich vermißt. Ok, falscher Thread :-)
Helmut S. schrieb: > Deshalb habe ich mal eine Anleitung geschrieben und ein paar screenshots > dazu gemacht. Siehe nachfolgender Text. Cool, danke. Damit habe ich es bei mir fix zum Laufen bekommen - bin ja neugierig und bewundere, was Lukas treibt. Aur meiner Büchse (i7-3770, 4GB RAM, Win 7, SSD) braucht es gefühlte 10 Sekunden für den Start. Anschließend sieht es dann etwas seltam aus - ich sehe zwar alle Bedienelemente, aber weder Schaltplan noch Layout. Grafikkarte ist eine Radeon HD3600 - ziemlich alte Gurke, lt. Wikpedia kann sie aber OpenGL 3.3. Windows behauptet, der Treiber sei aktuell. Das prüfe ich aber erst morgen, es ist Zeit fürs Bett. Fehlermeldungen wirft Horizon (2017-11-23-1801, das nenne ich mal bleeding edge) keine. Gibt es irgendwo ein Logfile?
Max G. schrieb: > Grafikkarte ist eine Radeon HD3600 - ziemlich alte Gurke, lt. Wikpedia > kann sie aber OpenGL 3.3. Windows behauptet, der Treiber sei aktuell. > Das prüfe ich aber erst morgen, es ist Zeit fürs Bett. > Ich habe gerade mal diese Version "horizon-2017-11-23-1801.zip" kurz gestartet. Die läuft einwandfrei auf einem PC mit neuerer Grafikkarte (GTX950). Nach meiner Erfahrung geht es ab Nvidia GTX560 und neuer problemlos. Bei einer Nvidia GTX260 geht fast alles bis auf das Füllen der Planes. Auf Rechnern mit Intel-CPU-Grafik läuft horizon auch. Das kann nur also nur an deiner Grafikkarte/Grafikkarten-Treiber liegen. Da hilft wohl nur eine neuere Grafikkarte.
Jörg W. schrieb: > Da fällt mir gerade auf: Alle Objekte im Pool Manager haben auch einen > "Create"-Button – nur Symbole nicht. Der ist bei den Units, da zu jedem Symbol eine Unit gehört. Symbole sind nicht die Primärquelle für Pins, dazu hat's die Units. Für bessere discoverability hab ich jetzt auch noch einen Knopf bei den Symbols eingebaut. Jörg W. schrieb: > Wie starte ich einen neuen Pool? Gibt's dafür ein Tool? Nein, da Leute dazu motiviert werden sollen, den globalen Pool zu benutzen. Wer seinen eignen Pool (z.B. in einem Unternehmen) haben will, kopiert sich am einfachsten den globalen Pool, löscht alles was nicht gefällt und ändert die UUID in der pool.json > Wenn ich im Pool ein Symbol editiere (wird vermutlich bei anderen > Elementen nicht anders sein), hätte ich außer "Save" auch gern ein > "Save As …", damit ich ausgehend von einem vorhandenen Element ein > neues ableiten kann. Okay, kommt bald, wenn auch wohl als "Duplicate"-Knopf im Pool-Manager. Falls sich wer wundert, weshalb so offensichtlich notwendige Features fehlen: Als Entwickler hat man leider eine etwas verzerrte Sicht auf die Dinge und hat 1000 Einfälle, was man als nächstes bauen könnte. Sowas wie Duplicate war auch mal dabei. Meistens gewinnt dann aber der Spieltrieb und sowas die 3D-Vorschau kommt dabei raus oder man kümmert sich um Details wie unglückliche Auswahl-Boxen. Solche wünsche von anderen Anwendern/Testern helfen mir ungemein Ideen zu priorisieren. Danke an alle! Max G. schrieb: > Aur meiner Büchse (i7-3770, 4GB RAM, Win 7, SSD) braucht es gefühlte 10 > Sekunden für den Start. Anschließend sieht es dann etwas seltam aus - > ich sehe zwar alle Bedienelemente, aber weder Schaltplan noch Layout. Kannst du mal einen Screenshot von dem Malheur machen? Tester schrieb: > Hast du eigentlich (oder wer anders) schon mal eine Platine fertigen > lassen? Spiele mit dem Gedanken, mal mein Projekt bei Elecrow fertigen > zu lassen um zu sehen was raus kommt ;-) Nicht dass ich wüsste. Wenn du magst nur zu, aber sei nicht böse mit mir, wenn's nichts wird ;) > Was anderes: Zu Kontrollzwecken wäre auch eine (konfigurierbare) > Druckerausgabe nicht schlecht. So wie ich jetzt drüber nachdenke eigentlich recht wenig Aufwand mit cairo...
Max G. schrieb: > Fehlermeldungen wirft Horizon (2017-11-23-1801, das nenne ich mal > bleeding edge) keine. Die werden auf der Console rausgeworfen, also std::cerr << "irgendwas". Müsstest du unter Windows wohl direkt aus einem cmd.exe heraus starten. Fehlermeldungen kommen hier auch nicht sooo viele (wenn ich nicht gerade mal in eine Exception trete ;), aber es gibt massenhaft Debugausgaben, bis hin zu SQL statements, die beim Ausfüllen des Suchfeldes angezeigt werden. Irgendwas solltest du da also schon sehen. :)
1 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
2 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
3 | create proc |
4 | exit stat 0 |
Noch ein Nachtrag: Bernd W. schrieb: > Nachtrag: >>> Ohne das ./ sucht die Shell in $PATH und nicht im aktuellen Verzeichnis. >>> Ich hab's im Wiki mal angepasst. >> >> <vor stirn patsch> Das wird es vermutlich gewesen sein. Irgendwie war >> ich wohl zu unkonzentriert. >> >> Ich werde es mal probieren, wenn ich heute Nachmittag wieder zu Hause >> bin. > > Das war es leider nicht. Aber da sind noch andere merkwürdige Dinge. > Ich such mal weiter. Schande über mich. Das war ich selber. Ein Klassiker, per remote auf dem falschen Rechner und das auch nicht mitkriegen. :( Nun startet das Programm, bricht aber mit einer Fehlermeldung ab: (horizon-prj-mgr:1424): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: unable to open database file Trace/Breakpoint ausgelöst Ich probier mal ein pull, ob es da was neues gibt. So, neue Daten, neuer build, aber gleiches Ergebnis: (horizon-prj-mgr:3274): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: unable to open database file Trace/Breakpoint ausgelöst Wenn mit der "database" der pool gemeint ist, den habe ich auch auf der Platte. Nur wie teile ich horizon mit, wo der ist? Bisher konnte ich ja noch nicht allzu viel an Ergebnis sehen, aber alleine die Menge an Sourcecode: "Hut ab" Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Bernd, ließ doch mal meine vorletzte Message - die mit den vielen Screenshots. Da steht drin wie man den Pool hinzufügt. Das muss man nur einmal machen. Helmut
Bernd W. schrieb: > Nur wie teile ich horizon mit, wo der ist? Mit dem Pool Manager. Wundert mich nur, dass er ohne irgendeinen registrierten Pool überhaupt startet. Das hat er bei mir abgelehnt.
Bernd W. schrieb: > (horizon-prj-mgr:1424): glibmm-ERROR **: > unhandled exception (type std::exception) in signal handler: > what: unable to open database file Ist repariert, das Problem war folgendes: Zum Speichern der Fenstergrößen benutze ich auch SQLite und das erwartet logischerweise, dass es das Verzeichnis, in dem die Datenbank liegt schon existiert. Bis jetzt ist das nur keinem aufgefallen, da alle das Verzeichnis schon hatten.
Man brauch SQlite zur Speicherung von 4 32Bit Zahlen? Da würde mich mal interessieren, wie man ohne Starten des Programms die Koordinaten eines Fensters per Hand ändert. Wie aufwändig ist das? Was muß man tun? Rein interessehalber. Normalerweise ist das doch in einer ini-Datei oder schlimmer noch in der Registry.
Abdul K. schrieb: > Man brauch SQlite zur Speicherung von 4 32Bit Zahlen? Du brauchst zwei Mal 32bit für Fenstergrößen? Respekt. Den Monitor hätte ich auch gerne...
Ich habe keine Ahnung wie MS das vorgibt. Vielleicht sinds auch nur 16bitter.
Abdul K. schrieb: > Man brauch SQlite zur Speicherung von 4 32Bit Zahlen? Macht Dinge einfacher: Je nachdem, was der Anwender macht, können ja auch mehrere Fenster nahezu zeitgleich geschlossen werden und dereb Größen müssen gespeichert werden. Bei einer ini/json-Datei hätte ich über Locking nachdenken müssen, damit das nicht hinfällt, bei SQLite haben schon andere mit mehr Ahnung von der Materie drüber nachgedacht. Der Overhead meinerseits von SQLite verglichen mit einer Datei geht auch gegen null. > Da würde mich mal > interessieren, wie man ohne Starten des Programms die Koordinaten eines > Fensters per Hand ändert. Wie aufwändig ist das? Was muß man tun?
1 | $ sqlite3 .config/horizon/window_state.db |
2 | SQLite version 3.21.0 2017-10-24 18:55:49 |
3 | Enter ".help" for usage hints. |
4 | sqlite> SELECT * FROM window_state; |
5 | prj-mgr|1914|871|1|38|0 |
6 | pool-editor-win-27|762|600|579|286|0 |
7 | imp-symbol|1914|871|1|38|0 |
8 | pool-mgr|1914|871|1|38|0 |
9 | |
10 | sqlite> UPDATE window_state SET width=100 WHERE window='prj-mgr'; |
11 | |
12 | sqlite> SELECT * FROM window_state; |
13 | prj-mgr|100|871|1|38|0 |
14 | pool-editor-win-27|762|600|579|286|0 |
15 | imp-symbol|1914|871|1|38|0 |
16 | pool-mgr|1914|871|1|38|0 |
Alles kein Hexenwerk.
Lukas K. schrieb: > bei SQLite haben schon andere mit mehr Ahnung von der Materie drüber > nachgedacht Genau darin sehe ich auch den Vorteil. SQlite ist einfach stabile Technik, die man nur noch benutzen muss.
Interessant. Ich sehe nur das Problem, wie man das dann repariert wenn was kaputt ist. Bei einer Textdatei ist das oft gut machbar. XML wird schon schwieriger. Gerade eben habe ich einen Vista-Rechner, der partout zu einen bestimmten WLAN AP keine Verbindung aufbauen will. Mann kann die Liste der aktiven APs aufrufen und einen auswählen, und das wars dann auch. Keine Fehlemeldung und der alte AP weiterhin aktiv. Andere Platte rein, geht. Tja, also config defekt. Google bedient. Konfigurationsdateien gibts pro AP. Diese habe ich auch gefunden. Inhalt unlesbar. Dekodiermaske gibts nicht. Bei Windoof alles geheim. In der Registry das gleiche Spiel. Zig Einträge, aber völlig unsichtbar was wo im Bereich WLAN verknüpft ist. DAS IST EINFACH EIN SCHROTTKONZEPT! Das Ende vom Lied: Werde Vista platt machen und Win7 komplett frisch installieren. Nicht nur wegen dem AP, sondern weil eh noch andere Sachen Probleme machen. Selbst der Ersatz der Konfigurationsdatei für diesen speziellen AP von der anderen lauffähigen Platte hat nicht funktioniert.
Hallo, ich hab mal versucht Horizon unter Solus Linux zu kompilieren, und es funktioniert erfreulicherweise out-of-the-box :) Tools installieren:
1 | $ sudo eopkg install git |
2 | $ sudo eopkg install -c system.devel |
3 | $ sudo eopkg install libgtkmm-3-devel cairomm-devel librsvg-devel util-linux-devel yaml-cpp-devel sqlite3-devel libboost-devel zeromq-devel cppzmq glm binutils-gold |
Source herunterladen und Build starten:
1 | $ mkdir -p ~/tmp/horizon |
2 | $ cd ~/tmp/horizon |
3 | $ git clone https://github.com/carrotIndustries/horizon.git |
4 | $ make |
Pool und Testprojekt herunterladen:
1 | $ cd ~/tmp |
2 | $ git clone https://github.com/carrotIndustries/horizon-pool.git |
3 | $ git clone https://github.com/carrotIndustries/horizon-test-project.git |
Starten:
1 | $ ~/tmp/horizon/horizon-prj-mgr |
2 | $ ~/tmp/horizon/horizon-pool-mgr |
Grüße, Ulrich
Ich hätte noch eine Anregung: Wenn man ein Objekt anwählt, kann man ja die Attribute editieren. Wählt man z.B. mehrere Leiterbahnsegmente aus und möchte man bei allen z.B. die Breite ändern, muss man alle durch klicken. Es wäre schön, wenn man z.B. eine Checkbox mit "Apply to all" hätte, so dass nach dem Anwählen der Checkbox die Änderungen für alle Segmente simultan angewendet werden würde.
Klaus R. schrieb: > Es wäre schön, wenn man z.B. eine Checkbox mit "Apply to all" > hätte, so dass nach dem Anwählen der Checkbox die Änderungen für alle > Segmente simultan angewendet werden würde. Das gibt es doch schon, das macht der Knopf mit dem Haken. Ich hab' dem gerade mal noch einen Tooltip spendiert.
Angehängte Dateien:
-
horizon16.png
47 KB
Aehm... der "Knopf mit Haken"? Die Haken "tun" bei mir nicht viel. Egal was ich anklicke, es ändert sich nur das als erstes angewähltes Segment. Edit: Ok, hab's kapiert. Erst die Breite für eines ändern, danach den Haken anwählen. Jetzt wird es für alle Angewählten übernommen.
Angehängte Dateien:
-
schematic.png
65 KB -
pcb.png
110 KB
Lukas K. schrieb: > Kannst du mal einen Screenshot von dem Malheur machen? Gerne. Sieht originell aus, die Kontextmenüs gehen auch. Man sieht nur nichts. Auf der CMD-Konsole kommt nichts an, ist aber unter Windows typisch. Die Ausgabe von GUI-Programmen landet irgendwo im Nirvana und ist nur per Debugger sichtbar.
Max G. schrieb: > Gerne. Sieht originell aus, die Kontextmenüs gehen auch. Man sieht nur > nichts. Seltsam ist ebenfalls, dass an der Stelle, an der normalerweise der Grid-Multiplikator steht, nichts steht. Um Ausagabe auf der Konsole zu bekommen, musst du den horizon-prj-mgr.exe aus einer mingw-Konsole starten. Wenn du dir eh msys2 installierst, installier' dort drin mal gtk: pacman -S mingw-w64-x86_64-gtk3 und starte die gtk3-demo und öffne die OpenGL-Demo. Was passiert da?
Jörg W. schrieb: > Meinst du wirklich, dass du dir mit deinem Geblubber „Freunde“ machst? > > Wenn du dir den Thread mal ansiehst, dann wirst du feststellen, dass > es hinreichend viele Leute gibt, die selbst in dieser Phase durchaus > in der Lage sind, das Dingens zum Laufen zu bekommen. Ach Jörg, ich hab mich an dein unsachliches Geblubber und deine persönlichen Anfeindungen mittlerweile gewöhnt, so daß ich diese zumeist einfach überlese. Wenn was nicht funktioniert, dann sag ich das auch - ob dir das schmeckt oder nicht, ist deine Sache. Ich erwarte ganz schlicht und einfach, daß sowas benutzbar ist, ohne daß man erst Sherlock Holmes spielen muß. Ich werde also eben NICHT nach irgendwelchen fehlenden Teilen im Internet herumsuchen. Punkt. Jörg W. schrieb: > Wie starte ich einen neuen Pool? Gibt's dafür ein Tool? Ach? Sieh mal einer an. Ein paar Beiträge nach deinem obigen Einwurf kommst du auf das gleiche Problem, ja? Ich sag dir eins: Es kommt eben doch auf den vor jeglicher Programmiererei gefaßten, formulierten und gründlich überprüften Entwurf an. W.S.
Jetzt laß die Karottenindustrie einfach mal machen. In einem Jahr ist das bestimmt brauchbar. Ich habe jedenfalls vollsten Respekt! Danach kann Lukas mit dem Transverter TINA nach LTspice Projektfile weitermachen :-)
W.S. schrieb: > Ein paar Beiträge nach deinem obigen Einwurf kommst du auf das gleiche > Problem, ja? Nein, ein völlig anderes. Wie du Lukas' Antwort entnehmen kannst, gibt es das, wonach ich gefragt habe, derzeit schlicht noch nicht. Das liegt aber daran, dass er den zentralen Pool im Moment als Designentscheidung erst einmal so vorgesehen hat. Damit kann ich leben, Würgaround hat er genannt, einen Script, um einen neuen Pool zu erzeugen, könnte ich mir zur Not sicher auch selbst zimmern. > Wenn was nicht funktioniert, dann sag ich das auch Du kommst aber mit der Anspruchshaltung eines „Endkunden“ an und übersiehst geflissentlich, dass sich Horizon derzeit überhaupt nicht an solche richtet. Das hat Lukas in diesem Thread von vornherein klar gemacht, und das steht im Prinzip bereits in der Überschrift. Die Schritte, wie man es zum Laufen bekommt, sind beschrieben. Wenn dir das zu umständlich ist, dann ist das Programm im derzeitigen Zustand einfach mal nichts für dich, aber dann musst du doch auch nicht ständig wieder hier aufschlagen und allen, die es gar nicht hören wollen verkünden, wie schlecht es doch sei.
@Lukas, mal was ganz Nichttechnisches: du solltest deinen Dateien irgendeine Art von Copyright-Header voranstellen. Ohne einen solchen darf man sie ganz formal eigentlich nicht weiterverbreiten.
Lukas K. schrieb: > Jörg W. schrieb: >> Da fällt mir gerade auf: Alle Objekte im Pool Manager haben auch einen >> "Create"-Button – nur Symbole nicht. > > Der ist bei den Units, da zu jedem Symbol eine Unit gehört. Symbole sind > nicht die Primärquelle für Pins, dazu hat's die Units. Hmm, das hatte ich so noch nicht verstanden. Ich hatte gedacht, dass die Units nur das Bindeglied sind, man aber ein und dasselbe Symbol in verschiedenen Units benutzen könnte. > Für bessere > discoverability hab ich jetzt auch noch einen Knopf bei den Symbols > eingebaut. OK, danke. Ich würde die Buttons allerdings tauschen (siehe Patch), denn in allen anderen Tabs ist auch erst "Create", danach "Edit".
Jörg W. schrieb: > Max G. schrieb: >> Fehlermeldungen [...] > > Die werden auf der Console rausgeworfen, also std::cerr << "irgendwas". Wären da nicht std::clog oder std::wclog sinnvoller?
W.S. schrieb: > Ich erwarte ganz schlicht und einfach, daß sowas benutzbar ist, ohne daß > man erst Sherlock Holmes spielen muß. Ich werde also eben NICHT nach > irgendwelchen fehlenden Teilen im Internet herumsuchen. Punkt. Auf der Git-Seite war eine Anleitug, wo man das pool.json herbekommt ... rtfm Außerdem ist die Software noch nicht mal Beta ... Seufz
Beitrag #5222891 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
double_click_parts.PNG
180 KB
Hallo Lukas, ./horizon-pool-mgr.exe Ab dem zweiten Doppelklick auf eine "Bauteilezeile" kommen permanent diese Debug-Meldungen. Sind diese Debug-Meldungen im mysys2-Terminal OK oder ist das ein Problem?
Helmut S. schrieb: > Sind diese Debug-Meldungen im mysys2-Terminal OK oder ist das ein > Problem? Nichts tragisches, Gtk ist wohl über irgendwas mit der Pad-Box rechts nicht ganz glücklich. Was genau, mag sich mir auch nicht so recht erschließen. Lukas K. schrieb: > Okay, kommt bald, wenn auch wohl als "Duplicate"-Knopf im Pool-Manager. Sind drin: Für Entities und Parts fallen die Dialoge ein wenig komplexer als vielleicht erwartet aus, da ausgewählt werden kann, ob referenzierte Objekte auch kopiert werden, oder die bereits vorhandenen referenziert werden sollen. Lukas K. schrieb: > Wie oben geschrieben, soll > was einmal im Pool ist eigentlich drin bleiben, daher kann der Pool > Manager nichts löschen. Hat sich herausgestellt, dass es zum experimentieren doch recht praktisch ist, Dinge einfach löschen zu können: Gibt's nun im Kontextmenü.
Angehängte Dateien:
-
change_package_C0603.PNG
76 KB
Hallo Lukas, ich hätte gerne die Möglichkeit im Parts-Editor das "Package" zu ändern, z. B. c0603 zu c0603a, weil die Anfoderungen an die Pads(pad stack) nicht bei allen die gleichen sind. Mal möchte der PCB-Hersteller die "solder mask" etwas anders (größer) oder der Platinenbestücker(oder auch ich) möchte etwas besonderes an der "paste-Mask" oder kleinere oder größere Pads. Kannst du das eiunbauen? Gruß Helmut
Helmut S. schrieb: > Kannst du das eiunbauen? Das gibt es schon in anderer Form: Im Board gibt es diese Einstellungen bei der Regel "Parameters". Mit Klick auf "Apply All" werden die Einstellungen dann auf alle Bauteile auf dem Board angewandt. Helmut S. schrieb: > ich hätte gerne die Möglichkeit im Parts-Editor das "Package" zu ändern, > z. B. c0603 zu c0603a, weil die Anfoderungen an die Pads(pad stack) > nicht bei allen die gleichen sind. Das Package ist nur bei Parts änderbar, die nicht von anderen Parts erben, da Package und Pin-Pad Zuordnung geerbt werden.
Jörg W. schrieb: > Du kommst aber mit der Anspruchshaltung eines „Endkunden“ an und > übersiehst geflissentlich, dass sich Horizon derzeit überhaupt nicht > an solche richtet. Das hat Lukas in diesem Thread von vornherein klar > gemacht, und das steht im Prinzip bereits in der Überschrift. Das ist mir alles von Anfang an klar gewesen - und es geht auch überhaupt nicht um mich selber. Aber sag mal selbst, was aus einem Projekt werden soll, wenn (wie du schreibst) Lukas sich mit seinem Projekt DERZEIT garnicht an Endkunden richtet. Da passiert nämlich ganz leicht genau dasselbe, was ich schon bei Kicad erleben mußte. Nämlich, daß auf weite Strecke das ganze Projekt nur aus Sicht seiner Programmierer vorangetrieben wurde und daß eben dabei an den Endkunden vorbei programmiert worden ist. Je früher man so einen Projektentwurf einem echten Endkunden vorsetzt (oder einem, der zumindest sich bemüht, das Ding aus Anwendersicht mal anzuschauen), desto eher kann man den Gang der Entwicklung noch in die richtige Richtung hinbiegen. Wenn hingegen erstmal viele Pflöcke eingeschlagen und eine Menge Codezeilen geschrieben sind, dann sind Änderungen an der Grundstruktur schmerzhaft, aufwendig oder sogar unmöglich, ohne große Teile des Ganzen wieder einzureißen. Genau deshalb sind solche frühen Tests dringendst notwendig. Verstehst du das jetzt besser? Ich habe aus gutem Grunde immer wieder das Bauen eines Hauses als Gleichnis herangezogen. Eben zuerst die richtigen Fundamente legen, sonst braucht man später die Abrißbirne und den Bagger. W.S.
Hallo Lukas und Joerg. Jörg W. schrieb: > Mit dem Pool Manager. > > Wundert mich nur, dass er ohne irgendeinen registrierten Pool überhaupt > startet. Das hat er bei mir abgelehnt. Hat ja auch nicht gestartet....darum die Fehlermeldungen. ;O) Lukas K. schrieb: > Ist repariert, das Problem war folgendes: Zum Speichern der > Fenstergrößen benutze ich auch SQLite und das erwartet logischerweise, > dass es das Verzeichnis, in dem die Datenbank liegt schon existiert. Bis > jetzt ist das nur keinem aufgefallen, da alle das Verzeichnis schon > hatten. Der Build von gestern hat gestartet, und ich war in der Lage, den Pool einzubinden. Soweit also ok. Leider komme ich erst irgendwann die Woche dazu, mir das näher anzusehen.....und dann natürlich mit einem aktuellen Build Bis jetzt macht es einen guten aufgeräumten Eindruck. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Helmut. Helmut S. schrieb: > 3. Pool laden. > 4. Example Project laden > 5. Programm starten Danke für Deine Quasi Anleitung. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Hallo Lukas, ich versuche gerade mal einen Pool aufzubauen und dabei eine sinnvolle Vorgehensweise zu finden. Im ersten Schritt habe ich erstmal Units und dazu die passenden Symbole angelegt. Aus denen kann man dann später Entities machen. Die Funktion "Duplicate Unit" ist dabei recht hilfreich. Dupliziert man aber erst das Symbol, steckt man in einer Sackgasse, weil man dem Symbol keine Unit zuordnen kann. Übersehe ich da was? Damit verwand dürfte eine andere Frage sein. Es gibt eine Unit "Generic 2 pin connector", die ist sowohl dem Symbol "Generic 2 pin connector (1x2)" als auch dem Symbol "Generic 2 pin connector (2x1)" zugeordnet. Ich vermute, da wurde ein Symbol dupliziert und dann der Name und das Symbol geändert. Die Unit blieb gleich, denn die ist ja ohnehin nicht änderbar. Was ist die Idee hinter dieser Vorgehensweise? Soll man damit solche Fälle wie das amerikanische und europäische Widerstandssymbol nur einer Unit zuordnen können? Beim Platzieren eines Parts im Schaltplan bekommt man zumindest die Auswahl zwischen diesen beiden, der einen Unit zugeordneten, Symbolen. In diesem Fall tritt übrigens ein Fehler auf. Wenn man die Box zur Auswahl des Symbols mit "Cancel" schließt, dann stürzt der Schaltplan-Editor ab. Nochmal eine positive Rückmeldung: ich baue jetzt seit ca. 2 Wochen fast täglich ein neues Debian-Paket und das klappt zu > 95% immer reibungslos. Manchmal muss ich meinen Patch für das Makefile anpassen, mehr aber nicht. Klasse Leistung. Uwe
Hallo W.S. W.S. schrieb: > Aber sag mal selbst, was aus einem Projekt werden soll, wenn (wie du > schreibst) Lukas sich mit seinem Projekt DERZEIT garnicht an Endkunden > richtet. > > Da passiert nämlich ganz leicht genau dasselbe, was ich schon bei Kicad > erleben mußte. Nämlich, daß auf weite Strecke das ganze Projekt nur aus > Sicht seiner Programmierer vorangetrieben wurde und daß eben dabei an > den Endkunden vorbei programmiert worden ist. Sagmal, Rauchst Du irgendwas? Das soll ein OpenSource Projekt werden! Als solches hat es KEINE KUNDEN. ;O) Das hat für den Anwenden den riesen Vorteil, dass es nicht darauf getrimmt sein muss, die Entscheider zu beeindrucken, die selten auch Anwender sind, sondern es wird von Leuten geschrieben, die selber Elektronikentwicklung machen. Als OS Programm kann es im allgemeinen deutlich praxisorientierter (insbesondere für Kleinanwender) sein, als proprietäre Software, die aus Verkaufsgründen immer auf Eindruck machen schielen muss. ;O) > Genau deshalb sind solche frühen Tests dringendst notwendig. ??? So wie ich das hier verstehe, sind zig Leute gerade mit Testen beschäftigt. WAS ist dein Problem? > Verstehst du das jetzt besser? Ich habe aus gutem Grunde immer wieder das > Bauen eines Hauses als Gleichnis herangezogen. Eben zuerst die richtigen > Fundamente legen, sonst braucht man später die Abrißbirne und den > Bagger. Die Menschheit baut wesentlich länger Häuser als sie CAD Programme schreibt. Insofern besteht bei Häusern sehr viel tradiertes Wissen, wärend bei CAD Programmen eigentlich alle Programme noch irgendwie in einem Experimentierstadium sind. So auch hier, wo ein paar Sachen ausprobiert werden sollen. Wenn Du konkrete Vorschläge hast, dann kannst Du sie bestimmt anbringen, aber was Du machst, ist eine Besinnung auf Grundlagen einfordern, die so überhaupt noch nicht existieren. Mal ganz abgesehen von Deinem etwas aggressiven Tonfall. Niemand startet ein solches Projekt ohne Vorüberlegungen. Selbst wesentlich kleinere Sachen habe ich selber Monate- bis Jahre im Kopf herumgewälzt, bevor ich ein kleines Konzept gemacht habe. So ist Lukas mit Sicherheit nicht dabei, ohne Konzept zu arbeiten. Aber an irgendeinem Punkte muss Schluss sein mit Konzept, und es muss angefangen werden, das ganze Umzusetzten. Weil jedes Konzept kann fatale Fehler enthalten, die erst auffallen, wenn man es anfängt Umzusetzten. Mann könnte also eine Ewigkeit damit verbringen, ein extrem detailiertes und perfektes Konzept aufzustellen, was überhaupt nicht funktioniert. Deine "geforderte" Vorgehensweise ist eher eine Projektverhinderungsstrategie, wenn man es genau sieht. Was ist eigentlich Deine Agenda? Konkrete Vorschläge kommen ja nicht...... Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Uwe S. schrieb: > Klasse Leistung. Auf FreeBSD 11.x (da kann der Clang native C++14) würde es praktisch aus der Dose heraus bauen. Ich finde das auch eine gute Leistung!
Bernd W. schrieb: >> Genau deshalb sind solche frühen Tests dringendst >> notwendig. > > ??? So wie ich das hier verstehe, sind zig Leute > gerade mit Testen beschäftigt. WAS ist dein Problem? Zu viele Fragen auf einmal :) 1. Das Problem von W.S. ist, dass er eine richtige Frage im falschen (sozialen) Kontext diskutieren will. Er ist ungefähr genauso nervig wie ein überzeugter Veganer auf dem Jahresball der Metzger-Innung: Sachlich vielleicht gar nicht falsch, aber nutzlos, nervtötend, unangemessen. 2. Deine Feststellung, FOS-Software habe keine Kunden (sondern nur Anwender) ist sachlich richtig, geht aber nicht weit genug: Manchmal hat sie nicht einmal "echte" Anwender. Der Spruch "Wenn Du hier nichts beitragen kannst, dann hast Du auch kein Recht, Forderungen zu stellen" schreibt die Inzucht auf Dauer fest. Das "Problem" (wenn es denn eins ist) bei Lukas' Vorgehen liegt in der ZIELSTELLUNG, nicht in der Durchführung. 3. Software-Tests werden aus unterschiedlichen Gründen gemacht. Die Fragen "Haben wir das Richtige implementiert?" und "Haben wir es richtig implementiert?" zielen in unterschiedliche Richtungen. Hier im Thread liegt der Fokus eindeutig auf der zweiten Frage. Das ist für sich genommen nicht falsch, aber W.S. bemängelt (nach meinem Verständnis) nur, dass die erste Frage deutlich zu wenig diskutiert wird. Letztlich liegen bei FOS-Software Licht und Schatten noch näher beieinander als bei kommerzieller: Gute FOSS-Software ist unter Umständen SEHR gut, eben weil der Programmierer auch der Anwender ist. Bei FOSS-Software, die aber an den Bedürfnissen (einiger) Anwender vorbeigeht, haben diese Anwender NOCH weniger Einfluss als bei kommerzieller Software: Gegen die Replik "Du hast mir gar nix vorzuschreiben -- ich bin nicht Dein Codiersklave!" hat man keine Handhabe. Bei kommerzieller Auftragsentwicklung sieht das deutlich anders aus. Ich bin ein ausgesprochener Freund von FOSS, aber man darf die Nachteile des Modells auch nicht übersehen. Bernd W. schrieb: > Weil jedes Konzept kann fatale Fehler enthalten, die erst > auffallen, wenn man es anfängt Umzusetzten. Ja -- aber dann taugt das Konzept nichts :) > Mann könnte also eine Ewigkeit damit verbringen, ein > extrem detailiertes und perfektes Konzept aufzustellen, > was überhaupt nicht funktioniert. Es gibt immer viele Wege, etwas falsch zu machen; das Aufstellen von Konzepten bildet da keine Ausnahme :) Projektplanung ist viel schlechter lehrbar als Bohren, Feilen oder Steaks braten, aber dennoch ist es ein Handwerk wie viele andere auch. Der sehr verbreitete Spruch "Wer glaubt, dass Projektleiter Projekte leiten, der glaubt auch, dass Zitronenfalter Zitronen falten" ist im Wesentlichen nur eins: Sehr dumm.
Possetitjel schrieb: > Es gibt immer viele Wege, etwas falsch zu machen; das > Aufstellen von Konzepten bildet da keine Ausnahme :) Mmhmm, oft hat man ja ein Bild vor Augen, wie das fertige Projekt aussehen soll ... Solange man quasi nur einer ist, der an einem Projekt arbeitet, ist es auch kein Problem, das genau so umzusetzen, wie man sich das vorstellt. Da braucht man dann keine Projektplanung oder Konzepte ;-)
Possetitjel schrieb: > Die Fragen "Haben wir das Richtige implementiert?" und "Haben wir es > richtig implementiert?" zielen in unterschiedliche Richtungen. Hier im > Thread liegt der Fokus eindeutig auf der zweiten Frage. Das sehe ich keineswegs so. Lukas hat weiter oben selbst postuliert, dass er für alle Anregungen dankbar ist, auch die, die in Richtung der ersten Frage gehen. Was er dabei sicher nicht in Frage stellen wird, ist den grundlegenden Workflow des Gesamtsystems. Der ist ja bei ihm insbesondere daraus entstanden, dass er mit dem, was es schon gab, aus Anwendersicht völlig unzufrieden war und es daher anders angehen wollte.
Hallo Possetitjel. Possetitjel schrieb: > 2. > Deine Feststellung, FOS-Software habe keine Kunden (sondern > nur Anwender) ist sachlich richtig, geht aber nicht weit > genug: Manchmal hat sie nicht einmal "echte" Anwender. Der > Spruch "Wenn Du hier nichts beitragen kannst, dann hast Du > auch kein Recht, Forderungen zu stellen" schreibt die Inzucht > auf Dauer fest. Vernünftigen Argumenten gegenüber ist ja auch niemand abgeneigt, sie zumindest in Erwägung zu ziehen. Allerdings, wenn Nischen Anwender sich ihre eigene Software als ihr eigenes Handwerkszeug selber in die Hand schreiben, sind sie wohl auch die einzigen wirklichen Experten dafür. > Das "Problem" (wenn es denn eins ist) bei Lukas' Vorgehen > liegt in der ZIELSTELLUNG, nicht in der Durchführung. Es geht um beides, Zielstellung und Durchführung. > Software-Tests werden aus unterschiedlichen Gründen gemacht. > Die Fragen "Haben wir das Richtige implementiert?" und "Haben > wir es richtig implementiert?" zielen in unterschiedliche > Richtungen. > Hier im Thread liegt der Fokus eindeutig auf der zweiten Frage. > Das ist für sich genommen nicht falsch, aber W.S. bemängelt > (nach meinem Verständnis) nur, dass die erste Frage deutlich > zu wenig diskutiert wird. So verstehe ich das auch.....aber W.S. bringt auch keine konkreten Vorschläge für ein Ziel. Er bemängelt nur, dass es nicht gemacht wurde. Ich gehe aber davon aus, dass das jeder macht, auch wenn es nicht unbedingt nach aussen sichtbar ist. Und das Ergebnis einer solchen Überlegung muss nicht mit dem Übereinstimmen, was bei W.S. herauskommen würde. ;O) > Bei FOSS-Software, die aber an den Bedürfnissen (einiger) > Anwender vorbeigeht, haben diese Anwender NOCH weniger > Einfluss als bei kommerzieller Software: Gegen die Replik > "Du hast mir gar nix vorzuschreiben -- ich bin nicht Dein > Codiersklave!" hat man keine Handhabe. Bei kommerzieller > Auftragsentwicklung sieht das deutlich anders aus. Richtig. Aber das sehe ich nicht als Problem. Weil eigentlich schreiben FOSS Entwickler immer extreme Nischensoftware für sich selber. Der Erfolg einiger dieser Produkte ist dann auf das Versagen kommerzieller Konzepte zurückzuführen. Also eher Zufall. Merkwürdigerweise treten diese Zufälle aber sehr häufig auf... > Bernd W. schrieb: >> Weil jedes Konzept kann fatale Fehler enthalten, die erst >> auffallen, wenn man es anfängt Umzusetzten. > > Ja -- aber dann taugt das Konzept nichts :) Richtig....aber wann will man das sonst feststellen, wenn nicht durch einen Umsetzungsversuch? > >> Mann könnte also eine Ewigkeit damit verbringen, ein >> extrem detailiertes und perfektes Konzept aufzustellen, >> was überhaupt nicht funktioniert. > > Es gibt immer viele Wege, etwas falsch zu machen; das > Aufstellen von Konzepten bildet da keine Ausnahme :) Ohja. > > Projektplanung ist viel schlechter lehrbar als Bohren, > Feilen oder Steaks braten, aber dennoch ist es ein > Handwerk wie viele andere auch. Ich sehe es eher als Kunst, weil mir komplett die Begabung dazu fehlt. Aber ich sehe dieses Fehlen einer Begabung dazu auch bei W.S., solange er nicht konkreter wird. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Jörg W. schrieb: > Possetitjel schrieb: >> Die Fragen "Haben wir das Richtige implementiert?" und >> "Haben wir es richtig implementiert?" zielen in >> unterschiedliche Richtungen. Hier im Thread liegt der Fokus >> eindeutig auf der zweiten Frage. > > Das sehe ich keineswegs so. Ich weiss :) > Lukas hat weiter oben selbst postuliert, dass er für alle > Anregungen dankbar ist, auch die, die in Richtung der > ersten Frage gehen. Ja, aber... > Was er dabei sicher nicht in Frage stellen wird, ist den > grundlegenden Workflow des Gesamtsystems. Eben. Das bedeutet faktisch: Es gibt eine gewisse Zahl fundamentaler Design-Entscheidungen, die nicht verhandelbar sind. Punkt. (Dazu gehört aus meiner Sicht z.B., dass es ein Komplett- paket werden soll.) > Der ist ja bei ihm insbesondere daraus entstanden, dass > er mit dem, was es schon gab, aus Anwendersicht völlig > unzufrieden war und es daher anders angehen wollte. Richtig. Wenn man die Äußerungen von W.S. mal mit gutem Willen liest (und über seinen unangemessenen Ton großzügig hinwegsieht), dann ist genau DAS ja auch sein Kritikpunkt: ER (L.) war unzufrieden, ER wollte es anders angehen. Was andere Anwender wollen, was andere Anwender stört, spielt keine wesentliche Rolle. (Wäre es anders, hätte es eine Planungsphase gegeben, in der die Wünsche der Anwender ermittelt worden wären. Gab es aber meines Wissens nicht.) Nur um nicht missverstanden zu werden: L. macht nix falsch. Er programmiert sich einfach die Software, die er haben möchte. Die Kritik zielt auf eine generelle Schwäche von FOSS.
Possetitjel schrieb: > Was andere Anwender wollen, was andere Anwender stört, spielt keine > wesentliche Rolle. Bezüglich des grundlegenden Designs: richtig. Ansonsten sehe ich schon, dass er auf geäußerte Wünsche eingeht. > Die Kritik zielt auf eine generelle Schwäche von FOSS. Die aber auch eine Stärke sein kann: es wird einfach mal gemacht, und „der Markt“ kann dann zeigen, ob sich das durchsetzt. Dieser besteht ja am Ende aus viel mehr Nutzern als nur W.S. :)
Hallo Jörg und Possetitjel- Jörg W. schrieb: >> Was andere Anwender wollen, was andere Anwender stört, spielt keine >> wesentliche Rolle. > > Bezüglich des grundlegenden Designs: richtig. Immerhin hat er das ganze ja gestartet, weil er mit den herkömmlichen Designs unzufrieden war, und eigene Ideen hatte. Da ist kaum zu erwarten, dass er ausgerechnet diese Grundlagen ändert. > > Ansonsten sehe ich schon, dass er auf geäußerte Wünsche eingeht. Das sehe ich auch. > >> Die Kritik zielt auf eine generelle Schwäche von FOSS. > > Die aber auch eine Stärke sein kann: es wird einfach mal gemacht, und > „der Markt“ kann dann zeigen, ob sich das durchsetzt. Dieser besteht > ja am Ende aus viel mehr Nutzern als nur W.S. :) Eben. Es scheint oft also eine ganze Menge von Leuten zu geben, die sich gut mit den Konzepten dieser Software anfreunden können. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Uwe S. schrieb: > Dupliziert man aber erst das Symbol, steckt man in einer > Sackgasse, weil man dem Symbol keine Unit zuordnen kann. Übersehe ich da > was? Nein, das ist by Design so: Symbole stellen nur die Pins einer Unit dar und sind daher recht fest mit dieser verbunden. Ohne Unit wüsste ein Symbol nicht, wie die Pins heißen. Ein Dialog zum Austauschen der Unit, wobei die Pins dann über Namen zur neuen Unit zugeordnet werden, wäre allerdings denkbar, wenn das unbedingt so gebraucht wird. > Damit verwand dürfte eine andere Frage sein. Es gibt eine Unit "Generic > 2 pin connector", die ist sowohl dem Symbol "Generic 2 pin connector > (1x2)" als auch dem Symbol "Generic 2 pin connector (2x1)" zugeordnet. > Ich vermute, da wurde ein Symbol dupliziert und dann der Name und das > Symbol geändert. Die Unit blieb gleich, denn die ist ja ohnehin nicht > änderbar. Was ist die Idee hinter dieser Vorgehensweise? Soll man damit > solche Fälle wie das amerikanische und europäische Widerstandssymbol nur > einer Unit zuordnen können? Das ist ein möglicher Anwendungsfall. Die Idee hier bei den Steckern war diese: In der Netzliste (Unit/Entity) ist es ja egal, wie die Pins nun räumlich im Stecker angeordnet sind, daher gibt es für jede Anzahl Pins nur eine Unit. So kann man auch ohne Probleme später mit dem "Assign Part"-Tool aus einem 1x10 einen 2x5-Stecker machen, da beide für die Netzliste identisch sind (selbe Unit/Entity). Im Schaltplan will man damit's optisch besser zum Board passt beide Optionen haben. Geplant sind hier noch diese Dinge: Symbol im Schaltpan änderbar machen (für Units mit mehreren Symbolen). Vielleicht: Parts können bevorzugte Symbole angeben, damit z.B. der 2x5-Wannenstecker standardmäßig auch das 2x5-Symbol bekommt und nicht erst der Dialog zur Auswahl des Symbols aufgeht. > Beim Platzieren eines Parts im Schaltplan > bekommt man zumindest die Auswahl zwischen diesen beiden, der einen Unit > zugeordneten, Symbolen. > In diesem Fall tritt übrigens ein Fehler auf. Wenn man die Box zur > Auswahl des Symbols mit "Cancel" schließt, dann stürzt der > Schaltplan-Editor ab. Ist repariert.
Jörg W. schrieb: > Possetitjel schrieb: >> Was andere Anwender wollen, was andere Anwender >> stört, spielt keine wesentliche Rolle. > > Bezüglich des grundlegenden Designs: richtig. Gut. Dann haben wir ja bis dahin erstmal Konsens. > Ansonsten sehe ich schon, dass er auf geäußerte > Wünsche eingeht. Selbstverständlich; das habe ich auch schon mehrfach zugestanden. Das ist ja gar nicht mein Zielpunkt. >> Die Kritik zielt auf eine generelle Schwäche von FOSS. > > Die aber auch eine Stärke sein kann: es wird einfach mal > gemacht, und „der Markt“ kann dann zeigen, ob sich das > durchsetzt. Naja. Das ist kein Alleinstellungsmerkmal von FOSS; das machen die Kommerziellen genauso. Der ärgerliche Unterschied ist nur, dass es bei FOSS überhaupt nicht notwendig wäre. Da es keinen Zwang zur Rentabilität gibt, muss sich niemand "durchsetzen".
Bernd W. schrieb: > Immerhin hat er das ganze ja gestartet, weil er mit den > herkömmlichen Designs unzufrieden war, und eigene Ideen > hatte. Sicher; Unzufriedenheit als Motiv, etwas zu ändern, ist ja ein durchaus häufiger Fall. > Da ist kaum zu erwarten, dass er ausgerechnet diese > Grundlagen ändert. Naja, fraglich ist, was GENAU ihn gestört hat und was also diese Grundlagen sind. Die Tatsache, dass es (meines Wissens) kein wirklich universelles Austauschformat für Schaltpläne gibt, war es schon mal nicht -- sonst hätte er sich das als Thema vorgenommen. Die Tatsache, dass jede Software die Bauteil-Stammdaten (Symbole, Footprints, ggf. Datenblätter, Spice-Modelle...) mehr schlecht als recht (und natürlich inkompatibel zu allen anderen Systemen) verwaltet, war es offensichtlich auch nicht. Nur um mal zwei Punkte zu nennen, die MICH stören. > Eben. Es scheint oft also eine ganze Menge von Leuten zu > geben, die sich gut mit den Konzepten dieser Software > anfreunden können. Was bleibt einem denn übrig? Die Alternativen sind ja noch schlimmer. Außerdem sind Anwender manchmal (notgedrungen) unfassbar leidensfähig -- sonst wären MS-DOS, Windows98 oder vi nie zum Einsatz gelangt.
Possetitjel schrieb: > Die Tatsache, dass jede Software die Bauteil-Stammdaten (Symbole, > Footprints, ggf. Datenblätter, Spice-Modelle...) mehr schlecht als recht > (und natürlich inkompatibel zu allen anderen Systemen) verwaltet, war es > offensichtlich auch nicht. Wieso? Gerade an dieser Stelle hat sich Lukas ja intensiv Gedanken gemacht. Also nicht Austauschbarkeit, das bleibt sowieso immer Wunschdenken, aufgrund nicht deckungsgleicher Konzepte – BAE bspw. benutzt metrisches Raster für die Schaltplandarstellung, viele andere (aus mir nicht nachvollziehbaren Gründen) zölliges. Da half es eben bei BAE auch nicht besonders, dass man per Script Eagle-Daten einlesen kann. Aber bezüglich der Organisation der Daten sehe ich schon ein Konzept. Das kann einem natürlich nun gefallen oder nicht, das ist wieder was anderes. ;-)
Die Situation mit Formaten für Schaltplan/Board/etc. ist ähnlich wie die mit Formaten für Textverarbeitung: Das Dateiformat muss jedes Feature, jede noch so versteckte Einstellung der Applikation abbilden. Bei Textverarbeitung hat man das gelöst, indem Formate von Applikationen zum Standard erklärt wurden. Mittelbar wurde damit die Applikation selber zum Standard, da man um das Format vollständig zu unterstützen die Applikation praktisch nachbauen muss. Wenn jetzt z.B. Autodesk es hinbekommen würde das XML-Format von Eagle als Standard bei der ISO oder so durchzubekommen, wären alle Applikationen, die das Format verwenden im Kern eben Eagle - mit allen vor- und Nachteilen. Ein Austauschformat zur Darstellung von Footprints und Symbolen ist in der Tat wünschenswert und meines Erachtens auch deutlich einfacher umsetzbar als ein Austauschformat für Schaltpläne, da alle Programme halbwegs vergleichbare Vorstellungen von Symbol und Package haben.
Hallo Lukas, ich habe mal angefangen einige der Units, Entities und Symbols aus meinem lokalen Pool als Pull-Request bei github einzustellen. Wenn das für dich so in Ordnung ist, dann hätte ich auch noch mehr und würde die auch als Pull-Request zur Verfügung stellen. Konkrete Bauteile habe ich auch noch ein paar, aber die können erstmal warten. Uwe
Hallo Lukas, jetzt habe zu viel gespielt und mein Pool lässt sich nicht mehr aktualisieren. Gemäß Fehlermeldung fehlt eine Symbol-Datei, die ich zuvor gelöscht hatte. Die Units und Entities aber auch. Mag sein, dass mir da ein Fehler unterlaufen ist. Ich stelle mir aber die Frage, woher der Pool-Manager überhaupt weiß, welche Datei fehlt. Läuft das nicht alles über Ids? Ich finde in keiner der json-Dateien eine Referenz auf die fehlende Datei. Uwe
Uwe S. schrieb: > Ich stelle mir aber die Frage, woher > der Pool-Manager überhaupt weiß, welche Datei fehlt. Läuft das nicht > alles über Ids? Ich finde in keiner der json-Dateien eine Referenz auf > die fehlende Datei. Den Dateinamen, die der Pool Manager anzeigt, ist die Datei bei der die Exception aufgetreten ist. Irgendwas, das die Datei referenziert gibt's nicht. Seit gerade sagt der einem auch welche UUID und welcher Typ fehlt. Uwe S. schrieb: > Wenn das > für dich so in Ordnung ist, dann hätte ich auch noch mehr und würde die > auch als Pull-Request zur Verfügung stellen. Schaut gut aus und ist merged. Bei den Symbolen hab' ich noch die Pin-Namen aus gemacht, da die sonst komisch ausschauen. Jetzt wo es im Pool auch Bauteile mit invertierten Pins gibt, sollte das horizon auch abbilden können: Wahrscheinlich wird es für die Pins in den Units noch Flags geben, um Eingenschaften wie Invertiert, oder Takteingang zu kennzeichnen, damit man nicht immer selber malen muss.
Possetitjel schrieb: > Bei FOSS-Software, die aber an den Bedürfnissen (einiger) > Anwender vorbeigeht, haben diese Anwender NOCH weniger > Einfluss als bei kommerzieller Software: Gegen die Replik > "Du hast mir gar nix vorzuschreiben -- ich bin nicht Dein > Codiersklave!" hat man keine Handhabe. Bei kommerzieller > Auftragsentwicklung sieht das deutlich anders aus. OpenSource ist aber keine Auftragsentwicklung! Trotzdem kann man Einfluß darauf nehmen, wenn man freundlich fragt oder gar einen funktionsfähigen Patch einreicht. Oder wenn man das Projekt forkt und seine Vorstellungen innerhalb dieses Forks realisiert. Oder indem man jemanden dafür bezahlt, eine dieser drei Vorgehensweisen umzusetzen. In der kommerziellen Auftragsentwicklung hast Du im Übrigen auch keinerlei Einflußmöglichkeit. Dann wird umgesetzt, was in der Spezifikation steht, auf deren Basis die Angebote, Preise und Zeitpläne kalkuliert und der Auftrag erteilt worden ist. Wenn Du Änderungen willst, mußt Du sie bezahlen. > Ich bin ein ausgesprochener Freund von FOSS, aber man darf > die Nachteile des Modells auch nicht übersehen. Das ist natürlich richtig, aber Du konstruierst welche, wo keine sind, und noch dazu mit falschen Analogien.
Possetitjel schrieb: > Das bedeutet faktisch: Es gibt eine gewisse Zahl fundamentaler > Design-Entscheidungen, die nicht verhandelbar sind. Punkt. Ohne solche Designentscheidungen kann man keine Software entwickeln. Sonst diskutiert man das Projekt tot, bevor es angefangen hat.
Lukas K. schrieb: > Wahrscheinlich wird es für die Pins in den > Units noch Flags geben, um Eingenschaften wie Invertiert, oder > Takteingang zu kennzeichnen, damit man nicht immer selber malen muss. Jetzt gibt es im Symbol-Editor für Pins dekorative Elemente wie Invertiert, Takteingang, Schmitt-Trigger, oder Open-Collector/Emitter mit/ohne Pullup/pulldown.
Hab's gerade mal die Pin-Dekorationen probiert. Funktioniert super. Ist die Bezeichnung 'Dot' für invertierte Pins nicht etwas unglücklich? Warum nicht 'Inverted'?
Bernd W. schrieb: > Hallo W.S. > ... > Sagmal, Rauchst Du irgendwas? Das soll ein OpenSource Projekt werden! > Als solches hat es KEINE KUNDEN. ;O) Erstens: nein ich bin Nichtraucher Zweitens: du bist unverschämt, sowas zu schreiben. Also bleib sachlich. Drittens: wenn du dediziert was gegen das Wort "Kunde" hast, dann nenne es doch einfach "finaler Anwender". Kommt auf's Gleiche raus. Es sind eben immer diejenigen, die ein Produkt benutzen wollen und nicht darin herumkonstruieren/programmieren wollen - und die eben auch nicht zuvor irgendwelche anderen Teile wie Pools und so von woanders zusammensuchen wollen/können. Aber "Kunde" ist griffiger und allgemeinverständlicher. Negativbeispiel: Frag doch mal nen Verkäufer im Mediamarkt, wieviel uint8_t's die Festplatte im Regal hat. Bernd W. schrieb: > So verstehe ich das auch.....aber W.S. bringt auch keine konkreten > Vorschläge für ein Ziel. Er bemängelt nur, dass es nicht gemacht wurde. Wiebitte??? Zur Sache: Das vorbereitete Projekt herunterzuladen und zu installieren/auszupacken reicht nicht. Es fehlt an dem Pool, was auch immer dessen Inhalt sein mag. Offenbar muß ich mich selber zitieren: W.S. schrieb: > Ich hätte erwartet, daß man als Benutzer zumindest die Chance hätte, das > System erstmal irgendwie aufzusetzen, so daß es auch läuft und einen > nicht vor ein zu nix brauchbares fast leeres Fenster setzt. Die > penetrante und durch nichts lösbare Nachfrage nach dem ominösen Pool > verhindert zuverlässig, daß man mit deinem Programm irgendwas beginnen > kann. Erwarte bitte nicht, daß irgend ein Interessent eine derartige > pool.json vorrätig hat. Ist dir das nicht klar genug? Nein? Dann sag ich es mal anders: In jede Distribution gehört wenigstens eine minimale "pool.json" hinein, damit man zumindest etwas vom eigentlichen Programm überhaupt sieht. Noch besser wäre es, wenn es einen Menüpunkt gäbe, mit dem man auf Knopfdruck sowas generieren kann. Bedarf dafür ist da, siehe Jörg: "Wie starte ich einen neuen Pool? Gibt's dafür ein Tool?" Eben. Meine Rede die ganze Zeit über. W.S.
W.S. schrieb: > Wiebitte??? > > Zur Sache: > Das vorbereitete Projekt herunterzuladen und zu installieren/auszupacken > reicht nicht. Es fehlt an dem Pool, was auch immer dessen Inhalt sein > mag. Öhm, RTFM!
W.S. schrieb: > Bedarf dafür ist da, siehe Jörg: Wenn du keine Ahnung hast, worüber ich schreibe, dann benutz' mich bitte nicht als Referenz. Den Standard-Pool runterzuladen und zu aktivieren, braucht's nur ein RTFM.
Angehängte Dateien:
-
package.PNG
35 KB
Hallo Lukas, in GitHub sehe ich Kommentare für eine neue Funktion um packages zu wählen. "board add alternate packages ...." Ich habe heute Abend dein Programm kompiliert. Sollte man das Package in dem PCB-Fenster auswählen können? Ich kann da aber in dem Feld "Package" nichts ändern. Siehe Bild. Ist die Funktion noch nicht fertig oder muss ich an anderer Stelle vorher etwas einstellen? Gruß Helmut
Diese Funktion ist so gemeint: Im Package kann man (im Popover, wo man auch Name, etc. eintippt) ein Package als alternate Package für ein anderes Package eintragen. Im Pool gibt es als Beispiel wie sowas aussehen kann die Packages "R0603 (manual soldering)" und "C0603 (manual soldering)". Diese haben als "alternate for" R0603 bzw. C0603 eingetragen. In der Combobox zum Package erscheinen dann alle Packages, die als "alternate for" das Package des Parts eingetragen haben. Diese Funktion ist ausdrücklich nicht dafür vorgesehen verschiedene Packages (z.B. DIP und SMD) einem Part zuzuordnen. Helmut S. schrieb: > Ist die Funktion noch nicht fertig oder muss > ich an anderer Stelle vorher etwas einstellen? Du musst wohl noch deinen Pool aktualisieren, damit da auch die oben genannten Packages drin sind.
Angehängte Dateien:
Hallo Lukas,
> Du musst wohl noch deinen Pool aktualisieren,
Habe gerade mal den Pool ganz neu heruntergeladen und unzip gemacht.
Dann den Pool-manager gestartet. Es sind keine packages und parts mehr
da. Die fehlen jetzt.
Teste das doch mal bei dir. Poolverzeichnis löschen, Pool herunterladen,
unzip vom Download des Pools machen, pool manager starten und schauen.
Mein Pool ist jetzt unbrauchbar.
Helmut S. schrieb: > Teste das doch mal bei dir. Poolverzeichnis löschen, Pool herunterladen, > unzip vom Download des Pools machen, pool manager starten und schauen. > Mein Pool ist jetzt unbrauchbar. Tatsache, das ist hingefallen, weil jetzt auch Packages andere Packages referenzieren und die Reihenfolge in der die Packages geladen werden relevant ist. Ist nun repariert.
Lukas K. schrieb: > Helmut S. schrieb: >> Teste das doch mal bei dir. Poolverzeichnis löschen, Pool herunterladen, >> unzip vom Download des Pools machen, pool manager starten und schauen. >> Mein Pool ist jetzt unbrauchbar. > > Tatsache, das ist hingefallen, weil jetzt auch Packages andere Packages > referenzieren und die Reihenfolge in der die Packages geladen werden > relevant ist. Ist nun repariert. Habe gerade noch mal kompiliert. Dann habe ich den Pool Manager gestartet. Dort musste ich "Update Pool" wählen. Danach habe ich das Layout geöffnet. Jetzt kann ich ein anderes Package wählen. >Diese haben als "alternate for" R0603 bzw. C0603 eingetragen. Jetzt stellt sich mir die Frage wo wird definiert welches alternative Package möglich ist.
Helmut S. schrieb: > Lukas K. schrieb: >>Diese haben als "alternate for" R0603 bzw. C0603 eingetragen. > Jetzt stellt sich mir die Frage wo wird definiert welches alternative > Package möglich ist. Im Pool-Manager. Einfach ein Package öffnen und dann mal das Menü in der Kopfzeile ausklappen. Dort wo man den Namen, Manufacturer und Tags eingeben kann, gibt es jetzt noch einen Button 'Alternate for'. Uwe
Angehängte Dateien:
-
pool_set_alternate_of.PNG
33 KB -
pcb_alternate_cell.PNG
29 KB
Uwe S. schrieb: > Helmut S. schrieb: >> Lukas K. schrieb: >>>Diese haben als "alternate for" R0603 bzw. C0603 eingetragen. >> Jetzt stellt sich mir die Frage wo wird definiert welches alternative >> Package möglich ist. > > Im Pool-Manager. Einfach ein Package öffnen und dann mal das Menü in der > Kopfzeile ausklappen. Dort wo man den Namen, Manufacturer und Tags > eingeben kann, gibt es jetzt noch einen Button 'Alternate for'. > > Uwe Danke Uwe, jetzt finde ich es auch. Man kann/muss das alternative package für jedes Bauteil auswählen, wenn man es ändern will. Das ist OK. Im Anhang ein screenshot für alle die es interssiert. Helmut
Angehängte Dateien:
Neue Frage Was macht dieses "Apply to all", das erscheint, wenn man auf das Häkchen klickt? Scheinbar nichts oder macht es doch etwas? Helmut
Helmut S. schrieb: > Neue Frage > Was macht dieses "Apply to all", das erscheint, wenn man auf das Häkchen > klickt? Scheinbar nichts oder macht es doch etwas? Wenn du mehrere Objekte ausgewählt hast, dann wird die Eigenschaft auf alle angewendet. In deinem Fall, mit nur einem Objekt, ist also in der Tat nichts zu sehen. Besser wäre es wohl, den Button dann garnicht anzuzeigen. Die gleiche Funktion gibt es auch bei mehreren ausgewählten Pads, wenn man 'Edit pads' aufruft. Uwe
Uwe S. schrieb: > Besser wäre es wohl, den Button dann garnicht > anzuzeigen. Ist jetzt (fast) so drin und der Tooltip ist auch ein bisschen erklärender. Ganz ausblenden wollte ich den Knopf nicht, weil das dann komisch aussah.
Angehängte Dateien:
Helmut S. schrieb: > Neue Frage > Was macht dieses "Apply to all", das erscheint, wenn man auf das Häkchen > klickt? Scheinbar nichts oder macht es doch etwas? Wenn du mehrere Objekte ausgewählt hast, dann wird die Eigenschaft auf alle angewendet. Danke Uwe, das passt. Lukas K. schrieb: > Uwe S. schrieb: >> Besser wäre es wohl, den Button dann garnicht >> anzuzeigen. > > Ist jetzt (fast) so drin und der Tooltip ist auch ein bisschen > erklärender. Ganz ausblenden wollte ich den Knopf nicht, weil das dann > komisch aussah. Hallo Lukas, Die Erklärung gefällt mir. Siehe screenshot für alle anderen. Flipped "on" bedeutet Bauteil ist auf der Unterseite. Flipped "off" bedeuted das Bauteil ist auf der Oberseite. Man kann die Lage eines Bauteils an dessen Farbe erkennen. Lukas, könntest du mal wieder eine WIN-Version machen für die Leute die nicht kompilieren wollen? Helmut
Angehängte Dateien:
-
select_one_of.PNG
34 KB
Noch ein Tipp Wenn man mehrere Bauteile selektiert hat, dann kann man mit den Pfeiltasten links und rechts unter Packages ein Bauteil nach dem anderen wählen. Klickt man auf 1/3 dann geht zusätzlich ein "Dialogfenst" mit Radiobuttons auf. Da kann man mit einem Klick eines der selektierten Bauteile auswählen.
Helmut S. schrieb: > Lukas, könntest du mal wieder eine WIN-Version machen für die Leute die > nicht kompilieren wollen? Soeben geschehen. Wenn sich jemand mit Appveyor auskennt und Windows-CI bauen mag, wäre ich demjenigen sehr verbunden :) Ein paar Worte noch zu dem Property-Editor auf der rechten Seite im allgemeinen: Tabellarische Propery-Editoren, wie man sie von vielen IDEs und CAD-Programmen kennt, wie z.B. http://doc.qt.io/qt-5/images/designer-property-editor.png waren mit immer zu fummelig zu bedienen und zeigen u.U. komische Platzhalter an, wenn mehrere Objekte ausgewählt sind. Daher stehen die Namen über und nicht neben den Werten und alles ist ein normales Widget und nicht die hakelig zu bedienenden Widgets aus Listen/Tabellen. Das "1/3" zur Auswahl des aktuellen Objektes in Kombination mit dem "Apply to all"-Knopf schien mir als gute Lösung um sowohl eines als auch mehrere Objekte zu bearbeiten. Wenn man eine Property anfasst, wird zunächst eine kurze Zeit gewartet, ob noch was passiert, um mehrere schnell aufeinander folgenden Änderungen zu einem Undo/Redo-Schritt zusammenzufassen. In dieser Zeit wird das "Commit pending" eingeblendet.
Hallo Lukas, war deine letzte Änderung jetzt so wichtig, dass man unbedingt wieder neu kompilieren sollte? Ich habe natürlich für mich neu kompiliert. core fix tool includes 44 minutes ago
Helmut S. schrieb: > core fix tool includes 44 minutes ago Nichts wichtiges, nur in paar includes angepasst, damit es nicht unnütz Dateien neu bauen muss.
Max G. schrieb: > Anschließend sieht es dann etwas seltam aus - > ich sehe zwar alle Bedienelemente, aber weder Schaltplan noch Layout. Auf einem anderen Rechner läuft es jetzt. Die UI sieht dank GTK ziemlich ungewohnt aus, aber daran gewöhnt man sich schnell. Gefühlt ist es wie ein Rewrite von KiCAD, der ein paar hakelige Punkte (Library-Verwaltung, Sync Schaltplan/Board) neu konzipiert hat. In jedem Fall sind einige Dinge besser als beim Adler gelöst. Bis jetzt finde ich´s ziemlich gut (und ich bin Schwabe ;) Ein paar Kleinigkeiten, die mir als unbedarftem Erstnutzer aufgefallen sind: * Der Unit Editor ist noch nicht ganz rund: * Ich kann keine Einträge löschen ("-" bewirkt nichts) * Ich würde mir wünschen, neue Einträge einfach per Tab/Enter o.ä. erzeugen zu können. Dann kann ich die Pinliste aus dem Datenblatt einfach abtippen und muss nicht zwischen Tastatur und Maus wechseln * Nach dem Hinzufügen eines Pins mit "+" hüpft der Cursor irgendwo hin, und die blaue Markierung ebenfalls. Manchmal auf´s gleiche, manchmal auch nicht. * Die automatische alphabetische Sortierung nervt mich eher, ab einer gewissen Anzahl muss ich scrollen, um zu finden, wo es denn jetzt weitergeht. Ich würde sie eher weglassen. Anregung: fertige Einträge mit Labels darstellen und erst nach Anklicken, nur für den aktuellen Eintrag, Combobox/Entry verwenden. Ist deutlich platzsparender. * "Enter Datum" ist zwar vermutlich korrekt, aber recht ungebräuchlich. "Enter Value" wäre gängiger. * Beim Duplizieren eines Packages beschwert sich Horizon, dass das Verzeichnis nicht existiert, anstatt es einfach anzulegen. Nach ANlegen von Hand geht´s problemlos. * Der Footprint Generator ist prima. Nur: wenn ich versuche, ein Quad-Package zu erzeugen, malt er nur die rechte und linke Pinreihe. Unten und oben fehlt. * Muss ich für das Zeichnen einer Verbindung im Schaltplan tatsächlich "dn n" tippen? * Änderungen beim Zeichnen (sei es Mirror, sei es Undo, ...) werden erst dann übernommen, wenn die Maus wieder bewegt wird. Bis dahin bleibt der alte Zustand erhalten. * Wie kriege ich es hin, dass eine abknickende Linie den Knickpunkt wechselt (das, was bei Eagle Strg+rechte Maustaste macht)? More to come...
Max G. schrieb: > Max G. schrieb: >> Anschließend sieht es dann etwas seltam aus - >> ich sehe zwar alle Bedienelemente, aber weder Schaltplan noch Layout. > > Auf einem anderen Rechner läuft es jetzt. Die UI sieht dank GTK ziemlich > ungewohnt aus, aber daran gewöhnt man sich schnell. > Gefühlt ist es wie ein Rewrite von KiCAD, der ein paar hakelige Punkte > (Library-Verwaltung, Sync Schaltplan/Board) neu konzipiert hat. In jedem > Fall sind einige Dinge besser als beim Adler gelöst. Bis jetzt finde > ich´s ziemlich gut (und ich bin Schwabe ;) Sehr schön :) > Ein paar Kleinigkeiten, die mir als unbedarftem Erstnutzer aufgefallen > sind: > * Der Unit Editor ist noch nicht ganz rund: > * Ich kann keine Einträge löschen ("-" bewirkt nichts) Kann ich jetzt nicht so reproduzieren. Einen oder mehrere Pins auswählen (sodass die blau werden), dann auf - klicken und die Pins verschweiden > * Ich würde mir wünschen, neue Einträge einfach per Tab/Enter o.ä. > erzeugen zu können. Dann kann ich die Pinliste aus dem Datenblatt > einfach abtippen und muss nicht zwischen Tastatur und Maus wechseln Hört sich sinnvoll an, kommt bald. > * Nach dem Hinzufügen eines Pins mit "+" hüpft der Cursor irgendwo > hin, und die blaue Markierung ebenfalls. Manchmal auf´s gleiche, > manchmal auch nicht. > * Die automatische alphabetische Sortierung nervt mich eher, ab einer > gewissen Anzahl muss ich scrollen, um zu finden, wo es denn jetzt > weitergeht. Ich würde sie eher weglassen. Ah, das hängt wohl zusammen, da neue Einträge automatisch einsortiert werden. Wär' wohl besser, wenn die direkt nach dem Eintrag kommen, der davor ausgewählt war. Die Sortierung habe ich eingebaut, weil die Pins innerhalb einer Unit sonst gar keine sinnvolle Reihenfolge hätten. > Anregung: fertige Einträge mit Labels darstellen und erst nach > Anklicken, nur für den aktuellen Eintrag, Combobox/Entry verwenden. Ist > deutlich platzsparender. Das schaut dann komisch aus, wenn sich die Höhe von den Zeilen verändert, je nachdem wo der Cursor gerade steht. > * Beim Duplizieren eines Packages beschwert sich Horizon, dass das > Verzeichnis nicht existiert, anstatt es einfach anzulegen. Nach ANlegen > von Hand geht´s problemlos. Du benutzt horizon auf Windows, oder? Die Meldung da kommt vom Windows-Dialog zum Speichern selber. Windows scheint keinen brauchbaren Dialog zu haben, um einen neuen Ordner anzulegen, nur Dialoge um vorhandene Ordner auszuwählen. Ich könnte an der Stelle auch den Dateidialog von Gtk benutzen, aber dann beschweren sich Leute zurecht, dass der komisch ausschaut... > * Der Footprint Generator ist prima. Nur: wenn ich versuche, ein > Quad-Package zu erzeugen, malt er nur die rechte und linke Pinreihe. > Unten und oben fehlt. Was für Einstellungen hast du da gemacht? Bei mir hat das immer funktioniert. > * Muss ich für das Zeichnen einer Verbindung im Schaltplan tatsächlich > "dn n" tippen? Entweder "dn" oder "n". > * Änderungen beim Zeichnen (sei es Mirror, sei es Undo, ...) werden erst > dann übernommen, wenn die Maus wieder bewegt wird. Bis dahin bleibt der > alte Zustand erhalten. Höre ich jetzt s zum ersten mal, was sind da die genauen Umstände? > * Wie kriege ich es hin, dass eine abknickende Linie den Knickpunkt > wechselt (das, was bei Eagle Strg+rechte Maustaste macht)? Du meinst von horizontal-vertikal auf vertikal-horizontal umschalten? Das geht mit "/".
Angehängte Dateien:
-
generate.png
39 KB -
ergebnis.png
2,4 KB
Hallo Lukas, alle Erfahrungen auf Windows 7 64 bit, integrierte Grafik (Intel 5500, was auch immer das ist). * Zum Einträge löschen im Unit Editor: ach so, ich muss auf den Rand klicken, um den Frame(?) auszuwählen. Wäre gut, wenn Cursor im Feld auch reichen würde. * Zu der Darstellung mit Labels/Entry: ja, die Höhe verändert sich, die Gesamthöhe aber nicht. Anbei mal eine kurze hässliche Fingerübung in Python zur Demo, wie das aussähe. [mg] >> * Beim Duplizieren eines Packages beschwert sich Horizon, dass das >> Verzeichnis nicht existiert, anstatt es einfach anzulegen. Nach ANlegen >> von Hand geht´s problemlos. > > Du benutzt horizon auf Windows, oder? Die Meldung da kommt vom > Windows-Dialog zum Speichern selber. Windows scheint keinen brauchbaren > Dialog zu haben, um einen neuen Ordner anzulegen, nur Dialoge um > vorhandene Ordner auszuwählen. Ich könnte an der Stelle auch den > Dateidialog von Gtk benutzen, aber dann beschweren sich Leute zurecht, > dass der komisch ausschaut... Ja, Windows, s.o. Lasse doch einfach den darüberliegenden Ordner auswählen und generiere den Namen aus dem schon bekannten Packagenamen. [mg] >> * Der Footprint Generator ist prima. Nur: wenn ich versuche, ein >> Quad-Package zu erzeugen, malt er nur die rechte und linke Pinreihe. >> Unten und oben fehlt. > > Was für Einstellungen hast du da gemacht? Bei mir hat das immer > funktioniert. Screenshots anbei. Ist reproduzierbar. >> * Änderungen beim Zeichnen (sei es Mirror, sei es Undo, ...) werden erst >> dann übernommen, wenn die Maus wieder bewegt wird. Bis dahin bleibt der >> alte Zustand erhalten. > > Höre ich jetzt s zum ersten mal, was sind da die genauen Umstände? Ist durchgängig so, vermutlich irgendein Treiberthema Gtk/Windows. Ich finde es aber nicht schlimm, höchstens ein bisschen gewöhnungbedürftig. Danke noch mal für dein Engagement! Max
Max G. schrieb: > * Zu der Darstellung mit Labels/Entry: ja, die Höhe verändert sich, die > Gesamthöhe aber nicht. Anbei mal eine kurze hässliche Fingerübung in > Python zur Demo, wie das aussähe. Das Problem bei der Sache ist, dass wenn man auf einen Eintrag klickt, dieser seine Position in der Liste leicht ändert. Das so hinzubekommen, dass ich damit zufrieden wäre, ist mir gerade zu viel Aufwand. Max G. schrieb: > Ja, Windows, s.o. > Lasse doch einfach den darüberliegenden Ordner auswählen und generiere > den Namen aus dem schon bekannten Packagenamen. Das selbe Problem gibt's auch beim neu anlegen von Packages. Vielleicht fällt mir da noch was ein... Max G. schrieb: > Screenshots anbei. Ist reproduzierbar. Hm, vielleicht sind die anderen Pads auch einfach nur an der falschen Position? Drück mal auf "Pos1", damit alles dargestellt wird.
Angehängte Dateien:
-
uberschneidungen.PNG
3,7 KB
Hallo Lukas, ich habe gerade die neueste Funktion im Schaltplan ausprobiert. schematic editor: start net lines by dragging from pins/junctions Dabei fielen mir mal wieder diese Überschneidungen an den Knicken der Leitungen auf. Ehrlich gesagt habe ich das noch nie in irgend einem anderen Schaltplan gesehen. Ich hätte es gerne ohne diese Überschneidungen, weil das dem ansonsten sehr guten Eindruck des Schaltplanes schadet. Ist das nur zu Debug-Zwecken so? Gruß Helmut
Helmut S. schrieb: > Ist das nur zu Debug-Zwecken so? Ist jetzt standardmäßig aus und kann ebenso wie das automatische starten von Netzlinien in den Einstellungen angepasst werden.
Lukas K. schrieb: > Helmut S. schrieb: >> Ist das nur zu Debug-Zwecken so? > > Ist jetzt standardmäßig aus und kann ebenso wie das automatische starten > von Netzlinien in den Einstellungen angepasst werden. Danke Lukas, eine clevere Idee das konfigurierbar zu machen. Auf die Idee wäre ich jetzt nicht gekommen. Da werde ich doch gleich mal den compiler starten ...
Lukas K. schrieb: > Max G. schrieb: >> Screenshots anbei. Ist reproduzierbar. > > Hm, vielleicht sind die anderen Pads auch einfach nur an der falschen > Position? Drück mal auf "Pos1", damit alles dargestellt wird. Ist repariert, war was Windows-spezifisches: https://github.com/carrotIndustries/horizon/commit/7d5918d4846ea79cbfb803a365eb7fefc0f97535
Hallo Lukas, erst einmal danke für die Zeit, die du in dieses Projekt investierst. Ist echt super! Allerdings gibt es eine Kleinigkeit von mir anzumerken: Ich finde, dass man von den Compiler-Meldungen regelrecht erschlagen wird. Ich mache das bei meinen Makefile-Projekten immer so: sobald ich weiß, dass die Compiler-/Linker-Aufrufe stimmen, gebe ich nur noch eine Status-Meldung pro Datei aus und nicht mehr die gesamte Command-line. Dadurch sieht das das kompilieren so aus:
1 | ... |
2 | Compiling file canvas3d/canvas3d.cpp... |
3 | In file included from ./canvas/poly2tri/poly2tri.h:35:0, |
4 | from canvas3d/canvas3d.cpp:11: |
5 | ./canvas/poly2tri/common/shapes.h: In Konstruktor »p2t::Point::Point(double, double)«: |
6 | ./canvas/poly2tri/common/shapes.h:60:29: Warnung: Deklaration von »y« überdeckt ein Element von »p2t::Point« [-Wshadow] |
7 | Point(double x, double y) : x(x), y(y) {}
|
8 | ^ |
9 | ./canvas/poly2tri/common/shapes.h:47:13: Anmerkung: verdeckte Deklaration ist hier |
10 | double x, y; |
11 | ^ |
12 | ... |
13 | Compiling file pool-mgr/duplicate/duplicate_window.cpp... |
14 | Compiling file resources.cpp... |
15 | Compiling file gitversion.cpp... |
16 | Linking final file horizon-imp... |
17 | Linking final file horizon-pool... |
18 | Linking final file horizon-prj... |
19 | Linking final file horizon-pool-update-parametric... |
20 | Linking final file horizon-prj-mgr... |
21 | Linking final file horizon-pool-mgr... |
Ich habe das diff-file vom Makefile einfach mal angehängt. Du musst das selbstverständlich nicht übernehmen, ist ja auch nur eine kosmetische Angelegenheit, die man nur beim kompilieren sieht :-) Das hat allerdings auch den Vorteil, dass man die Warnings besser sehen kann. Ein weiterer Punkt sind allerdings die ganzen Warnings bezüglich gleichnamigen Variablen (-Wshadow). Diese Variablen würde ich umbenennen, sonst kommt man teilweise echt durcheinander... :-) Mit freundlichen Grüßen, N.G.
Angehängte Dateien:
-
crash_select_more_1a.PNG
5,5 KB -
crash_select_more_1b.PNG
17 KB
Hallo Lukas, ich habe gerade einen reproduzierbaren "crash case" im PCB Layout gefunden. Version: WIN horizon-2017-12-10-0139.zip Zeichne mit dl ein Dreieck Selektiere das ganze Dreieck Dann Rechtsklick in dem Bereich des selektierten Dreiecks -> Select more Dann stürzt das Pogramm ab. Ich hatte übrigens gehofft einen log-file von dem crash zu bekommen. Da ist aber keiner. Bekomme ich den log-file nur in der mysys2 Umgebung?
N. G. schrieb: > Ein weiterer Punkt sind allerdings die ganzen Warnings bezüglich > gleichnamigen Variablen (-Wshadow). Diese Variablen würde ich > umbenennen, sonst kommt man teilweise echt durcheinander... :-) Das ist in Code, der nicht von mir ist. Sofern's da keinen dringenden Grund zu gibt, fass' ich den nicht an. N. G. schrieb: > [...] > Das hat allerdings auch den Vorteil, dass man die Warnings besser sehen > kann. Schaut sinnvoll aus, vielleicht bau' ich das in ner ruhigen Minute noch mit der Option die Compiler-Aufrufe anzuzeigen ein. Helmut S. schrieb: > ich habe gerade einen reproduzierbaren "crash case" im PCB Layout > gefunden. Ist repariert. Zusätzlich werden jetzt Exceptions aus den Tools abgefangen und erscheinen im Log-Fenster.
Unter Ubuntu scheint es ein paar mal ein paar Funktionen nicht zu kennen. Hab mal Issue #25 erstellt. Höre jetzt auf mit dem Versuch es zu compilieren.
Michael H. schrieb: > Unter Ubuntu scheint es ein paar mal ein paar Funktionen nicht zu > kennen. Hab mal Issue #25 erstellt. Höre jetzt auf mit dem Versuch es zu > compilieren. Wie schon auf github geschrieben: Da ist dein ubuntu wohl zu alt. Warte entweder auf das neue LTS oder upgrade auf 17.04.
Ich habe das Programm am Laufen. Danke an Lukas für den Support. Ich freue mich, zu sehen, wie dieses Projekt weiterentwickelt wird... Vielen Dank an Lukas für die Arbeit schomal. Mach weiter so!
Gute Neuigkeiten für alle, die den Pool als zip runtergeladen haben und keine sinnvolle Möglichkeit hatten, den Pool aktuell zu halten: Seit soeben kann der Pool-Manager das: Auf der Startseite mit "Download..." den Pool herunterladen, dann gibt's den neuen Tab "Remote" mit dem Knopf "Upgrade Pool", mit dem seinen lokalen Pool unter Beibehaltung eigener neuer Parts und Änderungen auf den aktuellen Stand bringen kann. Bald kann der Pool Manager dann auch mithilfe der Github-API für einen Pull Requests aufmachen, damit man auch ohne weitere Git-Kenntnisse neue Bauteile in den Pool einpflegen kann.
Angehängte Dateien:
-
libcurl-4.dll.PNG
12 KB
Hallo Lukas, ich habe Probleme beim build für Windows. $ ./make_bindist.sh Obiges läuft normal durch. Wenn ich dann in Windows auf horizon-pool-mgr.exe klicke erhalte ich eine Fehlermeldung wegen fehlender libcurl-4.dll. Gruß Helmut
Helmut S. schrieb: > eine Fehlermeldung wegen fehlender libcurl-4.dll. Ist repariert. Ein wenig unschön ist allerdings, dass ich auf Windows für curl und libgit selber die root-Zertifikate für TLS ausliefern muss...
Hier gibt es ein Tool zum exportieren von Eagle-Designs: https://hackaday.com/2017/12/21/exporting-eagle-libraries-to-foss-tools/ Vielleicht nützt das auch was für dieses Projekt.
chris schrieb: > Hier gibt es ein Tool zum exportieren von Eagle-Designs: Das Tool müsste ja in den horizon pool einspeisen, ist das überhaupt machbar? Nicht nur wegen der unterschiedlichen Datenstrukturen, sondern auch, weil im horizon Wiki steht: > Although you can create your own pool, you are strongly encouraged to > use the pool over at https://github.com/carrotIndustries/horizon-pool/. > To add new parts to it, simply submit a merge request. Wie ist denn das zu verstehen? Ob man wirklich meine Spezialteile im Pool haben will, sei mal dahin gestellt. Aber heißt das, wenn ich ein neues Bauteile brauche, muss ich warten, bis das im Pool eingepflegt ist? Wie ist das gedacht? Und wo wir gerade dabei sind, das README schreibt: > Features for developers > (...) > Everything is referenced by UUIDs Die UUIDs müssten doch zentral erzeugt werden? Und trotzdem wären sie u.U. nicht eindeutig; wie werden Kollisionen behandelt?
eagle user schrieb: > Die UUIDs müssten doch zentral erzeugt werden? Und trotzdem wären sie > u.U. nicht eindeutig; wie werden Kollisionen behandelt? Der Sinn von UUIDs ist, dass man eben ohne zentrale Instanz eindeutige IDs erzeugen kann. Da es ca. 3.4×10³⁸ verschiedene UUIDs gibt, klappt das auch gut genug. Die Wahrscheinlichkeit, dass Dinge aufgrund eines Bugs in meinem Code kaputt gehen, ist deutlich größer, als die, dass man über eine doppelte UUID stolpert. eagle user schrieb: > Aber heißt das, wenn ich ein > neues Bauteile brauche, muss ich warten, bis das im Pool eingepflegt > ist? Wie ist das gedacht? Nein, selber einpflegen. Derzeit heißt das Forken, Branch machen, Bauteil anlegen, Commiten, merge request aufmachen und hoffen dass der akzeptiert wird. Dann haben alle was davon. Gerade bin ich dabei, GitHub-Integration einzubauen, damit diese Schritte in vereinfachter Form direkt im Pool Manager ohne weitere git-Kenntnisse erledigt werden können. eagle user schrieb: > Das Tool müsste ja in den horizon pool einspeisen, ist das überhaupt > machbar? Nicht nur wegen der unterschiedlichen Datenstrukturen, Bei Packages sehe ich einen Importer noch am einfachsten umsetzbar. Bei Symbolen muss sich der Importer eben Units und Entities dazu ausdenken. Alles in allem kein Hexenwerk, Freiweillige vor :) Uwe B. schrieb: > Lukas, > > wirst Du auf der FOSDEM im EDA Devroom vortragen? Ja: https://fosdem.org/2018/schedule/event/cad_horizon/ Auf dem 34C3 bin ich auch anzutreffen, einfach PN schreiben.
Lukas K. schrieb: > Auf dem 34C3 bin ich auch anzutreffen Hälst du einen Vortrag? Das Programm ist so riesig, dass ich zumindest auf Anhieb nichts sehen konnte. Wenn du einen Vortrag hälst und es zeitlich passt, würde ich mir den Livestream reinziehen.
Jörg W. schrieb: > Hälst du einen Vortrag? Ne, dafür ist das Projekt m.E. noch nicht weit genug. Nächstes Jahr dann vielleicht.
Meine perschönliche Sichtweise auf das CAD-Programm ist, dass es auf dem richtigen Weg ist und das was werden könnte. Jedoch denke ich, dass noch einiges an Usability-Improvements von Nöten ist - wie Du selbst sagst ist das Programm in den Kinderschuhen. So hat KiCad auch mal angefangen. Was mich an KiCAD stört, ist das die keine Clearance-Matrix haben und das auch nicht implementieren wollen. Desshlab möchte ich mal dein Program ausprobieren. Ich habe heute ca. 2h gebraucht, um mir grob mal einen Überblick zu verschaffen. Ich erstelle Dir für alles was mir auffällt ein Issue. Das kann etwas bombadierend wirken - ist aber so nicht gemeint. Mit dem Fosdem würde mich auch der Vortrag interessieren - den würde ich mir auch gerne dann als Video reinziehen. Mein Plan ist es eine Testplatine damit zu machen, und mal 5 Euro in eine ChinaPCB zu investieren und den Prozess dann in einem separten Threat zu dokumentieren. Mal sehen, ob ich das hinbekomme. EDIT: Eine Problematik, die ich bei den Pools sehe, was ich aber auch falsch sehen könnte, ist falls jemand mist commited, andere darunter leiden. Desshalb hatte ich separate Pools vorgeschlagen. Jedoch sollte falls man nur einen Pool haben sollte, einen Button haben, der den Pool automatisch updated. Also, dass man nicht erst "umständlich" git clone, etc. machen muss. Praktiker würde das abschrecken...
Michael H. schrieb: > Jedoch sollte falls man nur einen Pool haben sollte, einen Button haben, > der den Pool automatisch updated. Genau das gibt es doch seit kurzem: Wenn du den Pool mit "Download..." heruntergeladen hast, gibt es im Tab "Remote" den Knopf "Upgrade" um den lokalen Pool auf den Stand von dem auf Github zu bringen. Michael H. schrieb: > ist falls jemand mist commited, andere darunter leiden. Darum schau ich's mir (und in Zukunft hoffentlich noch andere) an. Das entbindet einen als Anwender dennoch nicht davon, das Part selber zu verifizieren. EDIT: Wenn du Bugfixes schnell haben willst, ist es empfehlenswert selber zu bauen: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows
Lukas K. schrieb: > Darum schau ich's mir (und in Zukunft hoffentlich noch andere) an. Wird aber irgendwann ein Fulltime-Job werden. Man sollte vorher eine Strategie haben, wie jeder dann auf seinem privaten Fork des „offiziellen“ Pools arbeiten kann, von diesem ggf. Updates importiert, aber ansonsten seine eigenen Bauteile privat hält. Ein EDA-Programm, welches alle Bauteile in der Bibliothek hat, wird es ohnehin nicht geben können. Dazu sind erstens die Hersteller zu einfallsreich :) und zweitens die Anforderungen der Anwender zu verschieden. ps: Viel Spaß auf dem 34C3!
Michael H. schrieb: > Eine Problematik, die ich bei den Pools sehe, was ich aber auch falsch > sehen könnte, ist falls jemand mist commited, andere darunter leiden. Ich fürchte, das siehst du richtig. Deswegen sollte man das... chris schrieb: > Hier gibt es ein Tool zum exportieren von Eagle-Designs: ...wahrscheinlich vermeiden. Die bei Eagle mitgelieferten Bauteile haben mich schon nicht überzeugt, aber was ich bisher aus anderen Quellen gefunden habe war den Download nicht wert. Cadsoft hatte ja ein paar (wenige) Regeln festgelegt, aber nicht einmal die werden eingehalten. Die Idee, im Pool nur die originale Herstellernummer zu verwenden, finde ich ausgezeichnet (ich hoffe, ich hab' das richtig verstanden). Das ist schon mal sehr viel besser als die Praxis bei Eagle.
Bauteile genau anzulegen, und zu pflegen ist ein heiden Aufwand. Desshalb gibt es ja SnapEDA, Librarian und wie die alle heißen. Eventuell könnte man sich mit denen zusammentun? Für den Anfang kann ich gerne helfen, über die Bauteile drüber zu schauen, die reinkommen. Falls Hilfe gewünscht ist.
Hallo Eagle user und Michael . eagle user schrieb: >> Hier gibt es ein Tool zum exportieren von Eagle-Designs: > > ...wahrscheinlich vermeiden. Die bei Eagle mitgelieferten Bauteile haben > mich schon nicht überzeugt, aber was ich bisher aus anderen Quellen > gefunden habe war den Download nicht wert. Das wird wohl so für jede x-beliebige Quelle gelten, weil halt auch jeder andere Vorstellungen von einer guten Bibliothek hat. Darum wird niemand, der sich ernsthaft mit Schaltplänen und Platinenlayout beschäftigt, darumherum kommen, sich seine eigene Bibliothek zusammenzustellen, die er irgendwann halt auch gut kennt, und von deren Bestandteilen er weiss, dass sie auch im Zusammenhang mit seinen anderen "Systemen" gut funktioniert. Offizielle Bibliotheken sind eigentlich nur ein erster Vorschlag, den man oft so aktzeptieren kann, aber auch genauso oft anpassen muss, und der auch immer auf Fehler überprüft werden muss. Darum kann ein breiter Zugriff auch auf fremde Bibliotheken sehr sinnvoll sein. Snapeda bietet eine breite Palette von Programmen, in deren Format exportiert werden kann, aber nur Eagle und KiCad haben davon offene bzw. sogar freie Formate. Snapeda: https://www.snapeda.com/ Viele Distributoren bieten den Download von Bibliotheken zu denen von ihnen vertriebenen Bauteilen an wie zum Beispiel Farnell oder Digikey. Das sind dann auch meistens Eagle oder KiCad Bibliotheken. Digikey: https://www.digikey.de/de/news/press-releases/2017/aug/digi-key-adds-kicad-pcb-model-download Es ist also eher angeraten, eine Import und Exportfunktion für gängige Bibliotheksformate zu schreiben. Gängig und offen oder sogar frei sind aber nur drei: Eagle, KiCad und gEDA. Michael H. schrieb: > Bauteile genau anzulegen, und zu pflegen ist ein heiden Aufwand. > Desshalb gibt es ja SnapEDA, Librarian und wie die alle heißen. Das haut in die gleiche Kerbe. > Eventuell könnte man sich mit denen zusammentun? Warum soll man in den Format Zoo ein weiteres Format einbringen, solange es offene und freie gibt? Lieber auf ein freies vorhandenes gehen, was auch schon unterstützt wird. Ein neues Format müsste schon eine erhebliche Verbreitung bekommen, bevor es bei diesen Anbietern aufgenommen würde. KiCad wäre ein guter Kandidat als Austauschformat , weil dort Symbol, Footprint und 3D-Modell zusammengefasst werden können , aber nicht zusammengefasst werden müssen . Es ist also in dieser Hinsicht sehr flexibel. eagle user schrieb: > Cadsoft hatte ja ein paar > (wenige) Regeln festgelegt, aber nicht einmal die werden eingehalten. Es ist erstens auch immer die Frage, was an Regel sinnvoll ist, und zweitens selbst wenn irgendwann einmal alle Bibliotheken konform mit den Regeln sind, und die Regeln werden überarbeitet, ist es ein großer Arbeitsaufwand bzw. Zeitaufwand, die vorhandenen Bibliotheken anzupassen. Die Bibliotheken hinken den Regeln also immer hinterher. Das habe ich bei Eagle so bemerkt, und bei KiCad eben auch. Bei KiCad existiert für das Bibliotheksprojekt (was vom eigentlichen KiCad Projekt sogar getrennt ist) ein Regelwerk: https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention Wer zu der Bibliothek beitragen will, kann das nur, wenn irgend jemand anderes die Bibliothek auf Konsens mit dem aktuellen Regelwerk überprüft hat. > Die Idee, im Pool nur die originale Herstellernummer zu verwenden, finde > ich ausgezeichnet (ich hoffe, ich hab' das richtig verstanden). Das ist > schon mal sehr viel besser als die Praxis bei Eagle. Das ist ein guter Ansatz. Aber natürlich sind auch alternative Symbole und Footprints für das gleiche Bauteil sinnvoll. Im Schaltplan möchtest Du einmal z.B. eine monolitische Darstellung für z.B. ein Relais, wo Spule und Kontaktsätze zusammengefasst sind, aber auch eins in aufgelöster Darstellung wo Spule und Kontaktsätze getrennt sind, um sie bei größeren Schaltplänen verteilen zu können. Je nach den Umständen ist das eine oder andere Sinnvoll. Bei Footprints gibt es bei THT Bauteilen oft die Möglichkeit, sie liegend oder stehend zu montieren, oder allgemein kleine Pads wo Dichte oder Isolationsabstand wichtig sind, oder aber große Pads, wo Platz ist, aus Robustheitsgründen. Viele Bauteile existieren mit einem mehr oder weniger Festgelegten Gehäuse. Für diese sind generische Footprints gut, die man bei Bedarf auch ändern kann. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Bernd W. schrieb: > Das ist ein guter Ansatz. Aber natürlich sind auch alternative Symbole > und Footprints für das gleiche Bauteil sinnvoll. Das funktioniert bereits. Die GitHub-Integration zum Erstellen von Pull Requests gibt's nun auch: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard#using-the-github-integration
Angehängte Dateien:
-
make_fehler.PNG
23 KB
Hallo Lukas, das kompilieren in mysys2 bringt eine "Fehler"-Meldung - scheint aber trotzdem richtig kompiliert zu haben. Idee? Helmut
Bernd W. schrieb: > KiCad wäre ein guter Kandidat als Austauschformat , weil dort Symbol, > Footprint und 3D-Modell zusammengefasst werden können , > aber nicht zusammengefasst werden müssen . Es ist also in dieser > Hinsicht sehr flexibel. FÜhrt aber nicht gerade zur Standardisierung eines Übergabeformats, weil dann wieder jeder macht, was er möchte. Andererseits: Wer baucht bei der Übergabe von Produktionsdaten Symbole? Genau das möchte Ich z.B. nicht. Der Produzent soll die Platine machen und mehr nicht, weil Prototyp. Bei einer Serie ist es was anderes.
Helmut S. schrieb: > Hallo Lukas, > das kompilieren in mysys2 bringt eine "Fehler"-Meldung - scheint aber > trotzdem richtig kompiliert zu haben. Idee? > Helmut Richtig gebaut haben kann es damit nicht, ist repariert.
Bernd Wiebus (berndwiebus) Benutzerseite >Das wird wohl so für jede x-beliebige Quelle gelten, weil halt auch >jeder andere Vorstellungen von einer guten Bibliothek hat. >Darum wird niemand, der sich ernsthaft mit Schaltplänen und >Platinenlayout beschäftigt, darumherum kommen, sich seine eigene >Bibliothek zusammenzustellen, die er irgendwann halt auch gut kennt, und >von deren Bestandteilen er weiss, dass sie auch im Zusammenhang mit >seinen anderen "Systemen" gut funktioniert. Das genau bringt mich jedes Mal auf die Palme, wenn ich darüber nachdenke. Ich habe schon in Firmen gearbeitet, bei denen ein Mann mit nichts anderem beschäftigt ist, als Bauteile anzulegen. Wenn man dann ein Neues braucht, muss man jedes Mal warten, bis der Zeit hat. Jeder Hersteller eines Bauteils wird sein Bauteil wohl mit einem CAD-System konstruiert haben. Gäbe es eine einheitliches Format wie z.B. DIN, wäre die ganze Blindleistung dass jede Firma wieder ihr eigenes Bauteil anlegen muss, unnötig.
chris schrieb: > Gäbe es eine einheitliches Format wie z.B. DIN, wäre die ganze > Blindleistung dass jede Firma wieder ihr eigenes Bauteil anlegen muss, > unnötig. Du hast noch nicht verstanden, dass es absolut nicht am fehlenden Format liegt, sondern dass einfach jede Firma ihre eigenen Ideen hat, was beim Anlegen eines Bauteils wichtig ist, wie sich das Ding in die firmeneigene Infrastruktur integriert etc. pp. Die paar Striche zu zeichnen, ist dabei fast der geringste Anteil an Arbeit. Die MechCAD-Daten bekommt man mittlerweile teilweise sogar von den Herstellern (genauso wie die 3D-CAD-Daten). Gehört aber nicht hierher, hier geht es um Horizon.
Angehängte Dateien:
-
horizon17.png
66 KB
Ich konnte heute (nach einem Update "git pull; make") den interaktiven Router nicht mehr starten. Ich hatte ein paar Leiterbahnen gelöscht und wollte diese neue verlegen. Fehlermeldung siehe Bildschirmfoto.
Klaus R. schrieb: > Ich konnte heute (nach einem Update "git pull; make") den interaktiven > Router nicht mehr starten. Ich hatte ein paar Leiterbahnen gelöscht und > wollte diese neue verlegen. Fehlermeldung siehe Bildschirmfoto. Hallo Klaus, ich konnte den von dir beschriebenen Fehler in WIN10 nicht nachvollziehen. Falls du einen WIndows-Rechner hast, dann könntest du es mal mit der von Lukas generierten WIN-Version vom 01.01.2018 testen. http://0x83.eu/horizon-zip/ Gruß Helmut
Klaus R. schrieb: > den interaktiven > Router nicht mehr starten. Endlich kommt das Logging mal Sinnvoll zum Einsatz. Davor wäre das ganze Programm abgestürzt :) Der Fehler kam, daher, dass in deinem eigenen Padstack beim SSOP-28 aus noch unbekannter Ursache Polygone ohne Vertices waren. Jetzt werden diese nicht mehr geladen.
Lukas K. schrieb: > Der Fehler kam, daher, dass in deinem eigenen Padstack beim SSOP-28 aus > noch unbekannter Ursache Polygone ohne Vertices waren. Jetzt werden > diese nicht mehr geladen. Ja, danke! Jetzt geht es. Die "eigenen Padstacks" haben leider mir schon etwas Kummer bereitet. Hätte ich nur am Anfang kapiert, dass die schon vorhandenen Padstacks parametrisierbar sind... wüsste jetzt nicht, wo man dann noch eigene bräuchte.
Hi Lukas! Ich habe gestern ganz zufällig dein Projekt gefunden und ich muss dir wirklich sagen: Hut ab! Ich hatte das gleiche schon (einfaches Tool, globale Library (hier Pool), usw.) vor ein paar Jahren vor zu implementieren, jedoch fehlte mir einfach die Zeit dafür. Ich bin dir auf jeden Fall sehr dankbar für deine Mühe :) Auf Github hast du sicherlich schon mitbekommen, dass ich hier auch mit arbeiten möchte bzw. auch schon mache (Github-user: peterus). Unter anderem habe ich bereits ein Script erstellt um die SMD Widerstände der Größen 0402, 0603, 0805 und 1206 in der E12-Reihe automatisch zu generieren (von 0 bis 100MOhm). Das hab ich eigentlich einmal nur gemacht, um mich mit den Pool-Daten näher zu beschäftigen. Wenn du nichts dagegen hast, würde ich gerne das makefile "austauschen" auf cmake. Ich benütze cmake schon seit ein paar Jahren und man hat damit einige mehr Vorteile (auflösen von externen Bibliotheken ist einfacher, es gibt mehrere config files, logging von dem was man sehen möchte, logging ist auch schöner, usw.). Zusätzlich würde ich auch gleich ein bisschen aufräumen und ein bisschen eine bessere Struktur rein bringen wo die Daten gespeichert sind. Anfangen würde ich damit, dass ich mal alle cpp's und hpp's durch gehe und einen Header mit Lizenz rein schreiben lasse mit einem Script. edit: habs mir anders überlegt: Lizenz solltest du übernehmen :)
Peter B. schrieb: > Ich bin dir auf jeden Fall sehr dankbar für deine Mühe :) Schön zu hören :) > Auf Github hast du sicherlich schon mitbekommen, dass ich hier auch mit > arbeiten möchte bzw. auch schon mache (Github-user: peterus). > Unter anderem habe ich bereits ein Script erstellt um die SMD > Widerstände der Größen 0402, 0603, 0805 und 1206 in der E12-Reihe > automatisch zu generieren (von 0 bis 100MOhm). > Das hab ich eigentlich einmal nur gemacht, um mich mit den Pool-Daten > näher zu beschäftigen. Okay, aber eigentlich will ich im Pool nur Bauteile mit MPN und Hersteller haben, bzw. die CPL-Teilenummern, die man mit den Octopart-Bomtool zu echten Bauteilen zuordnen kann. Mir schwebt vor, dass man zukünftig die exportierte BOM direkt bei Octopart oder Digikey einwerfen und dann einfach bestellen kann. Allerdings hat nicht jedes Projekt diesen Anspruch und so generische Widerstände können dafür durchaus praktisch sein, mal drüber nachdenken. > Wenn du nichts dagegen hast, würde ich gerne das makefile "austauschen" > auf cmake. Ich benütze cmake schon seit ein paar Jahren und man hat > damit einige mehr Vorteile (auflösen von externen Bibliotheken ist > einfacher, es gibt mehrere config files, logging von dem was man sehen > möchte, logging ist auch schöner, usw.). Bis jetzt fehlt mir an make eigentlich nichts wirklich, was die zusätzliche Komplexität rechtfertigen würde. Externe Bibliotheken zu finden klappt mit pkg-config auf meinen Zielplattformen auch hinreichend gut. > Zusätzlich würde ich auch gleich ein bisschen aufräumen und ein bisschen > eine bessere Struktur rein bringen wo die Daten gespeichert sind. Wie meinst du das genau? Jetzt bezogen auf pool oder source code? > Anfangen würde ich damit, dass ich mal alle cpp's und hpp's durch gehe > und einen Header mit Lizenz rein schreiben lasse mit einem Script. > > edit: habs mir anders überlegt: Lizenz solltest du übernehmen :) Auch wenn es mir persönlich missfällt, muss das wohl so sein...
> Okay, aber eigentlich will ich im Pool nur Bauteile mit MPN und > Hersteller haben, bzw. die CPL-Teilenummern, die man mit den > Octopart-Bomtool zu echten Bauteilen zuordnen kann. Mir schwebt vor, > dass man zukünftig die exportierte BOM direkt bei Octopart oder Digikey > einwerfen und dann einfach bestellen kann. Kann ich voll und ganz verstehen, jedoch gibt es hier gerade ein mal ein paar Widerstände in der CPL-Bibliothek. Ich hab mich ein bisschen eingelesen in das CPL und heraus gefunden, dass diese nur die meist benutzten Sachen rein stellen. Das heißt, dass dort nie ein Widerstand sein wird mit 5.6k (in 1206) weil dieser nicht unter den meist benützten ist. Angenommen ich möchte nun ein Projekt bauen wo dieser Widerstand benötigt wird. Ich kann ihn auch kaufen, nur gibt es den nicht im Pool - wäre ziemlich blöd... > Bis jetzt fehlt mir an make eigentlich nichts wirklich, was die > zusätzliche Komplexität rechtfertigen würde. Externe Bibliotheken zu > finden klappt mit pkg-config auf meinen Zielplattformen auch hinreichend > gut. Sobald das Projekt größer wird, wird es viel einfacher zum managen ;) Spreche da aus guter Erfahrung aus der Arbeit usw. > Wie meinst du das genau? Jetzt bezogen auf pool oder source code? Der Pool ist schon gut strukturiert! Beim Source Code habe ich sehr lange gebraucht bis ich verstanden habe wie wo was liegt. Bzw. was außerdem auch ein externer Code ist.
Peter B. schrieb: > Angenommen ich möchte nun ein Projekt bauen wo dieser Widerstand > benötigt wird. Ich kann ihn auch kaufen, nur gibt es den nicht im Pool - > wäre ziemlich blöd... Meine (vielleicht utopische) Idee war, dass der Anwender sich dann auf digikey den gewünschten Widerstand aussucht und mit einem Skript wie deinem gleich die ganze Serie des Herstellers in den Pool einpflegt. Wenn man sich beim Design der Schaltung nicht von sowas aufhalten lassen will, kann man auch einfach im Schaltplan den Widerstand auch ohne Part, nur als Entity, platzieren und den Wert einfach eintippen. Später kann man dann das Anlegen von den Bauteilen nachholen und mit dem "Assign Part"-Tool den Widerständen das richtige Part zuweisen. Peter B. schrieb: > Beim Source Code habe ich sehr lange gebraucht bis ich verstanden habe > wie wo was liegt. Bzw. was außerdem auch ein externer Code ist. Okay, man könnte alles externe (clipper, etc) in einen "3rd_party"-Ordner stecken, damit das besser getrennt ist. Was hat dich sonst so konkret gestört?
Lukas K. schrieb: > Meine (vielleicht utopische) Idee war, dass der Anwender sich dann auf > digikey den gewünschten Widerstand aussucht und mit einem Skript wie > deinem gleich die ganze Serie des Herstellers in den Pool einpflegt. Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature ist. KiCad kann es ja schon und ich würde mit keinem (neuen) Programm mehr arbeiten wollen, das keine 3d-Fähigkeiten hat.
Vielleicht könnte man wieder die 3D Ansicht von KiCad in horizon integrieren!
Mampf F. schrieb: > Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature > ist. Das trifft sich gut, da bin ich gerade dran :) Laden von STEP-Modellen mit opencascade klappt schon, an der richtigen Stelle in der 3D-Vorschau sind sie auch schon. Fehlt nur noch ein bisschen drumherum. Der Code zum STEP-Importieren mit opencascade ist weitestgehend von https://github.com/KiCad/kicad-source-mirror/blob/master/plugins/3d/oce/loadmodel.cpp abgekupfert. STEP-Export steht auch der Roadmap, das wird dann darauf hinauslaufen kicad2step zu portieren. A. N. schrieb: > Vielleicht könnte man wieder die 3D Ansicht von KiCad in horizon > integrieren! Ne, die haben aus mir unbekannten Gründen gleich ein ganzes Scenegraph-Framework implementiert und verwenden legacy-OpenGL. Ich werfe die Vertices und Indizes für die Dreiecke aller Bauteile auf dem Board in VBOs auf die GPU und kann diese dann durch instancing mehrfach an den vorgesehenen Positionen rendern.
Welche Funktion hat das Icon "Herz" im Part Browser? Ich kann keine Funktion beim anklicken erkennen.
Helmut S. schrieb: > Welche Funktion hat das Icon "Herz" im Part Browser? > Ich kann keine Funktion beim anklicken erkennen. Das fügt das ausgewählte Part den Favoriten (links im Fenster) hinzu, bzw. entfernt es daraus.
Lukas K. schrieb: > Helmut S. schrieb: >> Welche Funktion hat das Icon "Herz" im Part Browser? >> Ich kann keine Funktion beim anklicken erkennen. > > Das fügt das ausgewählte Part den Favoriten (links im Fenster) hinzu, > bzw. entfernt es daraus. Danke. Da hätte ich auch selber draufkommen müssen. :-)
Lukas K. schrieb: > Mampf F. schrieb: >> Man sollte daran denken, dass mittlerweile 3d-Fähigkeit ein Must-Feature >> ist. > > Das trifft sich gut, da bin ich gerade dran :) Laden von STEP-Modellen > mit opencascade klappt schon, an der richtigen Stelle in der 3D-Vorschau > sind sie auch schon. Fehlt nur noch ein bisschen drumherum. Der Code zum Unglaublich! Habe es direkt mal ausprobiert, stecke aber beim Laden der Step-Datei fest. Im 3D-View des Packages klicke ich auf den Browse-Button für die Step-Datei, wählt diese aus und schließe dann den Datei-Dialog. Passieren tut allerdings nichts. Der Dateiname erscheint auch nicht im Textfeld vor dem Browse-Button. Das hätte ich erwartet. Ist das der richtige Weg? Wo liegen die Step-Dateien, wenn man sie denn mal hochgeladen bekommt? Uwe
Sodele, STEP-Modelle funktionieren nun grundlegend einige Worte dazu noch: Integration in die Download/Upgrade-Infrastruktur fehlt noch, kommt aber bald. Angedacht war das dann so: Im Pool wird es dann neben packages, entities, etc. noch den Ordner "3d_models" geben, in dem dann alle STEP-Dateien an Zentraler stelle liegen, also teil des Pools werden. Da die Lizenzbedingungen einiger Hersteller es nicht erlauben, deren Modelle weiterzuverteilen, wird es noch einen Ordner geben, in den man dann selber die Modelle mit dem richtigen Dateinamen ablegen kann. Geduldet euch am besten noch ein Paar Tage, dann wird aus dem Futur im Absatz oben auch Präsens ;) Uwe S. schrieb: > Das hätte ich erwartet. > Ist das der richtige Weg? Wo liegen die Step-Dateien, wenn man sie denn > mal hochgeladen bekommt? Da hat noch eine Fehlermeldung gefehlt (ist jetzt drin), die einem sagt, dass sich die Datei nicht im Pool befindet. Damit man keine absoluten Pfade hat, werden die Dateinamen relativ zum Pool gespeichert. Wenn du deine Modelle in einen Unterordner des Pools kopiert, sollte es klappen.
Welches dev package braucht man denn dafür?
util/step_importer.cpp:2:10: fatal error: TDocStd_Document.hxx: Datei
oder Verzeichnis nicht gefunden
#include <TDocStd_Document.hxx>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
tester schrieb: > Welches dev package braucht man denn dafür? > > util/step_importer.cpp:2:10: fatal error: TDocStd_Document.hxx: Datei > oder Verzeichnis nicht gefunden > #include <TDocStd_Document.hxx> > ^~~~~~~~~~~~~~~~~~~~~~ > compilation terminated. Unter Debian versuchs mal mit liboce-ocaf-dev Uwe
Uwe S. schrieb: > Unter Debian versuchs mal mit liboce-ocaf-dev Ja, danke, das wars. Noch ein Job für Lukas, Wahrscheinlich wieder mein vermurkstes Padstack. Wenn ich im Board auf die 3D Ansicht gehe, crashed horizon. klaus@Yoga:~/horizon/horizon$ ./horizon-prj-mgr SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC col 2 create proc spawn /home/klaus/horizon/horizon/horizon-imp -b /home/klaus/horizon/proj/rpi-codec/board.json /home/klaus/horizon/proj/rpi-codec/top_block.json /home/klaus/horizon/proj/rpi-codec/vias imp rx null (horizon-imp:4658): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: [Unsupported] Opposing point on constrained edge
tester schrieb: > unhandled exception (type std::exception) in signal handler: > what: [Unsupported] Opposing point on constrained edge Oh, den kennen wir doch: Klaus R. schrieb: > [...] > terminate called after throwing an instance of 'std::runtime_error' > what(): [Unsupported] Opposing point on constrained edge > end proc 4244 > exit stat 134 Da es jetzt Logging gibt, hab ich das die exception abgefangen und ein Log-Eintrag draus gemacht: https://github.com/carrotIndustries/horizon/commit/b3bd85d831cbecd4bb0b334cd87188cf0e0aa681 Dann fehlt immerhin nur die Füllung beim Silkscreen an der Stelle, an der's hinfällt.
Angehängte Dateien:
-
make.PNG
31 KB
Hallo Lukas, "make" in mysy64 (WIN 10) funktioniert seit heute nicht mehr. Es bricht einfach nach kurzer Zeit ab. Gruß Helmut
Helmut S. schrieb: > Hallo Lukas, > > "make" in mysy64 (WIN 10) funktioniert seit heute nicht mehr. Es bricht > einfach nach kurzer Zeit ab. > > Gruß > Helmut Seit heute ist opencascade zum Laden von den STEP-Modellen eine Abhängigkeit: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#install-dependencies Zum Installieren:
1 | pacman -Sy mingw-w64-x86_64-oce |
Hi Lukas! Ich arbeite schon seit ein paar Tagen an einer Restrukturierung so dass du normal weiter entwickeln kannst und ich mich eben um ein paar andere Punkte kümmere (Liste weiter unten). Nachdem das schon langsam ein bisschen größer geworden ist, wollte ich mich einmal mit dir absprechen welche Änderungen du übernehmen würdest und welche nicht (nicht das ich hier einige Tage arbeite und du die Änderungen e nicht rein-mergen möchtest). Hier ist die Liste mit einer Erklärung zu jedem Punkt wieso ich denke das diese Änderung besser ist:
1 | 1) externer Code wurde in den Ordner "extern" verschoben (umbenennen in "3part"?) -> Trennung zwischen Projekt-Code und externen/3part-Code |
2 | 2) Projekt-Code wurde in src/* verschoben -> Übersichtlicher Platz für den Code |
3 | 3) Umstellung von Makefile auf CMake -> siehe weiter unten |
4 | 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind |
5 | 5) gresources von CMake erstellen lassen -> Vereinfachung von einem Build Schritt für CMake |
6 | 6) board/board_layers.hpp Konstanten in einem enum verwandelt -> kann mit einer Shared-Lib (cmake) nicht mehr verwendet werden (Linker Error mit CMake), Umwandlung in einem enum war ohne weiteres einfach möglich. |
Natürlich gibt es hier leider ein paar Abhängigkeiten: Wenn 3) gemacht werden soll, muss auch 5) und 6) durchgeführt werden. Auch anders herum 5) ist Abhängig von 3) und das wiederum von 6)! Wieso nun CMake: * Du kannst unabhängig vom Buildsystem arbeiten -> Projekt kann mit Makefile, Visual Studio, <Buildsystem deiner Wahl> usw. geöffnet werden. * Wenn eine neue externe Library hinzugefügt wird (so wie jetzt gerade der Fall ist), meckert schon CMake von vornherein das die Library fehlt und es wird noch gar nicht gebaut. Außerdem bekommt man eine genaue Fehlerbeschreibung wieso und was fehlt. * Nettere Ausgabe (ok, ist Ansichtssache. Aber ich finde es cool das ich den Buildvorschritt mit %e sehen kann) So... das hab ich mal in den letzten 3 bis 4 Tagen fast alles erledigt! Nachdem es aber dein Projekt ist und du das sagen darüber hast, möchte ich dir da nicht auf die Füße treten und gleich einen riesigen "pull request" los schicken :) Ich bin gerne offen meine Änderungen auf deine neusten Änderungen aufzusetzen, würde aber gerne wissen mit was du einverstanden wärst und was ich dir alles schicken darf. Dann würde ich das Schritt für Schritt auf mehrere Pull Requests aufteilen, so dass du und ich nicht zu viel zum ändern haben ;) ------------------------------------------------------------------------ Bezüglich der Änderungen vom Pool die von mir noch offen sind: Mit dem Original Namen von der CPL Lib, kann ich aber auch nicht direkt in der SnapEDA's Library suchen. Möchte ich zb. einen 100Ohm Widerstand in 1206 haben finde ich in der CPL diesen Eintrag: CPL-RES-1206-100-0.25W Gehe ich nun auf die SnapEDA's Seite und gebe diesen Begriff bei der Suche ein, bekomme ich kein Ergebnis! Oder gibt es hier eine andere "Suche" wenn ich schon diesen Begriff habe?
Cool, dass mal jemand anders den Sourcecode anfasst :) Peter B. schrieb: > 1) externer Code wurde in den Ordner "extern" verschoben (umbenennen in > "3part"?) -> Trennung zwischen Projekt-Code und externen/3part-Code Sehr schön :) > 2) Projekt-Code wurde in src/* verschoben -> Übersichtlicher Platz für > den Code Geschmackssache, ist aber wohl so üblich, also ja. > 3) Umstellung von Makefile auf CMake -> siehe weiter unten Hast mich überzeugt. Insb. kann dann opencascade eine optionale Abhängigkeit werden und man kann auf https://github.com/FreeCAD/FreeCAD/blob/master/cMake/FindOpenCasCade.cmake aufbauen. > 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben > werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind Das hatte ich schon längers vor, aber war immer zu faul dazu. Danke! Ganz früher war alles in einem Ordner drin, als ich dann Zeug in Ordner einsortiert hatte, war ich zu faul zum Includes anpassen. -I war da am einfachsten... > 5) gresources von CMake erstellen lassen -> Vereinfachung von einem > Build Schritt für CMake D.h. man gibt Cmake die liste von ressourcen? > 6) board/board_layers.hpp Konstanten in einem enum verwandelt -> kann > mit einer Shared-Lib (cmake) nicht mehr verwendet werden (Linker Error > mit CMake), Umwandlung in einem enum war ohne weiteres einfach möglich. Oh, ganz vergessen, dass es die neben scoped enums auch noch gibt, danke :) Peter B. schrieb: > Oder gibt es hier eine andere > "Suche" wenn ich schon diesen Begriff habe? Octopart, da kommen dann Widerstände von mehreren Herstellern zur Auswahl. Das schöne an den CPL-Parts ist, dass sich schon jemand anders eine Zuordnung von generischer Part-Nummer zu MPN gemacht hat. Wenn es da noch andere Schemata gibt, sind die auch gerne gesehen, Hauptsache man bekommt automatisch eine MPN raus.
Lukas K. schrieb: > Cool, dass mal jemand anders den Sourcecode anfasst :) Ja ich kenn das leider zu gut von einigen Projekten von mir. Da werkelt man ewig lange herum und es gibt zwar viele Interessenten, aber am Schluss steht ma dann doch fast ganz alleine da. Da freut man sich schon wenn mal jemand anderer mit anpackt :) > Geschmackssache, ist aber wohl so üblich, also ja. Du hast hald den Vorteil, dass du wirklich den gesamten Code auf einem Platz hast. Alles was nicht Code ist, kommt einfach wo anders hin und es gibt eine Trennung dazwischen ;) >> 3) Umstellung von Makefile auf CMake -> siehe weiter unten > Hast mich überzeugt. Insb. kann dann opencascade eine optionale > Abhängigkeit werden und man kann auf > https://github.com/FreeCAD/FreeCAD/blob/master/cMake/FindOpenCasCade.cmake > aufbauen. Guter Punkt und wird dann von mir auch gleich mit umgesetzt! >> 4) Include-Dirs verringert (die Einzelnen Module müssen jetzt angegeben >> werden beim Include) -> damit Abhängigkeiten einfacher ersichtlich sind > Das hatte ich schon längers vor, aber war immer zu faul dazu. Danke! > Ganz früher war alles in einem Ordner drin, als ich dann Zeug in Ordner > einsortiert hatte, war ich zu faul zum Includes anpassen. -I war da am > einfachsten... :) In der Zwischenzeit ist das Projekt ja schon ziemlich groß geworden, da muss schon eine Struktur her, sonst wird das nur Chaos. >> 5) gresources von CMake erstellen lassen -> Vereinfachung von einem >> Build Schritt für CMake > D.h. man gibt Cmake die liste von ressourcen? Ja genau (gibt dafür extra eine CMake Erweiterung). Es werden dann automatisch die Files überprüft ob diese existieren und danach wird das xml erstellt und dann das Cpp file. >> Oder gibt es hier eine andere >> "Suche" wenn ich schon diesen Begriff habe? > Octopart, da kommen dann Widerstände von mehreren Herstellern zur > Auswahl. > Das schöne an den CPL-Parts ist, dass sich schon jemand anders eine > Zuordnung von generischer Part-Nummer zu MPN gemacht hat. Wenn es da > noch andere Schemata gibt, sind die auch gerne gesehen, Hauptsache man > bekommt automatisch eine MPN raus. Jaaa stimmt... wenn ich jetzt meine generierten Namen verwende kommt man nicht gleich auf ein Ergebnis. Man muss erst die "-" entfernen und dann kommt auch was raus. Da muss man noch was machen :)
Hat jemand schon Symbole erstellt? Ich brauche z.B. einen OpAmp. Aber irgendwie sehe ich z.B. nicht wo ich die Pins hinzufügen kann. Gibts da einen Trick?
Michael H. schrieb: > Hat jemand schon Symbole erstellt? > Ich brauche z.B. einen OpAmp. Aber irgendwie sehe ich z.B. nicht wo ich > die Pins hinzufügen kann. Gibts da einen Trick? Bei horizon werden die Pins eines Bauteils nicht im Symbol definiert, sondern in der Unit: https://github.com/carrotIndustries/horizon/wiki/The-Pool#units Du legst dir also für dein Bauteil eine neue Unit an, trägst dort die Pins ein und legst dann eines oder mehr Symbole dazu an.
Hm. Und wie soll dann ein Bauelement mit z.B. der typischen Varianten 16 Pins als DIP und 20 Pins als SMT definiert werden?
Abdul K. schrieb: > Hm. Und wie soll dann ein Bauelement mit z.B. der typischen Varianten 16 > Pins als DIP und 20 Pins als SMT definiert werden? Da legst du einfach ein zweites Bauteil an.
Angehängte Dateien:
-
to92-freecad.png
28 KB -
to92-horizon.png
2,3 KB
Hallo, diese 3D-Modelle machen mir gerade wahnsinnig. Angehängt sind mal zwei Screenshots. Einmal das Bauteil in FreeCAD und dann das importierte Bauteil in Horizon. Jetzt frage ich mich warum da zwei Beine fehlen und der Ursprung so verschoben ist. Wie muss man denn so ein Bauteil anlegen, damit es passend auf der Platine erscheint? Uwe
Linkes Bild ist auch noch ein Bug drin. Schau dir den Mittelpin oberhalb 0,0,0 an. Da ist er irrtümlich transparent. Sieht zumindest so aus.
Uwe S. schrieb: > . Jetzt frage ich mich warum da zwei Beine fehlen und > der Ursprung so verschoben ist. Wie muss man denn so ein Bauteil > anlegen, damit es passend auf der Platine erscheint? Hast du mir mal die STEP-Datei?
Abdul K. schrieb: > Linkes Bild ist auch noch ein Bug drin. Schau dir den Mittelpin oberhalb > 0,0,0 an. Da ist er irrtümlich transparent. Sieht zumindest so aus. Nö, das ist nur der eingeblendete Koordinatenursprung mit der Z-Achse, die blau dargestellt ist und direkt auf der Oberfläche des Anschlusses liegt.
Uwe S. schrieb: > Hier ist mal step Datei. Hab ich's mir doch schon fast gedacht, dass ich noch die Platzierung von Unterobjekten berücksichtigen muss. Mit den Modellen, die ich so in der Hand hatte, ging's auch ohne... Ist in https://github.com/carrotIndustries/horizon/commit/514027b3e9bb108b38b51016c16a1b363ac9ed28 repariert.
Lukas K. schrieb: > Uwe S. schrieb: >> Hier ist mal step Datei. > > Hab ich's mir doch schon fast gedacht, dass ich noch die Platzierung von > Unterobjekten berücksichtigen muss. Mit den Modellen, die ich so in der > Hand hatte, ging's auch ohne... > > Ist in > https://github.com/carrotIndustries/horizon/commit/514027b3e9bb108b38b51016c16a1b363ac9ed28 > repariert. Perfekt, damit läuft es. Danke. Uwe
Lukas, ich muss mal sagen: die Geschwindigkeit, in der du Patches bereitstellst und einbaust, sollte jeden kommerziellen Hersteller vor Neid erblassen lassen. Meinen allergrößten Respekt dafür!
Max G. schrieb: > Lukas, ich muss mal sagen: die Geschwindigkeit, in der du Patches > bereitstellst und einbaust, sollte jeden kommerziellen Hersteller vor > Neid erblassen lassen. Das geht nur, solange man kein kommerzieller Hersteller ist und größtenteils alleine daran arbeitet :) > Meinen allergrößten Respekt dafür! Ja, von mir auch! :)
Nochmal was zum Thema Step-Dateien. Kicad hat bereits eine ordentliche Menge Step-Dateien, die ich punktuell versucht habe einzubinden. Grundsätzlich kein Problem, nur die Ausrichtung des Packages und des 3d-Modells passt oft nicht zusammen. Bei dem besagten TO-92 hatte ich den Ursprung auf den mittleren Pin gelegt. Das 3D-Modell aus Kicad legt den Ursprung aber auf einen der äußeren Pins. Wenn ich jetzt das Package passend verschiebe dann zerreißt es mir die Boards, die dieses Packages bereits verwenden. Sicher ich könnte auf das Update des Pools im Projekt verzichten, aber grundsätzlich wird man immer wieder, nicht zu einander passende 3D-Modelle und Packages haben. Könnte man bei der Zuordnung des 3D-Modells zum Package nicht eine Verschiebung und Rotation des 3D-Models angegeben, die das Modell dann zurecht rückt? Uwe
@Uwe: Ich hatte das schon angefragt, es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. https://github.com/carrotIndustries/horizon/issues/61
Michael H. schrieb: > es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. Wenn man mal davon ausgeht, dass man heutzutage STEP-Dateien oft direkt vom Hersteller bekommt, finde ich das nicht so gut. Bei selbst erzeugten ist das sicher was anderes.
Michael H. schrieb: > @Uwe: Ich hatte das schon angefragt, es kam allerdings die Antwort, man > solle es in der STEP-Datei ändern. > https://github.com/carrotIndustries/horizon/issues/61 Ok. Das halte ich aber auch für unglücklich, weil man bei der Menge an bestehenden Step-Dateien kaum noch davon profitieren kann, wenn man die alle anpassen muss. Aber letztlich muss dass natürlich Lukas entscheiden.
Jörg W. schrieb: > Michael H. schrieb: >> es kam allerdings die Antwort, man solle es in der STEP-Datei ändern. > > Wenn man mal davon ausgeht, dass man heutzutage STEP-Dateien oft > direkt vom Hersteller bekommt, finde ich das nicht so gut. Eben bei denen, die von Herstellern kommen, liegt der Ursprung oft im nirgendwo und die Rotation passt auch überhaupt nicht. Sowas behebt man besser in einem anständigen MCAD-Programm wie FreeCAD, anstatt in horizon nach Augenmaß Nummern einzutragen. In Freecad z.B. ist es einfach möglich, das Modell so zu verschieben, dass dessen Unterseite genau bei z=0 liegt. Uwe S. schrieb: > Ok. Das halte ich aber auch für unglücklich, weil man bei der Menge an > bestehenden Step-Dateien kaum noch davon profitieren kann, wenn man die > alle anpassen muss. Bei den Modellen von SMD-Bauteilen, die ich mir so angesehen hatte, hat's gepasst, da dort der Ursprung vom Modell auch in der Mitte liegt. Eine wirkliche Konvention, wo in den Packages der Ursprung liegen soll fehlt noch. Bei Kicad ist's für alles was nicht Through hole ist der Mittelpunkt vom Bauteil und bei TH im Mittelpunkt von Pin 1, was sich auch so in den 3D-Modellen widerspiegelt. Mir persönlich gefällt das nicht so wirklich. Um die Through Hole-Modelle von KiCad verwenden zu können, ist es durchaus sinnvoll, Verschiebung/Rotation eintragen zu können, nur hat man dann wieder das Problem, dass Leute anstatt im MCAD nachzumessen und die Werte daraus zu übernehmen, einfach so lange an den Knöpfen drehen werden, bis es optisch passt.
Lukas K. schrieb: > Um die Through Hole-Modelle von KiCad verwenden zu können, ist es > durchaus sinnvoll, Verschiebung/Rotation eintragen zu können, nur hat > man dann wieder das Problem, dass Leute anstatt im MCAD nachzumessen und > die Werte daraus zu übernehmen, einfach so lange an den Knöpfen drehen > werden, bis es optisch passt. Dann habe ich mir in der Tat die Problemfälle rausgesucht. Ich kann durchaus verstehen, dass hier eine einheitlich Vorgehensweise besser wäre (z.B. den Ursprung auf Pin 1 oder den linken Pin (bei horizontaler Ausrichtung) zu legen). Ist halt blöd, wenn man einen ganzen Schwung 3D-Modelle und Packages hat, die nicht zusammen passen und beides aus Quellen kommt, die möglicherweise noch Änderungen vornehmen. Wenn ich die Kicad-Modelle anpasse, werde ich mögliche Korrekturen darin vermutlich nicht mehr übernehmen können. Folglich muss ich meine Packages in Horizon anpassen und das bedeutet Nacharbeiten in den bereits erstellten Boards. Zur Zeit noch überschaubar, kann aber ziemlich viel Arbeit bedeuten. Uwe
Und genau aus dem Grund ist es üblich eigentlich alles selber neu anzulegen bzw. nach eigenen Vorgaben externe dafür zu beauftragen. Eigentlich ein Witz, denn in DE sind ja sogar die Schaltsymbole in den Schaltplänen zu großen Teilen genormt. Nur die wenigsten halten sich dran. Vielleicht verändert sich das mal irgendwann. In den letzten 40 Jahren war dieser Zeitpunkt aber nie erreicht. Vielleicht liegt es an der Neumodigkeit von Elektronik, den vielen Individualisten in diesem Feld oder weil im Bereich Elektronik einfach noch <zu> viel Geld für Spezialgänge vorhanden ist.
> denn in DE sind ja sogar die Schaltsymbole in den Schaltplänen zu großen Teilen
genormt.
Nur finden alle Firmen außerhalb Deutschlands diese Symbole nicht
überzeugend. Deshalb werden die sich international auch nie durchsetzen.
Deshalb sollte sich Lukas an internationale Geflogenheiten orientieren.
International würde ich das nicht nennen, eher amerikanisch. Vielleicht in Zukunft auch chinesisch. Zeichnet sich ja jetzt schon deutlichst ab. Z.B. Datenblätter in chinesisch-only.
Abdul K. schrieb: > Und genau aus dem Grund ist es üblich eigentlich alles selber neu > anzulegen bzw. nach eigenen Vorgaben externe dafür zu beauftragen. Ich habe aber dabei noch niemanden (im industriellen Umfeld) gesehen, der sich seine eigenen 3D-Modelle gezimmert hat. Klar baut sich jeder seine Bauteile selbst, aber die 3D-Modelle sind nur dann dabei, wenn man sie irgendwoher bekommen kann: bei einfachen Dingen (Standard-Hühnerfutter) schon auch gut und gern mal aus dem EDA-Tool, bei spezielleren Bauteilen halt die vom Hersteller. Helmut S. schrieb: > Nur finden alle Firmen außerhalb Deutschlands diese Symbole nicht > überzeugend. Falls du die IEC-Symbole meinst: die sind nicht einmal deutsch, sondern international. ;-) Die BRD hat sie sogar relativ spät in die eigene Norm übernommen, im Ostblock sind sie kurz nach ihrer Normierung durch die IEC offiziell übernommen worden (und auch tatsächlich benutzt, sowohl von den Fachzeitschriften als auch in der Industrie). Aber da, wo man Entfernungen immer noch mit Daumen und Füßen misst, wird auch das wohl noch ein bisschen dauern … Ist aber hier egal, hier geht's ja um die Anpassungen, die Horizon gewillt ist, an einem 3D-Modell vorzunehmen. Lukas K. schrieb: > nur hat man dann wieder das Problem, dass Leute anstatt im MCAD > nachzumessen und die Werte daraus zu übernehmen, einfach so lange an den > Knöpfen drehen werden, bis es optisch passt. Sagen wir mal so: solange das einer für sich privat macht und nur „ungefähr“ ein Gefühl bekommen will, wie's am Ende aussieht, finde ich das auch OK. Ob das Modell da noch einen Zehntelmillimeter daneben sitzt, interessiert dafür kaum. In den offiziellen Pool würde ich es natürlich so nicht übernehmen. Nicht jeder will sich unbedingt auch noch privat mit einem 3D-MCAD befassen müssen (wenngleich das natürlich durch des Ingenieurs neues Spielzeug, den 3D-Drucker allmählich ohnehin mehr werden, die es tun :).
3D ist sicherlich ein neuer Trend. Liegt ja auch daran, daß ein dortiges "Symbol" doch deutlich aufwändiger zu erstellen ist als ein planes Schaltplansymbol.
Abdul K. schrieb: > Eigentlich ein Witz, denn in DE sind ja sogar die Schaltsymbole in den > Schaltplänen zu großen Teilen genormt. Nur die wenigsten halten sich > dran. Das Problem an den Normen ist, dass sie in den 70ern stehen geblieben sind bzw. darauf aufbauen, das elektronische Schaltungen wie Schaltschränke aus genormten und austauschbaren Bauteilen bestehen. Dass heutzutage fast jede Schaltung in irgendeine Art proprietäre Bauteile wie Mikrocontroller, FPGAs oder Schaltregler beinhaltet ist in den Normen nicht wirklich reflektiert. Daher muss besser früher als später ein verbindlicher Satz an Regeln her, um Diskussionen wie diese hier https://github.com/carrotIndustries/horizon-pool/pull/11 abzukürzen. Die KiCad library convention ist da schonmal ein guter Startpunkt. Abdul K. schrieb: > 3D ist sicherlich ein neuer Trend. Kommt drauf an. Für den Hobbyisten vielleicht, da kann das Projekt schon fertig sein, wenn das Board funktioniert. In der Industrie hingegen ist es ja üblich, Boards in Gehäuse einzubauen. Mit einem Gehäuse, das irgendwie lose mit vielen Kabeln um das Board zusammengeschustert ist gewinnt man da keinen Blumentopf mehr, man will das Board mit den darauf befindlichen Bauteilen aus dem ECAD ins MCAD exportieren können, damit das Gehäuse genau zum Board passt. In Zeiten von 3D-Druckern auch für Hobbyisten umsetzbar. Jörg W. schrieb: > Nicht jeder will sich unbedingt auch noch privat mit einem 3D-MCAD > befassen müssen Ich werde kein Package ablehnen, nur weil es kein 3D-Modell enthält. Besser gibt keines als ein nach Augenmaß positioniertes.
Hinsichtlich der 3D Diskussion: Ich von meiener Seite habe mir gesagt, das es schön gewesen wäre. Allerdings reicht es meistens schon aus, sich die STEPs von KiCad rüberzuziehen. Wenn da welche sind, dann gut, wenn nicht, halt kein 3D Model. (Sieht für meinen Zweck halt schön aus, allerdings für mich nicht überlebenswichtig...) Ich bin im Moment dabei in freien minuten Bauteile zu erstellen, sodass man eine Grundlage bekommt, schnell loslegen zu können. Ich denke, das Program hat Potential.
Gute Nachrichten für alle Windows-Nutzer hier: Es gibt jetzt automatische Builds mit appveyor: https://ci.appveyor.com/project/carrotIndustries/horizon/history Bei "Artifacts" ist dann die Zip-Datei.
Hab den Thread vor einigen Wochen mal durchgelesen. Ich freue mich auf die erste Beta-Version. :) Ein paar Fragen zu den Funktionen hätte ich da, ob es diese gibt oder geplant sind (und falls nicht, betrachtet dies bitte als Anregung/freundliche Anfrage dies zu integrieren): Bauteilerstellung: -Ist es möglich, Bauteile aus Datenbanken oder Tabellen (Excel) heraus zu erstellen? Ich hab damit unlängst massenhaft Bauteile mit einem Script erstellt, die zwar dasselbe Schaltplansymbol und denselben Footprint gemeinsam hatten, in Details wie Bauteilwert, Herstellerbezeichnung, usw. aber unterschiedlich waren. Einen Skriptinterpreter zu integrieren wäre auch super, der Aufwand würde aber vermutlich völlig ausarten... -Wie sieht es mit der Pin-Pad-Zuordnung aus..kann man da einem Pin im Schaltplan mehrere Pads im Layout zuordnen ohne das es Ärger geben könnte? Bei SMD-Transostoren, Motortreibern und generell Leistungs-ICs wäre das oft sehr nützlich. (In Altium ist dieser Punkt übrigens eine Katastrophe, es gibt da zwar Workarounds, meines Erachtens aber keine wirkliche Lösung.) -Wie siehts mit BOM-Erstellung aus: Kann Horizon Bauteile wie folgt darstellen: Schaltplan ja, Footprint ja, BOM nein (z.B. Layoutsicherung) Schaltplan nein, Footprint nein, BOM ja (Befestigungsmaterial) Schaltplan nein, Footprint ja, BOM bedingt (Drahtbrücken, und in der BOM taucht der Draht entweder gar nicht auf, oder wieviel Draht insgesamt benötigt wird) Schaltplanerstellung: -Benamsung von Netzen: Kann Horizon die Folge LCD-0, LCD-1, LCD-2, ... automatisch fortsetzen? -Schaltplanseiten automatisch kopieren (ich erstelle einmal eine bestimmte Seite, definiere die Anzahl, und Horizon verwaltet die Kopien), und das gleiche Spiel beim Layout, ich route eine solche Seite und Horizon übernimmt das Routing für alle anderen Seiten? Ich spiele auf die Multi-Channel-Funktion in Altium an, die ich gerne nutze, allerdings fehlen da meines Erachtens ein paar Dinge: z.B. daß bestimmte Bauteilparameter zu jeder Kopie variieren können. Eine Frage hätte ich noch an den Chef der Karottenindustrie: Mit welchen EDA-Programmen hast du denn bisher so Erfahrung gesammelt? Das soll es erstmal vorläufig sein...mir fällt nach der ersten Beta-Version bestimmt noch mehr ein. ;) Ich kenne KiCad nicht aus eigener Benutzung und will es nicht kritisieren, aber ich finde es gar nicht so verkehrt wenn es da künftig noch freie Alternative gibt. Und es tut den großen Firmen wie Mentor und Altium auch gut, etwas Konkurrenz auch aus dem OSS-Sektor zu bekommen (keine Ahnung ob das zum Anspruch von Horizon zählt, aber ich unterstütze das gerne).
Wühlhase schrieb: > Einen > Skriptinterpreter zu integrieren wäre auch super, der Aufwand würde aber > vermutlich völlig ausarten... Warte ab - übermorgen zur selben Zeit hat Lukas sicherlich Lua eingebaut xD
Wühlhase schrieb: > Hab den Thread vor einigen Wochen mal durchgelesen. Ich freue mich auf > die erste Beta-Version. :) Damit es eine Beta gibt, müsste es ja auch mal ein Release geben. Keine Ahnung wann da die rechte Zeit für ist. Obwohl man derzeit schon halbwegs bequem Schaltplan / Board entwickeln und Bauteile verwalten kann, fehlen noch einige wichtige Funktionen wie z.B. BOM-Export. Ich müsste mich wohl mal hinsetzen und definieren, was alles es alles für Version 0.1 braucht. > Ein paar Fragen zu den Funktionen hätte ich da, ob es diese gibt oder > geplant sind (und falls nicht, betrachtet dies bitte als > Anregung/freundliche Anfrage dies zu integrieren): > > Bauteilerstellung: > -Ist es möglich, Bauteile aus Datenbanken oder Tabellen (Excel) heraus > zu erstellen? Ich hab damit unlängst massenhaft Bauteile mit einem > Script erstellt, die zwar dasselbe Schaltplansymbol und denselben > Footprint gemeinsam hatten, in Details wie Bauteilwert, > Herstellerbezeichnung, usw. aber unterschiedlich waren. Dazu können Parts voneinander erben, man legt einmal sein Basis-Bauteil an und kann dann in einer Skriptsprache eigener Wahl die Parts aus welcher Quelle auch immer zu erzeugen. Die Parts sind wie der Rest auch json. z.B. https://github.com/carrotIndustries/horizon-pool/pull/6/commits/8b69df90e621348b8fa3ff98b1a379c964a08088 > -Wie sieht es mit der Pin-Pad-Zuordnung aus..kann man da einem Pin im > Schaltplan mehrere Pads im Layout zuordnen ohne das es Ärger geben > könnte? Ja! Einfach im Part-Editor bei einen Pin mehrere Pads auswählen und auf "Map" klicken. > -Wie siehts mit BOM-Erstellung aus: Kann Horizon Bauteile wie folgt > darstellen: > Schaltplan ja, Footprint ja, BOM nein (z.B. Layoutsicherung) Nein, aber einfach implementierbar > Schaltplan nein, Footprint nein, BOM ja (Befestigungsmaterial) Nein, auch einfach machbar > Schaltplan nein, Footprint ja, BOM bedingt (Drahtbrücken, und in der BOM > taucht der Draht entweder gar nicht auf, oder wieviel Draht insgesamt > benötigt wird) Nein, auch nicht einfach machbar, da alles was es auf dem Board gibt aus der Netzliste kommen muss. Zur BOM-Erstellung gibt es derzeit genau nichts. War mir persönlich noch nicht wichtig genug und du bist auch der Erste der danach fragt. Ich bin mir noch unsicher wie die genau geraten sein soll. Einen Dialog mit einer Vielzahl von Optionen, wie sie so manche kommerzielle Software bietet ist mir zu viel Aufwand: - XSLT wie KiCad: horizon gibt XML aus, XSLT macht CSV, etc draus. Vorteil: Kann gut integriert werden. Nachteil: Es gibt schönere Dinge als XSLT - JSON: Der Anwender schreibt in Skript in seiner Lieblingssprache, das macht dann daraus das gewünschte Format. Funktioniert allerdings nur auf Unixen wirklich sinnvoll. Andere/Bessere Vorschläge? > Schaltplanerstellung: > -Benamsung von Netzen: Kann Horizon die Folge LCD-0, LCD-1, LCD-2, ... > automatisch fortsetzen? Nein, es gibt aber Busse. Bis jetzt sind diese mehr auf serielle Busse wie SPI oder I²C ausgelegt. > -Schaltplanseiten automatisch kopieren (ich erstelle einmal eine > bestimmte Seite, definiere die Anzahl, und Horizon verwaltet die > Kopien), und das gleiche Spiel beim Layout, ich route eine solche Seite > und Horizon übernimmt das Routing für alle anderen Seiten? > Ich spiele auf die Multi-Channel-Funktion in Altium an, die ich gerne > nutze, allerdings fehlen da meines Erachtens ein paar Dinge: z.B. daß > bestimmte Bauteilparameter zu jeder Kopie variieren können. Das hatte ich vor mit Hierarchie zu erschlagen, ist aber noch in mehr oder minder ferner Zukunft. > Eine Frage hätte ich noch an den Chef der Karottenindustrie: Mit welchen > EDA-Programmen hast du denn bisher so Erfahrung gesammelt? EAGLE, KiCad, LTSpice und ein bisschen Mentor Graphics Expedition im professionellen Umfeld. Leider hatte ich noch nie wirklich die Gelegenheit sinnvoll mit Altium zu arbeiten, habe ich doch vergleichsweise viel gutes davon gehört. Einige Aspekte von horizon, wie z.B. die Design-Regeln sind von Altium inspiriert. Mampf F. schrieb: > Warte ab - übermorgen zur selben Zeit hat Lukas sicherlich Lua eingebaut > xD Ich hatte da auch mal drüber nachgedacht, war mir aber den Aufwand nicht wirklich wert, müsste man doch eine halbwegs stabile API bereitstellen.
Danke...das klingt doch schon mal gar nicht so schlecht. :) Vor allem wie du das Pinmapping beschreibst klingt in meinen Ohren sehr gut. Ich hab eben nochmal die 3D-Diskussion kurz überflogen-sehr schön, daß das in Horizon mit drin ist. Ohne 3D würde ich auch nicht mehr arbeiten wollen. Zur Positionierung: In Altium gibt es die Möglichkeit, eine ebene Fläche eines Step-Modells als "Boardberührfläche" zu definieren. Dann wird das Bauteil automatisch so ausgerichtet, daß die Fläche mit der Platinenoberfläche in einer Ebene und orthogonal zur Z-Achse liegt. Zum Ausrichten in der XY-Ebene kann man Snappoints am 3D-Modell hinzufügen, die dann in der 2D-Bearbeitung auch sichtbar sind. Einen Snappoint kann man dann z.B. in der Mitte eines Pins anlegen, und dann in der 2D-Ansicht in das entsprechende Lötauge legen. Vielleicht hilft das bei der Orientierung weiter. Dann hab ich noch ein paar Dinge, die Altium an dieser Stelle leider sehr halbherzig umgesetzt hat und die mich manchmal schon etwas ärgern: -Die 'Face-to-PCB-Funktion' kann nur mit planen Flächen, aber nicht mit runden Flächen. Einen aufrechten Zylinder ausrichten ist kein Problem, aber einen liegenden Zylinder ausrichten (z.B. Melf-Bauteile) geht damit nicht. -Altium findet Snappoints nur an Ecken oder Kanten. Rotationsachsen von rotationsymetrischen erkennt Altium leider nicht (was beim Ausrichten an Pins oft ärgerlich ist). Das mal so als Anregung... Ich hab bisher eigentlich nur mit Altium gearbeitet (wie vielleicht schon aufgefallen ist ;)), ich hab mich vor etlichen Jahren (so 2006 herum) mal zwei Stunden mit Eagle befaßt (das zähle ich nicht als Erfahrung) und danach nur etwas mit Sprint Layout herumgespielt, weil mir Eagle allzusehr mißfallen hat. Von daher ist mein Erfahrungshorizont etwas eingeschränkter als deiner (Expedition würd ich aber gerne mal ausprobieren), allerdings kenne ich Altium dafür recht gut und ich arbeite auch sehr gerne damit. Wenn du wissen wilst wie manches da gelöst ist, vielleicht als Inspiration, kann ich dir gerne was beisteuern. :)
Wühlhase schrieb: > -Die 'Face-to-PCB-Funktion' kann nur mit planen Flächen, aber nicht mit > runden Flächen. Einen aufrechten Zylinder ausrichten ist kein Problem, > aber einen liegenden Zylinder ausrichten (z.B. Melf-Bauteile) geht damit > nicht. > -Altium findet Snappoints nur an Ecken oder Kanten. Rotationsachsen von > rotationsymetrischen erkennt Altium leider nicht (was beim Ausrichten an > Pins oft ärgerlich ist). Genau deshalb meine Empfehlung, die Modelle davor im MCAD richtig auszurichten, denn selbst mit FreeCAD bekommt man das hin. Aktuell gibt es keine sinnvolle Möglichkeit mit den Modellen in der 3D-Vorschau zu interagieren, die STEP-Datei wird eingelesen, Trianguliert und auf die resultierenden Dreiecke auf die GPU geladen, das war's schon. Schön wäre es schon, die Modelle in horizon ausrichten zu können, doch steht das in keiner sinnvollen Relation zum dafür notwendigen Aufwand, damit es auch zufriedenstellend funktioniert.
Lukas K. schrieb: > Schön wäre es schon, die Modelle in horizon ausrichten zu können, doch > steht das in keiner sinnvollen Relation zum dafür notwendigen Aufwand, > damit es auch zufriedenstellend funktioniert. Ein Kompromiss wäre das so zu machen wie in KiCad ... Da kann man mit 6 Textboxen die Rotation und Translation einstellen. Für mich war das immer gut genug. Vlt gibt es ja irgendwann mal die Muse, das dann zu verbessern, aber ich würde sagen, besser als nichts :)
Mindestens die XY-Rotation/Position und die Höhe in der Z-Achse einzustellen wäre schon schön. Anders sind viele 3D-Modelle von 3Dcontentcentral leider nicht zu verwenden und jede Ausrichtung in Horizon mit einem externen Programm macht dies sicher auch nicht gerade zum Vergnügen...
Wühlhase schrieb: > Mindestens die XY-Rotation/Position und die Höhe in der Z-Achse > einzustellen wäre schon schön. Ah und die Skalierung noch ... Also 9 Parameter ... Rotation, Translation, Skalierung :) Oft sind die Models in inch pro Einheit oder mm pro Einheit ... Evtl würde da schon eine Checkbox reichen dann zum umskalieren.
Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein entsprechendes Modell, das Skalierung bedarf, präsentiert.
Lukas K. schrieb: > Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für > 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein > entsprechendes Modell, das Skalierung bedarf, präsentiert. Gerne, davon hab ich dutzende ... Alle Models, die von mir mit OpenScad entworfen wurden haben die falsche Skalierung - oder die richtige, aber KiCad nimmt inch statt mm an. Ich schicke dir morgen etwas.
Ich versuche zur Zeit Symbole hierfür zu erstellen. Was mich hier irgendwie stört, ist das iterative beim Package erstellen. Siehe: https://github.com/carrotIndustries/horizon-pool/pull/20 Könnte man nicht die Regeln genauer definieren, bzw. einen automatischen Test einbauen? Ich glaube, wenn man so oft nachbessern musst, hast Du Lukas keinen Spaß daran die anderen auf Ihre Fehler hinzuweisen, andernseits wirkt es nicht sehr motivierend, wenn man 3 Wochen braucht bis ein Package in der Repo ist... Stell dir mal vor, da kommen 5 heinzel wie ich, die sich genauso dumm anstellen... Da kommt man garnicht mehr nach.
Hallo Mampf. Mampf F. schrieb: > Oft sind die Models in inch pro Einheit oder mm pro Einheit ... Evtl > würde da schon eine Checkbox reichen dann zum umskalieren. Eine Voreinstellung für "inch oder mm" Anpassung wäre eine feine Optimierung. Trozdem ist eine individuelle Einstellung nötig, weil auch Modelle kursieren, wo sich jemand beim Umrechenen mm vs. inch und retour vertan hat. Sei es das er Multiplikation mit Division verwechselt hat, oder aber einen falschen Faktor verwendet hat, oder als Längeneinheit preußische Lachter verwendet hat. Mit freundlichem Gruß: Bernd wiebus alias dl1eic http://www.l02.de
Lukas K. schrieb: > Sodele, seit soeben gibt es es X/Z/Z-Offset und Roll/Pitch/Yaw für > 3D-Modelle. Skalierung kommt dann vielleicht noch, wenn mir jemand ein > entsprechendes Modell, das Skalierung bedarf, präsentiert. Hui, schön wie schnell das geht... :) Wie gesagt, ich freue mich auf das erste Beta-Release.
Michael H. schrieb: > Stell dir mal vor, da kommen 5 heinzel wie ich, die sich genauso dumm > anstellen... Da kommt man garnicht mehr nach. Andere haben es ja hinbekommen, auf Anhieb nahezu Perfekte Symbole, Packages etc. abzuliefern, siehe https://github.com/carrotIndustries/horizon-pool/pull/7 Ja, genauer spezifizierte Regeln braucht's noch, wobei ich auch erwarte, dass sich Leute an bereits vorhandenem orientieren. Wenn ein Vierfach Und-Gatter im Pool "Quad AND Gate" heißt, dann ist es doch naheliegend einen Einzel-Opamp "Single Operational Amplifier" oder "Single Opamp" zu nennen, oder? Selbes für die Namen/Prefixe von Gates, etc. Einfach gucken wie es nebendran gemacht ist und nachmachen.
Lukas K. schrieb: > Wenn ein Vierfach Und-Gatter im Pool "Quad AND Gate" heißt, dann ist es > doch naheliegend einen Einzel-Opamp "Single Operational Amplifier" oder > "Single Opamp" zu nennen, oder? Sollte man das "Single" vielleicht doch weglassen? Einen einzelnen Transistor nennt man ja auch nicht "Single Transistor", obwohl es durchaus auch dort "Dual Transistor" gibt.
1 und 4 davor wäre vielleicht schön kompakt.
Selbst dann würde ich die 1 weglassen, sonst müsstest du dann auch "1 Resistor", "1 Capacitor" etc. schreiben (es gibt ja schließlich auch Widerstandsarrays). Ist natürlich Lukas' Sache, welche Richtlinien er herausgibt, und wichtiger noch als die genauen Richtlinien ist, dass sie konsequent befolgt werden.
Und da wären wir beim Thema, es gibt tausend Möglichkeiten, und tausend Geschmacksrichtungen =) Desshalb sagte ich ja, finde ich ein gemeinsames Repository immer schwer. Was hier gut wäre, ist eine Checklist zum Abhaken, am besten wenn das Programm es durchcheckt, für die ganz doofen unter uns. Nur damit bekommt man imho einen Standard rein, und bekommt die Geschmacksvarianzen in Griff. Eine Sache, die ich zum Beispiel sinnvoll finde, ist das Power Gate "Z" zu nennen, da es immer das letzte sein sollte. Und so weiß man, das jedes Power immer Z heißt. Aber das ist deine Entscheidung. Wie gesagt, klare regeln, insbesondere super-verständlicht, und mit vielen Bildern würden hier extrem weiterhelfen.
Hallo Possetitjel. Possetitjel schrieb: > Kompatible DATEIFORMATE setze ich eigentlich voraus; notfalls > tut's ein funktionierender Export/Import. > > Aber genau DAS ist ja offensichtlich nicht gegeben. Da machen sich aber Leute schon einen Kopf drum: https://lists.launchpad.net/kicad-developers/msg33357.html Mit freundlichem Gruß: Bernd wiebus alias dl1eic http://www.l02.de
Angehängte Dateien:
-
remote-update.PNG
52 KB
Benötige ich einne Github-login um einen remote "upgrade-pool" meines lokalen "pools" zu machen? Siehe screenshot.
Hallo, wie bereits vor einiger Zeit erwähnt stellt Lukas "horizon" am Samstag auf der FOSDEM in Brüssel vor. https://fosdem.org/2018/schedule/track/cad_and_open_hardware/ Gruß Helmut
Bug-Report Die Programme in der aktuellen Version auf appveyor.com "horizon-2018-02-01-0021.zip" funktionieren nicht in WIN10. Wenn man die Programme startet, dann passiert einfach nichts. Die vorletzte Version (31.1.2018?) ging noch. Wenn ich die source mit mysys2 selber kompiliere funktionien die Programme.
Helmut S. schrieb: > Benötige ich einen Github-login um einen remote "upgrade-pool" meines > lokalen "pools" zu machen? > Siehe screenshot. Es funktioniert auch (wieder) ohne login. Entweder hatte ich etwas falsch gemacht oder jemand hat es gerichtet. Danke.
Hallo, hier mal der Entwicklungsstand und Ausblick auf zukünftige Funktionen von horizon basierend auf den Slides die Lukas auf der FOSDEM gezeigt hat. https://fosdem.org/2018/schedule/event/cad_horizon/attachments/slides/2286/export/events/attachments/cad_horizon/slides/2286/presi.pdf What's working Workflow from schematic to board Interactive router Pool management with GitHub integration Gerber export Planes with thermals Differential Pairs Buses 3D preview, STEP export Airwires Undo/Redo Copy/Paste DRC (Design rules and checks) Coming soon Pool Convention (WIP) UI polish Assembly drawings Title blocks BOM export ERC Hierachical designs Better PDF export Performance Link auf das Projekt in Github https://github.com/carrotIndustries/horizon Helmut
>Das Problem an den Normen ist, dass sie in den 70ern stehen geblieben >sind bzw. darauf aufbauen, das elektronische Schaltungen wie >Schaltschränke aus genormten und austauschbaren Bauteilen bestehen. Vor kurzem kam mal ein Radiobeitrag zur DIN-Normungs Komission. Tatsächlich ist das eine private Instituion und theoretisch kann jeder Privatmann einen Vorschlag zur Normung von Irgendwas einwerfen. Die meisten größeren Elektronikfirmen haben in ihren PCB-Abteilungen Leute, die nichts anders machen als Bauteile anlegen. Ich halte das für eine völlige Blindleistung. Das Ideal wäre, man bekommt die Designdaten fertig vom Hersteller inclusive der 3D-Daten und keiner muss in irgendwelchen CAD-Programmen Bauteile neu anlegen. Ginge alles, wenn es eine einheitlich Norm für das Datenformat gäbe.
Hallo Chris. chris schrieb: > Ich halte das für eine völlige Blindleistung. Das Ideal wäre, man > bekommt die Designdaten fertig vom Hersteller inclusive der 3D-Daten und > keiner muss in irgendwelchen CAD-Programmen Bauteile neu anlegen. Das würde so auch nur in 80% aller Fälle funktionieren. Weil viele eben halt eine eigene Interpretation vom idealen Footprint haben. In einer Firma, wo ich einmal gearbeitet habe, wurden z.B. die Bohrungen aller THT Bauteile gegenüber der Originalbibliothek des Layoutprogrammes vergrößert. In einer anderen Firma wurden für bestimmte Anschlüsse extragrosse Pads verwendet.... Aber eine solche Bibliothek könnte zur Konstruktion von angepassten Varianten verwendet werden. Mal abgesehen davon, das Tom Hausherr vorschlägt, für unterschiedlich dichte Layouts unterschiedliche Footprints für das gleiche Bauteil zu verwenden. Möglichst grob für robustes Design, wenn der Platz langt, aber feiner werdent, wenn der zur Verfügung stehende Platz kleiner wird. http://www.innofour.com/3783/news/literature/pcb-design-perfection-starts-in-the-cad-library/pcb-design-perfection-starts-in-the-cad-library-part-1 Teil 1. Teil 2 und folgende gibt es hier: https://blogs.mentor.com/tom-hausherr/blog/2010/09/22/pcb-design-perfection-starts-in-the-cad-library-part-2/ > Ginge > alles, wenn es eine einheitlich Norm für das Datenformat gäbe. Was hälst Du von Snapeda oder dem Digikey Ansatz? https://www.snapeda.com/ https://www.digikey.de/de/news/press-releases/2017/aug/digi-key-adds-kicad-pcb-model-download Eine einheitliche Norm müsste offen sein, und gut verbreitet. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
So, heute bin ich mal bleeding-edge. Ich wollte horizon auf xubuntu
18.04 beta 1 compilieren. Es kommt die Fehlermedlung "GLM_GTX_transform
is an experimental extension". Gut ein, #define GLM_ENABLE_EXPERIMENTAL
fixed das Problem, wollte das nur mal erwähnen.
In file included from /usr/include/glm/gtx/rotate_vector.hpp:18:0,
from src/canvas3d/canvas3d.cpp:14:
/usr/include/glm/gtx/transform.hpp:23:3: error: #error "GLM:
GLM_GTX_transform is an experimental extension and may change in the
future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you
really want to use it."
# error "GLM: GLM_GTX_transform is an experimental extension and may
change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before
including it, if you really want to use it."
^~~~~
In file included from src/canvas3d/canvas3d.cpp:14:0:
/usr/include/glm/gtx/rotate_vector.hpp:21:3: error: #error "GLM:
GLM_GTX_rotate_vector is an experimental extension and may change in the
future. Use #define GLM_ENABLE_EXPERIMENTAL before including it, if you
really want to use it."
# error "GLM: GLM_GTX_rotate_vector is an experimental extension and
may change in the future. Use #define GLM_ENABLE_EXPERIMENTAL before
including it, if you really want to use it."
^~~~~
Für LINUX: Unter folgendem Link findet ihr ein Flatpak manifest um Horizon als Flatpak Paket zu installieren. Im Moment wird im Manifest auf mein Repository gezeigt, da der Pull request noch offen ist. Um das Flatpak manifest auszuführen, müsst ihr vorher flatpak und flatpak-builder installieren. Sobald ihr diese installiert habt, müsst ihr aus meinem Repo (https://github.com/Murmele/horizon/tree/flatpak) die Datei "net.carrotIndustries.horizon.json" aus dem Pfad ressources/linux/Flatpak herunterladen. Das Paket könnt ihr dann mit den folgenden 3 Befehlen auf eurem Rechner installieren. flatpak-builder --repo=meinRepo --force-clean Horizon net.carrotIndustries.horizon.json flatpak remote-add meinRepo meinRepo --no-gpg-verify flatpak install meinRepo net.carrotIndustries.horizon "meinRepo" ist dabei ein beliebig gewählter Name für ein Repository Ich hoffe ihr könnt es damit einfach installieren :)
Murmele schrieb: > Sobald ihr diese installiert habt, müsst ihr aus meinem Repo > (https://github.com/Murmele/horizon/tree/flatpak) die Datei > "net.carrotIndustries.horizon.json" aus dem Pfad > ressources/linux/Flatpak herunterladen Sorry das ist falsch, ladet den Ganzen Ordner Flatpak runter, da einige Module übersichtshalber in eigene Dateien ausgelagert wurden, welche im Ordner Flatpak/modules zu finden sind
Hier findet ihr das erstellte Flatpak Paket, damit ihr es nicht lange kompilieren müsst: https://www.dropbox.com/s/r4vpml656xio931/HorizonFlatpak.zip?dl=0 Entpackt die Datei und betretet den Ordner. Wenn ihr diese beiden Befehle ausführt, dann wird das Paket installiert. flatpak remote-add meinRepo2 meinRepo2 --no-gpg-verify flatpak install meinRepo2 net.carrotIndustries.horizon Zum deinstallieren: flatpak uninstall net.carrotIndustries.horizon flatpak remote-delete meinRepo2
Angehängte Dateien:
Hallo Lukas, Ich habe mir gerade die neueste Windows-Version von horizon heruntergeladen. horizon-2018-04-02-1257.zip Der Pool-mamager horizon-pool-mgr.exe läuft nicht mehr wegen fehlender DLL libbrotildec.dll. Kannst du das beheben? Gruß Helmut
Helmut S. schrieb: > Der Pool-mamager horizon-pool-mgr.exe läuft nicht mehr wegen fehlender > DLL libbrotildec.dll. Bin zwar nicht Lukas, aber brotli ist glaub ich eine Bibliothek mit Kompressionsalgorithmen von Google. Vlt ein Anhaltspunkt, wie du das nachinstallieren könntest.
Helmut S. schrieb: > Kannst du das beheben? Ist im aktuellen Build behoben, libcurl hatte brotli als neue Abhängigkeit bekommen.
ich würde auch mal gerne versuchen die Software zu übersetzen. Allerdings würd ich mich da lieber auf das CMake Build System stürzen. Daher die Frage wie bekomme ich denn diesen Pull Request https://github.com/carrotIndustries/horizon/pull/111 auf meinen Rechner ? Die Frage ist auch ob Lukas K. auch auf CMake umschwenkt ?
Da muss ich W.S. voll zustimmen, die Basics müssen laufen, dann kommen die Spielsachen dran! Und ich sehne gerade nur Spielkram, dabei hatte ich mich so auf das Program gefreut. Ich muss noch ergänzen das die meisten User unfähig sind den Code zu übersetzen. Ich selber kann das auch nur in einer VM machen, weil nur da alle die benötigten Tools drauf sind. Da wäre es recht hilfreich wenn es gelegentlich eine Installation geben würde. VG, Klaus
Super, wenn du eine Installation hast, dann stell die doch mal zur Verfügung. Da würden sich bestimmt viele freuen. Ein Debian-Paket gibt es übrigens seit kurzem in Debian sid.
Windows! Und das ist jetzt auch schon älter. Aber eignetlich ist es doch nicht Sinn und Zweck der User es bereit zustellen. Das Programm will ja weiter kommen und da ist es immer gut Testversion raus zugeben. Es ist zwar nicht SOOOO kompliziert aber es war auch schon für mich eine nervige Sache alles auf den Rechner zubekommen. Es macht halt keinen Spass zig Pakete zuladen nur um entlich mal den Compiler anwerfen zukönnen. Ich stehe immer auf ein Repro laden und Compiler starten, alles andere ist nur nervig. Besser ist nur einen Installer zu laden und zur Sicherheit zugriff auf den Code zu haben, ändern kann ich da sowieso nichts. Na super W.S. hatte auf der 1. Seite unten seinen Kommentar abgegeben und ich wurde mal wieder nicht ans richtige Ende geleitet. Aber sein Kommentar stimmt auch noch Heute!
Hallo Klaus. Klaus schrieb: > Da muss ich W.S. voll zustimmen, die Basics müssen laufen, dann kommen > die Spielsachen dran! Gerade W.S. ist dabei aber ein Problem. Wenn irgendein Tool nur die grundlegenden Funktionen bereitstellt, bemängelt er mangelnde Userfreundlichkeit. ;O) > Und ich sehne gerade nur Spielkram, dabei hatte ich mich so auf das > Program gefreut. Das nächste Problem: Für den einen ist dieses wichtig und jenes Spielkram. Und für den Nächsten, der vorbeikommt, ist es genau umgekehrt. ;O) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
Klaus schrieb: > Aber sein Kommentar stimmt auch noch Heute! Ich will jetzt hier keine Trolle füttern, aber auch keine falschen Tatsachen im Raum stehen lassen: Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" Seit fast 3 Monaten fällt zu jedem commit automatisch ein zip raus, das man sich nur runterladen und auf eine der exe-Dateien mit icon doppelklicken muss. Sub-Sub schrieb: > Die Frage ist auch ob Lukas K. auch auf CMake umschwenkt ? Das mit cmake ist bis auf weiteres auf leider auf Eis: https://github.com/carrotIndustries/horizon/pull/111#issuecomment-375812240
Lukas K. schrieb: > Das mit cmake ist bis auf weiteres auf leider auf Eis: > https://github.com/carrotIndustries/horizon/pull/111#issuecomment-375812240 Das kann ich nicht verstehen. Tatsächlich würde ich nur dann versuchen die SW zu bazuen wenn es auf CMake bassiert.
Das mit "Artifacts" und der Zip-Datei hatte ich übersehen. Mein letztes eigenes Build ist jetzt auch gut 3 Monate alt, werde heute gleich mal die neueste Version testen. Den Download haben die aber gut verseckt, ich wollte schon hier mich beschwerden.
Sub-Sub schrieb: > Tatsächlich würde ich nur dann versuchen die SW zu bazuen wenn es auf > CMake bassiert. Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da drauf sind ohne cmake gebaut.
Bernd K. schrieb: > Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da > drauf sind ohne cmake gebaut. Tatsächlich ? ich hab einen windows Rechner und da bau ich sonst gar nix selber. aber bei dem Horizon würde mich das schon interessieren
Sub-Sub schrieb: > Bernd K. schrieb: >> Dann fahr mal ganz schnell Deinen Rechner runter. 95% der Software da >> drauf sind ohne cmake gebaut. > > Tatsächlich ? ich hab einen windows Rechner und da bau ich sonst gar nix > selber. aber bei dem Horizon würde mich das schon interessieren Mit der Anleitung von der Webseite kann sogar jeder "Nicht-Softwerker" erfolgreich kompilieren. Was will man mehr.
Was will man mehr: Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür.
Zweig schrieb: > Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür. CLion kann nicht mit Projekten zurechtkommen die ihr eigenes Buildsystem mitbringen? Das mag ich kaum glauben, ehrlich jetzt. Immerhin kostet das Ding Geld und soll angeblich ziemlich gut sein. Ein beliebiges existierendes Build-System benutzen zu können halte ich im Jahr 2018 für Stand der Technik bei einer C oder C++ IDE.
tester schrieb: > So, heute bin ich mal bleeding-edge. Ich wollte horizon auf xubuntu > 18.04 beta 1 compilieren. Es kommt die Fehlermedlung "GLM_GTX_transform > is an experimental extension". Gut ein, #define GLM_ENABLE_EXPERIMENTAL > fixed das Problem, wollte das nur mal erwähnen. Bin ich eigentlich der einzige, der dieses Problem hat? Ich wollte gerade eben (mal wieder) einen aktuellen build machen und habe dazu meine Änderung gelöscht (git stash), da canvas3d.cpp aktualisiert werden sollte. Anscheinend ist die "Unverträglichkeit" mit Ubuntu 18.04 beta immer noch drin. Ich habe jetzt im Makefile bei den DEFINES ein "-DGLM_ENABLE_EXPERIMENTAL" ergänzt.
Habe ein ähnlichs Problem, allerdings mit Debian. Wird es da langsam mal fertige executables geben? Dann sonst müsste Ich dem beipflichten: Klaus schrieb: > Ich muss noch ergänzen das die meisten User unfähig sind den Code zu > übersetzen. Ich selber kann das auch nur in einer VM machen, weil nur da > alle die benötigten Tools drauf sind.
Bernd K. schrieb: > Zweig schrieb: >> Das ganze in Clion einbinden. Ich hab da eine Lizenz dafür. > > CLion kann nicht mit Projekten zurechtkommen die ihr eigenes Buildsystem > mitbringen? Das mag ich kaum glauben, ehrlich jetzt. Immerhin kostet das > Ding Geld und soll angeblich ziemlich gut sein. Ein beliebiges > existierendes Build-System benutzen zu können halte ich im Jahr 2018 für > Stand der Technik bei einer C oder C++ IDE. Daran sieht man das du in dem Bereich keine Ahnung hast. Clion kann nur mir CMake Dateien. Eine moderne Entwicklung würde ich ausschließlich mit cmake durchführen. Der Grund ist noch nicht einmal Clion sondern eher die Features von cmake. cmake ist ein Build „Generator“ mit dem sich make und Projekt Dateien für verschiedene Entwicklungs Umgebungen generieren lassen. Sogar Microsoft Visual Studio wird unterstützt. Und es kann auch alle Abhängigkeiten zu anderen Paketen auflösen.
Zweig schrieb: > Eine moderne Entwicklung würde ich ausschließlich mit cmake durchführen. Tja, als nächstes kommt dann die SCons-Fraktion und stellt fest, dass sie eine „moderne Entwicklung“ ausschließlich mit SCons durchführen würde … Leute, das ist bislang einfach mal Lukas' Entscheidung, und eine Diskussion über eine Änderung des Buildsystems in diesem Thread ist müßig.
Jörg W. schrieb: > Leute, das ist bislang einfach mal Lukas' Entscheidung, und eine > Diskussion über eine Änderung des Buildsystems in diesem Thread ist > müßig. Da hast du völlig Recht!!! Mir ist halt durch den Kopf gemurmelt ein Import für Eagle Dateien hinzuzufügen..., mal sehen ...
Markus W. schrieb: > Habe ein ähnlichs Problem, allerdings mit Debian. Wird es da langsam mal > fertige executables geben? Jemand der Zeit hat könnte ja mal den Buildvorgang dockerisieren, am besten so daß alles statisch gelinkt wird.
Zweig schrieb: > Daran sieht man das du in dem Bereich keine Ahnung hast. Clion kann nur > mir CMake Dateien. Was hat das mit "Bereich keine Ahnung" zu tun wenn irgendeine kommerzielle IDE ein grundessentielles Feature nicht gebacken bekommt, dann kommt sie halt auch weiterhin nicht in die engere Wahl solange sie nicht mit 99% der existierenden Projekte zurecht kommt, so einfach ist das.
tester schrieb: > Ich habe jetzt im Makefile bei den DEFINES ein -DGLM_ENABLE_EXPERIMENTAL" ergänzt. Das liegt daran, dass Ubuntu 18.04 (ob beta oder final ist egal) glm 0.9.9 verwendet, und dort ist das feature "GLM_GTX_transform" halt nur via GLM_ENABLE_EXPERIMENTAL verfügbar. Bleibt die Frage an Lukas, warum man das nicht ins Makefile einbauen kann?
tester schrieb: > Bleibt die Frage an Lukas, warum > man das nicht ins Makefile einbauen kann? Muss ich wohl übersehen haben, ist jetzt drin.
Angehängte Dateien:
Hallo Lukas, der horizon-pool-mgr.exe bringt eine Fehlermeldung, weil in der neuesten Version für Windows mindestens eine DLL fehlt. Siehe Anhang. Gruß Helmut
Helmut S. schrieb: > Version für Windows mindestens eine DLL fehlt. Ist repariert. Wie auch letztes Jahr gibt's auch dieses Jahr auf der Gulaschprogrammiernacht einen Vortrag von mir zu horizon: https://entropia.de/GPN18:Fahrplan#Samstag.2C_12.05.2018 Samstag 19:00
Lukas K. schrieb: > Helmut S. schrieb: >> Version für Windows mindestens eine DLL fehlt. > > Ist repariert. > Hallo Lukas, danke für die jetzt mitgelieferte DLL. > Wie auch letztes Jahr gibt's auch dieses Jahr auf der > Gulaschprogrammiernacht einen Vortrag von mir zu horizon: > https://entropia.de/GPN18:Fahrplan#Samstag.2C_12.05.2018 Samstag 19:00 https://entropia.de/GPN18:horizon_EDA_-_ein_Jahr_sp%C3%A4ter Dem versprochenen Inhalt nach könnte das ein Ersatz für ein "user manaual" werden. Wird das ein live stream und/oder wird es eine Aufzeichnung geben die man später herunterladen kann? Gruß Helmut
Helmut S. schrieb: > Wird das ein live stream und/oder wird es eine Aufzeichnung geben die > man später herunterladen kann? Jep, C3VOC sei dank: Stream gibt's auf https://streaming.media.ccc.de/gpn18 und recordings landen dann auf https://media.ccc.de/
... und hier direkt von der media.ccc.de Seite https://media.ccc.de/v/gpn18-136-horizon-eda-ein-jahr-spter
Ich habe mir heute das Repository „horizon.git“ geholt und mit make kompiliert. Nach dem Aufruf des Linkers gab es keine weiteren Meldungen von make. Es sind einige ausführbare Dateien entstanden, die sich auch ausführen lassen. Alle starten. Alle ausser horizon-pool-mgr zeigen keine GUI bevor sie abstürzen. horizon-pool-mgr kann das pool-Repository herunterladen und eine Datenbank anlegen, und stürtzt dabei erst ab. (Mit der Option --help funktionieren alle Programme wie man es erwartet oder tun gar nichts.) Hier die Ausgabe in der Konsole:
1 | tuxpilot@elf:~/horizon/horizon$ ./horizon/horizon-pool-mgr |
2 | |
3 | (horizon-pool-mgr:18103): dbind-WARNING **: 04:52:45.566: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files |
4 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description, FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages on packages.uuid. parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
5 | SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, GROUP_CONCAT(tags.tag, ' '), parts.filename, parts.description, FROM parts LEFT JOIN tags ON tags.uuid = parts.uuid LEFT JOIN packages on packages.uuid. parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) GROUP BY parts.uuid ORDER BY parts.MPN COLLATE naturalCompare ASC |
6 | gl error 1282 in src/canvas/canvas_gl.cpp: 138 |
7 | Aborted (core dumped) |
8 | tuxpilot@elf:~/horizon/horizon$ ./horizon-imp -y |
9 | terminate called after throwing an instance of 'std::out_of_range' |
10 | what(): vector::_M_range_check: __n (which is 0) >= this->size() (which is 0) |
11 | Aborted (core dumped) |
12 | tuxpilot@elf:~/horizon/horizon$ ./horizon-pool-update-parametric |
13 | created db from shema |
14 | terminate called after throwing an instance of 'std::runtime_error' |
15 | what(): unable to open database file |
16 | Aborted (core dumped) |
Ich habe Lubuntu 18.04 LTS (alternate, 64 Bit) in einer VirtualBox. Da habe ich mit aptitude die Pakete installiert, die in https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Linux aufgezählt sind, das Repository geklont, und make aufgerufen. g++ -v schreibt: gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3) Kompiliert habe ich mit folgender angepasster Zeile im Makefile, da (zumindest in Ubuntu 18.04) einige header-Dateien in Unterverzeichnissen von /usr/include landen, wo der Compiler sie nicht findet.
1 | INC = -Isrc -I3rd_party -I/usr/include/uuid/ -I/usr/include/glib-2.0/ -I/usr/lib/x86_64-linux-gnu/glib-2.0/include/ |
Mache ich etwas falsch, oder liegt es an Ubuntu 18.04? Ich kann es ja noch mal mit 17.10 versuchen... (Ich habe es auch hier auf dem Hostsystem KDE Neon 5:12.5 versucht, aber da fehlt GTK, wegen Ubuntu 16.04 LTS.) Schade, ich hatte gehofft, endlich einen Platinenlayouter gefunden zu haben, der mir gefällt...
Ach ja: Der dbind-WARNING-Kram kommt in Lubuntu bei allen GTK-Anwendungen, scheint aber keine Probleme zu verursachen.
Von den Binaries, die aus dem Build rausfallen sind nur horizon-pool-mgr und horizon-prj-mgr unmittelbar verwendbar. Der eigentliche Fehler ist der hier: > gl error 1282 in src/canvas/canvas_gl.cpp: 138 Was für eine GPU hast du? Um den Fehler weiter einzugrenzen, füge mal GL_CHECK_ERROR (wie in Zeile 138) nach jedem Funktionsaufruf in https://github.com/carrotIndustries/horizon/blob/master/src/canvas/canvas_gl.cpp#L99 ein.
Ich habe eine Radeon HD 6850, was das für die virtuelle Maschine bedeutet, weiß ich nicht. Gast: tuxpilot@elf:~$ glxinfo | grep "OpenGL version" OpenGL version string: 3.0 Mesa 18.0.0-rc5 Host: $ glxinfo | grep "OpenGL version" OpenGL version string: 3.0 Mesa 17.2.8 VirtualBox Graphical User Interface Version 5.1.34_Ubuntu r121010 Ich habe GL_CHECK_ERRORs in canvas_gl.cpp eingefügt. Der Fehler tritt nun in Zeile 101 (ohne GL_CHECK_ERROR-Zeilen) auf:
1 | void CanvasGL::resize_buffers() |
2 | {
|
3 | […] |
4 | GL_CHECK_ERROR |
5 | glRenderbufferStorageMultisample(GL_RENDERBUFFER, num_samples, GL_RGBA8, width, height); |
6 | GL_CHECK_ERROR // Fehler hier. |
7 | […] |
8 | } |
Wenn ich die Zeile auskommentiere, erscheint eine Liste mit Bauteilen und eine grafische Fehlermeldung: Could not set up framebuffer, in der Konsole steht gl error in Zeile 176. Wenn ich die Zeile auch auskommentiere, ist es Zeile 178–180. (So lößt man auch keine Probleme, habe es also verdient.)
Hallo tuxpilot, falls du auf dem gleichen PC auch ein WIN7,8,10 installiert hast, kannst du ein fertig kompiliertes horizon herunterladen um mal zu testen, ob es an der Grafikkarte liegt. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Diese Version ist immer top-aktuell da die automatisch bei jedem "commit" kompiliert wurde.
Helmut S. schrieb: > falls du auf dem gleichen PC auch ein WIN7,8,10 installiert hast […] Nö, Tuxpilot hat hier kein Windoof. Ich habe versucht, die .exes aus dem .zip mit Wine auszuführen (auch im virtuellen Lubuntu 18.04 LTS), die Backtraces habe ich sinnloserweise angehängt. Aber ich habe eine Festplatte mit Windows 7 32bit gefunden und in meinen Computer geschoben. <blabla> Ich habe GRUB dazu bewegt, dieses Windows zu starten. Windows war fest davon überzeugt, es müsste für meinen MCP2200 ein paar Treiber suchen, und hat erst nach einer Minute aufgegeben. Für die anderen MCP2200 ging das ganze jeweils von vorne los... Schließlich konnte ich mit einem vorhandenem 7zip das .zip entpacken, was 25 Minuten gedauert hat. (Virtuelles Lubuntu: nur 2 Minuten...) Naja, die .exes wurden erstmal in Inkscape geöffnet. Hä!? </blabla> Schließlich hat Windows mir verraten, dass es nur 32bit ist, war also alles sinnlos. :( Ich habe einen Freund mit einer Radeon HD 6950 gefragt, ob er das fertig kompilierte Horizon testen kann. Wenn es an der Grafikkarte liegt, müsste er ja das gleiche Problem haben?
Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, hast du es mal nativ probiert? Die Radeon HD 6950 ist mehr als neu genug.
Lukas K. schrieb: > Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, hast > du es mal nativ probiert? > > Die Radeon HD 6950 ist mehr als neu genug. Da bin ich gespannt, weil ein Rechner MAC(Bootcamp WIN10) mit HD5800 geht bei mir nicht. "AMDs im Oktober vorgestellte Barts-GPU (Radeon HD 6800) war keine echte Neuentwicklung, sondern im Grunde genommen ein Hybrid verschiedener Radeon-HD-5000-Rechenkerne inklusive einiger kleineren Verbesserungen ..." Seite 3 von https://www.computerbase.de/2010-12/test-amd-radeon-hd-6970-und-hd-6950/3/
Win7/64 installation mit horizon-2018-05-20-1700.zip 20.Mai 2018 *********** c:\horizon\horizon mit exe, dll, ... c:\horizon\horizon-pool-master mit pool-master: pool.json ... c:\horizon\horizon-test-project-master mit test-project: pic32-eth.hprj ... horizon-pool-mgr.exe funktioniert horizon-project-manager funktioniert add pool funktioniert add project funktioniert schematic: this application has requested the runtime to terminate it in an unusual way - win7: imp.exe funktioniert nicht mehr - terminate board: this application has requested the runtime to terminate it in an unusual way - win7: imp.exe funktioniert nicht mehr - terminate part browser. this application has requested the runtime to terminate it in an unusual way - win7: prj-mgr funktioniert nicht mehr - terminate pool chache : funktioniert Kann leider keine spezifischeren Fehlermeldungen liefern. Alexandra
Hallo Alexandra, ich habe die horizon-2018-05-20-1700.zip auf zwei PCs mit WIN10 getestet. Es funktioniert genauso wie auch die früheren Versionen. Meine Verzeichnisstruktür sieht so aus: C:\horizon In dem verzeichnis packe ich immer den zip-File aus. Danach habe ich C:\horizon\horizon In dem Verzeichnis habe ich auch meinen Pool C:\horizon\pool1 und das Test-Projekt(Schaltplan, Layout) von der Github-Siete. C:\horizon\hotizon-test-project-master Man startet nur 2 Programme - horizon-pool-mgr.exe und/oder horizon-prj-mgr.exe. Alle anderen exe siind nicht für den Anwender gedacht. 1. Mit dem File-Explorer in diesen Ordner der exe-Dateinen wechseln. C:\horizon\horizon horizon-pool-mgr.exe starten (Doppelklick). Im pool-mamanger dann einen Pool auswählen. Wenn man den hat, dann gibt es oben im Menu ein Feld "Remote". Da draufklicken. dann Upgrade pool. Dann Merge. Den horizon pool manager schließen. 2. Das Projekt öffnen. horizon-prj-mgr.exe Doppelklick Ganz links oben auf das schwarze "horizon icon" klicken -> Preferences und mit "Add pool" einen pool auswählen, falls da noch keiner gesetzt ist. Zurück ins Hauptmenu. "Open" und das Projekt anwählen z. B. das heruntergeladen Project pic32-eth.hprj Jetzt hat man es fast geschafft. Es gibt jetzt vier buttons. "Top Schematic" "Board" "Part browser" "Pool Cache" "Pool Cache" wählen falls man updaten will (mach ich meistens). Falls es etwas neues für das Projekt gibt, die neuen Teile anklicken und dann "Update from pool". Pool Cache schließen. Jetzt auf "Top Schematic" oder "Board "klichen zum Öffnen des Schaltplanes oder Layouts. Nachtrag: Bei weiteren updates des Programms entpacke ich einfach den zip-file in C:\horizon und lasse das Unterverzeichnis horizon überschreiben. C:\horizon\horizon
Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - bei einer 3Mbit-Leitung. Macht fuer mich keinen Sinn mehr mitzulesen oder etwas beizutragen.
@Helmut S danke für die Rückmeldung. Auch mit veränderter Verzeichnis-Struktur erzeugen die aus horizon-prj-mgr aufgerufenen Funktionen in meinem Win7/64 AppCrash-Laufzeitfehler Hardware: Toshiba-L770-14N-Notebook mit IntelGraphics PartBrowser : horizon-prj-mgr.exe crasht und wird beendet: Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-prj-mgr.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-prj-mgr.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 000000000011f22a Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: 0252 Zusatzinformation 2: 0252b7e8806be3f352f78783978e4b54 Zusatzinformation 3: 0816 Zusatzinformation 4: 0816dc325007f9d08cf3f87eb61e4aa0 Board : horizon-imp.exe crasht und wird beendet, horizon-prj-mgr.exe funktioniert weiter Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-imp.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-imp.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 00000000002f63ca Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: f3cb Zusatzinformation 2: f3cb96d6f8d6bdc527a608eb82d9985c Zusatzinformation 3: 3461 Zusatzinformation 4: 34610f60121e0543dce0d79c85026758 Top Schematic: horizon-imp.exe crasht und wird beendet, horizon-prj-mgr.exe funktioniert weiter Problemsignatur: Problemereignisname: APPCRASH Anwendungsname: horizon-imp.exe Anwendungsversion: 0.0.0.0 Anwendungszeitstempel: 00000000 Fehlermodulname: horizon-imp.exe Fehlermodulversion: 0.0.0.0 Fehlermodulzeitstempel: 00000000 Ausnahmecode: 40000015 Ausnahmeoffset: 00000000002f63ca Betriebsystemversion: 6.1.7601.2.1.0.256.48 Gebietsschema-ID: 2055 Zusatzinformation 1: f3cb Zusatzinformation 2: f3cb96d6f8d6bdc527a608eb82d9985c Zusatzinformation 3: 3461 Zusatzinformation 4: 34610f60121e0543dce0d79c85026758 PoolChache: funktioniert
@MitLeserin: Ich hab' mal das Error-Reporting für OpenGL-Fehler auf Windows verbessert, damit man auch ohne Konsole sieht wo es hingefallen ist: https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.197/artifacts
@Mitleserin
> i3-2350M
Ich vermute, dass da die integrierte Grafik zu alt ist.
Versuch es mal mit einem neueren PC.
Ich schreibe gerade auf einem i5-4250U Laptop mit integrierter
Grafikeinheit. Darauf läuft horizon problemlos.
Gruß
Helmut
Tuxpilot schrieb: > Ich habe mir heute das Repository „horizon.git“ geholt und mit make > kompiliert. […] horizon-pool-mgr […] stürtzt […] ab. > […] > Ich habe Lubuntu 18.04 LTS (alternate, 64 Bit) in einer VirtualBox. > […] > Schade, […] Lukas K. schrieb: > Der eigentliche Fehler ist der hier: > >> gl error 1282 in src/canvas/canvas_gl.cpp: 138 > > Was für eine GPU hast du? Lukas K. schrieb: > Die in VMs emulierten GPUs tun sich mit OpenGL 3 bisweilen schwer, > hast > du es mal nativ probiert? > > Die Radeon HD 6950 ist mehr als neu genug. (Ist eine 6850) So, ich habe Lubuntu 18.04 LTS nativ installiert. Da funktioniert make direkt vollständig, und die entstehenden Programme scheinen ohne Abstürze zu funktionieren. Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor, wenn man das Fenster größer macht. Später versuche ich es nochmal mit Lubuntu 17.10.
Tuxpilot schrieb: > Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind > größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor, > wenn man das Fenster größer macht. Kannst du mal einen Screenshot davon machen? Hört sich doch sehr nach Gtk/Grafiktreiber-Bug an. Installiere mal gtk3-examples und mach' aus der gtk3-demo die OpenGL-Demo auf. Sieht die auch so kaputt aus?
> Leider ist die gesamte GUI sehr buggy, d. h. fast alle Widgets sind
größtenteils ausserhalb der Fensterränder, und kommen auch nicht hervor,
wenn man das Fenster größer macht.
Normal ist das nicht.
Das wird dann an den Grafiktreibern bzw. der Grafikkarte liegen.
Angehängte Dateien:
Die OpenGL-Demo sieht prima aus. (In VirtualBox ist alles ausser der Grafikfläche schwarz, funktioniert aber trotzdem. (Der Rest dieses Beitrags bezieht sich auf nativ installiert.)) Die anderen Demos, die ich angeguckt habe, sehen auch gut aus, insbesondere die mit den Listen oder Panes. In anderen Anwendungen habe ich auch nichts bemerkt. In den Pool-Ansichten fehlt immer mindestens der rechte oder linke Rand von den Anzeigen, und die Knöpfe oben drüber fehlen irgendwie auch, obwohl da noch Platz wäre. Als ob die Panes ausserhalb des Fensters beginnen würden... Die übrigen Fenster (Schaltplan-Editor und so) funktionieren jetzt überwiegend, nur im Tastenkürzel-Menü habe ich gesehen, dass das letzte Element halb abgeschnitten ist. Übrigens kann man die Spalte Pads in der Breite verändern, die anderen aber nicht. Glaube nicht, dass das so soll.
Angehängte Dateien:
-
horizon-pool-mgr.exe.jpg
220 KB -
horizon-prj-mgr.exe.jpg
150 KB
@tuxpilot Ich vermute dass du das Fenster zu klein gemacht hast. Zieh doch mal das Fenster breiter. Im Anhang die Darstellung auf einem Monitor mit 1920x1080, WIN10. Da muss ich die Fenster schon fast auf die komplette Bildschirmbreite ziehen damit ich alles sehe.
Toxic schrieb: > Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - > bei einer 3Mbit-Leitung. Melde dich als Nutzer im Forum an, dann kannst du eine Seitenaufteilung einschalten. Der Thread hat dann inzwischen 4 Seiten.
Jörg W. schrieb: > Toxic schrieb: >> Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - >> bei einer 3Mbit-Leitung. > > Melde dich als Nutzer im Forum an, dann kannst du eine Seitenaufteilung > einschalten. Der Thread hat dann inzwischen 4 Seiten. Hallo Joerg, ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? (Ich habe mit 50MBit/s Zugang kein wirkliches Problem mit der Auswahl "alles", aber mich würde trotzdem interessieren wie man die Auswahl 1,2 zurück bekommt.)
Helmut S. schrieb: > ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl > "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? Über der Box "Antwort schreiben" gibt es einen Link "Seitenaufteilung einschalten".
Jörg W. schrieb: > Helmut S. schrieb: >> ich habe einmal auf "alles" geklickt. Jetzt sehe ich aber die Auswahl >> "1, 2, alles" nicht mehr. Wie bekommt man die Auswahl zurück? > > Über der Box "Antwort schreiben" gibt es einen Link "Seitenaufteilung > einschalten". Danke, hat geklappt.
Hallo Toxic. Toxic schrieb: > Mittlerweile dauert es mehr als 4 Minuten um diesen Thread zu oeffnen - > bei einer 3Mbit-Leitung. Dann hast Du aktuell halt keine 3Mbit-Leitung. Mit einer 600k Leitung dauert es wenige Sekunden. > Macht fuer mich keinen Sinn mehr mitzulesen oder etwas beizutragen. Dann solltest Du mal untersuchen, was auf Deiner Leitung abgeht. 3Mbit-Leitung ist irre viel, falls sie funktioniert. Wenn hier abends die Nachbarn saugen, sackt bei mir die Leitung auch auf teilweise unter 10k ab. Allerdings.....der Mittelwert über ca. 15min bleibt immer in etwa gleich. D.h. Dateien ziehen geht so lala, aber ein Audiostream reisst ab. Anmeckern kann ich den Provider aber dafür nicht. Das steht so im indirekt im kleingedruckten des Vertrags. Vermutlich hast Du ähnliches im Kleingedruckten. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.l02.de
@Lukas K
Danke,
die Fehlermeldung lautet in allen Fällen:
gl error 1281 in src/canvas/canvas:gl.cpp:120
program will abort
114 void CanvasGL::on_realize()
. {
. Gtk::GLArea::on_realize();
. make_current();
. GL_CHECK_ERROR
. grid.realize();
120 GL_CHECK_ERROR ---------> error
Angehängte Dateien:
-
Horizon.JPG
35 KB
Intel Driver Update direkt von Intel für i3-2350M ************************************************* Der Laufzeitfehler tritt nicht mehr auf. Horizon - Schematic startet mit einer Oberfläche, nur Text, ein leerer Bereich mit x/y Position des Cursors. Auf einem zweiten Notebook(Asusi7): dasselbe Resultat
MitLeserin schrieb: > gl error 1281 in src/canvas/canvas:gl.cpp:120 Seltsam, dass es da hinfällt, in der grid.realize() passiert eigentlich nichts besonderes. MitLeserin schrieb: > Horizon - Schematic startet mit einer Oberfläche, nur Text, ein leerer > Bereich mit x/y Position des Cursors. Hm, auch nicht wirklich besser. Installier' dir mal MSYS2 (vgl. https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows) und starte die horizon-prj-mgr.exe aus der mingw64-shell. Da sollte dann irgendwas in der Konsole stehen, das erklärt weshalb es hingefallen ist.
Tuxpilot schrieb: > So, ich habe Lubuntu 18.04 LTS nativ installiert. […] > Später versuche ich es nochmal mit Lubuntu 17.10. Auf Lubuntu 17.10: kein Unterschied feststellbar. gtk3-demo funktioniert auch da einwandfrei. Helmut S. schrieb: > @tuxpilot > > Ich vermute dass du das Fenster zu klein gemacht hast. Zieh doch mal das > Fenster breiter. Im Anhang die Darstellung auf einem Monitor mit > 1920x1080, WIN10. Da muss ich die Fenster schon fast auf die komplette > Bildschirmbreite ziehen damit ich alles sehe. Daran liegt es wohl nicht. Ich habe die Fenster auf 16.000 Pixel Breite gezogen, aber die Widgets waren immer noch halb unter dem Rand. Dann ist X abgestürtzt, was zu erwarten war.
Tuxpilot schrieb: > Daran liegt es wohl nicht. Ich habe die Fenster auf 16.000 Pixel Breite > gezogen, aber die Widgets waren immer noch halb unter dem Rand. Dann ist > X abgestürtzt, was zu erwarten war. Das sollte mit dem Commit repariert sein: https://github.com/carrotIndustries/horizon/commit/0c370219bbb6190a361ac880a3db9a168b7863e0
Angehängte Dateien:
-
Horizon.prj-mgr..JPG
150 KB
@Lukas ich habe da mal mit der Anleitung von Helmut S Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" etwas versucht : horizon startet und die Konsole liefert folgende Meldung: Alexandra@Asus-i7 MINGW64 /home/horizon_/horizon $ ./horizon-prj-mgr.exe SELECT parts.uuid, parts.MPN, parts.manufacturer, packages.name, tags_view.tags, parts.filename, parts.description FROM parts LEFT JOIN tags_vi ew ON tags_view.uuid = parts.uuid LEFT JOIN packages ON packages.uuid = parts.package WHERE parts.MPN LIKE ? AND parts.manufacturer LIKE ? AND (parts.entity=? or ?) ORDER BY parts.MPN COLLATE naturalCompare ASC col 2 create proc spawn C:\msys64\home\horizon_\horizon\horizon-imp -c C:\horizon\horizon\horizon-test-project-master\top_sch.json C:\horizon\horizon\horizon-test-project-master\top_block.json imp rx false (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:32.832: fb setup not supported (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:35.047: fb setup not supported ****************** Gtk-WARNING gibt es jede Menge und die Zahl korreliert irgendwie mit den Koordinaten des Mauszeigers.
MitLeserin schrieb: > (horizon-imp.exe:6460): Gtk-WARNING **: 09:06:35.047: fb setup not > supported Vielen Dank für's Debuggen bis hier hin schonmal, viele andere hätten schon (verständlicherweise) entnervt aufgegeben und sich anderen Dingen zugewandt. So auf die Schnelle fallen mir zwei Dinge ein, an denen das liegen könnte: - horizon fasst Buffer falsch an und Gtk ist dann hinterher unglücklich - Bug in Gtk (wär' nich der erste im Bezug auf OpenGL und Windows) So als Vorwarnung: weiteres Debuggen muss nicht unbedingt zur Lösung des Problems führen, sei mir' also nicht böse, wenn's dann immer noch nicht funktioniert. Wenn du jetzt eh schon Msys2 hast, starte mal die gtk3-demo und darin die OpenGL-demo. Funktioniert die?
GTK3-demo.exe funktioniert, verschiedene Demos funktionieren normal. OpenGL Area erzeugt aber sofort eine (gtk3-demo.exe:4500): Gtk-WARNING **: 13:25:13.752: fb setup not supported Warnung und bei jedem move der Slider eine Vielzahl weiterer identischer Warnungen.
Hallo Zusammen, wo finde ich in der Windows Version den Part Editor bzw. wie muss ich vorgehen, wenn ich einen neues Bauteil definieren will. Gruß Frank
MitLeserin schrieb: > (gtk3-demo.exe:4500): Gtk-WARNING **: 13:25:13.752: fb setup not > supported > > Warnung Ok, dann ist wohl das Problem bei Gtk. Leider sagt einem Gtk nicht, wo nun das Problem mit dem Framebuffer ist, daher hier im Anhang ein gepatchtes Gtk, das in der Fehlermeldung mehr anzeigt. Mit der dll ersetzt du dann die gleichnamige im Ordner mingw64/bin in deiner mingw-installation und probierst die OpenGL-Demo nochmal. MitLeserin schrieb: > und bei jedem move der Slider eine Vielzahl weiterer identischer > Warnungen. Das kommt daher, dass dieses Stück code bei jedem rendern aufgerufen wird. Frank L. schrieb: > wo finde ich in der Windows Version den Part Editor bzw. wie muss ich > vorgehen, wenn ich einen neues Bauteil definieren will. Den Part Editor startest du aus dem pool manager heraus. Zum Erstellen von neuen Bauteilen: https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard
(gtk3-demo.exe:7300): Gtk-WARNING **: 23:13:39.518: fb setup not supported, status=36055 status=36055 bleibt konstant immer 36055 (gtk3-demo.exe:3264): Gtk-WARNING **: 23:16:46.160: fb setup not supported, status=36055 (gtk3-demo.exe:^^^^) ändert nach Beendigung und erneutem Aufruf von gtk3-demo.exe
MitLeserin schrieb: > (gtk3-demo.exe:3264): Gtk-WARNING **: 23:16:46.160: fb setup not > supported, status=36055 > > (gtk3-demo.exe:^^^^) ändert nach Beendigung und erneutem Aufruf von > gtk3-demo.exe Die sich ändernde Nummer ist die Prozess-ID, das passt schon so. Der Fehlercode ist GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT, irgendwas hat wohl beim Aufsetzen der Framebuffer nicht funktioniert. Die DLL im Anhang hat weitere Debug-Ausgabe drin, selbes Vorgehen wie im letzten post.
Lukas K. schrieb: > Den Part Editor startest du aus dem pool manager heraus. Zum Erstellen > von neuen Bauteilen: > https://github.com/carrotIndustries/horizon/wiki/Working-with-the-Pool-Manager-and-Part-Wizard Hallo Lukas, dann habe ich leider einen Fehler entdeckt. Sobald ich im Pool Manager den Pool auswähle, schließt sich die Anwendung. Leider weiß ich nicht, wo ich das LOG in der Windows Version finde. Vielleicht kannst Du Dir das ja mal ansehen bzw. mir sagen, wo ich das LOG finde, dann stelle ich es hier ein. Gruß Frank
RUN [OpenGL Area] erzeugt in der Konsole (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.882: fb attach texture=0 buffer=1 error=1282 (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.886: fb setup not supported, status=36055 - Klick in der Konsole erzeugt 12 weitere identische paarweise Logs, - Frame mit den drei Slidern erscheint nicht, - beenden durch beenden der Konsole.
Frank L. schrieb: > Sobald ich im Pool Manager den Pool auswähle, schließt sich die > Anwendung. Leider weiß ich nicht, wo ich das LOG in der Windows Version > finde. Dann mach' es mal wie MitLeserin und starte es aus der Mingw-shell, sieht auch nach OpenGL-Problem aus. Was für eine GPU hast du? MitLeserin schrieb: > (gtk3-demo.exe:6524): Gtk-WARNING **: 11:54:32.882: fb attach texture=0 > buffer=1 error=1282 Okay, da fällt also was schon davor hin. Die DLL im Anhang hat noch mehr Debug-Ausgabe. Was für eine GPU hast du eigentlich genau?
Lukas K. schrieb: > Was für eine GPU hast du eigentlich genau? Gute Frage, war ich mir eigentlich nicht wirklich bewusst. Bisher je nach Notebook irgendwie automatisch und hat bis jetzt mit horizon scheinbar immer alles funktioniert... Erkenntnis und Stand der Dinge: ****************************** Auf ASUSi7 kann ich für jedes Programm die GPU wählen. - Intel HD Graphics 4600 : gtk3-demo.exe funktioniert NICHT - NVIDIA GeForce GTX 850M : gtk3-demo.exe funktioniert Mit *IntelHD 4600 und libgtk-3-0.dll V3* liefert gtk3-demo.exe zyklische Fehlermeldungen : (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.735: fb setup not supported, status=36055 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.744: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.747: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.750: opengl error 1281 at gtkglarea.c:547 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:14.753: fb setup not supported, status=36055 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.773: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.774: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:5996): Gtk-WARNING **: 09:26:21.777: opengl error 1281 at gtkglarea.c:547 ... to be continued ...
Auf den folgeneden Grafikkarten läuft horizon nach meiner Erfahrung. NVIDIA GTX560, GTX950, GTX1080 Intel Graphic HD 5000, HD 530 Auf der GTX260 läuft es nicht richtig. Daraus kann man den Schluss ziehen, dass es zumindest ab GTX560 und höher funktioniert.
MitLeserin schrieb: > Mit *IntelHD 4600 und libgtk-3-0.dll V3* liefert gtk3-demo.exe zyklische > Fehlermeldungen : Okay, probier's nochmal mit der DLL im Anhang und achte insb. auf die Ausgabe direkt nach dem starten der OpenGL-Demo.
Bei mir läuft eine Desktop MSI GEFORCE GTX1060 mit 6GB. Es sind zwei 4K Monitore angeschlossen. Die Anwendung lässt sich auch wundervoll bedienen und arbeitet einwandfrei. Lediglich der Aufruf des Part Editors aus dem Pool Manager heraus klappt nicht, da es hier zu einem beendigen der Anwendung kommt. Der Vorgang ist immer gleich, ich wähle im Pool Manager den Eintrags aus, der wird Bildschirm kurz weiß und dann beendet sich die Anwendung. @Lukas Sorry, mit MingW kenne ich mich nicht aus und ich habe nicht genug Zeit mich mit den Dingen zu beschäftigen. Von daher muss ich da passen. Allerdings würde ich die Anwendung gerne intensiver nutzen. Vielleicht hat ja noch wer anders das gleiche Problem und kann sich damit beschäftigen. Besteht eventuell die Möglichkeit, dass Du das Log für die Windows Version, im Verzeichnis %Appdata%\local\Horizon ablegt? Da befinden sich ja auch die Konfigurationsdateien. Gruß Frank
So, ich habe ein wenig geforscht. Jetzt läuft es, bei mir war der OpenGL gar nicht bzw. nicht korrekt installiert. Nachdem ich den aktuellsten Treiber der Karte installiert habe, funktioniert es. Gruß Frank
Alexandra@Asus-i7 MINGW32 /mingw64/bin $ ./gtk3-demo // NVIDIA - libgtk-3-0.dll /V4 //**************************************************************** // startup /***************************************************************** (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.977: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.978: allocate buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:41.979: attach 0 1 // slider - twisting the triangle //**************************************************************** (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.290: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.290: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.324: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.324: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.340: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.341: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.357: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.358: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.375: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.376: attach 0 1 (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.391: attach buffers (gtk3-demo.exe:3524): Gtk-WARNING **: 13:57:47.391: attach 0 1 Alexandra@Asus-i7 MINGW64 /mingw64/bin $ ./gtk3-demo //INTEL - libgtk-3-0.dll /V4 //**************************************************************** // startup //**************************************************************** (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.365: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:04:49.366: fb setup not supported, status=36055 // slider - no graphics visible //**************************************************************** (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.182: fb setup not supported, status=36055 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: attach buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: allocate buffers (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1282 at gtkglarea.c:487 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1282 at gtkglarea.c:489 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: attach 0 1 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: opengl error 1281 at gtkglarea.c:548 (gtk3-demo.exe:9112): Gtk-WARNING **: 14:05:01.215: fb setup not supported, status=36055 ... // unnecessary CR removed
Okay, vielleicht ist es ein Problem, dass der Renderbuffer von einer EXT-Funktion erzeugt, aber von einer nicht-EXT Funktion verwendet wird, probier's mal mit der DLL im Anhang.
Angehängte Dateien:
-
Horizon.prj-mgr....JPG
180 KB
MitLeserin schrieb: ****************************************** > - Klick in der Konsole erzeugt 12 weitere identische paarweise Logs, > - Frame mit den drei Slidern erscheint nicht, > - beenden durch beenden der Konsole. Das ist ein Fehler von gtk3-demo.exe. Dieser Fehler ist unabhängig von der ausgewählten GPU: Verschieben des Programm-Windows von gtk3-demo.exe in einen zweiten Monitor hat den Effekt, dass die Programm-Windows einzelner Tochter-Programme nicht erscheinen und die Kontrolle über gtk3-demo.exe verloren geht. -> Beenden von gtk3-demo.exe mit Ctrl-C in der Konsole. Betroffen sind vermutlich alle gtk3-demo-Beispiele mit "Grafik", darunter auch OpenGL Area. ****************************************************** Zurück zum Thema **************** Alexandra@Asus-i7 MINGW64 /mingw64/bin $ ./gtk3-demo // INTEL - libgtk.3.0.dll /V5 //**************************************************************** // startup //**************************************************************** (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: allocate buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:17.892: attach 0 1 // slider no effect - background visible //*************************************************************** (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:49.224: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:49.224: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.339: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.339: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.357: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.357: attach 0 1 (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.373: attach buffers (gtk3-demo.exe:520): Gtk-WARNING **: 10:36:50.373: attach 0 1 ... Das Grafik-Fenster ist durchsichtig, Mausspur im Grafikfenster wird ohne Einträge in der Konsole dargestellt , Slider hat im Grafikfenster keinen Effekt, erzeugt aber Einträge in der Konsole. ( die Mausspur wird von PrtScr gelöscht und kann deshalb nicht dokumentiert werden )
Hallo Zusammen, ich brauche mal einen Tipp, in welcher Reihenfolge man bei der Definition eigener Bauteile vorgehen muss. Mein Ziel, ich möchte verschiede Röhren mit Oktal und Noval Sockel erstellen. Um Smash verwenden zu können, möchte ich z.B. bei einer ECC83 die beiden Systeme und die Heizung jeweils getrennt halten. Andere Röhren mit Noval Sockel haben unterumständen nur ein System plus Heizung. Ich würde das Ganze gerne in einem Artikel zusammenfassen und hier veröffentlichen. Aber ich finde keinen Einstieg in die Materie :-( Gruß Frank
Angehängte Dateien:
-
pool.PNG
250 KB
@Frank https://media.ccc.de/v/gpn18-136-horizon-eda-ein-jahr-spter Lade dir doch mal den Vortrag herunter. In der ersten Hälfte wird ganz grob das erstellen von Bauteilen gezeigt. (Lass dich nicht von der Tonstörung(Hall) im ersten Viertel des Vortrages stören.) Das angehängte Bild zeigt dei Struktur und die Namensgebung der Bestandteile eines Bauteils. Das Programm zum erstellen der Bauteile heißt horizon-pool-mgr.exe
MitLeserin schrieb: > Betroffen sind vermutlich alle gtk3-demo-Beispiele mit "Grafik", > darunter auch OpenGL Area. Ich bin untröstlich, aber sieht so aus, als geht's hier nicht wirklich weiter. Im IRC Channel von Gtk meine man, dass das recht sicher ein Bug im Intel-Treiber ist, der nicht durch hohe Qualität im Bezug auf OpenGL bekannt sei. So ohne Problemhardware in der Hand debuggt sich's auch eher mühsam... Immerhin tut's bei dir ja mit der Nvidia-GPU.
Hallo Lukas, ich habe mir das auch so gedacht. Wenn ein Programm auf unterschiedlicher Hardware einerseits prima funktioniert und andererseits so krasse Fehlermeldungen produziert muss ein Hardware naher Fehler vorliegen. Ich denke nicht, dass Intel für die älteren Grafikeinheiten noch BugFixes nachliefern wird. vom Fehler betroffen: ******************** System: Toshiba Satpro L770-14N : Intel i3-2350M mit Intel HD3000 GPU System: Asus............N750 IK : Intel i7-4710HQ mit Intel HD4600 GPU vom Fehler nicht betroffen: ************************** System HP...............Envi 15 : Intel i7-6500U mit Intel HD520 System HP...............Envi 15 : Intel i7-6500U mit NVIDIA GTX 950M System Asus.............N750 IK : Intel i7-4710HQ mit NVIDIA GTX 850M Respekt für horizon! Alexandra
Markus W. schrieb: > Liegt das an den core-steppings der Prozessoren? Hallo Markus, das liegt nicht am CPU-Core sondern an deren GPU und dessen OpenGL-Treiber. Auch alle älteren Grafikkarten versagen hier. Helmut
Angehängte Dateien:
-
Fehler_Plane-Ausschnitt.PNG
599 Bytes -
Kicad-Plane-Ausschnitt.GIF
34 KB
Hallo Lukas, Fehler: "Plane Update" ignoriert Ausschnitte im Board. In meinem Beispiel habe ich ein Polygon auf Lage "outline" gezeichnet. "Plane Update" sollte hier entsprechend der Design-Rule das Kupfer um 0,xmm um den Ausschnitt herum zurückziehen. Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. Gruß Helmut
Zu der Sache mit den Intel 4000er-GPUs habe ich noch das hier gefunden: https://bugzilla.gnome.org/show_bug.cgi?id=792174#c2 Der hatte wohl die selben Ideen wie ich und auch gleich wenig Erfolg... Helmut S. schrieb: > Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. Horizon hatte es mal richtig gemacht, ist wohl in https://github.com/carrotIndustries/horizon/commit/b2ae2dd6348a110d18538b802d88de887ba30547 kaputt gegangen... Jetzt geht's wieder.
Angehängte Dateien:
-
Plane-Ausschnitt.PNG
996 Bytes
> Helmut S. schrieb: >> Kicad macht es richtig, horizon (noch) nicht. Siehe angehängte Bilder. > Horizon hatte es mal richtig gemacht, ist wohl in > https://github.com/carrotIndustries/horizon/commit... > kaputt gegangen... Jetzt geht's wieder. Hallo Lukas, danke für die schnelle Korrektur. Habe es gerade selbst getestet. Es funktioniert jetzt wie erwartet.
Für alle die sich wundern, wo seit dem letzten Build Pool- und Projektmanager sind: Die wurden beide in "horizon-eda" vereint, sodass es jetzt nur ein Programm zum Anklicken gibt.
Angehängte Dateien:
-
p1.png
78 KB
Die Vereinigung mach Sinn. Aber: Es gibt Probleme: (horizon-eda:5961): glibmm-CRITICAL **: 20:36:14.899: unhandled exception (type Glib::Error) in signal handler: domain: g-resource-error-quark code : 0 what : Die Ressource auf »/net/carrotIndustries/horizon/prj-mgr/part_browser/part_browser.ui« existiert nicht Auch sind meine selbst definierten Bauteile weg. Starte ich die alten Programme horizon-prj-mgr und horizon-pool-mgr befinden sich die Bauteile alle nur im Cache. Allerdings könnte das schon seit einem länger vergangenen Update sein...
Hallo Lukas, habe die neueste kompilierte Version für WIN heruntergeladen. Dann habe ich horizon-eda.exe gestartet. Darin kann ich aber nur den Pool-Manager starten und den Pool updaten aber nicht das Projekt (Schaltplan, Layout) starten. Weder "Open" noch Doppelklick in "Recent Projects" auf das Projekt hilft. Da passiert einfach gar nichts.
Helmut S. schrieb: > Da passiert einfach gar nichts. Ähm, ich hätte vielleicht zu meiner Fehlermeldung im vorletzten Post dazu schreiben sollen, dass diese geworfen wird wenn ich versuche, ein Projekt zu öffnen.
Helmut S. schrieb: > Hallo Lukas, > > habe die neueste kompilierte Version für WIN heruntergeladen. > Dann habe ich horizon-eda.exe gestartet. Darin kann ich aber nur den > Pool-Manager starten und den Pool updaten aber nicht das Projekt > (Schaltplan, Layout) starten. Weder "Open" noch Doppelklick in "Recent > Projects" auf das Projekt hilft. Da passiert einfach gar nichts. Danke Lukas, Schaltplan und Layout starten jetzt wieder mit deiner neuesten Version.
Angehängte Dateien:
-
program-icon.PNG
54 KB
Hallo Lukas, mir fällt da gerade auf, dass jetzt das horizon-Icon bei horizon-eda.exe fehlt. Siehe screenshot - links neu, rechts alt. Das Icon hilft, dass man leichter die wichtige .exe findet.
Helmut S. schrieb: > das horizon-Icon bei horizon-eda.exe > fehlt. War so nicht beabsichtigt, ist repariert.
Hallo Lukas, ich habe gerade die Funktion "Flip view" in der neuesten Version vom 7.7.2018 probiert. (In Mentor Xpedition heißt diese Funktion "Mirror".) Space bar -> Doppelklick auf "Flip view" geht. Die Altrenative mit CTRL-f macht aber gar nichts. Liegt das jetzt an Windows7. "Select only on work layer" Wenn ich das anmache dann kann ich Leitungen/Polygone selektieren aber keine Bauteile. Ist das wirklich so gedacht? Gruß Helmut
Helmut S. schrieb: > CTRL-f macht aber gar nichts. Das ist Ctr-F, also Ctrl-Shift-f. Ctrl-f wird mal irgendwann die Suchfunktion. Helmut S. schrieb: > "Select only on work layer" > Wenn ich das anmache dann kann ich Leitungen/Polygone selektieren aber > keine Bauteile. Ist das wirklich so gedacht? Ja, weil die nicht auf einem Layer im engeren Sinn liegen. Lang- Mittelfristig wird sich an dem eh noch was ändern.
Hallo Lukas, der Windows-build von horizon scheint nicht mehr zu funktionieren. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Selber kompilieren schlägt auch fehl. Ist das ein bekanntes Problem? Gruß Helmut
Angehängte Dateien:
-
remote_selfcompiled_version.PNG
26 KB -
AppVeyor_version.PNG
8,7 KB
Helmut S. schrieb: > Hallo Lukas, > > der Windows-build von horizon scheint nicht mehr zu funktionieren. > https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts > > Selber kompilieren schlägt auch fehl. > > Ist das ein bekanntes Problem? > > Gruß > Helmut Hallo Lukas, selber kompileren geht jetzt wieder, aber man kann den Pool nicht updaten. Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein fehlendes Zertifikat. Siehe Anhang. Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert über eine fehlende DLL. Gruß Helmut
Angehängte Dateien:
Hallo Lukas, an den Problemen hat sich aber nichts geändert. Die selber kompilierte Vresion hat immer noch das Problem mit dem Zertifikat und die AppVeyor Version startet schon gar nicht richtig wegen der immer noch fehlenden dll. Helmut
Helmut S. schrieb: > Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert > über eine fehlende DLL. https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.267 behebt das Helmut S. schrieb: > Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein > fehlendes Zertifikat. Siehe Anhang. Beim selber bauen muss man sich das Zertifikatsbündel noch selber an die richtige Stelle kopieren: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#running
Lukas K. schrieb: > Helmut S. schrieb: >> Die neueste Version von AppVeyor geht übrigens gar nicht. Die meckert >> über eine fehlende DLL. > > https://ci.appveyor.com/project/carrotIndustries/horizon/build/1.0.267 > behebt das > > Helmut S. schrieb: >> Sobald ich "Remote" klicke kommt eine Fehlermeldung über ein >> fehlendes Zertifikat. Siehe Anhang. > > Beim selber bauen muss man sich das Zertifikatsbündel noch selber an die > richtige Stelle kopieren: > https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows#running Danke. Jetzt laufen beide Versionen wieder.
Angehängte Dateien:
-
fame.PNG
3,7 KB
Hallo Lukas, was soll denn im PCB-layout in "Fame" mal stehen oder ist das ein Tippfehler? Gruß Helmut
Helmut S. schrieb: > was soll denn im PCB-layout in "Fame" mal stehen oder ist das ein > Tippfehler? Ja, und eigentlich sollte das da gar nicht auftauchen. Ist repariert.
Hallo Lukas, habe nach längerer Zeit mal wieder die aktuelle Version im git unter Debian Sid kompiliert. Das ging soweit glatt, die Anwendung lässt sich starten und auch ein Projekt auswählen. Wenn ich dann den Schaltplan, das Board oder den Part browser aufrufe, startet dieser, aber an den Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der Schaltplan oder das Board selbst werden korrekt angezeigt. Wenn man weiß, wo man in der schwarzen Fläche klicken muss, lässt sich das Programm sogar bedienen. Also z.B. ein Klick rechts oben im Fenster schließt dieses wieder. Was könnte ich den tun, um diesen Fehler wieder abzustellen? Uwe
Uwe S. schrieb: > startet dieser, aber an den > Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der > Schaltplan oder das Board selbst werden korrekt angezeigt. Das ist eine Regression in mesa, hatte ich auch. Nach Downgrade auf 18.0.4 tat es bei mir wieder. Man müsste mal ein bug in deren Bugzilla aufmachen... Du hast auch eine Intel GPU?
Lukas K. schrieb: > Uwe S. schrieb: >> startet dieser, aber an den >> Stellen, an denen Bedienelemente sind, ist nur eine schwarze Fläche. Der >> Schaltplan oder das Board selbst werden korrekt angezeigt. > > Das ist eine Regression in mesa, hatte ich auch. Nach Downgrade auf > 18.0.4 tat es bei mir wieder. Man müsste mal ein bug in deren Bugzilla > aufmachen... > Du hast auch eine Intel GPU? Ja, Intel GPU. Zu blöd. Danke trotzdem für die Info. Uwe
Hallo Lukas, vor ein paar Wochen habe ich horizon ausprobiert. Leider war ich mitten in einem größeren Projekt, das ich schon mit Kicad begonnen hatte.. Jetzt aber gerne eine Rückmeldung was mir dabei aufgefallen ist: Als allererstes ganz großes Lob! Eine wunderbar klare, aufgeräumte Oberfläche. Der Schaltplaneditor der endlich mal seine "Junctions" aufräumt und Netzsegmente die zu einem Stück zusammengefasst werden. Wenn man einmal die ?-Taste gefunden hat ist alles gut. Nicht zuletzt die Videos sind extrem hilfreich. Ein paar Fragen habe ich auch: Ich glaube, daß ich das Konzept zu dem Pool einigermaßen verstanden habe. Aber vielleicht auch nicht ganz. * Warum gibt es die Unterscheidung in Unit und Symbol? Gibt es Units die kein Symbol haben oder andersherum? Auf den ersten Blick ist es eine 1:1 Abbildung und mir nicht klar warum nicht jedes Symbol gleichzeitig auch Unit ist. * Warum gibt es im Pool, sowohl bei den Units als auch bei den Symbolen die "Manufacturer" Spalte? Das hat mich irritiert. Ich dachte ich bewege mich auf einer rein abstrakten Ebene wenn ich eine Unit oder Symbol anlege.. Klar gibt es Symbole oder Entities die ein von einem bestimmten Hersteller produziertes Bauteil symbolisieren. Aber müsste dann nicht der beim Entity hinterlegte Hersteller beim Symbol auftauchen? Im Moment kann man sowohl für Unit als auch Symbol als auch Entity verschiedene Hersteller angeben.. * Bei der 3D-Ansicht sehe ich keine Platine (Substrat). Auch wenn ich eine Outline angebe. Nur Leiterbahnen und den ganzen Rest.. Dann habe ich auch noch ein paar Anregungen: * Mehrere Pools pro Projekt. Während des Schaltplanens mache ich mal schnell ein Symbol, welches nicht in den Pool gehört. Entweder weil ich es nur ganz schnell zeichne oder weil es ein spezielles Symbol ist, daß nie wieder jemand anderer verwenden wird (zB. ein eigenes Aufsteck-Board o.a.). Außerdem habe ich gerne eine Sammlung von eigenen Symbolen und Packages die von mir überprüft sind und auf die ich schnellen Zugriff möchte.. Mir ist klar, daß das das Konzept des Pool etwas aufweichen würde .. * Mehrere Boards pro Projekt. Die meisten meiner Projekte haben mehr als ein Board. Z.B. noch ein Aufsteckboard fürs Display oder ein Breakout-Board o.ä. Es wäre schick die alle in Form eines Projekt-Explorers zusammengefasst zu haben. * Zoomen. Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist das beispielsweise so.. Danke jedenfalls schonmal für das schöne Programm und schönen Abend und entschuldige wenn ich die eine oder andere Antwort auf die eine oder andere Frage überlesen habe. Flo
Flo G. schrieb: > Der Schaltplaneditor der endlich mal seine "Junctions" > aufräumt und Netzsegmente die zu einem Stück zusammengefasst werden. Sollte eigentlich selbstverständlich sein, inzwischen kann KiCad das auch... > Wenn man einmal die ?-Taste gefunden hat ist alles gut. Nicht zuletzt > die Videos sind extrem hilfreich. Sehr schön :) Flo G. schrieb: > * Warum gibt es die Unterscheidung in Unit und Symbol? Gibt es Units die > kein Symbol haben oder andersherum? Auf den ersten Blick ist es eine 1:1 > Abbildung und mir nicht klar warum nicht jedes Symbol gleichzeitig auch > Unit ist. Idee dahinter ist es, Darstellung im Schaltplan (Symbol) und in der Netzliste (Unit) zu trennen, damit nicht der Schaltplan, sondern die Netzliste die Primärquelle für Konnektivität ist. Nebenbei kann man für eine Unit mehrere Symbole in verschiedenen Geschmacksrichtungen haben. Flo G. schrieb: > * Warum gibt es im Pool, sowohl bei den Units als auch bei den Symbolen > die "Manufacturer" Spalte? Die Spalte "Manufacturer" bei den Symbolen ist identisch mit der bei den Units, damit man besser erkennt was man vor sich hat. > Das hat mich irritiert. Ich dachte ich bewege > mich auf einer rein abstrakten Ebene wenn ich eine Unit oder Symbol > anlege.. Klar gibt es Symbole oder Entities die ein von einem bestimmten > Hersteller produziertes Bauteil symbolisieren. Das ist mehr so als Gedankenstütze, denn die Teilenummern sind ja manchmal recht wenig aussagekräftig. > Aber müsste dann nicht > der beim Entity hinterlegte Hersteller beim Symbol auftauchen? Im Moment > kann man sowohl für Unit als auch Symbol als auch Entity verschiedene > Hersteller angeben.. Kann man, am Ende vom Tag zählt das, was im Part eingetragen ist. Flo G. schrieb: > * Bei der 3D-Ansicht sehe ich keine Platine (Substrat). Auch wenn ich > eine Outline angebe. Nur Leiterbahnen und den ganzen Rest.. Dann hast du wahrscheinlich die Kontur als Linien und nicht als Polygon gezeichnet. Mit dem tool "Line loop to polygon" kannst du's umwandeln. Flo G. schrieb: > * Mehrere Pools pro Projekt. Seit kurzem geht das: Du legst dir einen eigenen Pool an, und fügst im Tab "Settings" den globalen Pool hinzu. Damit hast du einen Pool, in dem alles aus dem globalen Pool eingeblendet ist und du zusätzlich deine eigenen Bauteile hinzufügen kannst. Flo G. schrieb: > * Mehrere Boards pro Projekt. Das Passt nicht wirklich ins Konzept. Was für Vorteile versprichst du dir davon? Flo G. schrieb: > * Zoomen. > Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr > praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist > das beispielsweise so.. Ist wohl Geschmackssache, ich finde das überaus irritierend. Mit Wayland wird das ohnehin nicht mehr funktionieren, da Applikationen dann nicht mehr den Cursor positionieren können. Ist denen bei Kicad auch aufgefallen: https://bugs.launchpad.net/kicad/+bug/1725920
Flo G. schrieb: > * Zoomen. > Beim Zoomen (mit dem Mausrad) finde ich es bei anderen Programmen sehr > praktisch, wenn die Stelle des Cursors in die Mitte rückt. Bei Kicad ist > das beispielsweise so.. Das stelle ich immer als erstes ab :) Ich liebe es, wenn der der Punkt unter der Maus beim Zoomen gleich bleibt. Das irre rumgespringe macht mich ganz wirr^^
Lukas K. schrieb: > Mit Wayland > wird das ohnehin nicht mehr funktionieren, da Applikationen dann nicht > mehr den Cursor positionieren können. Endlich! ENDLICH! Es geschehen also doch noch Zeichen und Wunder! Ein Zeitalter in dem diese UX-Vergewaltigung endlich nicht mehr möglich ist bricht an, daß ich das noch erleben darf!
Angehängte Dateien:
Hallo Lukas, die neueste Version von horizon läuft nicht wegen mindestens einer fehlenden DLL - "libthai-0.dll". Siehe Anhang. Gruß Helmut
Hallo Lukas, wenn ich selber einen "build" für Windows mache, dann läuft das Programm obwohl es gar keine libthai-0.dll baut. Damit ist das ein reines Problem des von AppVeyor CI gebauten Programms. Gruß Helmut
Hallo Lukas, danke für neueste AppVeyor Version. Die funktioniert. Gruß Helmut Die WNODOWS-Version von horizon gibt es hier. https://github.com/carrotIndustries/horizon/wiki/Getting-started
Helmut S. schrieb: > danke für neueste AppVeyor Version. Die funktioniert. Jetzt ist auch ein Test drin, der nachsieht, ob auch alle benötigten DLLs mit dabei sind. Damit sollte sowas in Zukunft nicht mehr unbemerkt bleiben. Helmut S. schrieb: > wenn ich selber einen "build" für Windows mache, dann läuft das Programm > obwohl es gar keine libthai-0.dll baut. Wann hast du bei deinem msys2 das letzte mal Updates gemacht? Gtk und andere Libraries scheinen von Version zu Version mehr Abhängigkeiten zu bekommen. Zum Updates installieren mehrfach "pacman -Syu" in der mingw-shell ausführen.
Lukas K. schrieb: > Helmut S. schrieb: >> wenn ich selber einen "build" für Windows mache, dann läuft das Programm >> obwohl es gar keine libthai-0.dll baut. > > Wann hast du bei deinem msys2 das letzte mal Updates gemacht? Gtk und > andere Libraries scheinen von Version zu Version mehr Abhängigkeiten zu > bekommen. > > Zum Updates installieren mehrfach "pacman -Syu" in der mingw-shell > ausführen. Danke. Jetzt generiert das "make" auch auf meinem PC die libthai-0.dll".
Hallo Lukas, in einem thread um KiCad ging es um die Frage wie man zwei traces für ein Netz legen kann ohne dass der bereits vorhandenene trace gelöscht wird. Beitrag "KiCAD Leitungen auf Top UND Bottom" ----- > Wie mache ich es in KiCAD, dass ich sowohl auf Top und auf Bottom > Leiterbahnen gleichen Netzes routen kann? der Default unter "Interactive Router Settings" ist "remove redundant tracks". Kann man ausschalten... ----- Horizon löscht immer/meistens den alten trace, wenn man parallel einen neuen trace routet. Das entsprciht der Default-Einstellung von KiCad. Ich sehe in horizon bisher keine Möglichkeit dieses Verhalten auch mal abzuschalten wie das in KiCad möglich ist. Hast du das auf deiner ToDo-Liste oder übersehe ich eine Einstellmöglichkeit in horizon?
Hallo Lukas, hier noch ein Nachschlag zu meinem letzten Beitrag/Wunsch. Diese Funktion mit Auswahlmöglichkeit gibt es nicht nur in KiCad sondern vermutlich in vielen Layout-Programmen die einen online-DRC haben. KiCad: Remove redundant tracks Altium: Automatically remove loops (E)Xpedition: Prevent loops Diskussion im Forum KiCad, Beitrag "KiCAD Leitungen auf Top UND Bottom" Altium, Beitrag "Altium mehrere Leiterbahnen an ein SMD Pad"
Das abstellbar zu machen, wäre auf die schnelle kein großer Aufwand, doch platzt die Statuszeile beim Routing Tool mittlerweile schon aus allen Nähten und die Übersichtlichkeit derer lässt auch zu wünschen übrig. Mittelfristig wird für Tools die mehr Einstellmöglichkeiten haben, als sinnvoll in die Statuszeile passen eine Seitenleiste, an der Stelle an der sonst der Properties sind, geben.
Angehängte Dateien:
-
prevent_loops.PNG
16 KB
Wie wäre es das in "Rules" unter einer neuen Rubrik "Route" unterzubringen. Da könnte ja noch mehr kommen. Route -> Prevent loops
Angehängte Dateien:
-
3d.png
360 KB
Sodele, nun gibt's dank meiner Masterarbeit auch endlich ein vorzeigbares Demoprojekt für horizon EDA: https://github.com/carrotIndustries/x-band-tx
Lukas K. schrieb: > Sodele, nun gibt's dank meiner Masterarbeit auch endlich ein > vorzeigbares Demoprojekt für horizon EDA: > https://github.com/carrotIndustries/x-band-tx Hallo Lukas, vielen Dank für die CAD-files. Das PCB sieht sehr gut aus. Nach dem Starten deines Layouts bekommt man eine Menge "air wires". Erst nach dem Plane-update sind die "air wires" weg. Ist es gewollt, dass die Planes nach dem Laden des Projects immer erst mit "Update all planes" aktiviert werden müssen? Warum sehe ich die grünen LEDs in meiner 3D-Ansicht nicht? Gruß Helmut
Helmut S. schrieb: > Nach dem Starten deines Layouts bekommt man eine Menge "air wires". Erst > nach dem Plane-update sind die "air wires" weg. > Ist es gewollt, dass die Planes nach dem Laden des Projects immer erst > mit "Update all planes" aktiviert werden müssen? Aktuell ja, die Füllung der Planes wird nicht gespeichert. > Warum sehe ich die grünen LEDs in meiner 3D-Ansicht nicht? Einige Packages (z.B. die LEDs) habend 3D-Modelle, deren Lizenz die Weiterverbreitung explizit verbietet, manche haben auch gar keine wirkliche Lizenz. Diese Modelle landen daher nicht im git. Wenn man die 3D-Modelle haben will muss man die sich selber von irgendwo runterladen und an die richtige Stelle kopieren.
Angehängte Dateien:
-
kicad_schieben.PNG
6,7 KB -
kicad_schieben1.PNG
3,3 KB
Hallo Lukas, Beim lesen einer Diskussion über push and shove in Kicad habe ich mir das mal genauer in Kicad angesehen. Es gibt dort ein Menu in dem man einstellen kann ob der interactive router um andere Leitungen herumfährt oder ob Leitungen weggeschoben werden. Siehe die zwei Bilder. Im zweiten Bild hat Kicad die bestehende Leitung weggeschoben um Platz zu machen. Diese Möglichkeit des wegschiebens beim verlegen einer Leitung (Befehl x) scheint es in horizon nicht zu geben oder übersehe ich etwas?
Lukas K. schrieb: > Einige Packages (z.B. die LEDs) habend 3D-Modelle, deren Lizenz die > Weiterverbreitung explizit verbietet Warum nimmst Du nicht einfach die 3d-Modelle von KiCAD, die sind frei nutzbar, so verstehe ich die LICENSE.md Datei die sich in deren übergeordnetem Ordner befindet: https://github.com/KiCad/kicad-packages3D/blob/master/LICENSE.md
Helmut S. schrieb: > Diese Möglichkeit des wegschiebens beim verlegen einer Leitung (Befehl > x) scheint es in horizon nicht zu geben oder übersehe ich etwas? Wenn das Router-Tool aktiv ist, aber man noch keinen Track routet kann man mit 's' zwischen push/shove und walkaround umschalten. Bernd K. schrieb: > Warum nimmst Du nicht einfach die 3d-Modelle von KiCAD Wenn KiCad welche hat, nehme ich die, nur bei exotischen Bauteilen hat's in der KiCad-Library nichts.
Hallo Lukas,
> Wenn das Router-Tool aktiv ist, aber man noch keinen Track routet kann
man mit 's' zwischen push/shove und walkaround umschalten.
Danke, das hatte ich in der Statuszeile übersehen.
Jetzt ist mir aber moch etwas anderes wichtiges aufgefallen. Wenn ich
ein trace-segment mit "drag track" oder "drag keeping slope" schiebe,
kann ich das Leitungsstück über andere Leitungen schieben (Kurzschluss).
Es werden also keine interaktiven Checks gemacht. Ist das immer so oder
übersehe ich da schon wieder etwas?
(In Kicad wird da die andere Leitung weggeschoben damit die nicht
übereinander liegen.)
in welcher Sprache ist es jetzt eigentlich programmiert worden? Ahhh..ich sehe gerade c++-richtig?
Hallo Lukas, die neueste Version von horizon (horizon-2018-10-03-1629.zip) für WINDOWS läuft nicht. https://ci.appveyor.com/project/carrotIndustries/horizon/build/artifacts Es fehlen die beiden DLLs libssl-1_1-x64.dll und libcrypto-1_1-x64.dll. Wenn man die zwei fehlenden Dateien aus MSYS64 dazukopiert, dann läuft das Programm. Die Ursache liegt also nur an der Batchdatei die die WIN-Files zusammenkopiert. Gruß Helmut
Helmut S. schrieb: > Es fehlen die beiden DLLs libssl-1_1-x64.dll und libcrypto-1_1-x64.dll. > Wenn man die zwei fehlenden Dateien aus MSYS64 dazukopiert, dann läuft > das Programm. Die Ursache liegt also nur an der Batchdatei die die > WIN-Files zusammenkopiert. Hmm, mal sehen weshalb das mein Test nicht erkannt hat... Im aktuellen Build sollten die jetzt drin sein.
Angehängte Dateien:
-
3D_failed.PNG
5,6 KB
Hallo Lukas, in der neuesten Version von horizon geht die 3D-Ansicht nicht mehr. Es geht überhaupt kein Fenster für die 3D-Ansicht auf. Im Anhang die Fehlermeldung beim klicken auf den 3D-button, wenn man horizon-eda im mysys gestartet hat. Das war jetzt mit der selbstkompilerten Version. In der Appveyor-Version geht 3D auch nicht mehr.
Helmut S. schrieb: > in der neuesten Version von horizon geht die 3D-Ansicht nicht mehr. Es Danke für's Testen, ist repariert.
Helmut S. schrieb: > die neueste Version von horizon (horizon-2018-10-03-1629.zip) für > WINDOWS läuft nicht. Nun ja, auch bei der "horizon-2018-10-23-2257.zip" läuft's hier nicht: "gl error 1281 in src/canvas/canvas_gl.cpp:87" System: Thinkpad T410s, Intel-HD Grafik, OpenGL 2.1 und ein Update auf die neueste OpenGL Version ist dafür nicht verfügbar. Es ist wie bei Kicad: jede Begegnung mit Horizon ist mir wie ein Schlag ins Gesicht. W.S.
W.S. schrieb: > OpenGL 2.1 Genügt nicht, stand schon ganz am Anfang fest, und Lukas hat ausführlich erklärt, warum er davon nicht abgehen möchte. OpenGL 3 ist Pflicht. Allerdings hat selbst mittlerweile schon recht betagte Hardware damit kein Problem mehr, ein T410 ist mit 8 Jahren ja schon ein Großvater.
Jörg W. schrieb: > Genügt nicht, stand schon ganz am Anfang fest Lukas K. schrieb: > OpenGL 3.2 ist leider Pflicht Tja, i5, 4 Kerne, 8 GB RAM, Intel-HD bis >2000x2000, DirectX-10 genügt so einem Programm nicht. Toll. Ist ne klasse Zielstellung. Manchmal frag ich mich, warum. Ich kann's mir nur mit überschäumendem Hormon erklären. Etwa so wie im Straßenverkehr, wo mir oft genug Leute auffallen, die aus lauter Lust nochmal Vollgas geben, wohl wissend, daß sie nach 300m dann ne Vollbremsung hinlegen müssen, weil sie dort links abbiegen müssen. Kluge Entscheidungen vor dem Schreiben der ersten Codezeile sehen anders aus. Aber diesen Punkt hatte ich dem Lukas ja schon vor langer Zeit dringendst angeraten und er hat ihn in den Wind geschlagen. W.S.
W.S. schrieb: > Manchmal frag ich mich, warum. Das hat Lukas ausführlich begründet. Im Gegensatz zu deinem Gemuffel war es eine kluge Designentscheidung von ihm, damit er sich eben bei einer kompletten Neuentwicklung, die ohnehin erst ein paar Jahre nach Designgstart irgendwann "ready for the masses" sein wird, den Aufwand für irgendwelche Rückwärtskompatibilität bis zur Jungsteinzeit sparen kann und sich stattdessen auf die gewünschten Features konzentriert. Die Kiste hier in der Firma hat nun auch schon 4 Jahre auf'm Buckel, ist ein i5, und genügt vollauf für Horizon. Nur dein knapp 10 Jahre alter Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr für eine halbwegs aktuelle Windows-Version, oder?
W.S. schrieb: > DirectX-10 genügt > so einem Programm nicht DirectX ist was Windows-spezifisches, die Software soll aber bewusst plattformunabhängig sein, ist also völlig irrelevant. OpenGL 3.2 ist aus dem Jahre 2009. https://de.wikipedia.org/wiki/OpenGL#Versionsgeschichte Selbst Grafikkarten aus dem Jahr 2008 haben (später) OpenGL 3.2 und mehr unterstütz, z.B. die GeForce 200er-Serie oder die alte 9000er-Serie https://de.wikipedia.org/wiki/Nvidia-GeForce-200-Serie#Grafikprozessoren https://de.wikipedia.org/wiki/Nvidia-GeForce-9-Serie#Grafikprozessoren Eventuell läuft es auch auf noch älteren Grafikkarten, das hab ich jetzt nicht überprüft. Intel war mit seinem internen "Grafikbeschleuniger" (in der Vergangenheit) immer sehr stiefmütterlich umgegangen. Meist war Intel auch DirectX Support wichtiger wie OpenGL. W.S. schrieb: > Manchmal frag ich mich, warum. Ich kann's mir nur mit überschäumendem > Hormon erklären. Irgendwann muss man die Altlasten auch mal loswerden, und OpenGL 3.2 ist echt keine große Hürde, jede nVidia oder AMD Karte der letzten 10 Jahre kann das. W.S. schrieb: > Kluge Entscheidungen vor dem Schreiben der ersten Codezeile sehen > anders aus. Doch die sehen genauso aus, nämlich das man Altlasten größer 10 Jahre irgendwann mal loswird. Oder willst du noch Standards untersützen W.S. schrieb: > System: Thinkpad T410s, Intel-HD Grafik Hättest du damals die "NVIDIA Quadro NVS 3100M" mitkaufen sollen, die untersützt alles bis OpenGL 4.3 ;-) http://www.gpuzoo.com/GPU-NVIDIA/Quadro_NVS_3100M.html Zudem ist auch nur die alte Westmere-Generation (also Core i erste Generation) auf OpenGL 2.1 hängen geblieben, alle anderen gehen ab 3.3 unter Linux los https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities
Kein win95, win98, ME, XP --> also schrott? Nicht ganz, auch wenn ich auch heute fast alles noch mit XP mache. Liegt teilweise an der Software darauf. Leider bin ich aktuell bei horizon auch raus, mein I3 mit WIN7 will halt nicht so richtig. Der wird auch noch einige Jahre laufen. Dabei würde ich sehr gerne zu horizon wechseln, weil es jetzt schon einen super Eindruck macht.
Jörg W. schrieb: > W.S. schrieb: >> Manchmal frag ich mich, warum. > > Das hat Lukas ausführlich begründet. Im Gegensatz zu deinem Gemuffel > war es eine kluge Designentscheidung von ihm, damit er sich eben bei > einer kompletten Neuentwicklung, die ohnehin erst ein paar Jahre nach > Designgstart irgendwann "ready for the masses" sein wird, den Aufwand > für irgendwelche Rückwärtskompatibilität bis zur Jungsteinzeit sparen > kann und sich stattdessen auf die gewünschten Features konzentriert. ...das überhaupt "ausführlich begründen" zu müssen halte ich schon für sehr konziliant, weil offensichtlich... > > Die Kiste hier in der Firma hat nun auch schon 4 Jahre auf'm Buckel, ist > ein i5, und genügt vollauf für Horizon. Nur dein knapp 10 Jahre alter > Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr > für eine halbwegs aktuelle Windows-Version, oder? da wiederum wäre ich nicht so sicher, nicht unwahrscheinlich dass Microsoft ein Extra-Team nur für die Gate-A20-Emulationen unterhält ;-) (zumindest auf meiner 2009er-Kiste z.B. läuft Win10 unauffällig)
Jörg W. schrieb: > Nur dein knapp 10 Jahre alter > Laptop genügt eben nicht mehr, aber der genügt sicher auch nicht mehr > für eine halbwegs aktuelle Windows-Version, oder? Der stammt aus 2011 und du schmeißt mal wieder mit beleidigenden Sprüchen um dich. Muß man ein etwa 8 Jahre altes Notebook wegschmeißen, obwohl es immer noch tadellos funktioniert? Das Ganze ist ne generelle Frage, nämlich die nach der heutigen Wegwerf-Gesellschaft. Muß man sein Auto alle 4.1 Jahre wechseln? Und sein Mobiltelefon alle 2.4 Jahre und sein Notebook alle 3 Jahre? Tatsächlicher Verschleiß ist ein echter Grund, aber gedankenlos oder mit Mutwillen programmierte Software ist was Anderes. Ach, Schwamm drüber. W.S.
W.S. schrieb: > Muß man ein etwa 8 Jahre altes Notebook wegschmeißen, obwohl es immer > noch tadellos funktioniert? Muss man nicht, ich benutze auch noch mein >10 Jahre altes Thinkpad - für Browser, Doku und µC-Flashen z.B. Ich käme aber nicht auf die Idee, damit ein aktuelles EDA nutzen zu wollen, oder mich dann gar noch über damit verbundene Probleme zu beschweren...
Ich denke eure Erwartungen sind zu hoch, ich würde nicht mal im Traum daran denken eine (noch nicht mal fertige) Software zu kritisieren weil sie auf 10 Jahre alten Gurken nicht läuft, selbst ein 2009er MacBook (nicht Pro) unterstützt OpenGL 3.3. Also irgendwo muss man mal auch die Reissleine ziehen... Was kommt als nächstes? Die Software taugt nichts weil Opas Windows 3.11 Rechner nicht mit Horizon zusammen spielt? Ich benutze selbst noch ein 2010er MacBook und 2010er HP Notebook, mit den Gurken würde ich aber nie auf die Idee kommen ein CAD Programm produktiv einzusetzen... Wenn die Software Produktivstand erreicht hat werden die genannten Modelle welche nicht unterstützt werden auch ihre 10 Jahre erreicht haben. Ich bin ebenfalls kein Befürworter von dauernd neukaufen, ich fahre auch ein 15 Jahre altes Auto aber ich denke einen Computer aus dem Consumer-Bereich kann man ohne schlechten Gewissens nach 8 Jahren in den Ruhestand schicken oder zumindest anderweitig einsetzen, ich habe auch ein Thinkpad T23 mit Windows XP hier, das Teil wird halt angeschmissen wenn ich eine echte parallele oder serielle Schnittstelle benötige (und ich kann mich ehrlich gesagt auch nicht mehr daran erinnern wann dass das letzte mal war)
Jan L. schrieb: > Muss man nicht, ich benutze auch noch mein >10 Jahre altes Thinkpad - > für Browser, Doku und µC-Flashen z.B. > Ich käme aber nicht auf die Idee, damit ein aktuelles EDA nutzen zu > wollen, oder mich dann gar noch über damit verbundene Probleme zu > beschweren... Stop mal. Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. hier in diesem Forum herumzudaddeln. Und ich komme genau wie du auch nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf diesem Notebook. So viel zum Thema "aktuelles EDA". Ich sag's mal so: Jörg und andere haben einfach den Mund zu voll genommen - und es ist wohl eher nicht sehr klug, die Systemvoraussetzungen zu hoch zu schrauben. Dann fehlen nämlich viele Tester und übrig bleiben nur die Fanboys. Ihr hättet meine Fehlermeldung auch ganz einfach so stehen zu lassen wie sie ist. Schließlich ist mir die Version 2.1 schon zuvor klar gewesen. Aber aus eigener Erfahrung weiß ich, daß gelegentlich aus einer einigermaßen detaillierten Fehler-Rückmeldung und einer kleinen Änderung im Quellcode etwas Gutes werden kann, z.B. bessere Kompatibilität und geringere HW-Anforderungen ohne daß man sich viel an Performance vergibt. Kann, nicht Muss. Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes Feature aus OpenGL 4.6 zu benutzen? W.S.
W.S. schrieb: > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Ich habe von einem aktuellen Windows gesprochen, nicht von Eagle (oder einem anderen EDA-Programm). Mein Sohn hat billig ein ähnlich altes Thinkpad bekommen, daher habe ich durchaus ungefähr ein Gefühl dafür, wie performant oder lahm so'n Ding ist. Fürs gelegentliche Arbeiten sicher OK, als primäre Maschine will das heute wohl keiner benutzen. Wenn du Horizon dort sowieso gar nicht verwenden willst, ist die Lamentiererei doppelt unsinnig, zumal du ja ganz genau wusstest, dass es aufgrund der eingangs genannten Systemvoraussetzungen gar nicht gehen kann. > Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes > Feature aus OpenGL 4.6 zu benutzen? Er hat sich zum Projektstart auf Mindestanforderungen seines Zielsystems festgelegt (und diese auch begründet). An die hat er sich bislang gehalten.
Angehängte Dateien:
-
horizon.png
14 KB
Also ich habe mich jetzt mal entschlossen das Programm auszuprobieren. Bisher leider nur mit mäßigem Erfolg. Ich bekomme es noch nicht einmal gestartet. Es poppen sofort 2 Fehlermeldungen auf. Die erste Meldung lautet "No pools setup ....". Was das auch immer sein mag. Gleichzeitig mit dieser Meldung popt noch die im Anhang gezeigte Fehlermeldung auf. Ich habe gar kein Laufwerk B. Immerhin die erstere von beiden Meldungen kann ich schließen, während die zweite (die mit dem Laufwerk B) sich hartnäckig weigert. Keine der Funktionen "Abbrechen", "Wiederholung" oder "Weiter" führt zu einem sichtbaren Ergebnis. Auch das Beenden des Programmes mit dem Taskmanager funktioniert nicht. Braucht es denn noch weitere Voraussetzungen, damit das Programm lauffähig ist? Ich befürchte, W.S. hat wieder mal mit seiner Einschätzung recht. So wie es momentan ist, ist es leider unbrauchbar. Pulsonix 9.0, Eagle und auch einige andere CAD-Programme laufen völlig problemlos auf dem Rechner.
Zeno schrieb: > Die erste Meldung lautet "No pools setup ....". Was das auch immer sein > mag. Lies mal den Rest des Threads bzw. Lukas' Dokumentation (die URL seines Projekts steht ja im einleitenden Beitrag, dort gibt es auch ein Wiki). Einen Pool musst du erstmal einrichten, der ist Grundvoraussetzung. Möglicherweise erledigt sich ja dann die Frage nach dem ominösen Laufwerk B.
Jörg W. schrieb: > Einen Pool musst du erstmal einrichten, der ist Grundvoraussetzung. > Möglicherweise erledigt sich ja dann die Frage nach dem ominösen > Laufwerk B. Wie mache ich das? Keines der Programme im Horizonordner zeigt nachvollziehbare Reaktion. Dachte das ich diesen ominösen Pool hiermit horizon-pool.exe bzw. diesem horizon-pool-update-parametric.exe erzeugen kann. SEhe bei diesen Programmen außer einem kurzen Blinkern keine wirkliche Reaktion.
Weiß ich auch gerade nicht mehr, müsste ich nachlesen. Meine Binaries zu Hause funktionieren auch im Moment nicht mehr, weil irgendwelche Systembibliotheken neu gebaut worden sind. Schau mal durch den Thread.
Zeno schrieb: > Wie mache ich das? Keines der Programme im Horizonordner zeigt > nachvollziehbare Reaktion. ...aus "getting started" im Wiki:
1 | Get the pool |
2 | Don't know how to git? No problem! Double-click horizon-eda.exe or launch > ./horizon-eda from your shell and click on 'Download...' to download the pool. The default pool carrotIndustries/horizon-pool is the one you want to use. |
möglich, dass man da inzwischen oben links auf den Button "New..." klicken muss - aufgerufen aber wird nur "horizon-eda.exe". Kommt schonmal vor, dass auch das nicht klappt - es ist halt "work in progress", und ab und zu "vergisst" der Paketierer da wohl mal eine Library... Ich hatte zufällig gestern mal aktualisiert, und die Version läuft - da ich aber eine alte Version vorher hatte, ist das nicht unbedingt aussagekräftig...
@Jan, Jörg Habe Eure Hinweise beherzigt aber funktionieren tut es immer noch nicht. Die im Anhang meines obigen Post gezeigte Fehlermeldung kommt immer noch, immerhin kann ich jetzt den ominösen Pool einlesen. Er rödelt ne Weile und dann ist eine 2. Fehlermeldung da (s. Anhang). Die untere kann ich mit OK wegklicken. Danaach kann ich dann wenigstens das Programm schließen, allerdings bleibt die obere Fehlermeldung jetzt stehen. Diese läßt sich auch mit dem Taskmanager nicht wirklich schließen. Wenn ich die Meldung versuche mit dem Taskmanager zu schließe, dann erhalte ich die aus meinem ersten Post. Wenn ich diese über den Taskmanager schließe kommt diese wieder und so kann man lustig hin un her schalten. Wenn es schon daran scheitert das Programm zu starten, dann ist das Teil für mich unbrauchbar und damit raus. Vielleicht probier ich es später noch einmal. Schade eigentlich, denn ich hatte durchaus den Eindruck das es Lukas besser machen wollte (als KiCAD). Leider ist das bisher aus meiner Sicht schon im Ansatz stecken geblieben. KiCAD ließ sich bisher bei mir wenigsten starten. Das Erzeugen eines PCB's ist dann wieder eine andere Sache, da hat sich KiCAD bisher aber auch nicht mit Ruhm bekleckert. Dennoch habe ich mich entschlossen es noch einmal zu probieren und lade mir grad mal die aktuelle Version herunter. Befürchte aber es wieder im Disaster enden, da sich der Workflow von KiCAD mir nicht wirklich erschließt. Noch einmal kurz zu Horizon. Ich ziehe durchaus den Hut vor Lukas der sich an so eine Aufgabe herantraut, aber in dem gegenwärtigen Zustand ist Programmpaket für den geneigten User leider unbrauchbar. Ich bin schon der Meinung es wäre gut gewsen den einen oder anderen Rat von W.S. zu beherzigen, denn ganz so unrecht hat er nicht. Und ja Kritik schmerzt immer, aber wenn man ein Programm veröffentlicht und darum bittet das es die Allgemeinheit testet, dann muß man halt auch Kritik aushalten und annehmen. Noch habe ich die Hoffnung nicht ganz aufgeben das bei dem Projekt was Benutzbares herauskommt, aber das wird noch eine Weile dauern. Ein gutes Konzept zu Anfang hätte dem Projekt mit Sicherheit sehr gut getan. Ein KOnzept bedeutet ja nicht, das danach alles in Stein gemeißelt ist. Man kann es sehr wohl immer wieder (mit den gewonnenen Erfahrungen) erweitern. Aber es gibt erst mal eine Richtung und Prämissen vor die man der Reihe nach abarbeiten kann. Lukas hat die Planung leider versäumt und gleich in die Tasten gehauen. Wichtig wäre jetzt, das Lukas mal ein Paket baut, welches alles enthält was erforderlich ist - auch diesen ominösen Pool -, damit man erst einmal damit arbeiten kann und nicht rumfrickeln muß.
Zeno schrieb: > Sorry habe im letzten Post die Bildanhänge vergessen. ...wenn ich diese Fenster so sehe - worauf probierst du das (OS, OpenGl)? Ansonsten - vielleicht mal nicht Äpfeln mit Birnen vergleichen, KiCad ist ja schon relativ gut ‚abgehangen‘, und du benutzt sicherlich eine *Release*-Version. Horizon dürfte hingegen ‚alpha‘ sein. Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein Changelog scheint‘s auch nicht zu geben. Und m.E. wäre es auch bestimmt nützlich, in der Wiki-Doku auf Stand und vor allem die Voraussetzungen hinzuweisen, um Missverständnissen wie hier vorzubeugen...
Jan L. schrieb: > ...wenn ich diese Fenster so sehe - worauf probierst du das (OS, > OpenGl)? Das ist Win7 prof. 64Bit. Open GL müßte ich noch prüfen. Wenn es wirklich an OpenGl liegen sollte, dann wäre eine passende Fehlermeldung schon hilfreich. Die Fehlermeldung deutet aber auf ein ganz anderes Problem hin. Zu KiCAD: Ja natürlich habe ich eine Release Version benutzt. Ich wills ja auch noch mal probieren, derzeit scheitert es noch am Download der aus irgendwelchen Gründen derzeit schnarchlangsam ist (andere Downloads funktionieren normal). Wobei ich sagen muß Knapp 1GB für den KiCAD Installer ist schon heftig, zumal der gepackt sein dürfte. Pulsonix ist da deutlich sparsamer. Das bringt es installiert, also ausgepackt, auf knapp 400MB. Da fragt man sich schon wie die das hinbekommen.
Zeno schrieb: > Wobei ich sagen muß Knapp 1GB für den KiCAD Installer ist schon heftig, > zumal der gepackt sein dürfte. Das sind vor allem 3D-Modelle, die sowas fett machen. Bei mir hier liegen über 4 GiB an 3D-Modellen in ${INSTALLDIR}/share/kicad herum. Zeno schrieb: > Wenn es schon daran scheitert das Programm zu starten, dann ist das Teil > für mich unbrauchbar und damit raus. Ist halt im Moment wirklich Entwicklersoftware und eigentlich besser, wenn man es sich tatsächlich selbst compiliert. Die eine Fehlermeldung ("kein Datenträger im Laufwerk") sieht aber schon etwas seltsam aus, das dürfte eher ein Artefakt dessen sein, was dein System sonst so bereits hinter sich hat. Vielleicht ja auch irgendwas, was aus dem System stammt, auf dem die Windows-Version gebaut wird. Ich weiß schon, warum ich die Windows-Binaries für AVRDUDE lieber auf meinem FreeBSD mit einem Crosscompiler baue und nicht irgendwo auf einem tatsächlichen Windows :), aber das ist natürlich von der Komplexität her mit Horizon nicht vergleichbar.
Jörg W. schrieb: > Die eine Fehlermeldung ("kein Datenträger im Laufwerk") sieht aber schon > etwas seltsam aus, das dürfte eher ein Artefakt dessen sein, was dein > System sonst so bereits hinter sich hat. Das System dürfte so sehr gestresst worden sein. Bisher habe ich das System nur genutzt um ein 32Bit Programm, welches ich für die Firma geschrieben habe, auf einem 64Bit System zu testen. Das System ist quasi noch jungfreulich. Bis auf einen Virenscanner, MSWord und Visualstudio 2015 habe ich da keine weitere Software installiert. Das Problem liegt schon im Horizonkompilat, das mit irgendeiner Systemeinstellung nicht klar kommt und sich verrennt.
...Lukas kompiliert gerade, life zu sehen: https://ci.appveyor.com/project/carrotIndustries/horizon Vielleicht gibt‘s dann gleich ein neues Binary... ;)
Jan L. schrieb: > ...Lukas kompiliert gerade, life zu sehen: > https://ci.appveyor.com/project/carrotIndustries/horizon > > Vielleicht gibt‘s dann gleich ein neues Binary... ;) Hab diese neue Version gerade angetestet. Die Methode "Drag track" beim verschieben einer Leitung funkioniert wieder. Die Methode schiebt andere Leitungen weg, wenn die im Weg sind. Allerdings verschiebt die auch Vias die im Weg sind und sie schiebt auch weiter entfernte Leitungsstücke. Da hätte ich gerne die Wahl mit oder ohne andere Vias schieben. Ob das der Cern-router kann?
Zu den OpenGL-Anforderungen wurde hier ja schon fast alles gesagt, was es zu sagen gibt. Meine Windows-Testhardware ist ein ca. 10 Jahre alter Plastiklaptop mit Core 2 Duo und Nvidia GeForce 9650M GT. Darauf läuft horizon problemlos. Mittlerweile benutze ich einige OpenGL-Funktionen, wie z.B. glDrawElementsInstancedBaseInstance, die es offiziell erst seit OpenGL 4.0 gibt, aber bis jetzt von allem auf dem horizon überhaupt startet unterstützt wird. Das schöne an dieser Funktion ist, dass so mit einem einzigen Drawcall alle Instanzen des selben 3D-Modells auf dem Board gerendert werden können. Zeno schrieb: > Es poppen sofort 2 Fehlermeldungen auf. > Die erste Meldung lautet "No pools setup ....". Was das auch immer sein > mag. Das "No pools setup" ist weniger eine Fehlermeldung als mehr ein Hinweis, was man als nächstes tun könnte. Ohne die würde man mit einem ganz leeren Fenster dastehen. Aber ja, ein freundliche Begrüßungseite beim ersten Start ist durchaus sinnvoll. > Gleichzeitig mit dieser Meldung popt noch die im Anhang gezeigte > Fehlermeldung auf. Ich habe gar kein Laufwerk B. Ehrlich gesagt, keine Ahnung wie es dazu kommt. Die Fehlermeldung kommt von Windows selber, nicht von horizon. Wenn du magst, kannst du dem mit dem Process Monitor nachgehen und rausfinden worauf horizon hier genau zugreifen Will und wie der Stack an der Stelle ausschaut. Für die Runtime-Exception ist es hilfreich, wenn du horizon selber baust und aus der Msys-Shell startest: https://github.com/carrotIndustries/horizon/wiki/Building-horizon-on-Windows Jan L. schrieb: > Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein > Changelog scheint‘s auch nicht zu geben. Der offizielle Stand ist der master-branch im git, bzw. das letzte zip aus der Appveyor CI. Changelog sind die commit messages: https://github.com/carrotIndustries/horizon/commits/master Helmut S. schrieb: > Da hätte ich gerne die Wahl mit oder ohne andere Vias schieben. Ob das > der Cern-router kann? Unterstützt wird es vom router scheinbar, nur von horizon noch nicht. Der Titel "Halbfertig" hat sich in den letzten 1.5 Jahren doch sehr stark gewandelt, da horizon bereits für mittelgroße Projekte, wie z.B. Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" gut einsetzbar ist.
Lukas K. schrieb: > Der Titel "Halbfertig" hat sich in den letzten 1.5 Jahren doch sehr > stark gewandelt Vielleicht solltest du ja mal einen Fahrplan für eine Version 1.0 machen, sonst läufst du Gefahr, dass dein "halbfertiges" Horizon am Ende mehr kann als manches als "ganz fertig" verkaufte Werkzeug. :) Bei mir zu Hause (FreeBSD) habe ich leider im Moment link errors, da sind wohl ein paar Bibliotheken gerade inkonsistent (glibmm und Konsorten). Muss mal einen Rundum-Update-Schlag machen, damit ich wieder mal reinschauen kann.
Jörg W. schrieb: > Bei mir zu Hause (FreeBSD) habe ich leider im Moment link errors, da > sind wohl ein paar Bibliotheken gerade inkonsistent Zum Beispiel:
1 | dialogs/map_pin.cpp:10: error: undefined reference to 'Glib::operator<<(std::ostream&, Glib::ustring const&)' |
nm -D sagt mir, dass es in der Bibliothek gibt:
1 | 0000000000069520 T Glib::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, Glib::ustring const&) |
Es dürfte die Diskrepanz zwischen "std::__1::basic_ostream" und "std::ostream" sein, vermute ich mal. Vielleicht hat ja jemand eine schnelle Idee, an welcher Stelle da was veraltet ist. Vermutung: glibmm ist mit einem älteren Compiler compiliert worden, Horizon braucht einen relativ neuen. Irgendwie hasse ich diese Umbenennerei in std::__1 …
Lukas K. schrieb: >> Leider ist der ‚offizielle‘ Stand nicht klar gekennzeichnet, und ein >> Changelog scheint‘s auch nicht zu geben. > > Der offizielle Stand ist der master-branch im git, bzw. das letzte zip damit war eher gemeint, welchen "groben Reifegrad" der Autor seiner Software zuordnet. Derzeit könnte ein geneigter Wiki-Besucher dank der netten Bildchen etc. auf die Idee kommen, es handele sich hier um eine "langjährig ausgereifte und abgehangene Produktivsoftware". Und "wundert" sich dann vielleicht doch, dass da je nach Wochentag halt schonmal eine DLL fehlen könnte, oder etwas, was gestern noch ging, heute nichtr mehr tut. Stünde da aber z.B. klar "hey, hot stuff, bleeding edge, work in progress" bzw. "das ist hier alpha- oder beta-Status", dann weiss jeder Interessierte, was ihn erwarten kann - behaupte ich mal... :) Natürlich könnte ich auch völlig auf dem Holzweg sein, und der Autor geht von einer "bereits ausgereiften Produktivsoftware" aus - dann, äh, würde ich mich natürlich umorientieren müssen... ;-) > aus der Appveyor CI. Changelog sind die commit messages: > https://github.com/carrotIndustries/horizon/commits/master Ja, ok, das stimmt natürlich - allerdings kann der geneigte Programminteressierte damit aber womöglich weniger anfangen, als mit einem "Meta-Changelog", aus dem die für den User relevanten Änderungen wie "Push-and-shove-Router eingebaut" nicht untergehen zwischen 100erten gleichartigen Einträgen der Art "missing DLL xy added" etc. Aber vermutlich spielt sowas erst dann eher eine Rolle, wenn es mal "offizielle Releases" gegeben hat, und man dann evtl. doch die relevanten Unterschiede zum Folgerelease dokumentieren möchte...
Hallo W.S. W.S. schrieb: > Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. > hier in diesem Forum herumzudaddeln. Ich benutze ein altes Netbook von 2006. Es war schon vor jahren nicht mehr möglich, darauf ein aktuelles Windows zu installieren.... > Und ich komme genau wie du auch > nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Ich schon. Die Grafik kann zwar kein openGl, aber mit Mesa lässt sich openGL emulieren. Das ist schnarchlangsam, aber um mir unterwegs mal einen Schaltplan oder ein Layout/Bestückung anzusehen langt es. > Und was macht ihr, wenn Lukas übermorgen auf die Idee kommt, ein nettes > Feature aus OpenGL 4.6 zu benutzen? Nichts. Das ganze ist ja noch tief in der Betaphase. Da müssen halt radikale Schnitte noch möglich sein. Mit freundlichem Gruß: Bernd Wiebus alias dl1eic.de http://www.dl0dg.de
Bernd W. schrieb: > Das ist schnarchlangsam, aber um mir unterwegs mal > einen Schaltplan oder ein Layout/Bestückung anzusehen langt es. Genau für so etwas verwende ich auch ein Notebook. Es ist sehr praktisch, es direkt neben Lötkolben und Mikroskop liegen zu haben, um einen direkten Blick auf die EDA-Daten werfen zu können.
W.S. schrieb: > Ich benutze dieses knapp 7 Jahre alte Notebook eben auch wie du, um z.B. > hier in diesem Forum herumzudaddeln. Und ich komme genau wie du auch > nicht auf die Idee, ein EDA-System auf diesem Teil benutzen zu wollen. > Allerdings läuft die aktuelle Eagle-Bastler-Version 9.2 problemlos auf > diesem Notebook. Interessant, dass dieser Betrag ein -1 bekommt.
Holm T. schrieb: > M. W. schrieb: > [..] >> >> Interessant, dass dieser Betrag ein -1 bekommt. > > ...wirklich? > > Gruß, > > Holm Auf die -1 würde ich pfeifen. Ich habe auch einen alten Laptop auf dem horizon nicht mehr läuft. Da mus halt ein neuerer her oder den Desktop nehmen der eine nicht so alte Grafikkarte hat. Meiner Meinung nach geht es bei Desktops ab GTX560 und höher oder neuer. Die Idee von Lukas ist es möglichst viel von der Grafikkarte selber zeichnen zu lassen. Dinge wie zoomen im PCB-layout gehen dann rasend schnell. Dazu werden natürlich bestimmte Fähigkeiten der Treiber der Grafikkarte benötigt.
W.S. schrieb: > Manchmal frag ich mich, warum. Ich kann's mir nur > mit überschäumendem Hormon erklären. Aber was soll denn das. Ist das nicht schon vor Monaten in epischer Breite diskutiert worden? Man nimmt so ein Riesenprojekt wie z.B. ein EDA-System nur in Angriff, wenn man sehr gern, gut und viel programmiert. Menschen, die gern, gut und viel programmieren, wollen PROGRAMMIEREN -- und nicht endlos über Datenmodellen, Userinterfaces, Dateiformaten und sparsamem Umgang mit den Ressourcen grübeln. Die Datenmodelle, Userinterfaces und Dateiformate sind aber das, was die Benutzbarkeit der Software für den Endanwender ausmacht. Es gibt deswegen überhaupt keine Garantie, dass selbst der begnadetste Superprogrammierer Software erschafft, die die Benutzer gern nutzen wollen. Das mag man zu Recht bedauern, aber das ergibt sich einfach daraus, dass Lukas durch keinerlei Vertrag verpflichtet ist, eine Software mit bestimmten Leistungsmerkmalen zu schaffen. > Kluge Entscheidungen vor dem Schreiben der ersten > Codezeile sehen anders aus. Klugheit bemisst sich an der Tauglichkeit, einem bestimmten Ziel näherzukommen. Ob Lukas seinen Zielen näher kommt, kannst Du überhaupt nicht beurteilen. Du kannst lediglich feststellen, dass er nicht die Software erschafft, die DU (oder ich) gern verwenden würde -- aber DAS ist nun keine echte Überraschung. Lukas' Klugheit wird nicht daran gemessen, inwieweit er DEINEN Zielen näherkommt :) Ich gebe Dir ja in einigen Sachfragen durchaus Recht, ich verstehe nur nicht, warum Du von jemandem, der Drechseln zu seinem neuen Hobby erkoren hat, erwartest, er würde jetzt zur Zimmerei wechseln, nur weil Du einen neuen Dachstuhl brauchst. Das muss doch nicht jedesmal neu durchgekaut werden.
Jan L. schrieb: > ...das überhaupt "ausführlich begründen" zu müssen halte > ich schon für sehr konziliant, weil offensichtlich... Was ist denn daran offensichtlich? Die (wenigen) EDA-Systeme, die ich (mehr oder weniger) kenne, kranken primär an: - einer Bedienung, die zwischen "eigenwillig" und "gehirnkrank" einzuordnen ist, - einem übergreifenden Datenmodell, das durch komplette Abwesenheit glänzt und - mangelnder Interoperabilität. Inwieweit hilft da eine egoshooter-taugliche Graphik weiter?
Egon D. schrieb: > Jan L. schrieb: > >> ...das überhaupt "ausführlich begründen" zu müssen halte >> ich schon für sehr konziliant, weil offensichtlich... > > Was ist denn daran offensichtlich? Dass eine nicht-kommerzielle one-man-show es weder leisten kann noch höchstwahrscheinlich Lust dazu verspürt, Flohmarkt-Hardware zu unterstützen. Wie da der Bezug zur "egoshooter-tauglichen Graphik" reingerät, verschliesst sich mir.
Egon D. schrieb: > Du kannst lediglich feststellen, dass er nicht die > Software erschafft, die DU (oder ich) gern verwenden > würde Also damit beschreibst du genau DAS, was ich mit "Hormon" schon gesagt habe. Das Beipiel von Autofahrern, die kurz vor dem Abbiegen ihrem Motor nochmal so richtig die Sporen geben, weil ihnen eben das Mütchen danach ist, hatte ich ja schon genannt. Aber sag mal, findest du denn nicht, daß das Programmieren eines derartigen Projektes OHNE Anzielen einer breiten Verwendung irgendwie.. nun ja, eher etwas eigentümlich ist? Oder nennen wir es mutwillig? Etwa vergleichbar mit dem zweiten Gang bis Anschlag "una musica dolce suonava soltanto per me"? W.S.
W.S. schrieb: > Aber sag mal, findest du denn nicht, daß das Programmieren eines > derartigen Projektes OHNE Anzielen einer breiten Verwendung irgendwie.. > nun ja, eher etwas eigentümlich ist? Das ist doch nur deine Wahrnehmung, dass er keine breite Verwendung anzielen würde. Selbst du gibst ja zu, dass du diesen ältlichen Computer nur ausgekramt hast, damit du eine reale Hardware vorweisen kannst, auf der das nicht läuft – obwohl du diese Hardware am Ende nicht tatsächlich dazu benutzen wölltest, EDA damit zu machen. Weil sie eben auch für Software, die darauf noch läuft, lahm genug ist, als dass das gar keinen Spaß macht, das wirklich darauf zu tun.
Helmut S. schrieb: > Holm T. schrieb: >> M. W. schrieb: >> [..] >>> >>> Interessant, dass dieser Betrag ein -1 bekommt. >> >> ...wirklich? >> >> Gruß, >> >> Holm > > Auf die -1 würde ich pfeifen. Exakt! >Ich habe auch einen alten Laptop auf dem > horizon nicht mehr läuft. Da mus halt ein neuerer her oder den Desktop > nehmen der eine nicht so alte Grafikkarte hat. Meiner Meinung nach geht > es bei Desktops ab GTX560 und höher oder neuer. Es ist völliger Blödsinn sich bei Mikeysoft darüber beklagen zu wollen das irgend ein Programm von denen auf einem Alten Topplappen nicht mehr läuft, hier meint man aber damit Eindruck schinden den zu können. > > Die Idee von Lukas ist es möglichst viel von der Grafikkarte selber > zeichnen zu lassen. Dinge wie zoomen im PCB-layout gehen dann rasend > schnell. Dazu werden natürlich bestimmte Fähigkeiten der Treiber der > Grafikkarte benötigt. Das ist ja auch vernünftig. In allererster Linie schreibt er das Programm für sich selbst, nach seinen Bedürfnissen. (alle Achtung!!) Ich halte es für absolut nicht verwunderlich wenn er da nun nicht die Befindlichkeiten jeder religiösen Minderheit berücksichtigt die sich gerade für am Wichtigsten hält. Die Bewertung? Drauf geschi..... Gruß, Holm
Jan L. schrieb: > Egon D. schrieb: >> Jan L. schrieb: >> >>> ...das überhaupt "ausführlich begründen" zu müssen >>> halte ich schon für sehr konziliant, weil >>> offensichtlich... >> >> Was ist denn daran offensichtlich? > > Dass eine nicht-kommerzielle one-man-show es weder > leisten kann noch höchstwahrscheinlich Lust dazu > verspürt, Flohmarkt-Hardware zu unterstützen. Verstehe ich nicht. Software, die auf einer alten Mühle anständig läuft, tut es ganz sicher auch auf einer aktuellen Maschine. Software, die auf einer aktuellen Maschine nur anständig läuft, ist auf einer alten Mühle nicht verwendbar -- dazu müsste sie auf einer aktuellen Maschine irrsinnig schnell sein :) Es geht überhaupt nicht darum, besondere, nicht leistbare Aufwendungen zu tätigen, um uralte, exotische Hardware zu unterstützen -- es geht nur darum, mit den Ressourcen nicht um sich zu werfen. > Wie da der Bezug zur "egoshooter-tauglichen Graphik" > reingerät, verschliesst sich mir. Der kommt durch Helmuts Bemerkung über "rasend schnelles zoomen" zustande. Ich sage es gerne nochmal, auch wenn Du es nicht hören willst: An der EDA-Software, die ich kenne, hat mir NIE irgend eine Graphikfähigkeit gefehlt, sondern immer nur Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. Sie sind aber (vermutlich) deshalb nicht realisiert worden, weil das (zumindest bei der preiswerten Software) ökonomisch einfach nicht drin war.
Egon D. schrieb: > Verstehe ich nicht. Dann geh' mal paar Postings zurück: Beitrag "Re: Neues, halbfertiges Elektronik-CAD-Programm" Dort hat Helmut noch einmal kurz zusammengefasst, warum Lukas sich so entschieden hat. Man könnte es auch noch kürzer zusammenfassen: Konzentration auf das Wesentliche, statt sich in Nebenschauplätzen zu verlieren, nur um Hardware aus dem letzten Jahrhundert auch noch unterstützen zu können. Als One-Man-Show muss man halt sehen, wo man seine Ressourcen investiert. > Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. Dann hast du wohl noch nie mit einem EDA-System mit 3D-Darstellung gearbeitet – egal, ob nun Kicad oder Altium. Das hätte man nämlich auf der Hardware von vor 20 Jahren einfach nicht machen können, ist aber eine wirklich gute Hilfe, wenn man das einmal benutzen durfte. Kann einem gut und gern mal einen Prototypenzyklus einsparen, bei dem man sonst nur festgestellt hätte, dass Bauteil xyz am Ende doch mit einem Gehäusevorsprung kollidiert … Möchte ich nicht mehr missen, ehrlich.
Egon D. schrieb: > Jan L. schrieb: > >> Egon D. schrieb: >>> Jan L. schrieb: >>> >>>> ...das überhaupt "ausführlich begründen" zu müssen >>>> halte ich schon für sehr konziliant, weil >>>> offensichtlich... >>> >>> Was ist denn daran offensichtlich? >> >> Dass eine nicht-kommerzielle one-man-show es weder >> leisten kann noch höchstwahrscheinlich Lust dazu >> verspürt, Flohmarkt-Hardware zu unterstützen. > > > Verstehe ich nicht. > > Software, die auf einer alten Mühle anständig läuft, > tut es ganz sicher auch auf einer aktuellen Maschine. > > Software, die auf einer aktuellen Maschine nur anständig > läuft, ist auf einer alten Mühle nicht verwendbar -- > dazu müsste sie auf einer aktuellen Maschine irrsinnig > schnell sein :) Dein Denkfehler liegt nicht in der Hardware, sondern in der Software begründet. WS Rechner funktioniert nicht, weil seine Treibersoftware auf diesem Rechner unzureichend ist. Das hat mir Recourcenverschwendung nicht viel zu tun und wenn es das hat, dann ist Lukas der falsche Ansprechpartner. Läufst denn auf diesem Rechner mit Linux und Mesa? Wen ja: bitte sehr. Wenn langsam: Du wolltest das Ding verwenden. Wenn nicht: der Taschenrechner ist wirklich zu alt. Keine Hände, keine Kekse! Gruß, Holm
W.S. schrieb: > Egon D. schrieb: >> Du kannst lediglich feststellen, dass er nicht die >> Software erschafft, die DU (oder ich) gern verwenden >> würde > > Also damit beschreibst du genau DAS, was ich mit > "Hormon" schon gesagt habe. Nicht ganz. Dein "hormongesteuert" drückt eine negative Wertung aus, die meiner Formulierung (hoffentlich) fehlt. Auch wenn ich betrübt über Lukas' Entscheidung bin, so muss ich ihn deshalb nicht gleich beleidigen. > Aber sag mal, findest du denn nicht, daß das > Programmieren eines derartigen Projektes OHNE Anzielen > einer breiten Verwendung irgendwie.. nun ja, eher etwas > eigentümlich ist? Nein -- und zwar aus zwei Gründen. Zum einen: "Breit" liegt im Auge des Betrachters. Selbst wenn von den -- aus der Luft gegriffen -- 10 Millionen EDA-Leuten nur eine verschwindenden Minderheit von 0.1% horizon verwenden, wären das 10'000 Nutzer. Wenn solche verbitterten Rentner wie Du und ich nicht zu diesen 0.1% gehören, so wird das für Lukas kein Problem sein... :) Zum zweiten: Wer die Diskussionen in Newsgroups und Foren kennt, der weiss, dass man sich keinesfalls von der "öffentlichen Meinung" abhängig machen darf. Es ist ratsam, auf fundierte Kritik zu hören -- aber mehr auch nicht, ansonsten kommt man zu gar nichts. Es ist also durchaus eine gute Idee, selbst ein klares, an den eigenen Bedürfnissen orientiertes Konzept zu haben, an dem man sich orientiert. Wenn dann noch andere Nutzer dazukommen, die mit den eigenen Grundwerten übereinstimmen -- um so besser. Du kritisierst meiner Meinung nach Lukas auf einer Ebene, auf der er nichts falsch macht.
Leute, das hier jemand (Lukas) nicht nachgedacht hat und einfach das neueste benutzt was ihm untergekommen ist kann ich verstehen. Auch wenn ich es sehr bedauere, weil ich mit meiner Onboard Grafikkarte nicht teilhaben kann. Eine 2. Karte kann ich nicht mehr einbauen, weil kein Platz. Ein neuer Rechner kommt mir nur wegen einem CAD System nicht ins Haus. Ich kenne noch andere Projekte wo ich schon dem Entwickler vor 10 Jahren gesagt hatte das seine Entscheidung (.NET + XNA) eine Dummheit ist. Nun heute ist sein Produkt zwar fertig, aber er hat sich selber in die WINDOWS Ecke gedrückt wobei alle mitbewerber auch Linux und MAC können. QT und Konsorten, sind da halt einfach besser porttierbar. Achso, ratet mal was öfter benutzt wird.
Klaus schrieb: > Leute, das hier jemand (Lukas) nicht nachgedacht hat und einfach das > neueste benutzt was ihm untergekommen ist kann ich verstehen. Ist allerdings nicht der Fall. Er hat nachgedacht – und deshalb das benutzt, was seit 10 Jahren (inzwischen) am Markt verfügbar ist.
Jörg W. schrieb: > Dann hast du wohl noch nie mit einem EDA-System > mit 3D-Darstellung gearbeitet – egal, ob nun Kicad > oder Altium. ... oder Target. -- Doch, das habe ich. > Das hätte man nämlich auf der Hardware von vor 20 Jahren > einfach nicht machen können, ist aber eine wirklich gute > Hilfe, wenn man das einmal benutzen durfte. Kann einem > gut und gern mal einen Prototypenzyklus einsparen, bei > dem man sonst nur festgestellt hätte, dass Bauteil xyz > am Ende doch mit einem Gehäusevorsprung kollidiert … > Möchte ich nicht mehr missen, ehrlich. <Seufz> Ich weiss wirklich nicht, was daran so schwer zu verstehen ist: Natürlich das das Feature SINNVOLL -- aber es ist mir nicht wichtig genug, um andere Eigenschaften der Software dafür zu opfern. Ist das so schwer zu begreifen?
Holm T. schrieb: > Dein Denkfehler liegt nicht in der Hardware, sondern > in der Software begründet. WS Rechner funktioniert > nicht, weil seine Treibersoftware auf diesem Rechner > unzureichend ist. Es geht (mir) nicht um W.S.'s Rechner, sondern um die Graphik-Fixierung von horizon. Mir hat bei den EDA-Systemen, mit denen ich bisher zu tun hatte, NIE irgend eine Graphikfähigkeit gefehlt. Ergo sind alle Argumente, die auf die überlegenen Graphikfähigkeiten von horizon zielen, für mich gleichwertig zu leeren Zeichenketten. Das hat einfach keine Priorität. Wenn etwas, was ich nicht brauche, einfach so dabei ist, dann stört das nicht. Wenn ich aber für etwas, das ich nicht benötige, zusätzliche Komplikationen in Kauf nehmen muss, dann ist der Spaß zu Ende.
Egon D. schrieb: > <Seufz> Ich weiss wirklich nicht, was daran so schwer zu verstehen ist: > Natürlich das das Feature SINNVOLL -- aber es ist mir nicht wichtig > genug, um andere Eigenschaften der Software dafür zu opfern. Naja, was genau „opferst“ du denn? Aber eigentlich ist das jetzt so langsam egal, dreht sich eh' nur alles im Kreise. Zum Glück arbeitet Lukas unabhängig von all diesem Palaver daran wohl weiter. ;-) Das ist das beste, was er tun kann. Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur deshalb, weil Horizon sich auf einen Mindeststandard an OpenGL-Level festgelegt hat, ihm die Nutzer ausbleiben würden. Die meisten potenziellen Nutzer werden das vermutlich nicht einmal bemerken, dass diese Anforderung existiert, und sie werden Horizon nach ganz anderen Kriterien bewerten, ob sie damit dann arbeiten möchten oder nicht.
Jörg W. schrieb: >> Dinge, die man auch auf Hardware von vor 20 Jahren hätte realisieren können. > > Dann hast du wohl noch nie mit einem EDA-System mit 3D-Darstellung vor allem - er hat sicherlich auch noch nie eines programmiert. Würde ich heute mit der Erstellung irgendeiner Anwendung anfangen, dann würde ich ganz sicher die APIs von heute nehmen, die mir Basisfunktion X und Y abnehmen, und nicht die APIs von vorgestern, bei denen ich womöglich noch langweilige Dinge wie Bresenham zu Fuss basteln müsste, nur damit's auch auf Herkulesgrafik noch täte... :-)
Jan L. schrieb: > Jörg W. schrieb: >>> Dinge, die man auch auf Hardware von vor 20 Jahren >>> hätte realisieren können. >> >> Dann hast du wohl noch nie mit einem EDA-System mit >> 3D-Darstellung [gearbeitet] > > vor allem - er hat sicherlich auch noch nie eines > programmiert. Wird schätzungsweise auch nie passieren. Unwahrscheinlich, aber dennoch möglich wäre immerhin, dass ich mal an einem EDA-System arbeite. Das bekommt mit hoher Wahrscheinlichkeit einen 3D-Export, so dass man einen externen Viewer aufrufen kann, wenn einem das wichtig ist. Das EDA-System ist natürlich auch ohne 3D-Viewer benutzbar.
Jörg W. schrieb: > Egon D. schrieb: >> <Seufz> Ich weiss wirklich nicht, was daran so >> schwer zu verstehen ist: Natürlich das das Feature >> SINNVOLL -- aber es ist mir nicht wichtig genug, >> um andere Eigenschaften der Software dafür zu opfern. > > Naja, was genau „opferst“ du denn? Modularität beispielsweise. Aber das ist vor Monaten alles schon durchgekaut worden. > Aber eigentlich ist das jetzt so langsam egal, Eigentlich nicht. Es ist nicht egal -- man kann es nur nicht ändern. Das ist nicht dasselbe. > Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur > deshalb, weil Horizon sich auf einen Mindeststandard > an OpenGL-Level festgelegt hat, ihm die Nutzer > ausbleiben würden. Nein, deshalb nicht. Die OpenGL-Sache ist nur das Symptom, nicht die Ursache. > Die meisten potenziellen Nutzer werden das vermutlich > nicht einmal bemerken, dass diese Anforderung existiert, > und sie werden Horizon nach ganz anderen Kriterien > bewerten, ob sie damit dann arbeiten möchten oder nicht. Richtig. Sie werden sie nach den Kriterien bewerten, die sie an x-beliebige fertige Software anlegen: Entweder sie gefällt ihnen, dann werden sie sie verwenden, oder sie gefällt ihnen nicht, dann verwenden sie sie eben nicht. Eine Möglichkeit, diese Software grundlegend mitzugestalten, hatten sie ja nicht. Und -- nein, das ist keine echte Kritik. Es ist nur eine etwas enttäuschte Feststellung.
Egon D. schrieb: > Eine Möglichkeit, diese Software grundlegend mitzugestalten, hatten sie > ja nicht. In Teilen schon, allerdings nicht im Konzept. Aber das ist OK für eine One-Man-Show. Lukas wollte ja in erster Linie etwas für sich machen, weil er mit dem Existierenden unzufrieden war. Er stellt es außerdem allen zur Verfügung.
Egon D. schrieb: > Das bekommt > mit hoher Wahrscheinlichkeit einen 3D-Export, so dass > man einen externen Viewer aufrufen kann, wenn einem > das wichtig ist. > > Das EDA-System ist natürlich auch ohne 3D-Viewer > benutzbar. "3D-Export", "3D-Viewer"... klingt, als würdest du davon ausgehen, dass die Festlegung auf OpenGL 3.2 als Mindeststandard irgendwie mit "3D" zu tun hat. Hat es aber eher nicht... Ob du nun den "3D-Viewer" weglässt, oder nicht - OpenGL3.x malt dir halt ohne Krücken automatisch hübsche runde Ecken (und vieles andere) ins Canvas... :)
Jörg W. schrieb: > Egon D. schrieb: >> Eine Möglichkeit, diese Software grundlegend >> mitzugestalten, hatten sie ja nicht. > > In Teilen schon, allerdings nicht im Konzept. Tja... ich hatte mal so einen Chef. Der Mann war fachlich gut und sehr vielseitig, aber er hatte die Macke, das Grundkonzept für unsere Geräte in seiner kompletten Breite festlegen zu wollen -- also das physikalische Prinzip, die Werkstoffauswahl, die Mechanik, die analoge Hardware, die Software. Völlig unnötig zu erwähnen, dass der Mann zwar besser war als jeder Einzelne von uns Technikern -- aber er war nicht besser als wir alle zusammen. Folge: Seine Konzepte waren i.d.R. untauglich; die Geräte nur verkaufbar, weil die Techniker massiv Arbeit in die Verbesserung gesteckt haben. > Aber das ist OK für eine One-Man-Show. Ich kritisiere den Verlauf dieser Ein-Mann-Show nicht. Ich bin enttäuscht davon, dass es erklärtermaßen eine solche bleiben soll.
Jan L. schrieb: > Egon D. schrieb: >> Das bekommt >> mit hoher Wahrscheinlichkeit einen 3D-Export, so dass >> man einen externen Viewer aufrufen kann, wenn einem >> das wichtig ist. >> >> Das EDA-System ist natürlich auch ohne 3D-Viewer >> benutzbar. > > "3D-Export", "3D-Viewer"... klingt, als würdest du > davon ausgehen, dass die Festlegung auf OpenGL 3.2 als > Mindeststandard irgendwie mit "3D" zu tun hat. Hat es > aber eher nicht... Ach ja, richtig, da war was... > Ob du nun den "3D-Viewer" weglässt, oder nicht - OpenGL3.x > malt dir halt ohne Krücken automatisch hübsche runde Ecken > (und vieles andere) ins Canvas... :) Ja, naja, und genau das ist der Punkt: Die hübschen runden Ecken mögen zwar hübsch sein -- aber sie sind völlig verzichtbar. Ich würde auch eine Xlib-basierte Software verwenden, wenn sie das macht, was ich brauche. Eine Bauteilbibliothek, die den Namen verdient, ist aber NICHT nur hübsch, sondern essenziell. Da die Prioritäten auf "hübsch aussehen" liegen und nicht auf "essenziell", taugt die Software für mich nicht, und da Mitarbeit, die über Kosmetik hinausgeht, nicht gewünscht ist, muss ich mich halt anderweitig umsehen.
Egon D. schrieb: > Ja, naja, und genau das ist der Punkt: Die hübschen runden > Ecken mögen zwar hübsch sein OMG, das war doch nur ein Beispiel; hier (für dich) substantieller vielleicht: OGL3.x malt dir das Grid automatisch. Und sicherlich noch einiges an "Routine" mehr... > Eine Bauteilbibliothek, die den Namen verdient, ist aber > NICHT nur hübsch, sondern essenziell. wo kommt denn jetzt die "Bauteilebibliothek" auf einmal her? Da geht ja Flöhe hüten einfacher... > Da die Prioritäten auf "hübsch aussehen" liegen und nicht > auf "essenziell", taugt die Software für mich nicht, und > da Mitarbeit, die über Kosmetik hinausgeht, nicht gewünscht > ist, muss ich mich halt anderweitig umsehen. jetzt wird's aber etwas wunderlich, finde ich - das Ding liegt im Github, und erst wenn dein dritter brauchbarer Pullrequest abgelehnt wird, gäbe es überhaupt mal Anlass, über der Grad der gewünschten Mitarbeit zu spekulieren. Und dann gehst du eben hin und klonst das Repo, und stellst deine Version der Allgemeinheit zur Verfügung...
Egon D. schrieb: > Da die Prioritäten auf "hübsch aussehen" liegen und nicht auf > "essenziell", Das ist allerdings eine recht unfaire Unterstellung. Lukas hat klar und deutlich Konzepte hinter seiner Implementierung, das ist nicht „irgendwie drauf los programmiert“. Die Konzepte gehen auch deutlich über eine zeitgemäß aussehende Grafik hinaus. > taugt die Software für mich nicht Das ist eine Schlussfolgerung für dich, aber hat mit „hübsch aussehen“ nun nichts zu tun. Es heißt lediglich, dass Lukas' Konzepte nicht die sind, die du von so einer Software erwarten würdest. Andere Anwender können das völlig anders sehen.
Jörg W. schrieb: > Lukas hat klar und deutlich Konzepte hinter seiner > Implementierung, Das habe ich nirgendwo bestritten. > das ist nicht „irgendwie drauf los programmiert“. War nie meine Behauptung. Verwechselst Du mich mit W.S.? > Die Konzepte gehen auch deutlich über eine zeitgemäß > aussehende Grafik hinaus. Mag sein. Als das vor Monaten hier diskutiert wurde, hieß es z.B. "SPICE-Export ist nicht vorgesehen." Auch wenn ich kein großer SPICE-Fan bin -- aber das geht mir etwas zu weit. Austauschbarkeit von Symbolen, Footprints, Schaltplänen und Layouts mit anderer Software hatte, soweit ich mich entsinne, auch keine Priorität. Von projektübergreifend kompatiblen Schnittstellen, so dass man den horizon-Schaltplaneditor mit pcb-rnd kombinieren kann, ist sowieso keine Rede. Also: Das übliche. Alles, was mit herkömmlicher Software nicht geht, geht mit horizon auch nicht. >> taugt die Software für mich nicht > > Das ist eine Schlussfolgerung für dich, aber hat mit > „hübsch aussehen“ nun nichts zu tun. Es heißt lediglich, > dass Lukas' Konzepte nicht die sind, die du von so einer > Software erwarten würdest. Andere Anwender können das > völlig anders sehen. Ich verstehe nicht ganz, warum Dich meine Einschätzung so aufbringt. Jedermann hat nur eine begrenzte Arbeitskraft. Was ich von außen sehe, das ist: Das GUI von horizon sieht ziemlich geil aus. Funktionalität, die ich für wichtig halte, spielt keine Rolle. Ob das nur Korrelation oder schon Kausalität ist, will ich nicht beurteilen -- es ist aber auch egal.
Jörg W. schrieb: > Im Gegensatz zu W.S. sehe ich sowieso nicht, dass nur deshalb, weil > Horizon sich auf einen Mindeststandard an OpenGL-Level festgelegt hat, > ihm die Nutzer ausbleiben würden. Jörg, versuche doch bitte mal ganz einfach ruhig mitzulesen, ohne auf alles allergisch zu reagieren. Egon hat lediglich das gesagt: Egon D. schrieb: > Du kannst lediglich feststellen, dass er nicht die > Software erschafft, die DU (oder ich) gern verwenden > würde -- aber DAS ist nun keine echte Überraschung. Eben, es ist für niemanden eine Überraschung, insbesondere nicht für mich - siehe meine früheren Einlassungen. Dennoch frage ich mich nach dem WARUM. Irgend ein 'warum' muß es ja geben. ODER ETWA NICHT? Ich habe mein ganzes Leben lang meine Entwicklungen genau SO betrieben, daß ich mit einer möglichst großen Käuferschicht rechnen kann. Sowas ist derart lebensnotwendig, daß allenfalls jemand aus dem öff.Dienst es nicht versteht. Aber jeder, der seine Brötchen selbst verdienen muß, versteht das sofort. Warum also macht Lukas das so wie er es macht? Ich sehe da zwei Gründe: die pure Lust am Programmieren (die ich in jungen Jahren ebenfalls in den Knochen gespürt habe) und das Bestreben, mal was vorzulegen, womit man am Beginn seines Berufslebens Eindruck machen kann und folglich schneller und höher hinaus kommt. Beides sind wirklich ernsthafte und zu akzeptierende Beweggründe - wenn man mal drüber nachdenkt! Aber bei beiden Gründen tritt die tatsächliche Verbreitung des Produkts in den Hintergrund - das wäre mein Punkt, den du jedoch indirekt in Frage gestellt hast. Es gäbe auch noch einen anderen Grund: die innere Verärgerung darüber, wie es andere Hersteller machen und daraus der Ansporn, eben die Punkte, die einem selber mißfallen mal exemplarisch besser zu machen. Aber dann sind Hardwareangelegenheiten wie OpenGL eher nebensächlich. Also: Ich gönne dem Lukas die beiden ersten Gründe voll und ganz, da hat er meine Sympathie. Ich kann auch Grund #4 verstehen. Aber Grund #3 sollte dabei nicht untergehen, möglicherweise bedarf es nur eines kleinen Kringels im Programm. Es wäre jedenfalls SCHADE. Bedenke mal, daß es auch Rückwärts-Inkompatibilitäten zwischen OpenGL 3 und 4 gibt, so daß Lukas in jedem Falle irgendwann eine Abstraktion oberhalb OpenGL und darunter eine Versionsbehandlung wird einführen müssen. Da ist 2.1 versus 3.3 nur die Spitze des Eisberges. So, denk mal ganz ruhig drüber nach. W.S.
Egon D. schrieb: > Als das vor Monaten hier diskutiert wurde, hieß es z.B. "SPICE-Export > ist nicht vorgesehen." Auch wenn ich kein großer SPICE-Fan bin -- aber > das geht mir etwas zu weit. „nicht vorgesehen“ heißt ja erstmal nicht, dass man das nicht haben kann, sondern nur, dass er sich darum (zumindest derzeit) nicht kümmert. Wäre ein Punkt, wo jemand anders eingreifen könnte, wenn er möchte, denn dass es konzeptionell gar nicht möglich ist, das zu realisieren, vermute ich zumindest nicht. So ein Export ist ja erstmal nur eine Datenkonvertierung, das kann man am Ende sogar in einer Scriptsprache hinlegen. > Austauschbarkeit von Symbolen, Footprints, Schaltplänen und Layouts mit > anderer Software hatte, soweit ich mich entsinne, auch keine Priorität. Hätte ich mir an seiner Stelle auch nicht als Priorität gesetzt. Das ist nämlich ein Fass ohne Boden. Habe sowas schon mal bei BAE gesehen, welches Eagle-Import-Scripte hat. Diskutiert hatten wir darüber auch schon, kann ich mich erinnern. > Von projektübergreifend kompatiblen Schnittstellen, so dass man den > horizon-Schaltplaneditor mit pcb-rnd kombinieren kann, ist sowieso keine > Rede. Wäre die Frage, wofür man sowas braucht. Und falls es jemand braucht, was derjenige denn an Horizon ändern müsste, um so eine Schnittstelle zu haben. Die einzige Schnittstelle, die ich mir „projektübergreifend kompatibel“ jemals bei EDA-Software gewünscht hätte, wäre ein mögliches Anflanschen des BAE-Autorouters … der ist wirklich gut. Kann man aber vergessen, denn die BAE-Schnittstelle ist nicht offengelegt. Ansonsten ist es mir lieber, wenn der Board-Editor eines Systems sinnvoll und gut zum Schaltplaneditor passt.
Jan L. schrieb: > Egon D. schrieb: >> Ja, naja, und genau das ist der Punkt: Die hübschen >> runden Ecken mögen zwar hübsch sein > > OMG, das war doch nur ein Beispiel; hier (für dich) > substantieller vielleicht: OGL3.x malt dir das Grid > automatisch. Und sicherlich noch einiges an "Routine" > mehr... Nein, das ist für mich nicht substanzieller. Ein Gitter konnte man auch vor OpenGL schon zeichnen -- und hat das auch getan. Dass das jetzt in 1µs statt in 1ms abläuft, interessiert mich ehrlich gesagt nicht. >> Eine Bauteilbibliothek, die den Namen verdient, ist >> aber NICHT nur hübsch, sondern essenziell. > > wo kommt denn jetzt die "Bauteilebibliothek" auf > einmal her? "OMG, das ist ein Beispiel!" Und zwar ein Beispiel für eine Sache, die mir wesentlich wichtiger ist als eine geile Graphik. >> Da die Prioritäten auf "hübsch aussehen" liegen und >> nicht auf "essenziell", taugt die Software für mich >> nicht, und da Mitarbeit, die über Kosmetik hinausgeht, >> nicht gewünscht ist, muss ich mich halt anderweitig >> umsehen. > > jetzt wird's aber etwas wunderlich, finde ich - das Ding > liegt im Github, und erst wenn dein dritter brauchbarer > Pullrequest abgelehnt wird, gäbe es überhaupt mal Anlass, > über der Grad der gewünschten Mitarbeit zu spekulieren. Da muss ich nicht spekulieren. Es gibt keinen Zweifel daran, dass die Art der Mitarbeit, die ich bieten könnte, nicht gewünscht wird. > Und dann gehst du eben hin und klonst das Repo, und > stellst deine Version der Allgemeinheit zur Verfügung... Das werde ich aus dem einfachen Grund nicht tun, weil ich von C++ keine Ahnung habe. Wenn, dann ist es deutlich wahrscheinlicher, dass ich mal zu pcb-rnd Kontakt aufnehme, denn dort scheint mir die Einstiegsschwelle WESENTLICH niedriger.
W.S. schrieb: > Aber bei beiden Gründen tritt die tatsächliche > Verbreitung des Produkts in den Hintergrund - das > wäre mein Punkt, den du jedoch indirekt in Frage > gestellt hast. Ich kann Dir offen gestanden nicht folgen. Du hast weiter oben gefragt, ob es denn nicht eigenartig wäre, eine Software zu erstellen und zu publizieren, an deren Verbreitung man nicht wirklich interessiert ist. Meine Antwort war: Nein, das ist nicht eigenartig. Jetzt lieferst Du selbst Gründe dafür, warum ein Mensch genau das tut: Software erstellen, an deren Verbreitung er nicht vorrangig interessiert ist. Wo siehst Du jetzt den Widerspruch? Ich habe auch mindestens ein Projekt, bei dem ich zwar gern Feedback, gute Ideen und unbezahlte Tester hätte, aber nicht wirklich gern sehen würde, wenn andere die Software kommerziell einsetzen. Nun ja... beides gleichzeitig geht halt nicht :)
Hey, ich bin dabei alternativen für Eagle zu evaluieren und da sehen mir KiCad und Horizon interessant aus. Den aktuelle Stand bekomme ich jedoch leider nicht compiliert (Debian Stretch)
1 | src/parameter/program_polygon.hpp:8:7: error: no matching function for call to ‘horizon::ParameterProgram::ParameterProgram()’ |
2 | In file included from src/pool/padstack.hpp:9:0, |
3 | from src/package/pad.hpp:5, |
4 | from src/pool/package.hpp:14, |
5 | from src/pool/package.cpp:1: |
6 | |
7 | src/pool/padstack.cpp:13:112: error: use of deleted function ‘horizon::ParameterProgramPolygon::ParameterProgramPolygon()’ |
8 | Padstack::MyParameterProgram::MyParameterProgram(Padstack *p, const std::string &c) : ParameterProgram(c), ps(p) |
Vielleicht interessiert dies ja die Entwickler und lässt sich leicht beheben.
Malte _. schrieb: > Vielleicht interessiert dies ja die Entwickler und lässt sich leicht > beheben. Ist behoben und sollte in Zukunft auch nicht mehr so einfach passieren, da die CI jetzt auch mit debian stretch statt ubuntu artful baut.
Ein paar Worte zu OpenGL an der Stelle noch: OpenGL kommt sowohl zum Rendern von 2D-Ansichten wie Schaltplan und Board zum Einsatz, als auch für die 3D-Vorschau. Bei letzterer ergeben sich mit Geometry shadern ganz nette Möglichkeiten, so müssen z.B. für "Boden" und "Deckel" der Layer insgesamt nur ein Satz Dreieecke auf die GPU geladen werden, das Duplizieren nach oben und unten geschieht dann im geometry shader auf der GPU. Auch für die Wände wird nur die Kontur auf die GPU geladen, die macht daraus dann die Dreieecke für die Wand. In der 2D-Ansicht bekommt man Dinge wie Alpha-Transparenz quasi für Umme. Auch die Auswahl-Boxen werden weitestgehend in Shadern auf der GPU gemalt. Nun mag einer entgegnen, das ginge ja auch ohne OpenGL in Software, was grundsätzlich auch stimmt. Allerdings müsste ich mir dann mehr Gedanken darüber machen, was mit der darunter liegenden Grafik geschieht, wenn die Auswahl-Box wieder weg ist. Mit OpenGL alles kein Problem und ich kann mich auf die wirklich wichtigen Dinge konzentrieren. Zumal (viele) Computer der letzten 10 Jahre einen geeigneten Coprozessor (GPU) haben, der genau für solche Grafikaufgaben gemacht ist. Wär' ja schade, wenn der sich langweilt.
Lukas K. schrieb: > Zumal (viele) Computer der letzten 10 Jahre einen geeigneten Coprozessor > (GPU) haben, der genau für solche Grafikaufgaben gemacht ist. Wär' ja > schade, wenn der sich langweilt. Dein Ansatz ist schon richtig - Wenn W.S. für Android entwickeln würde, dann vmtl die nächsten 10 Jahre noch für Android 4 SCNR ;-)
Lukas K. schrieb: > In der 2D-Ansicht bekommt man Dinge wie Alpha-Transparenz quasi für > Umme. Darauf möchte ich auch nicht mehr verzichten müssen. :) Ohne OpenGL ist das nicht nur Aufwand in der Programmierung, sondern auch wirklich vermplemperte Rechenzeit der CPU, die sie für besseres benutzen kann.
Ich bin nochmal alle Argumente hier durchgegegangen und finde eigentlich nur eine Quintessenz daraus: Man programmiere sich sein eigenes tool zum Selbstzweck und aus Spass am Programmieren. Sinn macht es keinen. Wer ernsthaft Funktionalität verbessern will, der muss sich in ein bestehendes Programm einklinken und z.B.: * Ein ULP für EAGLE schreiben, welches die Funktionen hat * Einen alternativen Editor für KiCAD entwickeln * Einen alternativen Autorouter / Placer schreiben * Einen Checker zur Einhaltung bestimmter Regeln im Sonderplatinenbau entwickeln, der übers Design rattert * und und und Gerade KiCAD bietet uns damit alle Möglichkeiten. Die Sourcen sind mehr oder weniger frei verfügbar und auch dokumentiert. Dort würde ich einhaken, weil sich da auch sofort Unterstützer finden, die ein Projekt weiterziehen, wenn man selber nicht mehr kann.
M. W. schrieb: > Gerade KiCAD bietet uns damit alle Möglichkeiten. Ach, Mensch. Was willst du damit in diesem Thread? Hast du ihn wirklich gelesen? Lukas hatte ganz am Anfang mal geschrieben, dass er diese Idee durchaus auch hatte. Hat er zu den Akten gelegt, weil da eben vieles schon zu „verbaut“ ist, und das, was ihm wichtig war, auf diese Weise nicht oder nur außerordentlich umständlich realisierbar schien. > Sinn macht es keinen. Mag deine Meinung sein, und wir haben ja Meinungsfreiheit. Aber außer W.S. und einigen wenigen anderen werden die meisten Mitleser dieses Threads wohl diese deine Meinung eher nicht teilen.
Ich finde es ja super, was Lukas hier auf die Beine stellt. Ich verstehe auch die Beweggründe, sein eigenes Ding machen zu wollen, ohne Kompromisse einzugehen. Nur für den Anwender und die Open Source Szene ist das die übliche Katastrophe! Anstatt die Energie auf ein CAD zu bündeln, und dieses zur Perfektion zu bringen, bleiben viele Baustellen übrig, die meistens irgendwann nicht mehr gewartet werden. Jedes Programm hat ab einer gewissen Komplexität und Reife eine lange Liste von Kompromissen und Eigenheiten. Da ist Lukas CAD nicht anders. Ich würde da auch nichts ändern wollen, reine Bloatware igitigit :-) Programmierer wollen programmieren, und nicht den Code anderer verstehen und debuggen, der per Definition suboptimal ist. Aber Vielfalt ist auch schön.
udok schrieb: > Nur für den Anwender und die Open Source Szene ist das > die übliche Katastrophe! Sehe ich nicht so. Aber das ist dann halt meine Meinung. :) > Anstatt die Energie auf ein CAD zu bündeln, und > dieses zur Perfektion zu bringen, > bleiben viele Baustellen übrig, die meistens > irgendwann nicht mehr gewartet werden. Wenn du merkst, dass du das eine CAD halt nicht zur „Perfektion“ bringen kannst, weil es designmäßig ziemlich verbaut ist, dann finde ich es völlig legitim, an dieser Stelle einen Schnitt zu machen und was Neues anzufangen. Gerade in der Opensource-Szene passiert das immer wieder, und keineswegs deshalb notwendigerweise zum Schlechten (für den Anwender). Ein Beispiel, welches mir spontan einfiele, wäre hier sendmail. War mal der Mailserver schlechthin, viele seine Features waren damals durchaus wichtig, aber mittlerweile benutzt es fast niemand mehr ob der Alternativen. Es muss aber eben auch niemand mehr zwischen UUCP-, Internet-, DECnet- und was-weiß-ich-Net-Mailadressen irgendwas umschreiben, dafür sind uns andere Dinge wichtig geworden. Horizon bietet halt damit die Chance, dass es tatsächlich auch besser sein könnte als die Dinge, die Lukas sich ja durchaus angesehen hat, bevor er begonnen hat. Wenn es nicht besser wird, war's halt ein Versuch, wenn's besser wird, haben am Ende alle gewonnen.
Jörg W. schrieb: > Wenn du merkst, dass du das eine CAD halt nicht > zur „Perfektion“ bringen kannst, weil es designmäßig > ziemlich verbaut ist, dann finde ich es völlig > legitim, an dieser Stelle einen Schnitt zu machen > und was Neues anzufangen. Ja -- aber Dein Irrtum liegt in der Voraussetzung. "Das eine CAD" enthält mindestens einen Schaltplan- editor, eine Bauteildatenbank und einen Layout- editor. Es ist nicht sinnvoll, wenn jedes neue Projekt versucht, ALLE diese Komponenten neu aus dem Boden zu stampfen. Was würdest Du denn sagen, wenn IDE, Compiler, Linker, Assembler und Versionsverwaltung so miteinander verflochten wären, dass Du alles wechseln musst, wenn Du eigentlich nur ein anderes VCS benutzen willst? > Horizon bietet halt damit die Chance, dass es > tatsächlich auch besser sein könnte als die Dinge, > die Lukas sich ja durchaus angesehen hat, bevor > er begonnen hat. Wenn es nicht besser wird, war's > halt ein Versuch, wenn's besser wird, haben am Ende > alle gewonnen. Nein! Erfahrungsgemäß ist die Wahrheit VIEL ärgerlicher: Es wird einige Dinge geben, die in horizon tatsächlich SO viel besser sind, dass man eine bestimmte Komponente von horizon wirklich benutzen will. Aber da man diese eine Komponente nicht mit anderen Komponenten aus anderen Projekten kombinieren können wird, bleibt alles beim Alten: Wahl zwischen Pest und Cholera.
Egon D. schrieb: > Es ist nicht sinnvoll, wenn jedes neue Projekt versucht, ALLE diese > Komponenten neu aus dem Boden zu stampfen. Doch, aus meiner Sicht schon. Denn zumindest bei Kicad (und auch gEDA) sind diese Komponenten jeweils ziemlich getrennt voneinander entstanden und daher nur mäßig gut in ihrem Zusammenspiel. Wenn ein „integriertes Design“ es mal schafft, das besser zu bekommen, dann bin ich da vollauf mit Lukas. (Ob Eagle oder Altium oder BAE oder Target oder … das besser machen, hülfe uns ohnehin nicht viel, da nicht Opensource.) > Erfahrungsgemäß ist die Wahrheit VIEL ärgerlicher: Wir haben aber da völlig entgegengesetzte Standpunkte: für mich (und, wie ich das sehe, auch für Lukas) sind die Komponenten eines EDA-Systems eben keine eigenständigen Teile, die man völlig voneinander unabhängig bemuddeln oder gegenseitig austauschen kann. Derartige Ansätze gab's ja bereits in der Vergangenheit, sie waren eher nicht erfolgreich (gEDA) oder „so einigermaßen brauchbar“ (Kicad, aber eigentlich auch erst nach einem Jahrzehnt oder mehr an diesem Punkt angekommen, nachdem CERN da mitmischte).
Jörg W. schrieb: > Egon D. schrieb: >> Es ist nicht sinnvoll, wenn jedes neue Projekt >> versucht, ALLE diese Komponenten neu aus dem >> Boden zu stampfen. > > Doch, aus meiner Sicht schon. Denn zumindest bei > Kicad (und auch gEDA) sind diese Komponenten > jeweils ziemlich getrennt voneinander entstanden > und daher nur mäßig gut in ihrem Zusammenspiel. Da besteht aus meiner Sicht kein (zwingender) Zusammenhang. Die Frage ist aus meiner Sicht nicht, ob die Komponenten getrennt oder zusammen entstehen, sondern ob es eine tragfähige Vorstellung von der Struktur des Gesamtsystems gibt oder nicht. > Wir haben aber da völlig entgegengesetzte > Standpunkte: für mich (und, wie ich das sehe, auch > für Lukas) sind die Komponenten eines EDA-Systems > eben keine eigenständigen Teile, die man völlig > voneinander unabhängig bemuddeln oder gegenseitig > austauschen kann. Derartige Ansätze gab's ja > bereits in der Vergangenheit, Hier muss ich dann doch schmunzeln. Das liest sich wie eine Laudatio zum 100. Todestag, aber ganz so weit sind wir ja dann doch noch nicht. > sie waren eher nicht erfolgreich (gEDA) oder „so > einigermaßen brauchbar“ (Kicad, aber eigentlich > auch erst nach einem Jahrzehnt oder mehr an diesem > Punkt angekommen, nachdem CERN da mitmischte). Ich denke, Du verwechselst hier Korrelation mit Kausalität. Der modulare Ansatz beider Projekte und der begrenzte Erfolg beider Projekte lässt nicht den Rückschluss zu, beide Projekte hätten WEGEN des modularen Ansatzes nur begrenzten Erfolg. Darüberhinaus denke ich, dass die Hemmnisse in beiden Projekten jeweils andere sind. gEDA hatte nach meinem Gefühl durchaus eine nennens- werte Zeit wachsender Popularität; das lange Siechtum der letzten Jahre ist wohl auf ein sehr suboptimales Projektmanagement zurückzuführen. Dem Boss waren wohl untergeordnete technische Details wichtiger als tragfähige Kompromisse mit seinen Entwicklern. Kicad andererseits war ja wohl lange Zeit eine one-man-show. Ich kann daher den Gedanken nicht ganz unterdrücken, W.S. könnte Recht haben mit seiner Behauptung, man laboriere jetzt an der Beseitigung der Mängel, die durch die schon vor Jahren getroffenen suboptimalen Entscheidungen hervorgerufen wurden.
Egon D. schrieb: > Der modulare Ansatz beider Projekte und der begrenzte > Erfolg beider Projekte lässt nicht den Rückschluss zu, > beide Projekte hätten WEGEN des modularen Ansatzes nur > begrenzten Erfolg. Bei gEDA sehe ich das schon, das war immer nur eher eine Art Projektidee, die als Konglomerat Dinge versucht hat zu vereinen, die für sich bereits eigenständige Projekte waren. PCB kenne ich jedenfalls schon ziemlich lange, gSchem wurde dann erst später „dazu gestrickt“. gerbv ist relativ eigenständig, aber das ist eingedenk seiner Schnittstelle (Gerber-Daten) nicht weiter verwunderlich, denn die Gerberdaten sind nunmal die Schnittstelle zum Fertiger und als solche zumindest einigermaßen normiert. > Kicad andererseits war ja wohl lange Zeit eine > one-man-show. Ich kann daher den Gedanken nicht ganz > unterdrücken, W.S. könnte Recht haben mit seiner > Behauptung, man laboriere jetzt an der Beseitigung > der Mängel, Das kann durchaus sein, allerdings sind die „Mängel“, die W.S. bei Horizon sieht, einfach nur Designentscheidungen, die ihm nicht so sehr gefallen, wie eben bestimmte Mindestvoraussetzungen an die Hardware. Er hat ja nun extra „zum Beweis“ eine Hardware ausgegraben, die er zwar laut eigener Aussage nie ernsthaft für EDA benutzen würde, aber mit der er „belegen“ kann, was von vornherein so postuliert worden war. :) Du wiederum erwartest unbedingt einzeln für sich herauslösbaren und woanders integrierbare Komponenten.
M. W. schrieb: > Ich bin nochmal alle Argumente hier durchgegegangen und finde eigentlich > nur eine Quintessenz daraus: > > Man programmiere sich sein eigenes tool zum Selbstzweck und aus Spass am > Programmieren. Sinn macht es keinen. > > Wer ernsthaft Funktionalität verbessern will, der muss sich in ein > bestehendes Programm einklinken und z.B.: > > * Ein ULP für EAGLE schreiben, welches die Funktionen hat > > * Einen alternativen Editor für KiCAD entwickeln > > * Einen alternativen Autorouter / Placer schreiben > > * Einen Checker zur Einhaltung bestimmter Regeln im Sonderplatinenbau > entwickeln, der übers Design rattert > > * und und und > > Gerade KiCAD bietet uns damit alle Möglichkeiten. Die Sourcen sind mehr > oder weniger frei verfügbar und auch dokumentiert. Dort würde ich > einhaken, weil sich da auch sofort Unterstützer finden, die ein Projekt > weiterziehen, wenn man selber nicht mehr kann. Ich bin nochmal alle Deine Argumente durchgegangen und ziehe folgende Quintessenz daraus: Du bist einer von diesen typisch deutschen Jammerlappen und Nörglern, die jedem auch wirklich alles schlecht reden müssen und so lange herumnölen, bis sie was gefunden haben, über das sie sich aufregen können. Solche Menschen sind die liebsten Nachbarn im Schrebergarten! Kauf Dir verdammt nochmal einen akutellen PC und hör auf herumzujammern! Meine Güte! Jeder billige Aldi-PC erfüllt die Hardwareanforderungen und nur weil Du zu geizig bist, nach mehr als einer Dekade ein paar Euro in die Hand zu nehmen, wird hier ein Shitstorm losgetreten, der jemanden bodenlos kritisiert, der SEINE Zeit in ein Projekt investiert und netterweise hier für andere zur Verfügung stellt! Und wenn Du dafür zu geizig bist, dann bist Du hier sowieso komplett fehl am Platz! Und dann nimm halt KiCAD wenn das alles genauso oder besser kann und heul leise! Und hör auf, diesen Thread damit zuzuspammen! Das will hier keiner lesen und braucht auch keiner!
Martin S. schrieb: > Kauf Dir verdammt nochmal einen akutellen PC und hör auf herumzujammern! Nö, das war/ist eigentlich nicht sein Problem. Das war nur W.S., und auch er hat extra irgendeine hornalte Büchse ausgraben müssen um zu „beweisen“, was von vornherein klar (als Anforderung gesetzt) war. Fazit: wirklich ernsthaft diskutiert hier keiner mehr über die OpenGL-Anforderungen. Anders als vor knapp 2 Jahren, als Lukas den Thread gestartet hat, ist OpenGL 3 mittlerweile ganz offensichtlich bereits so sehr Standard geworden, dass das gar kein ernsthaftes Diskussionsthema mehr ist. Also letztlich genau das, was Lukas auch so als Annahme seinem Projekt vorangestellt hat. M.W. will zwar nicht wirklich was mitmachen, aber er möchte sich halt gern von allen Projekten am besten die Rosinen rauspicken. Daher müssen alle Projekte ihre Datenschnittstellen vereinheitlicht haben, und wenn sie das nicht haben, dann müssen jetzt alle weiteren Opensource-Programmierer daran arbeiten …
M.W. ... W.S. ... Ich sehe da kaum einen Unterschied in der Argumentation.
Martin S. schrieb: > M.W. ... W.S. ... Ich sehe da kaum einen Unterschied in der > Argumentation. W.S. braucht sowieso nichts anderes als seinen Adler, und alles, was nicht ganz genauso funktioniert wie jener, ist bei ihm zum Scheitern verdammt.
Schlage folgendes Argument für jede weitere Diskussion zum Thema OpenGL vor: "Heul doch!" Damit sollten sich weitere uninteressante Befindlichkeiten von Nörglern abdecken lassen. @J: Lieber Politik als das hier, das ist ja nur noch als jämmerlich zu bezeichnen. Gruß, Holm
Alternativ Aufteilen des Threads in * "Horizon - Erfahrungen und Probleme" * "Horizon - Diskussionen" o.ä. Ersterer dann gerne mit etwas nachdrücklicherer Moderation...
Jörg W. schrieb: > Egon D. schrieb: > >> Der modulare Ansatz beider Projekte und der begrenzte >> Erfolg beider Projekte lässt nicht den Rückschluss zu, >> beide Projekte hätten WEGEN des modularen Ansatzes nur >> begrenzten Erfolg. > > Bei gEDA sehe ich das schon, das war immer nur eher > eine Art Projektidee, die als Konglomerat Dinge > versucht hat zu vereinen, die für sich bereits > eigenständige Projekte waren. Das ist ja sachlich richtig -- ich sehe nur nicht, dass das die tiefere URSACHE für den Misserfolg ist. Nach allem, was ich (u.a. von Stefan S. und Tibor Palinkas) gehört habe, ermangelte es dem gEDA-Chef einer gewissen Führungstärke, und ich sehe DAS als das entscheidende Problem an. >> Kicad andererseits war ja wohl lange Zeit eine >> one-man-show. Ich kann daher den Gedanken nicht ganz >> unterdrücken, W.S. könnte Recht haben mit seiner >> Behauptung, man laboriere jetzt an der Beseitigung >> der Mängel, > > Das kann durchaus sein, allerdings sind die „Mängel“, > die W.S. bei Horizon sieht, einfach nur > Designentscheidungen, die ihm nicht so sehr gefallen, > wie eben bestimmte Mindestvoraussetzungen an die > Hardware. Nee, ich denke, wir missverstehen uns. Nach meinem Eindruck kämpfen nicht nur die freien, sondern auch die "kleinen" kommerziellen Systeme (Eagle, Target, ...) damit, ein ziemlich komplexes Problem mit sehr beschränkter Arbeitskraft lösen zu wollen, und der Erfolg ist ja durchaus wechselhaft. Man möge mir also nachsehen, wenn ich einen Analogieschluss ziehe und einer weiteren one-man-show etwas zweifelnd gegenüberstehe. Wenn es draußen donnert, dann gehe ich ja auch einfach von einem Gewitter aus -- und nicht davon, dass jetzt der Messias erscheint...
Jörg W. schrieb: > M.W. will zwar nicht wirklich was mitmachen, aber er > möchte sich halt gern von allen Projekten am besten > die Rosinen rauspicken. Daher müssen alle Projekte > ihre Datenschnittstellen vereinheitlicht haben, [...] Ja und? Das ist genau das, was weltweit viele Millionen Debian- oder Ubuntu-User machen. Ich sehe das Problem nicht.
Egon D. schrieb: > Man möge mir also nachsehen, wenn ich einen Analogieschluss ziehe und > einer weiteren one-man-show etwas zweifelnd gegenüberstehe. War ich anfangs auch. Allerdings überzeugt mich Lukas' Produktivität, die er mit so einer one-man-show an den Tag gelegt hat. Damit ist das Teil aus meiner Sicht zumindest schon jetzt soweit „aus dem Gröbsten heraus“, dass es fortan auch ohne ihn eine Chance hat zu bestehen. Ich hätte nicht gedacht, dass das tatsächlich jemand in annehmbarer Zeit stemmen könnte, aber es scheint zu klappen.
Jörg W. schrieb: > Ich > hätte nicht gedacht, dass das tatsächlich jemand in annehmbarer Zeit > stemmen könnte, aber es scheint zu klappen. Dem kann ich mich nur anschließen, hab wirklich den *allergrößten Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer Zeit und mit einer solchen Motivation und Stetigkeit! Da kann man nur den Hut ziehen, müsste ich mir eine dicke Scheibe von abschneiden für meine eigenen Projekte. Ich beobachte das Projekt gerne und sehe ihm beim wachsen zu, wer weiß vielleicht wird horizon eines Tages die PCB Software, mittlerweile ist der Name auch richtig passend ;-) Aber die Designentscheidungen von Lukas teile ich nahezu alle uneingeschränkt, hätte ich genauso gemacht und die typischen Muffel hier die nur zum Nörgeln rauskommen gibt es halt leider in jedem Thread...
Julian W. schrieb: > Dem kann ich mich nur anschließen, hab wirklich den *allergrößten > Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer > Zeit und mit einer solchen Motivation und Stetigkeit! Allerdings. Wenn man das sieht, dann fragt man sich schon, warum Eagle in einer vielfachen Zeit nur so wenig erreicht hat.
Martin S. schrieb: > Julian W. schrieb: >> Dem kann ich mich nur anschließen, hab wirklich den *allergrößten >> Respekt* vor Lukas was der da auf die Beine gestellt hat in so kurzer >> Zeit und mit einer solchen Motivation und Stetigkeit! > > Allerdings. Wenn man das sieht, dann fragt man sich schon, warum Eagle > in einer vielfachen Zeit nur so wenig erreicht hat. Man benötigt 10% der Zeit für 90% der Funktionalität ...^^ Sobald mal ein gewisses Feature-Set erreicht ist, verlagert sich der Fokus mehr auf einzelne kleine Erweiterungen, Bug-Fixing. Außerdem macht das Lukas im Prinzip im Alleingang, weshalb er da von niemanden aufgehalten wird.
Mampf F. schrieb: > Außerdem macht das Lukas im Prinzip im Alleingang, weshalb er da von > niemanden aufgehalten wird. Vor allem das ist am Anfang ein ungemeiner Vorteil, sobald 2 oder mehr Leute an einem Projekt beteiligt sind geht ein gigantischer Anteil der Zeit für Planung/Diskussionen/Absprachen/"Streiten" etc. drauf. Lukas kann die Planung etc. alles "im Kopf" machen was wesentlich schneller geht, das sollte man nicht unterschätzen.
... jetzt bitte wieder weiter ..... mit wirklich entscheidenden Fragestellungen und Problemlösungen zum Elektronik-CAD-Programm von Lukas .... Danke
Michel M. schrieb: > mit wirklich entscheidenden Fragestellungen und Problemlösungen zum > Elektronik-CAD-Programm von Lukas Gern. Hab's nun endlich mal geschafft, das Teil hier auf meinem FreeBSD wieder zum Compilieren zu bekommen, und habe mit einem simplen Test, den ich vor geraumer Zeit angefangen habe, weitergemacht. Das "Panning" im 3D-Viewer mit der mittleren Maustaste ist mir ziemlich gewöhnungsbedürftig im Vergleich mit allem anderen, was ich bislang in dieser Richtung gesehen habe (und ich dachte immer, Altiums 3D-View wäre in der Bedienung gewöhnungsbedürftig ;-). Ich schaffe es ganz fix, dass ich dort alles so sehr verschiebe, dass ich am Ende gar nichts mehr sehe … Was ich daher sehr begrüßen würde: oben, neben den Icons mit den verschiedenen Ansichten, noch eins zu haben für "fit all", d.h. das gesamte 3D-Modell wird so geschoben und gezoomt, dass man es in der aktuell gewählten Ansicht bildschirmfüllend sieht. Habe ich auch bei FreeCAD immer mal wieder gebraucht, ist eine bequeme Möglichkeit, "auf Start zurück zu gehen", wenn man sich mal völlig daneben navigiert hat. Außerdem fände ich es sehr praktisch, wenn man für gängige Funktionen nicht erst das jeweilige Element anklicken muss, also bspw. es genügt, die <DEL>-Taste über einem Leiterzug oder einer Verbindung im Schaltplaneditor zu drücken, und der wird gelöscht. (Bei Mehrdeutigkeiten müsste natürlich dann der entsprechende Dialog aufklappen, welches Element jetzt genau gemeint ist.)
Jörg W. schrieb: > Außerdem fände ich es sehr praktisch Öhm :), das nehme ich zurück. Geht jetzt, ich könnte schwören, dass es vorhin nicht ging … vielleicht habe ich mich geirrt.
Jörg W. schrieb
> Außerdem fände ich es sehr praktisch, wenn man für gängige Funktionen
nicht erst das jeweilige Element anklicken muss, also bspw. es genügt,
die <DEL>-Taste über einem Leiterzug oder einer Verbindung im
Schaltplaneditor zu drücken, und der wird gelöscht.
Unter Windows 10 funktioniert das sobald das Objekt links oben angezeigt
wird. Wenn da nichts angezeigt wird, dann ist man noch in irgend einem
anderen Modus. Dann drücke ich einmal ESC und ab da erscheint oben links
die Anzeige des Objekts über dem der Cursor steht. Ab da funktioniert
dann auch DEL(ENTF) beliebig oft.
Yup, hatte ich dann auch bemerkt. Danke für den Hinweis mit dem "heads-up display" links oben, da sollte ich wirklich häufiger mal einen Blick drauf werfen. Was mir dabei auffällt: Horizon fühlt sich sehr flink an, verglichen mit Kicad auf gleicher Hardware oder Altium auf vergleichbarer Hardware.
Angehängte Dateien:
-
poolmanager.png
140 KB
Eine Frage zum Poolmanager: Die markierte Spalte ganz rechts kann ich in der Breite nicht ändern. Damit ist das, was dort angezeigt wird, eigentlich ziemlich nutzlos (außer, dass man es mit der rechten Maustaste kopieren kann). Ist das so beabsichtigt? Die "Manufacturer"-Spalte belegt ziemlich viel Platz für eine Information, die man m.M.n. oft gar nicht braucht (generische Bauteile). Wäre gut, wenn man sie einfach kleiner ziehen könnte, um mehr Platz für die anderen Spalten zu haben.
Weil ich gerade drüber stolpere: im Package-Generator wäre es cool, wenn beim Duplizieren eines Pads, dessen Name auf eine Zahl endet, diese Zahl mit jeder Kopie automatisch eins hochgezählt werden würde. Es dürfte in den allermeisten Fällen die gewünschte Aktion sein, nicht das gleiche Pad nochmal zu erzeugen. So, wie es jetzt ist, bekommen die Duplikate alle eine fette Warnung, und man muss danach jedes einzeln editieren.
Angehängte Dateien:
-
1920-100.jpg
280 KB -
1980-125.PNG
130 KB
Jörg W. schrieb: > Eine Frage zum Poolmanager: > > Die markierte Spalte ganz rechts kann ich in der Breite nicht ändern. > Damit ist das, was dort angezeigt wird, eigentlich ziemlich nutzlos > (außer, dass man es mit der rechten Maustaste kopieren kann). Mit einer HD-Auflösung von 1920 Breite bekommt man alles angezeigt. Dabei wäre zu erwähnen, dass die Schriften/Felder größer werden, wenn man in WIN 125% eingestellt hat. > Ist das so beabsichtigt? > > Die "Manufacturer"-Spalte belegt ziemlich viel Platz für eine > Information, die man m.M.n. oft gar nicht braucht (generische Bauteile). > Wäre gut, wenn man sie einfach kleiner ziehen könnte, um mehr Platz für > die anderen Spalten zu haben. Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. Dazu "Descriptions maximal nach links schieben. Man sollte die Verwendung einer HD-Auflösung oder höher für horizon empfehlen.
Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach nicht nur einzeln jedes für sich editieren könnte, sondern die gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte.
Helmut S. schrieb: > Mit einer HD-Auflösung von 1920 Breite Habe ich. > bekommt man alles angezeigt. Jetzt habe ich auch die Ecke gefunden, an der ich ziehen muss, damit ich die Tabelle insgesamt breiter bekomme. Das ist natürlich nicht Lukas' Schuld, sondern eher ein Problem im Handling von Gtk3 (dessen Default-Skin mir absolut nicht gefällt, aber irgendwie schaffe ich das auch nicht, dieses abzuändern, fehlt mir wohl irgendein dbus oder was auch immer Dämon). > Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. Nö, kleiner als im Screenshot gezeigt, habe ich sie nicht bekommen. Von mir aus sollte man die aber gern bis zur Unkenntlichkeit zusammenschieben können (wie bei "Path" oben), wenn man sie nicht braucht. > Man sollte die Verwendung einer HD-Auflösung oder höher für horizon > empfehlen. Naja, man muss es schon auch mal auf'm Laptop laufen lassen können mit eingebautem Display, auch wenn das vielleicht nicht die reguläre Arbeitsumgebung ist. Wie gesagt, wie ich Gtk3 zu einem anderen Layout überrede, ist hier noch 'ne andere Baustelle (und nicht Lukas' Problem), aber sowas wie die minimale Spaltenbreite dürfte ja doch in Horizon festgeschrieben sein.
Holm T. schrieb: > /usr/ports/cad/horizon-devel?? Nö, git clone. Hab' gerade keine freien CPU-Zyklen, da was in Richtung Port zu unternehmen.
Jörg W. schrieb: >> Also etwas kleiner hättest du die "Manufacturer"-Spalte machen können. > > Nö, kleiner als im Screenshot gezeigt, habe ich sie nicht bekommen.
1 | diff --git a/src/widgets/pool_browser_package.cpp b/src/widgets/pool_browser_package.cpp
|
2 | index ec7e332..14b1a35 100644
|
3 | --- a/src/widgets/pool_browser_package.cpp
|
4 | +++ b/src/widgets/pool_browser_package.cpp
|
5 | @@ -29,7 +29,7 @@ void PoolBrowserPackage::create_columns()
|
6 | {
|
7 | auto col = append_column("Manufacturer", list_columns.manufacturer, Pango::ELLIPSIZE_END);
|
8 | col->set_resizable(true); |
9 | - col->set_min_width(200);
|
10 | + col->set_min_width(30);
|
11 | } |
12 | treeview->append_column("Pads", list_columns.n_pads);
|
13 | {
|
Das wäre mein Vorschlag. ;) @Lukas: Willst du solche Dinge eigentlich gern hier haben oder als pull request auf Github?
Part Wizard, Funktion eines Pins: "unconnected" fehlt dort, für IC-Pins, die nicht belegt sind.
@Jörg, Lukas liest hier meinem Gefühl nach vielleicht einmal am Tag. Mach lieber gleich einen request in Github.
Genügt ja auch, ich erwarte keine 5minütigen Reaktionszeiten. ;-) War eher eine Frage, ob er solche Einzeiler auch gern als pull request haben will oder nicht.
Jörg W. schrieb: > Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst > habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: > mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach > nicht nur einzeln jedes für sich editieren könnte, sondern die > gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es > gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch > vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte. Definitiv! Das regt mich im Altium auch immer extrem auf, dass das nicht so ohne weiteres geht (oder gar nicht??). Es ist ja technisch problemlos umsetzbar. Man graut halt die Elemente aus, die nicht gemeinsam sind oder lässt sie sogar aktiv, dann kann man die Eigenschafte für Objekte setzen, die diese haben. Kurzer Hinweis: "Die Eigenschaftsänderung wirkt sich nicht auf alle Objekte aus. Fortsetzen?" und man könnte sich zukünftig sehr viel nervige Klick-Arbeit sparen.
Martin S. schrieb: > Das regt mich im Altium auch immer extrem auf, dass das nicht so ohne > weiteres geht (oder gar nicht??). in Altium geht das ohne Probleme...
Martin S. schrieb: > Jörg W. schrieb: >> Noch was, was ich cool fände (und bspw. auch bei Kicad schon vermisst >> habe): wenn man eine Reihe gleichartiger Objekte ausgewählt hat (hier: >> mehrere Linien eines Rechtecks), dann wäre es gut, wenn man diese danach >> nicht nur einzeln jedes für sich editieren könnte, sondern die >> gemeinsamen Eigenschaften auch „im Block“. Bei den Linien hier war es >> gerade die Breite, die ich bei allen ändern wollte, aber kann mir auch >> vorstellen, dass man auf diese Weise bspw. den Layer ändern könnte. > > Definitiv! Das geht zumindest bei Durchkontaktierungen ... Kann man markieren, E drücken und für alle markierten zB der Drill einstellen. Das geht auch bei Leiterbahnen - inklusive Layer-wechsel. Ihr solltet mal das Manual lesen ;-) SCNR Natürlich dürft ihr nicht den veralteten legacy-Modus verwenden. Aber stimmt, für Linienbreiten im zB cutoff layer wäre das ein gutes Feature.
Re 3D Vorschau: Ehrlich gesagt ist das Pan-Verhalten (insb. die Konstanten in der Formel) das Ergebnis von Trial-And-Error bis es sich halbwegs ordentlich anfühlte: https://github.com/carrotIndustries/horizon/blob/master/src/canvas3d/canvas3d.cpp#L80 Knopf zum Zurücksetzen der Ansicht sollte einfach machbar sein. Zur Auswahl von Dingen: Es gibt den "Hover" und den "Normalen" Modus. Im Hover-Modus wird das Objekt mit der kleinsten Bounding-Box unter dem Mauszeiger ausgewählt. Wenn man dann ein Tool startet, wird das gerade ausgewählte verwendet - eben um einfach mit der Maus drauf zeigen und DEL drücken zu können. Dieses Verhalten ist Primär aus dem entstanden, wie es mir in KiCad nicht gefallen hat: 1. man weiß nicht, was man gerade ausgewählt hat, Tool starten ist dann Glücksspiel 2. Die ständigen "Clarify Selection" haben mich genervt Mit einmal klicken wird die Auswahl dann fixiert und man ist im normalen Modus. Wenn man jetzt nochmal klickt, kommt das "Clarify Selection"-Menü, allerdings ohne komischen unnützen erstem Menüeintrag. Mit Esc kommt man wieder zurück in den Hover-Modus. Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele für das Projekt und geht auch, nur ist die UI dafür wohl nicht unmittelbar ersichtlich geraten: Wenn man z.B. 4 Linien ausgewählt hat, steht rechts im Property-Editor bei den Linien 1/4, mit den links/rechts-Knöpfen kann man auswählen welche davon man nun bearbeitet. Ein Klick auf den Haken an der Property appliziert den Wert der gerade sichtbaren auf alle ausgewählten. Andere Implementierungen von solchen Editoren zeigen bei der Auswahl mehrerer Objekte dann sowas wie ???, das hat mir noch nie so recht gefallen.
Martin S. schrieb: > gjhvf schrieb: >> in Altium geht das ohne Probleme... > > Wie? wenn Du mehrere ähnliche Objekte markiert hast (z.B. über find similar objects) kannst Du in den Properties fröhlich ändern. Diese Änderungen werden für alle markierten Objekte übernommen.
Lukas K. schrieb: > Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele > für das Projekt und geht auch, nur ist die UI dafür wohl nicht > unmittelbar ersichtlich geraten: OK, schau ich mir heute abend mal an. Bei Schließen des Pool-Managers nach dem Speichern meines neu angelegten Parts habe dann einen bus error geschossen. Stacktrace:
1 | $ gdb801 horizon-eda horizon-eda.core |
2 | GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD] |
3 | Copyright (C) 2017 Free Software Foundation, Inc. |
4 | License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> |
5 | This is free software: you are free to change and redistribute it. |
6 | There is NO WARRANTY, to the extent permitted by law. Type "show copying" |
7 | and "show warranty" for details. |
8 | This GDB was configured as "x86_64-portbld-freebsd10.4". |
9 | Type "show configuration" for configuration details. |
10 | For bug reporting instructions, please see: |
11 | <http://www.gnu.org/software/gdb/bugs/>. |
12 | Find the GDB manual and other documentation resources online at: |
13 | <http://www.gnu.org/software/gdb/documentation/>. |
14 | For help, type "help". |
15 | Type "apropos word" to search for commands related to "word"... |
16 | Reading symbols from horizon-eda...done. |
17 | [New LWP 101804] |
18 | [New LWP 100855] |
19 | [New LWP 100225] |
20 | [New LWP 100127] |
21 | [New LWP 102699] |
22 | [New LWP 102028] |
23 | [New LWP 102027] |
24 | [New LWP 102017] |
25 | [New LWP 102000] |
26 | |
27 | warning: Unexpected size of section `.reg-xstate/101804' in core file. |
28 | Core was generated by `./horizon-eda'. |
29 | Program terminated with signal SIGBUS, Bus error. |
30 | |
31 | warning: Unexpected size of section `.reg-xstate/101804' in core file. |
32 | #0 0x000000000044df95 in horizon::uuid_ptr<horizon::Package const>::operator-> (this=<optimized out>) at src/util/uuid_ptr.hpp:41 |
33 | 41 assert(ptr->get_uuid() == uuid); |
34 | [Current thread is 1 (LWP 101804)] |
35 | (gdb) bt |
36 | #0 0x000000000044df95 in horizon::uuid_ptr<horizon::Package const>::operator-> (this=<optimized out>) at src/util/uuid_ptr.hpp:41 |
37 | #1 horizon::Part::serialize (this=0x812600920) at src/pool/part.cpp:200 |
38 | #2 0x00000000005a9094 in horizon::PartWizard::finish (this=0x812600800) at src/pool-prj-mgr/pool-mgr/part_wizard/part_wizard.cpp:354 |
39 | #3 0x00000000005a4ef6 in horizon::PartWizard::handle_finish (this=0x812600800) at src/pool-prj-mgr/pool-mgr/part_wizard/part_wizard.cpp:252 |
40 | #4 0x0000000802b43e90 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/local/lib/libglibmm-2.4.so.1 |
41 | #5 0x0000000804f079a2 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 |
42 | #6 0x0000000804f1ce94 in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
43 | #7 0x0000000804f1d918 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
44 | #8 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
45 | #9 0x0000000802f3f47b in ?? () from /usr/local/lib/libgtk-3.so.0 |
46 | #10 0x0000000801b8a124 in Gtk::Button_Class::released_callback(_GtkButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
47 | #11 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
48 | #12 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
49 | #13 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
50 | #14 0x0000000802f3df76 in ?? () from /usr/local/lib/libgtk-3.so.0 |
51 | #15 0x000000080a27236c in ffi_call_unix64 () from /usr/local/lib/libffi.so.6 |
52 | #16 0x000000080a271c3b in ffi_call () from /usr/local/lib/libffi.so.6 |
53 | #17 0x0000000804f091dc in g_cclosure_marshal_generic_va () from /usr/local/lib/libgobject-2.0.so.0 |
54 | #18 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
55 | #19 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
56 | #20 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
57 | #21 0x0000000802ffba12 in ?? () from /usr/local/lib/libgtk-3.so.0 |
58 | #22 0x0000000804f0afeb in g_cclosure_marshal_VOID__BOXEDv () from /usr/local/lib/libgobject-2.0.so.0 |
59 | #23 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
60 | #24 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
61 | #25 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
62 | #26 0x0000000802ff87ee in ?? () from /usr/local/lib/libgtk-3.so.0 |
63 | #27 0x0000000802ff9c96 in ?? () from /usr/local/lib/libgtk-3.so.0 |
64 | #28 0x0000000802ffd283 in ?? () from /usr/local/lib/libgtk-3.so.0 |
65 | #29 0x0000000802fc875b in gtk_event_controller_handle_event () from /usr/local/lib/libgtk-3.so.0 |
66 | #30 0x000000080319b58b in ?? () from /usr/local/lib/libgtk-3.so.0 |
67 | #31 0x0000000801c61373 in Gtk::Widget::on_button_release_event(_GdkEventButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
68 | #32 0x0000000801c5a3fd in Gtk::Widget_Class::button_release_event_callback(_GtkWidget*, _GdkEventButton*) () from /usr/local/lib/libgtkmm-3.0.so.1 |
69 | #33 0x00000008030474d9 in ?? () from /usr/local/lib/libgtk-3.so.0 |
70 | #34 0x0000000804f07bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
71 | #35 0x0000000804f1d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
72 | #36 0x0000000804f1e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
73 | #37 0x000000080319b1f8 in ?? () from /usr/local/lib/libgtk-3.so.0 |
74 | #38 0x00000008030460ac in ?? () from /usr/local/lib/libgtk-3.so.0 |
75 | #39 0x00000008030455f8 in gtk_main_do_event () from /usr/local/lib/libgtk-3.so.0 |
76 | #40 0x00000008036f5841 in ?? () from /usr/local/lib/libgdk-3.so.0 |
77 | #41 0x000000080372ab97 in ?? () from /usr/local/lib/libgdk-3.so.0 |
78 | #42 0x0000000805191878 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 |
79 | #43 0x0000000805191bb3 in ?? () from /usr/local/lib/libglib-2.0.so.0 |
80 | #44 0x0000000805191c44 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 |
81 | #45 0x00000008042b33dd in g_application_run () from /usr/local/lib/libgio-2.0.so.0 |
82 | #46 0x000000000054c941 in main (argc=1, argv=0x7fffffffe528) at src/pool-prj-mgr/pool-prj-mgr-main.cpp:15 |
Hat ja schon fast was von den typischen Java-Stacktraces. ;-) ptr und uuid sind leider "value optimized out". Ein Level darüber kann ich mir das package ansehen:
1 | (gdb) p package |
2 | $2 = {ptr = 0x8280da330, uuid = {uu = "V\355QM;\236M<\223\320\350\275b\020\300\226"}}
|
Jörg W. schrieb: > Holm T. schrieb: >> /usr/ports/cad/horizon-devel?? > > Nö, git clone. > > Hab' gerade keine freien CPU-Zyklen, da was in Richtung Port zu > unternehmen. Achso, falls du es selbst bauen willst: Die Voraussetzungen hat Lukas irgendwo bei sich auf der Seite beschrieben, die musst du halt mit der Hand installieren (gtkmm30 zum Beispiel). Danach tut's ein einfaches
1 | gmake CXX=clang++60 |
Am besten noch ein -j<Anzahl deiner CPU-Kerne> dranhängen. :) Dauert sonst ein Weilchen.
Der Crash ist repariert, das Pasten von Pads auch. Die anderen Dinge kommen zeitnah.
Angehängte Dateien:
-
pool.png
140 KB -
selectsymbol.png
11 KB
Cool! Habe nun versucht, das Teil zu Ende zu bauen, bei dem es gestern am Ende abgestürzt ist. Sieht auf den ersten Blick komplett aus, im Partbrowser sehe ich keinen Unterschied zwischen meinem A210E und den anderen Teilen. Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein Symbol zu wählen mit einer leeren Auswahlbox.
Lukas K. schrieb: > Mehrere Dinge auf einmal ändern: Das war eines meiner wichtigen Ziele > für das Projekt und geht auch, nur ist die UI dafür wohl nicht > unmittelbar ersichtlich geraten: Ja, da würde ich zustimmen. ;-) Der Haken sieht halt aus wie eine Checkbox, nur dass sich an dieser nichts ändert, wenn man draufdrückt … Platz ist ja eigentlich, was spräche dagegen, statt des Hakens ein "ALL" reinzuschreiben? Alternativ, das Ding wirklich als Checkbox implementieren, und man kann damit einschalten, ob die späteren Änderungen auf alle ausgewählten Objekte angewendet werden oder nur das aktuelle. Fände ich intuitiver. Selbst mit deiner Beschreibung hat es bei mir eine Weile gedauert, bis ich es verstanden habe, wie's funktioniert.
Jörg W. schrieb: > Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein > Symbol zu wählen mit einer leeren Auswahlbox. Hm, wie sieht's denn im Pool Cache im Projekt aus? Wenn da noch was altes im Cache drin ist, dann könnte das das Verhalten erklären.
Wie ist das, Füllflächen gibt's noch nicht, oder habe ich sie nur nicht gefunden? Die vielen Tastenkürzel sind nicht so einfach im Kopf zu behalten. Jedesmal auf die Hilfe zu gehen, ist auch nervig. Irgendeine Form von Menü fände ich sinnvoll, mit der man alternativ zum jeweiligen Tastenkürzel an die entsprechende Funktion gelangen kann. Ob das nun irgendwie mit der rechten Maustaste oder eine Menüleiste ist, wäre mir egal. Auf diese Weise wird sich bei der täglichen Arbeit dann irgendwann ein Gleichgewicht einstellen zwischen den Funktionen, die man häufig braucht und per Tastaturkürzel aktiviert und den Sachen, die man nur einmal im Monat braucht und dann auch gut und gern aus einem Menü rauspopeln kann.
Lukas K. schrieb: > Jörg W. schrieb: >> Wenn ich es aber platzieren will, bekomme ich eine Aufforderung, ein >> Symbol zu wählen mit einer leeren Auswahlbox. > > Hm, wie sieht's denn im Pool Cache im Projekt aus? Wenn da noch was > altes im Cache drin ist, dann könnte das das Verhalten erklären. OK, das war's wohl. Habe ein neues Projekt begonnen, da klappt es.
Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich viele:
1 | In file included from src/pool/part.cpp:1: |
2 | In file included from src/pool/part.hpp:3: |
3 | In file included from src/pool/package.hpp:13: |
4 | In file included from src/package/package_rules.hpp:3: |
5 | src/package/rule_package_checks.hpp:12:17: warning: 'get_brief' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] |
6 | std::string get_brief(const class Block *block = nullptr) const; |
7 | ^ |
8 | src/rules/rule.hpp:38:25: note: overridden virtual function is here |
9 | virtual std::string get_brief(const class Block *block = nullptr) const = 0; |
10 | ^ |
11 | In file included from src/pool/part.cpp:1: |
12 | In file included from src/pool/part.hpp:3: |
13 | src/pool/package.hpp:76:10: warning: 'get_uuid' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] |
14 | UUID get_uuid() const; |
15 | ^ |
16 | src/util/uuid_provider.hpp:11:18: note: overridden virtual function is here |
17 | virtual UUID get_uuid() const = 0; |
18 | ^ |
Jörg W. schrieb: > Wie ist das, Füllflächen gibt's noch nicht, oder habe ich sie nur nicht > gefunden? Das ist ein zweistufiger Prozess: 1. Polygon in der gewünschten Lage zeichnen: Draw Polygon / Draw Polygon Rectangle 2. Das Polyon zu einer Fläche machen und dabei das Netz auswählen: Add Plane Jörg W. schrieb: > Die vielen Tastenkürzel sind nicht so einfach im Kopf zu behalten. > Jedesmal auf die Hilfe zu gehen, ist auch nervig. Irgendeine Form von > Menü fände ich sinnvoll, Menüs gibt es zweierlei: 1. Rechte Maustaste: Aktionen nur für das ausgewählte Objekt 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte Objekt sowie globalen Aktionen. Jörg W. schrieb: > Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich > viele: Das hier ist mein erstes wirkliches C++-Projekt, ganz am Anfang wusste ich von override noch nichts...
Lukas K. schrieb: > Das ist ein zweistufiger Prozess: > > 1. Polygon in der gewünschten Lage zeichnen: Draw Polygon / Draw Polygon > Rectangle Da war ich schon. :) > 2. Das Polyon zu einer Fläche machen und dabei das Netz auswählen: Add > Plane OK, schau ich mir morgen (heute :) an. > 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte > Objekt sowie globalen Aktionen. OK, auch das schau ich mir an. > Jörg W. schrieb: >> Mit clang++60 bekomme ich von derartigen Meldungen übrigens ziemlich >> viele: > > Das hier ist mein erstes wirkliches C++-Projekt :-)) Dafür ist es beeindruckend. Habe noch einen weiteren segfault:
1 | Program terminated with signal SIGSEGV, Segmentation fault. |
2 | |
3 | warning: Unexpected size of section `.reg-xstate/102223' in core file. |
4 | #0 p2t::Triangle::EdgeIndex (this=0x0, p1=0x815d57668, p2=0x815d57640) at 3rd_party/poly2tri/common/shapes.cpp:168 |
5 | 168 if (points_[0] == p1) {
|
6 | [Current thread is 1 (LWP 102223)] |
7 | (gdb) bt |
8 | #0 p2t::Triangle::EdgeIndex (this=0x0, p1=0x815d57668, p2=0x815d57640) at 3rd_party/poly2tri/common/shapes.cpp:168 |
9 | #1 0x0000000000668103 in p2t::Sweep::IsEdgeSideOfTriangle (triangle=..., ep=..., eq=..., this=<optimized out>) at 3rd_party/poly2tri/sweep/sweep.cpp:164 |
10 | #2 p2t::Sweep::EdgeEvent (this=0x829dba8c0, tcx=..., ep=..., eq=..., triangle=0x0, point=...) at 3rd_party/poly2tri/sweep/sweep.cpp:109 |
11 | #3 0x00000000006678b2 in p2t::Sweep::SweepPoints (this=0x829dba8c0, tcx=...) at 3rd_party/poly2tri/sweep/sweep.cpp:56 |
12 | #4 0x000000000066777e in p2t::Sweep::Triangulate (this=0x829dba8c0, tcx=...) at 3rd_party/poly2tri/sweep/sweep.cpp:45 |
13 | #5 0x00000000007fdb66 in horizon::Canvas3D::polynode_to_tris (this=0x823c6c800, node=<optimized out>, layer=<optimized out>) |
14 | at src/canvas3d/canvas3d.cpp:276 |
15 | #6 0x00000000007ffcde in horizon::Canvas3D::prepare_layer (this=<optimized out>, layer=100) at src/canvas3d/canvas3d.cpp:484 |
16 | #7 0x00000000007fef30 in horizon::Canvas3D::prepare (this=0x823c6c800) at src/canvas3d/canvas3d.cpp:356 |
17 | #8 0x00000000007f1cd9 in horizon::View3DWindow::update (this=0x823c96900, clear=false) at src/imp/3d_view.cpp:236 |
18 | #9 0x000000000061cc18 in horizon::ImpBoard::construct()::$_5::operator()() const (this=<optimized out>) at src/imp/imp_board.cpp:232 |
19 | #10 sigc::adaptor_functor<horizon::ImpBoard::construct()::$_5>::operator()() const (this=<optimized out>) |
20 | at /usr/local/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256 |
21 | #11 sigc::internal::slot_call0<horizon::ImpBoard::construct()::$_5, void>::call_it(sigc::internal::slot_rep*) (rep=<optimized out>) |
22 | at /usr/local/include/sigc++-2.0/sigc++/functors/slot.h:114 |
23 | #12 0x0000000805f43e90 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/local/lib/libglibmm-2.4.so.1 |
24 | #13 0x00000008087279a2 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 |
25 | #14 0x000000080873ce94 in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
26 | #15 0x000000080873d918 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
27 | #16 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
28 | #17 0x000000080633f47b in ?? () from /usr/local/lib/libgtk-3.so.0 |
29 | #18 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
30 | #19 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
31 | #20 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
32 | #21 0x000000080633df76 in ?? () from /usr/local/lib/libgtk-3.so.0 |
33 | #22 0x00000008113b936c in ffi_call_unix64 () from /usr/local/lib/libffi.so.6 |
34 | #23 0x00000008113b8c3b in ffi_call () from /usr/local/lib/libffi.so.6 |
35 | #24 0x00000008087291dc in g_cclosure_marshal_generic_va () from /usr/local/lib/libgobject-2.0.so.0 |
36 | #25 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
37 | #26 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
38 | #27 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
39 | #28 0x00000008063fba12 in ?? () from /usr/local/lib/libgtk-3.so.0 |
40 | #29 0x000000080872afeb in g_cclosure_marshal_VOID__BOXEDv () from /usr/local/lib/libgobject-2.0.so.0 |
41 | #30 0x0000000808727bfa in ?? () from /usr/local/lib/libgobject-2.0.so.0 |
42 | #31 0x000000080873d5f6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 |
43 | #32 0x000000080873e064 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 |
44 | #33 0x00000008063f87ee in ?? () from /usr/local/lib/libgtk-3.so.0 |
45 | ---Type <return> to continue, or q <return> to quit---q |
46 | Quit |
47 | (gdb) p points_ |
48 | Cannot access memory at address 0x8 |
49 | (gdb) l |
50 | 163 return -1; |
51 | 164 } |
52 | 165 |
53 | 166 int Triangle::EdgeIndex(const Point* p1, const Point* p2) |
54 | 167 {
|
55 | 168 if (points_[0] == p1) {
|
56 | 169 if (points_[1] == p2) {
|
57 | 170 return 2; |
58 | 171 } else if (points_[2] == p2) {
|
59 | 172 return 1; |
60 | (gdb) up |
61 | #1 0x0000000000668103 in p2t::Sweep::IsEdgeSideOfTriangle (triangle=..., ep=..., eq=..., this=<optimized out>) at 3rd_party/poly2tri/sweep/sweep.cpp:164 |
62 | 164 const int index = triangle.EdgeIndex(&ep, &eq); |
63 | (gdb) p ep |
64 | $1 = (p2t::Point &) @0x815d57668: {x = 19850000, y = 14850000,
|
65 | edge_list = {<std::__1::__vector_base<p2t::Edge*, std::__1::allocator<p2t::Edge*> >> = {<std::__1::__vector_base_common<true>> = {<No data fields>},
|
66 | __begin_ = 0x0, __end_ = 0x0, |
67 | __end_cap_ = {<std::__1::__libcpp_compressed_pair_imp<p2t::Edge**, std::__1::allocator<p2t::Edge*>, 2>> = {<std::__1::allocator<p2t::Edge*>> = {<No data fields>}, __first_ = 0x0}, <No data fields>}}, <No data fields>}}
|
68 | (gdb) p eq |
69 | $2 = (p2t::Point &) @0x815d57640: {x = 20000000, y = 14850000,
|
70 | edge_list = {<std::__1::__vector_base<p2t::Edge*, std::__1::allocator<p2t::Edge*> >> = {<std::__1::__vector_base_common<true>> = {<No data fields>},
|
71 | __begin_ = 0x815c3ac40, __end_ = 0x815c3ac48, |
72 | __end_cap_ = {<std::__1::__libcpp_compressed_pair_imp<p2t::Edge**, std::__1::allocator<p2t::Edge*>, 2>> = {<std::__1::allocator<p2t::Edge*>> = {<No data fields>}, __first_ = 0x815c3ac48}, <No data fields>}}, <No data fields>}}
|
Gute Nacht!
Jörg W. schrieb: >> 2. Leertaste: Durchsuchbares Menü mit Aktionen für das ausgewählte >> Objekt sowie globalen Aktionen. > > OK, auch das schau ich mir an. Ja, das ist in der Tat das, was ich mir darunter vorgestellt habe. Spricht was dagegen, das (zusätzlich) auf die rechte Maustaste zu legen? Die ist derzeit ja ohnehin ungenutzt. Ich denke, das wäre eher die Stelle, wo viele solch ein Menü erwarten würden (zumindest mir geht's so). Die Leertaste hat einen Nachteil: sie ist „asymmetrisch“. Nach dem Öffnen des Menüs befindet man sich im Suchfeld, und ein weiteres Leerzeichen landet dann dort, statt dass man damit das Menü wieder schließen könnte.
Habe übrigens einen seltsamen Effekt mit diesem Menü. Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches ich mir gerade ausgewählt habe, damit das Gtk3 etwas weniger Tablet-mäßig aussieht, oder ob da irgendwelche Größen falsch festgelegt sind.
Angehängte Dateien:
-
schematic1.PNG
190 KB
Hallo Jörg, hier mal ein screenshot mit horizon in WIN10. Ich habe da keine Probleme mit dem Befehlsmenü.
Helmut S. schrieb: > Ich habe da keine Probleme mit dem Befehlsmenü. Wenn ich das ~/.config/gtk-3.0/settings.ini zur Seite räume, sodass alles wieder auf das default theme zurückfällt, sieht das bei mir auch OK aus. Allerdings macht dieses Theme auch kein "hover", wenn man über die Menüeinträge fährt, wie es das CDE/Motif-Theme macht, welches im Video zu sehen ist. In einem reinen Screenshot lässt sich das kaum zeigen, daher hatte ich den Video-Mitschnitt gezimmert.
Jörg schrieb
> Allerdings macht dieses Theme auch kein "hover", wenn man über
die Menüeinträge fährt, wie es das CDE/Motif-Theme macht, welches im
Video zu sehen ist.
OK, jetzt weiß ich was du meinst.
Sollte das ein neuer Vorschlag für das GUI sein?
Ist das in anderen CAD-Programmen üblich?
Jörg W. schrieb: > Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches > ich mir gerade ausgewählt habe, Ist es, ich hab' mir das Theme gerade mal selber installiert, sieht genau so aus wie bei dir, mit Adwaita ist es OK. Auch wenn man es anders vermuten könnte sind themes nicht wirklich von Gtk3 unterstützt: https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/ Jörg W. schrieb: > Habe noch einen weiteren segfault: Ok, kann ich reproduzieren: Wenn im Outline-Layer die Ecken von zwei Polygonen die selbe Position haben und eines davon im stumpfen Winkel ist, verschluckt's sich beim Triangulieren. Scheint wohl auch eine Anforderung zu sein... https://github.com/greenm01/poly2tri Vermutlich hast du dieses Verhalten erzeugt, als du die Outline mit einer Linie gemalt hast. Horizon unterscheidet strikt zwischen Linien und Polygonen. Dinge, die eine Fläche beschreiben, wie eben Board-Outline und Bauteil-Konturen sind als Polygon zu zeichnen. Wenn du schon ein Linienzug hast, kannst du den mit "Line loop to polygon" zum Polygon machen. Eigentlicher Zweck dieses Tools, ist aus importierten Linienzügen Polygone zu machen, um Logos und dergleichen aufs Board zu bekommen.
Lukas K. schrieb: > Jörg W. schrieb: >> Weiß nicht, ob das nun ein Problem mit dem CDE/Motif-Theme ist, welches >> ich mir gerade ausgewählt habe, > > Ist es, ich hab' mir das Theme gerade mal selber installiert, sieht > genau so aus wie bei dir, mit Adwaita ist es OK. OK, damit kann ich leben. > Auch wenn man es anders > vermuten könnte sind themes nicht wirklich von Gtk3 unterstützt: > https://blogs.gnome.org/tbernard/2018/10/15/restyling-apps-at-scale/ Naja, wenn wenigstens das default theme nicht so hässlich aussähe, dass man meint, die ganze Welt wäre nun ein Tablet … Vermutlich ist in diesem CDE/Motif-Thema die Schrift einfach zu groß. > Vermutlich hast du dieses Verhalten erzeugt, als du die Outline mit > einer Linie gemalt hast. Das ist gut möglich. > Horizon unterscheidet strikt zwischen Linien > und Polygonen. OK. Abstürzen sollte es natürlich nicht, aber zumindest ist das eine Erklärung.
@Lukas Wie ist dein Interesse an pull requests im horizon-pool? Ich könnte mir vorstellen, einige der bei mir in der Datenbank vorhandenen Bauteile mal aufzunehmen, sodass bspw. eine Anzahl an Standard-Transistoren auf diese Weise zustande käme. Ich würde mich dabei vorrangig auf SMD konzentrieren, denn anders als die THT-Bauteile verwalte ich meinen SMD-Kram in einer Datenbank, sodass ich einen ganz guten Überblick habe, was da ist.
Feature request: Es sollte eine Möglichkeit geben, Elemente des Pools im Dateisystem zu verschieben. Hatte gerade gemerkt, dass meine neu eingerichteten Unterverzeichnisse "afpoweramp" eigentlich vom Sinn her deckungsgleich mit den (teilweise) schon existierenden "afamp" waren. Manuelles Verschieben aller Teile parallel im Dateisystem und im pool.db ist doch etwas aufwändig, und ich vermute, dass ich nicht der letzte sein werde, der sowas mal ändern möchte. Die "tags" sind keine schlechte Idee, aber so wie sie jetzt sind, kaum zu überschauen. Bei der Auswahl von tags fände ich es sinnvoll, ein Dropdown-Menü zu haben, in dem alle existierenden tags aufgeführt sind. Bei der Vergabe von tags wäre das auch nicht schlecht, auf diese Weise zu wissen, was es schon gibt.
Jörg W. schrieb: > Manuelles > Verschieben aller Teile parallel im Dateisystem und im pool.db ist doch > etwas aufwändig, und ich vermute, dass ich nicht der letzte sein werde, > der sowas mal ändern möchte. Du kannst Teile frei im Pool verschieben, sofern sie in ihren jeweiligen Ordnern bleiben (Parts in "parts", etc). Beim klicken auf "Update Pool" wird die pool.db geleert und mit dem, was es an Dateien gibt, neu aufgebaut.
Lukas K. schrieb: > Beim klicken auf "Update Pool" wird die pool.db geleert und mit dem, was > es an Dateien gibt, neu aufgebaut. OK, gut zu wissen.
Lukas K. schrieb: > Ist behoben und sollte in Zukunft auch nicht mehr so einfach passieren, > da die CI jetzt auch mit debian stretch statt ubuntu artful baut. Danke, ich habe es noch mal ausprobiert und compilieren geht jetzt. Nur starten leider nicht: ./horizon-eda (horizon-eda:17562): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: gtk-builder-error-quark code : 11 what : .:1071:40 Invalid property: gtkmm__GtkInfoBar.revealed Ich las irgendwo im Thread was von gtkmm und einer Mindestversion 3.2. Laut Debian Versionsnummer sollte es bei mir 3.22.0 sein. Irgendwelche Ideen?
Angehängte Dateien:
-
moving-wires.png
96 KB
Lukas K. schrieb: > Ist repariert. Das nenn ich mal schnelle Reaktionszeit. Nun startets, aber der Pool Download klappt nicht: Error: git error 12 Failed to resolve address for https: Der Name oder der Dienst ist nicht bekannt. Per Wireshark sehe ich dass die Github Url zu 192.30.253.116 aufgelöst, und dann eine https Verbindung aufgebaut wurde. Im Ordner wird auch ein .remote Ordner angelegt. Ein manuelles git clone https://github.com/carrotIndustries/horizon-pool.git funktioniert hingegen. Was mir bisher aufgefallen ist: 1. Verschiebt man Leitungen und Bauteile per Auswahl "Move" im Untermenü scheint es einen Versatz in der Rasterung zu geben (links im Schematic), bei der Auswahl über die Tastatur "m" trat dies nicht auf (rechts im PCB). 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache. 3. Nachdem ich das Fenster auf volle Bildschirmhöhe gezogen hatte (ich habe die Taskleiste an der Seite), war es nicht mehr möglich die Fensterhöhe zu ändern, da ein entsprechendes Symbol bei der Maus nicht mehr eingeblendet wurde. Nur über einen Rechtsklick in der Taskleiste des Fensters und dann Auswahl "Move" konnte ich es wieder verkleinern. Aber ansonsten halte ich Horizon für vielversprechend :)
> Nun startets, aber der Pool Download klappt nicht:
Error: git error 12 Failed to resolve address for https: Der Name oder
der Dienst ist nicht bekannt.
Hast du in dem Ordner in dem horizon-eda liegt die Datei
"ca-bundle.crt"?
Wenn man unter WIN kompiliert, dann muss man diese Datei selber dort hin
kopieren. Wie das in Linux ist weiß ich nicht.
Running
....
For the pool download to work, you'll have to copy the file
/mingw64/ssl/certs/ca-bundle.crt to the directory the directory
horizon-eda.exe resides in.
Malte _. schrieb: > Nun startets, aber der Pool Download klappt nicht: > Error: git error 12 Failed to resolve address for https: Der Name oder > der Dienst ist nicht bekannt. Da darfst du dich wohl bei debian bedanken, bei denen aus lizenzpolitischen gründen libgit2 aktuell ohne TLS-Unterstützung gebaut ist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798 Mit dem libgit2 und -dev aus den backports tut's. Malte _. schrieb: > 1. Verschiebt man Leitungen und Bauteile per Auswahl "Move" im Untermenü > scheint es einen Versatz in der Rasterung zu geben (links im Schematic), > bei der Auswahl über die Tastatur "m" trat dies nicht auf (rechts im > PCB). In der Zoomstufe bei dir wird im schaltplan gerade nur jeder 4. Gitterpunkt angzeigt (s. ×4 rechts neben der Rastereinstellung) > 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache. Hamburger-Menü → Annotate > 3. Nachdem ich das Fenster auf volle Bildschirmhöhe gezogen hatte (ich > habe die Taskleiste an der Seite), war es nicht mehr möglich die > Fensterhöhe zu ändern, da ein entsprechendes Symbol bei der Maus nicht > mehr eingeblendet wurde. Konnte ich mit xfce und compositing nachvollziehen, hängt wohl mit den client-side decorations von Gtk zusammen, da dort die Fensterschatten die Anfasser zum Größe ändern sind. Da du den screeshots nach zu urteilen kein Composting benutzt, hab ich's mal damit probiert und konnte das Problem nicht reproduzieren. Helmut S. schrieb: > Wenn man unter WIN kompiliert, dann muss man diese Datei selber dort hin > kopieren. Wie das in Linux ist weiß ich nicht. Auf Linux muss man das nicht machen, dort bedient sich curl/openssl aus den Systemzertifikaten.
Lukas schrieb
> 2. Ich habe nicht herausgefunden wie ich aus D? D1 mache.
Hamburger-Menü → Annotate
Man will doch oft manuell den "Reference designator" setzen.
Warum nicht rechts im Property-Fenster D? zu D1 ändern?
Dafür ist das eingeblendete Fenster unter anderem doch da.
guten Morgen, Ich möchte mich auch an Horizon versuchen und quäle mein C2D Laptop (lubuntu 18.04.x) mit dem Build. Der Build benötigt gute 2GB freien Plattenplatz, das sollte man im voraus wissen, bitte einen Hinweis dokumentieren. So vermisse ich ein clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu behalten. Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend quälend langsam vonstatten. Die Abhängigkeiten sind im Makefile Wohl nicht vollständig erfasst: alle meine Versuche mit make -j 2 (oder anderer Zahl) bringen den Rechner zwar auf Vollast aber dafür endlos bis zum hängen =:'( auch wenn ich bloss ein Teilziel builde (z.B. horizon-pool). Gibt es eine, zumindest grobe, Übersicht zur Quellcodearchitektur? Ich würde mich daran versuchen das Makefile zu pimpen um den Build auf Trab zu bringen...
Roland schrieb: > Der Build benötigt gute 2GB freien Plattenplatz, das sollte man im > voraus wissen, bitte einen Hinweis dokumentieren. Naja, das ist ja mittlerweile "peanuts". Kann man sicher dokumentieren, aber andere (Firefox z.B. oder gar Openoffice) sind da drastisch gefräßiger. > So vermisse ich ein > clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu > behalten. "mostlyclean"? > Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend > quälend langsam vonstatten. Zu wenig RAM? Diese C++-Builds sind recht speicherintensiv. > Die Abhängigkeiten sind im Makefile Wohl nicht vollständig erfasst: alle > meine Versuche mit make -j 2 (oder anderer Zahl) bringen den Rechner > zwar auf Vollast aber dafür endlos bis zum hängen =:'( auch wenn ich > bloss ein Teilziel builde (z.B. horizon-pool). Ich habe kein Problem, alles mit -j4 gebaut zu bekommen (auf 4 Kernen).
Angehängte Dateien:
-
moving-wires2.png
52 KB
Jörg W. schrieb: > Roland schrieb: > >> Der Build lastet meine Maschine nur so 15..30% aus und geht entsprechend >> quälend langsam vonstatten. > > Zu wenig RAM? Diese C++-Builds sind recht speicherintensiv. Das wird es sein, ich habs mal beobachtet, meist braucht ein einzelner Compiler bei Horizon 6-8%, teilweise aber bis zu 11% meiner 8GB RAM. Also rund 800MB. Bei 2GB RAM und 1GB fürs System, bleibt da nur RAM für einen Compileraufruf übrig. Ich war überrascht, dass auch mein System mit make -j 12 folglich anfängt zu swappen. Bauen dauert bei mir 4,5 Minuten (Ryzen 1600). Lukas K. schrieb: > ist: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798 > Mit dem libgit2 und -dev aus den backports tut's. Danke, daran kannst du ja nicht wirklich was ändern. > Malte _. schrieb: > In der Zoomstufe bei dir wird im schaltplan gerade nur jeder 4. > Gitterpunkt angzeigt (s. ×4 rechts neben der Rastereinstellung) Hmm, ich habe da mal etwas reingezoomt (siehe Screenshot). > Hamburger-Menü → Annotate Ah, gut. > Konnte ich mit xfce und compositing nachvollziehen, hängt wohl mit den > client-side decorations von Gtk zusammen, da dort die Fensterschatten > die Anfasser zum Größe ändern sind. Ich verwende da zugegebenermaßen eine nieschen GUI - Trinity (ehemals KDE 3.5). Interessanterweise gibt es das Problem nur, wenn das Fenster vertikal den Bildschirm ausfüllt. Horizontal ist kein Problem.
Jörg W. schrieb: > Roland schrieb: : : > >> So vermisse ich ein >> clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu >> behalten. > > "mostlyclean"? Gerne! Wo?
1 | .../horizon$ |
2 | .../horizon$ make mostlyclean |
3 | make: *** No rule to make target 'mostlyclean'. Stop. |
4 | .../horizon$ |
5 | .../horizon$ grep -i mostly Makefile |
6 | .../horizon$ |
7 | .../horizon$ |
8 | .../horizon$ grep PHONY Makefile |
9 | .PHONY: clean clean_router clean_oce clean_res |
10 | .../horizon$ |
11 | .../horizon$ grep clean Makefile |
12 | src/pool-prj-mgr/prj-mgr/pool_cache_cleanup_dialog.cpp\ |
13 | clean: clean_router clean_oce clean_res |
14 | clean_router: |
15 | clean_oce: |
16 | clean_res: |
17 | .PHONY: clean clean_router clean_oce clean_res |
18 | .../horizon$ |
19 | .../horizon$ |
Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur
Zwischenprodukte des Builds (*.o, *.d, ...) loeschen sollte, nicht aber
die gebrauchsfertigen Executables (und fuer deren Betrieb noetigen,
generierten Hilfsdateien)?
Um ALLES komplett zu loeschen ("Kaltstart" des Buildes) dann lieber das
Maketarget clean-all
Vollstaendigkeitshalber fehlen M.M.n. folgende Maketargets: clean-imp
, clean-pool , clean-prj , clean-pool ,
clean-pool-update-parametric , clean-eda alle in Anlehnung an das
Maketarget all1 | .../horizon$ |
2 | .../horizon$ grep ^all Makefile |
3 | all: horizon-imp horizon-pool horizon-prj horizon-pool-update-parametric horizon-eda |
4 | .../horizon$ |
Auch muesste auch all noch als PHONY markiert werden.
1 | .../horizon$ |
2 | .../horizon$ grep all Makefile |
3 | all: horizon-imp horizon-pool horizon-prj horizon-pool-update-parametric horizon-eda |
4 | src/core/tool_update_all_planes.cpp\ |
5 | src/core/tool_set_nc_all.cpp\ |
6 | src/canvas3d/wall.cpp\ |
7 | CXXFLAGS =$(DEBUG) $(DEFINES) $(OPTIMIZE) $(shell pkg-config --cflags $(LIBS_ALL)) -MP -MMD -pthread -Wall -Wshadow -std=c++14 -O3 |
8 | .../horizon$ |
9 | .../horizon$ grep PHONY Makefile |
10 | .PHONY: clean clean_router clean_oce clean_res |
11 | .../horizon$ |
12 | .../horizon$ |
Alle Ausfuehrbaren Maketargets sollten in einer Variable (z.B. EXE_ALL aehlich OBJ_ALL) gelistet werden, so lassen diese sich einfach von der Loeschliste auslassen. (es gibt noch bessere "Richtlinien", aber erstma so als Minimum) ZIEL: kein rm sollte direkt mit Dateinamen operieren, sondern nur mit Variablen welche Listen von Dateien nennen. ZIEL: kein Dateinamen sollte mehrmals im Makefile erwaehnt sein --> Ausfaktorieren in Variable(n) Ist es zudem nicht auch so dass, insbesondere Plattfomuebergreifend (hier Win u Linux), die make-externen Befehle wie z.B. rm via Variablen a la $(RM) aufgerufen werden sollten, anstatt sich blind auf beliebig vorliegende Werte von PATH zu stuetzen? Die Aufteilung der Gruppe "horizon-*" <-> "clean_*" erschliesst sich mir nicht ganz: zum einen sind da die resultierenden Userprogramme horizon-imp/-pool/-prj/-pool-update-parametric/-eda aber WAS sind _router, _oce, und _res ? (router waere noch als 3rd_party/router zu finden, aber fuer keine der anderen 3rd_party-Teile gibt es separate Maketargets...)
I <3 Makefiles schrieb: >> "mostlyclean"? > > Gerne! Wo? War jetzt eher ein Implementierungsvorschlag. > Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur > Zwischenprodukte des Builds (*.o, *.d, ...) loeschen sollte, nicht aber > die gebrauchsfertigen Executables (und fuer deren Betrieb noetigen, > generierten Hilfsdateien)? Ja. War vielleicht vor 25 Jahren so zuweilen gebräuchlich ("make clobber" entfernte dann alles), aber mittlerweile ist "make clean" ein Synonym für "räume alles auf, was beim normalen Build entsteht". Lediglich Dinge wie "configure"-Scripte und deren Hinterlassenschaften bleiben dann noch üblicherweise liegen, diese sind aber auch nicht durch "make all" entstanden. Den Wunsch, nur die Objektdateien aber nicht die Ergebnisse zu löschen, hat heutzutage eigentlich kaum noch jemand. Plattenplatz kost' nichts mehr.
I <3 Makefiles schrieb: > Jörg W. schrieb: >> Roland schrieb: > : > : >> >>> So vermisse ich ein >>> clean-Target um nur die o-Files zu entsorgen jedoch die Executables zu >>> behalten. >> >> "mostlyclean"? > > Gerne! Wo? da, wo du's implementierst? War ja offensichtlich als "Idee" gemeint... > Liege ich mit meiner Erwartung falsch wenn Maketarget clean nur Ja. Zumindest wenn ich mich auf knapp 30 Jahre Praxis in "configure; make" stütze, so lief das üblicherweise immer so: "make clean" - löscht Objekte und Ausführbare "make distclean" - löscht zusätzlich die Ergebnisse aus "configure" [oops, da kam ein Kaffee dazwischen :-)]
Wem' die Kompilate zu groß sind, der kann auch ohne Debug-Symbole bauen. Die Binaries werden davon z.B. um Faktor 30 kleiner. Die verschiedenen Make-Targets für router und oce gibt es, damit nicht alles andere die komischen Include-Pfade für diese Programmteile abbekommt. Wenn jemand das Makefile noch weiter verbessern will, bitte als Pull Request einreichen, aber dabei bitte Dinge die man nun wirklich nicht braucht, wie z.B. rm als Variable, sein lassen. Jörg W. schrieb: > Ich habe kein Problem, alles mit -j4 gebaut zu bekommen (auf 4 Kernen). Hat bei anderen Leuten auch mit -j8 gebaut und alle Kerne beschäftigt. Wenn sich die CPU langweilt, dann muss das wohl an Swappen oder langsamem IO liegen. Wär' schön, wenn damit die Diskussion über das Makefile sich damit erübrigt hat. Malte _. schrieb: > Hmm, ich habe da mal etwas reingezoomt (siehe Screenshot). Da scheint ja gar nichts zu passen. Wurde die Diode schon off-grid platziert, oder ist die erst durch verschieben so geraten? Jörg W. schrieb: > Die "tags" sind keine schlechte Idee, aber so wie sie jetzt sind, kaum > zu überschauen. Das musste ich auch feststellen. Vielleicht ist eine klassische Baumstruktur stattdessen doch keine so dumme Idee.
Seit kurzem ist jetzt endlich ein überaus nützliches Feature auch tatsächlich benutzbar: https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout und Platizerung von Spannungsreglern, die mehrfach in verschiedener Ausführung auf dem Board vorhanden sind, nur einmal machen muss.
Lukas K. schrieb: > Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von > zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout > und Platizerung von Spannungsreglern, die mehrfach in verschiedener > Ausführung auf dem Board vorhanden sind, nur einmal machen muss. Ui nettes Feature - das kann KiCad meines Wissens nicht.
Angehängte Dateien:
-
group_visibility.GIF
150 KB
Lukas K. schrieb: > Seit kurzem ist jetzt endlich ein überaus nützliches Feature auch > tatsächlich benutzbar: > https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement > > Wie im Wiki beschrieben kann man damit Platzierung und Leiterbahnen von > zuvor im Schaltplan definierten Gruppen kopieren, sodass man z.B. Layout > und Platizerung von Spannungsreglern, die mehrfach in verschiedener > Ausführung auf dem Board vorhanden sind, nur einmal machen muss. Hallo Lukas, ich habe gerade "group" und copy-layout in WIN10 versucht. Bin aber gescheitert. Dazu habe ich beide Schaltregler in eine group gepackt. Ist das so richtig oder muss sich jeden Regler in eine eigene group packen? Ein "Highlight group/tag" finde ich nicht. Dafür finde ich "Toggle grpup & tag visibility". Das Ergebnis sieht aber nicht so aus wie in dem wiki. Da gibt es rote und gelbe Umrandungen. Bei mir gibt es nur ellenlangen Text. https://github.com/carrotIndustries/horizon/wiki/Copying-layout-and-placement Was mache ich falsch? Dann dachte ich mir ich platziere und vedrahte einen Regler im Layout. Wie bekomme ich dann das Layout kopiert mit dem 2. Regler? Aus dem Text werde ich nicht schlau. To tell horizon EDA the matching components in each group, these get assigned identical tags. Since a newly-placed component will already be assigned a unique tag and groups and tags get preserved on copy/paste other instances of the same circuit will likely have the appropriate tags already set. To change the tag on a component, use the "Set tag" tool.
Hallo Lukas, nachdem ich deinen screenshot im wiki genauer angeschaut habe, denke ich dass ich das mit den groups und tags verstanden und im Schaltplan jetzt richtig gemacht habe. Layoutfenster Das Kopieren im Layout klappt aber immer noch nicht nach der Anleitung. Wie kann ich feststellen, dass das Layout etwas von den groups und tags weiß?
Helmut S. schrieb: > Hallo Lukas, > nachdem ich deinen screenshot im wiki genauer angeschaut habe, denke ich > dass ich das mit den groups und tags verstanden und im Schaltplan jetzt > richtig gemacht habe. > > Layoutfenster > Das Kopieren im Layout klappt aber immer noch nicht nach der Anleitung. > Wie kann ich feststellen, dass das Layout etwas von den groups und tags > weiß? Hallo Lukas, Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. Danke für diese Funktion. Gruß Helmut
Angehängte Dateien:
-
3D_board_schwarz.GIF
17 KB
Hallo Lukas, warum ist mein Board in 3D schwarz. Wo wird die Farbe dafür eingestellt? Wie wäre es mit grün als Standard? Helmut
Helmut S. schrieb: > Hallo Lukas, > warum ist mein Board in 3D schwarz. > Wo wird die Farbe dafür eingestellt? > Wie wäre es mit grün als Standard? > Helmut Asche auf mein Haupt. Ich muss blind gewesen sein, dass ich die rechteckigen Felder zur Einstellung der Boardfarbe in den Preferences der 3D-Ansicht übersehen habe.
https://github.com/carrotIndustries/horizon/commit/9614c23e2c4660c04d755b884311d66f085a3e7b repariert die Default-Farben für neue Boards. Helmut S. schrieb: > Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu > verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. > Danke für diese Funktion. Was genau in der Anleitung war unklar?
Lukas K. schrieb: > https://github.com/carrotIndustries/horizon/commit/9614c23e2c4660c04d755b884311d66f085a3e7b > repariert die Default-Farben für neue Boards. > > Helmut S. schrieb: >> Ich habe jetzt den Text deiner Beschreibung noch genauer versucht zu >> verstehen. Jetzt klappt das kopieren der Platzierung und der Traces. >> Danke für diese Funktion. > > Was genau in der Anleitung war unklar? Ich hatte versucht mit dem Wissen von Xpedition das im Blindflug zu probieren.
Angehängte Dateien:
-
plane_to_fehler.GIF
190 KB
Hallo Lukas, Bei mir in WIN10 geht "Plane to trace" oder auch "plane zu sonstwas" überhaupt nicht. Bei mir sind da immer 0.1mm Abstand egal was ich in den Rules eingestellt habe. Selbst mit deinem TX-board geht es nicht. Da sind es immer 0,2mm obwohl auch dort in Rules "plane to trace 0,5mm" eingestellt ist. Im Anhang ein screenshot von einem meiner Tests.
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.
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.
Angehängte Dateien:
-
Thermal_relief.GIF
230 KB
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"
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?
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 …
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.
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.
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.
>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 |
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 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.