Es gibt nun auch eine Linux-Version meines Programms Comvisu zur Visualisierung von Mikrocontrollerdaten über COM und IP/UDP. Die Funktionsweise und Features im Vergleich zur Windowsversion sind die gleichen. Es gibt momentan folgende Instrumente: - Numerische Anzeige - Numerische Ausgabe - Analoganzeige/-schieber - Balkenanzeige - Zeitdiagramm - Mehrfachzeitdiagramm - Fernanzeige - Zeichenausgabe - Taster - Schalterleiste - LED-Anzeige - Bild-Anzeige - E/A-Kanal - Dateirekorder In diesem Thread bitte nur Probleme/Anregungen posten, die speziell die Linuxversion betreffen, für allgemeine Anregungen, Instrumenten-Wünsche etc. bitte im Ur-Thread schreiben: Beitrag "Serielle Visualisierung mit Comvisu" Linux-Versionen werd ich immer hier reinstellen (wenn Bedarf da ist~) Es gilt das gleiche wie für die Windowsversion: Frei zur privaten Nutzung; Kommerzielle Nutzung ist nicht gestattet. Die Installation ist einfach: Es müssen lediglich die beiden Dateien im Unterordner "QtBinding32bit" in das Verzeichnis /usr/lib/ kopiert werden. Die Programmdatei Comvisu kann dann aus einem beliebigen Verzeichniss heraus gestartet werden. Eventuell muss noch das Attribut 'ausführbar' gesetzt werden. Damit die (serielle) Schnittstelle verbunden werden kann, müssen dem Benutzer in Linux Rechte zugewiesen werden. Wer mit Schnittstellen arbeitet weiß das ja: $ sudo adduser username dialout Bisher konnte ich leider nur auf dem Rechner testen, wo ich auch kompiliert habe. D.h. ich hoffe jetzt das Beste, dass es bei euch auf Anhieb läuft. Viele Grüße [Datei auf Wunsch des TE ausgetauscht. - Mod]
Angehängte Dateien:
-
Ausfuehren.png
59 KB -
Bearbeiten.png
83 KB -
Terminal.png
130 KB -
Schnittstelle.png
45 KB
:
Bearbeitet durch Moderator
Hallo, schön das es eine Linuxversion gibt allerdings funktioniert es bei mir schon mal nicht. Ich bekomme bei Start folgende Fehlermeldung:
1 | ./ComvisuV045: error while loading shared libraries: /usr/lib/libQt4Pas.so.5: file too short |
Die beiden Dateien hab ich kopiert. Ich nutze Linux Mint 17.3 Gruß Jonas
Es scheint daran zu liegen, dass ich die Dateien in Windows kopiert habe (Eines ist ein Symlink). Im Anhang die original-gezippten Dateien. Unten der Link, wo man sie auch direkt bekommt. Es sind nur die Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5 notwendig, der Speicherort müsste schonmal stimmen. http://users.telenet.be/Jan.Van.hijfte/qtforfpc/V2.5/bin-qt4pas-V2.5_Qt4.5.3.tar.gz
Also ich hab jetzt alle Dateien aus dem 2. Archiv nach /usr/lib kopiert und dann ging es. Mehr hab ich noch nicht ausprobiert aber ich freu mich, dass es jetzt eine Linux Version gibt. Gruß Jonas
Kleiner Tip: Dzie Libs die man selbst händisch in eine Distribution einfügt gehören in /usr/local/lib ;)
Neue Version V0.5 Neuerungen siehe "Hauptthread": Beitrag "Re: Serielle Visualisierung mit Comvisu" Harry L. schrieb: > in /usr/local/lib ;) Das habe ich ausprobiert, funktioniert bei mir allerdings nicht (k.A. warum). Also lieber in /usr/lib/ packen~
Version V0.51: - Fehler beim Ändern der Größen behoben, betroffene Instrumente: Fernanzeige, Zeichenausgabe, Mehrfachzeitdiagramm. - Tasterinstrument kann nun optional auch einen frei definierbaren Text/Zahl senden
Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu paranoid um fremde binaries einfach mal so auf meinem PC laufen zu lassen...
Petr schrieb: > Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu > paranoid um fremde binaries einfach mal so auf meinem PC laufen zu > lassen... Das versteh ich schon. Aber deswegen meinen Quellcode freigeben möchte ich auch nicht. Ist halt ein Hobbyprojekt, wo nicht ein großer Name dahinter steht der Vertrauen schafft. Wenn ich eine Version hochlade, bin ich hier immer angemeldet. Das Vertrauen muss eben mit der Zeit kommen. Es ist auch keine Installation notwendig und damit auch keine Superuser-Rechte (Für die Fremdbibliothek, welche in das Dateisystem kopiert werden muss, sind Sourcen verfügbar). Natürlich versichere ich, keinen Blödsinn zu treiben. Das Programm versucht auch nicht "rauszutelefonieren" o.ä.
Ich bekomme unter Ubuntu 16.04 folgende Fehlermeldung noch: ./ComvisuV051: error while loading shared libraries: libQtWebKit.so.4: cannot open shared object file: No such file or directory libqtWebKit4 habe ich installiert... Hast du eine Idee wo das Problem sein könnte? Danke.
OK, Problem gefunden. 32bit Version von libqtwebkit verwenden, dann läuft das Programm auch.
Weinga U. schrieb: > OK, Problem gefunden. > 32bit Version von libqtwebkit verwenden, dann läuft das Programm auch. Das ist ein Pronblem, das mir auch schon aufgefallen ist. Die Bibliotheken für 32bit und für 64bit heißen unglücklicherweise auch genau gleich. Falls jemand zwecks anderen Abhängigkeiten die 32bit Bibliothek nicht verwenden kann, kann ich auch eine 64bit Version der Comvisu bereitstellen. Da es aber sonst keinen Vorteil bietet (ist nur zusätzlicher Kompilieraufwand) und den Nutzer vor die Frage stellt, ob er jetzt die 32 oder 64bit-Version verwenden soll, würde ich gerne darauf verzichten.
Auf welchen modernen PC mit Linux läuft denn noch 32bit? Im 64Bit Mode hat so eine Kiste einen anderen Befehlsatz, der weniger Altlasten enthält. Z.B. 16-General-Purpose-Register z.B., dazu sinngemäß Herb Sutter, Chef der C++-Compiler-Truppe von Microsoft (um das nicht als rein Linux ab zu tun): "mit den 8-(nicht ganz)-Universalregistern im 32bit Mode, ist eine vernüftige Optimierung durch den Compiler kaum hin zu bekommen". Und Register sind die schnellsten Caches überhaupt. Wozu also überhaupt auf PC-Linux in 32bit entwickeln? Und wenn es die Tools nicht erlauben, dann hat das Problem auch schon einen Namen. Und 64bit Software ist mit nichten doppelt so groß. Eine Ubuntu 12.04 Installation (danach hab ich's nie mehr mit 32bit versucht) belegt in der 64Bit Version spürbar weniger Platz als die 32bit Variante der exakt selben Distribution. Und schneller ist sie auch. Dank Befehlssatz, den AMD ohne Rücksicht auf alte 8080-Kunden entwerfen konnte. Wenn man aber tatsächlich mit 32bit Software konfrontiert wird, deren Sourcecode man nicht hat, dann kann man mit geringem Aufwand die I386-Laufzeitumgebung installieren. Oh, ich sehe gerade, Ubuntu 16.04 ist noch nicht so weit, also bitte nur 64Bit. BTW, daß Herb sich nicht durchsetzen konnte, sieht man im Windows-Taskmanager. Leider!
Carl D. schrieb: > Auf welchen modernen PC mit Linux läuft denn noch 32bit? Keine Ahnung, es scheint aber schon noch Leute zu geben, die 32bit Linux verwenden. > Im 64Bit Mode hat so eine Kiste einen anderen Befehlsatz, der weniger > Altlasten enthält. > Z.B. 16-General-Purpose-Register z.B., dazu sinngemäß Herb Sutter, Chef > der C++-Compiler-Truppe von Microsoft (um das nicht als rein Linux ab zu > tun): "mit den 8-(nicht ganz)-Universalregistern im 32bit Mode, ist eine > vernüftige Optimierung durch den Compiler kaum hin zu bekommen". Und > Register sind die schnellsten Caches überhaupt. > > Wozu also überhaupt auf PC-Linux in 32bit entwickeln? Und wenn es die > Tools nicht erlauben, dann hat das Problem auch schon einen Namen. Ich kompilier sowieso auf einem 64bit Linux, für mich macht das keinen Unterschied ob ich 64bit oder 32bit anbiete. Nur beides ist halt ein Zusatzaufwand. > Und 64bit Software ist mit nichten doppelt so groß. Eine Ubuntu 12.04 > Installation (danach hab ich's nie mehr mit 32bit versucht) belegt in > der 64Bit Version spürbar weniger Platz als die 32bit Variante der exakt > selben Distribution. Der Hauptgrund für ein 32bit Linux ist sicherlich, dass man es eben schon hat und keinen Grund für eine Neuinstallation sieht. > Wenn man aber tatsächlich mit 32bit Software konfrontiert wird, deren > Sourcecode man nicht hat, dann kann man mit geringem Aufwand die > I386-Laufzeitumgebung installieren. Bei mir musste ich nichts installieren (LinuxMint 17, 64bit). Ich war auch der Meinung, das die 32bit Version auf allen gängigen 64bit Linux (PC) läuft. Mal die Frage in die Runde: 32bit oder 64bit?
Bei Ubuntu 14.04 mußte ich ia32-Libs nachinstallieren. Und für 16.04 ist es aktuell noch nicht fertig.
Est Est E. schrieb: > Mal die Frage in die Runde: 32bit oder 64bit? Also gesetzt den Fall, man plant eine Anwendung auf einen Raspberry Pi, wird man 32 Bit benötigen. Ein alter 15" Monitor mit dahinter geklebten Raspberry könnte eine Prima Kontrolltafel für ein Labor, Heizungszentrale, Wetterstation, usw. sein
OK, dann belasse ich es zunächst bei der 32bit Version. Wenn es jemand wirklich nicht zum Laufen bekommt, kann ich auch eine 64bit Version erstellen.
Neue Version V0.6 Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu" Ich hab jetzt auch eine Homepage eingerichtet, wo man die Comvisu alternativ runterladen kann: http://www.comvisu.de Vielleicht erhöht das ja die Seriösität~ Petr schrieb: > Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu > paranoid um fremde binaries einfach mal so auf meinem PC laufen zu > lassen...
Est Est E. schrieb: > Ich hab jetzt auch eine Homepage eingerichtet, wo man die Comvisu > alternativ runterladen kann: > http://www.comvisu.de Dann mach besser noch ein Impressum dran, bevor dich ein "freundlicher" Anwalt dazu auffordert. Web und anonym geht leider nicht zusammen.
:
Bearbeitet durch User
Carl D. schrieb: > Dann mach besser noch ein Impressum dran, Hast du es mittlerweile gefunden? Hab die Seite (nur) im Firefox und IE getestet, es wird jeweils sauber angezeigt.
Moby A. schrieb im Beitrag #4696061: > Carl D. schrieb: >> Dann mach besser noch ein Impressum dran > > Dann schau besser noch genauer hin. Ich hab es gefunden ;-) BTW: Aus Schorndorf, ist ja witzig. direkt um die Ecke! Da komm ich doch mal rum! :D
Angehängte Dateien:
-
Taktausgabe.png
41 KB
Neue Version V07. Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu"
Angehängte Dateien:
-
NeueInstrumente.png
60 KB
Neue Version V0.80 natürlich auch für Linux:-) Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu" Das neue Instrument Tongeber funktioniert (bisher) allerdings unter Linux nicht. Download auch direkt unter Comvisu.de
Angehängte Dateien:
-
URLRequest2.png
59 KB -
FunktionenZurFilterung.png
59 KB -
LookupTable.png
59 KB
Neue Version V0.90 Neuerungen (Details siehe Hauptthread): - Neue Schnittstellenart: URL-Request - Neues Instrument Lookup-Tabelle - Neue Funktionen (speicherwertig): COUNT,LAST,Z,SEQMIN,SEQMAX,FLOATAVG - Neue Funktionen ANS und NULL - Zeitdiagramm löst nun bei jeder Abtastung eine Berechnung aus - Fehler in XYTimeChart beseitigt
Hallo, zur Info: der Link zum Linux-File funktioniert auf deiner Web-Site nicht. Jetzt werde ich HTTP probieren weil ich es wirklich brauche :-) Lg
Ich hatte scheinbar die Linuxversion nicht eingestellt, der Download sollte jetzt wieder funktionieren! Grüße
Hallo Manfred, auf dem Raspberry läuft es nicht, ist ja ein anderer Befehlsatz (ARM statt x86). Lazarus kann zwar auch dafür kompilieren, aber da ich keinen Raspi habe, kann ich das nicht testen. Und ohne gewisse Anpassungen funktioniert es auf Anhieb nie. Viele Grüße
Est Est E. schrieb: > Hallo Manfred, > > auf dem Raspberry läuft es nicht, ist ja ein anderer Befehlsatz (ARM > statt x86). Lazarus kann zwar auch dafür kompilieren, aber da ich keinen > Raspi habe, kann ich das nicht testen. Und ohne gewisse Anpassungen > funktioniert es auf Anhieb nie. > > Viele Grüße Eben: Quellcode bitte. Dann steigt die Chance SCHLAGARTIG dass Du auch Unterstützung bekommst f. HW welche Du nicht hast. 32bit: RasPi (armhf), SPARC, MIPS, 68k 64bit: UltraSPARC, AXP, PPC
hi, wie schaut es aus, wenn du den source nicht zur verfügung stellen möchtest, würdest du eventuell eine 64bit version bauen ???
Hallo, Das kann ich machen. Ich muss nur schauen, wie ich das mit den (gleichnamigen) QT-Bibliotheken dann mache. Also etwas Geduld~
Angehängte Dateien:
Neue Version V0.95. Es gibt nun auch eine 64bit Version. Zu beachten ist, dass sich die mitgelieferte QT-Bibliothek für die 32 und 64bit-Version unterscheidet, es muss die passende installiert sein. Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu" Downloads auch unter http://Comvisu.de
Est Est E. schrieb: > Petr schrieb: >> Schade, dass man es nicht als Quellcode runterladen kann. Ich bin zu >> paranoid um fremde binaries einfach mal so auf meinem PC laufen zu >> lassen... > Das versteh ich schon. Aber deswegen meinen Quellcode freigeben möchte > ich auch nicht. > Ist halt ein Hobbyprojekt Sehr interessante Einstellung. Normalerweise ist genau das Gegenteil der Fall.
Ich habe heute versucht ComVisu unter Xubuntu 32 Bit Version zu installieren. Habe mir das Archiv runtergeladen und die beiden Dateien nach /usr/lib entpackt und die ComVisu Datei habe ich ausführbar gemacht. Wenn ich draufklicke passiert garnichts. Die ComVisu Datei liegt in einem eigenen Verzeichnis unterhalb meines Home Verzeichnises. Hat jemand eine Idee woran das liegen könnte?
Hallo Markus, das hört sich an, als ob eine falsche Bibliotheksversion installiert ist. QT muss auch installiert sein, ich weiß nicht, ob das auf allen Linuxen schon dabei ist. Starte die Comvisu mal über die Shell: ./ComvisuV095 Wenn was mit der Bibliothek nicht stimmt, sollte in der Shell dann eine Fehlermeldung angezeigt werden. Viele Grüße
Dankeschön. Daran hat es gelegen. Es war unter meinem Xubuntu tatsächlich kein QT Framework installiert.Jetzt startet die Software einwandfrei!
Beitrag #5006142 wurde von einem Moderator gelöscht.
Beitrag #5006290 wurde von einem Moderator gelöscht.
Neue Version Comvisu V1.0 Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu" Downloads auch unter Comvisu.de Viele Grüße
Hallo, Ich wollte mal fragen, ob sich inzwischen in Richtung Comvisu für RaspberryPi etwas getan hat? Wäre ja eigentlich prädestiniert für sowas. Hier im Forum gäbe es sicherlich genügend Leute zum Testen ;-) Grüße, Georg
Hallo Georg, es hat sich in dieser Richtung nichts getan, es mangelt mir immernoch an einem Raspi. Viele Grüße
Testweise hier eine Version für den RASPBERRY PI, bzw. für ARM Linux mit dem Befehlssatz ARMV6. Getestet habe ich es lediglich auf einer Emulation eines Raspi I. Sollte aber auf allen Raspis laufen. Zur Performanz kann ich nichts sagen, die Emulation war sehr träge. Ich bitte also um Rückmeldung. Die Installation funktioniert in gleicher Weise wie bei der Linux-PC-Version. Eine Kurzanleitung ist beiliegend. Nach meinem Verständnis sollte das Programm auch auf Nicht-Raspis laufen, wie dem Beagle Bone bspw. Das wäre auch zu testen, bzw. vielleicht kennt sich jemand genauer aus. Wenns nicht startet empfiehlt sich immer der Start über die Shell, dort sind dann evtl. Hinweise/Fehlermeldungen. Viele Grüße
Ich hatte jetzt die Möglichkeit die Comvisu auf einem Raspberry 2 B (Raspbian) zu testen, läuft! Die serielle Schnittstelle und Netzwerkverbindungen funktionieren auch. Auf Raspbian muss noch das Webkit für Qt4 installiert werden, sonst startet die Comvisu nicht: sudo apt-get install libqtwebkit4 @multiprogger USB-Seriell-Wandler funktionieren, ich hab bei mir am Rechner gar keine Seriellen mehr. "Echte" USB-Geräte werden nicht unterstützt.
Hallo Est Est Est, ich habe mir jetzt einen Raspberry Pi 3 Mod. B zugelegt. Super Teil. Jetzt will ich die Comvisu für ARM zum Laufen bringen. Die libqtwebkit4 habe ich installiert wie oben beschrieben. Benötigt man hier auch die beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5? Enthalten diese Binärcode, sodaß spezielle ARM-Versionen notwendig sind, oder sind die normalen Linux-Versionen hier auch verwendbar? Als serielle Schnittstellen habe ich ein RS232/USB-Teil (Renkforce) bei Conrad gekauft (kostet um die 10 Euro), das funktioniert super und stellt zwei RS232 zur Verfügung (ttyUSB0 und ttyUSB1), benötigt keine extra Treiber und wird vom Raspbian sofort erkannt. Günter
> Benötigt man hier auch die > beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5? I.A. schon, *.so.* steht für Shared Objekts d.h. ähnlich wie *.o-Dateien aus den Compilern, nur eben für dynamic linking (also zur Laufzeit d. Programms, nicht at build time ) Die Idee ist dass solche *.so.* gemeinsam für mehrere Programme sind, gerne auch für Programme unterschiedlicher Herkunft, in verschiedenen Programmiersprachen geschrieben. Natürlich gibt es auch SW-Pakete welche darauf bestehen nur ihre eigene *.so.* zu verwenden; das ist dann aber... "unsorgfältig" gemachte SW. (vulgo: Pfusch, ohne Sachverstand) > Enthalten diese > Binärcode, sodaß spezielle ARM-Versionen notwendig sind, oder sind die > normalen Linux-Versionen hier auch verwendbar? Ja: binärcode. Nix speziell, nur passend zur CPU die den Code ausführen soll und dem BS das gerade läuft. Genau so speziell/normal wie ein ausführbares Binärprogramm.
Hallo Günter, gute Entscheidung~ Die beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5 sind Binaries (ARMv6), sie sind zusätzlich zum libqtwebkit4 erforderlich. Die Zip-Datei mit der Comvisu-Raspberry-Version enthält die entsprechenden Dateien. Wenn beides installiert ist, muss man evtl. noch dem User (Standard: pi) die Rechte zum Ausführen der Comvisu geben (Rechte Maustaste/Eigenschaften). Viele Grüße
Hallo Est Est Est, ich habe einige Probleme, Comvisu auf dem RaspberryPi zum Laufen zu bringen. Die libqtwebkit4 hatte ich ja schon installiert wie oben beschrieben. Nun hatte ich die beiden Dateien libQt4Pas.so.5 und libQt4Pas.so.5.2.5 (zunächst aus dem Comvisu-ZIP-File) in einen Ordner /usr/lib kopiert, ihnen die Berechtigungen "Jeder" für alle Eigenschaften gegeben (mit dem Dateimanager) und dann das Comvisu-Programm in einen eigenen Ordner /opt/Comvisu/ kopiert und ihm den kürzeren Namen "CV" und auch die Berechtigungen "Jeder" für alle Eigenschaften gegeben und das Comvisu-Programm CV nun aus dem MidnightCommander heraus gestartet. Nun erscheint die Fehlermeldung "./CV: error while loading shared libraries: /usr/lib/libQt4Pas.so.5: file too short". Was mag falsch sein? Vielen Dank für einen Hinweis. Günter
Günter R. schrieb: > ich habe einige Probleme, Comvisu auf dem RaspberryPi zum Laufen zu > bringen. Die libqtwebkit4 hatte ich ja schon installiert wie oben > beschrieben. Nun hatte ich die beiden Dateien libQt4Pas.so.5 und > libQt4Pas.so.5.2.5 (zunächst aus dem Comvisu-ZIP-File) in einen Ordner > /usr/lib kopiert, ihnen die Berechtigungen "Jeder" für alle > Eigenschaften gegeben (mit dem Dateimanager) und dann das > Comvisu-Programm in einen eigenen Ordner /opt/Comvisu/ kopiert und ihm > den kürzeren Namen "CV" und auch die Berechtigungen "Jeder" für alle > Eigenschaften gegeben und das Comvisu-Programm CV nun aus dem > MidnightCommander heraus gestartet. > > Nun erscheint die Fehlermeldung "./CV: error while loading shared > libraries: /usr/lib/libQt4Pas.so.5: file too short". Die vermutlich bessere Variante ist, herauszufinden, in welchem Paket die betreffenden Bibliotheken enthalten sind -- libqt4pas-dev oder libqt4pas5 -- und dann eines dieser Paket zu installieren, damit sind dann auch deren Abhängigkeiten befriedigt. Ich habe darum jetzt mit "sudo apt-get install libqt4pas-dev" auf meinem RasPi unter Raspbian GNU/Linux 8.0 (jessie) die entsprechenden Bibliotheken mit ihren Abhängigkeiten installiert, dann die Zip-Datei ausgepackt, dem Programm mit "chmod u+x ComvisuV101ARMV6Linux" Ausführrechte gegeben und siehe da: läuft. Den im Zip-Archiv enthaltenen Tarball mit den Linux-Libraries habe ich nichtmal ausgepackt. Ansonsten sollten libQt4Pas.so, libQt4Pas.so.5 und libQt4Pas.so.5.2 nur symbolische Links zu libQt4Pas.so.5.2.5 sein, und manuell ausgelieferte Versionen sollten nicht in /usr/lib, sondern in /usr/local/lib kopiert werden. Dabei sollte nur die Datei libQt4Pas.so.5.2.5 in das Verzeichnis kopiert und die symbolischen Links idealerweise durch einen Aufruf von /sbin/ldconfig erzeugt werden. Aber grundsätzlich ist es immer eine sehr schlechte Idee, Libraries am Paketmanagement vorbei zwischen verschiedenen Linux-Installationen zu kopieren, ihre Abhängigkeiten zu ignorieren und sie dann obendrein auch noch in Systemverzeichnissen abzulegen, die exklusiv für die Verwaltung durch den Paketmanager vorgesehen sind. ;-)
Hallo Günther, es kam gar keine Mitteilung an mich, hab deinen Beitrag erst jetzt gesehen. Deine Vorgehensweise müsste eigentlich funktionieren. In einer früheren Linuxversion hat es beim Zippen der Symlinks unter Windows diese irgendwie zerstört, vielleicht ist das hier auch passiert. Die Fehlermeldung könnte dazu passen. Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst die Bibliothek über den Paketmanager zu installieren (händisch installierte natürlich vorher wieder löschen). Mit Linux kenn ich mich nicht so aus, ich habe eben die Anleitung gegeben, wie es bei mir funktioniert hat. Problem ist auch, ich kanns nicht so einfach testen, da ich ja die Entwicklungsbibliotheken installiert habe, bzw. auch kompiliert. Hoffe es klappt!
Sheeva P. schrieb: > Ich habe darum jetzt mit > "sudo apt-get install libqt4pas-dev" auf meinem RasPi unter Raspbian > GNU/Linux 8.0 (jessie) die entsprechenden Bibliotheken mit ihren > Abhängigkeiten installiert, dann die Zip-Datei ausgepackt, dem Programm > mit "chmod u+x ComvisuV101ARMV6Linux" Ausführrechte gegeben und siehe > da: läuft. Hallo Sheeva Plug, sehr herzlichen Dank! Habs jetzt genauso gemacht: funktioniert! Est Est E. schrieb: > Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst > die Bibliothek über den Paketmanager zu installieren (händisch > installierte natürlich vorher wieder löschen). Hallo Est Est Est, ja, jetzt hats geklappt. Kenne mich mit Linux auch nicht besonders gut aus, die Hinweise von Sheeva Plug haben es voll gebracht. Jetzt kann ich die Schnittstellen testen und mein Beispielprojekt auf den RP bringen. Melde mich wieder. Evt. könntest Du die Hinweise von Sheeva Plug in die nächste Ausgabe von CV für RP bzw. Linux einpflegen. Jedenfalls Euch beiden (und allen anderen natürlich auch) noch Frohe Weihnachten! Günter
Hallo Günther, gut dass es geklappt hat. Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder libqt4pas5 installiert? Viele Grüße
Est Est E. schrieb: > Deine Vorgehensweise müsste eigentlich funktionieren. Leider nicht. Unter Windows kannst Du .DLL-Dateien oft problemlos hin- und herkopieren, das funktioniert unter Linux aber meistens nicht. In allen Linux-Distributionen (meines Wissens mit Ausnahme von Slackware Linux) gibt es einen Paketmanager, der Pakete installiert und dabei deren Abhängigkeiten auflöst, und das gesamte Ökosystem der Distribution sowie alle seine Infrastrukturen sind auf die Benutzung dieses Paketmanagers ausgelegt. Obendrein bietet Linux über die Symlinks zu den Libraries die Möglichkeit, unterschiedliche Versionen derselben Library gleichzeitig zu installieren, darum müssen die Symlinks unbedingt korrekt erzeugt und können daher oft nicht einfach kopiert werden, weil sie dann eventuell neuere Versionen der Bibliothek überschreiben würden. > Die Hinweise von Sheeva Plug hören sich gut an. Am Besten du versuchst > die Bibliothek über den Paketmanager zu installieren (händisch > installierte natürlich vorher wieder löschen). Mit Linux kenn ich mich > nicht so aus, ich habe eben die Anleitung gegeben, wie es bei mir > funktioniert hat. Problem ist auch, ich kanns nicht so einfach testen, > da ich ja die Entwicklungsbibliotheken installiert habe, bzw. auch > kompiliert. Der Trick ist eigentlich ganz einfach: mit "ldd <executable>", also hier "ldd ComvisuV101ARMV6Linux" bekommst Du eine Liste der dynamischen Libraries, die das Programm laden will. Auf einem System ohne libQt4Pas sieht diese Liste bei mir auf dem obengenannten Raspbian so aus:
1 | linux-vdso.so.1 (0x7edae000) |
2 | /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f12000) |
3 | libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76edb000) |
4 | libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ec8000) |
5 | libQt4Pas.so.5 => not found |
6 | libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76db2000) |
7 | libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76c73000) |
8 | /lib/ld-linux-armhf.so.3 (0x54ae8000) |
9 | libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76c54000) |
10 | libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x76c49000) |
11 | libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x76c3d000) |
In Zeile 5 siehst Du: die Bibliothek "libQt4Pas.so.5" wurde nicht gefunden. Deine Aufgabe als Entwickler bzw. Distributor der Software ist es jetzt, herauszufinden, welches Softwarepaket diese Bibliothek bereitstellt. Auf Deinem Entwicklungssystem ist das ein Leichtes, das Kommando
1 | find / -name 'libQt4Pas.so.5' -exec dpkg -S {} \;
|
sucht systemweit nach der Datei und schaut dann mit dem Kommando dpkg(1) in der Datenbank installierter Pakete, zu welchem Paket die gefundene Datei gehört. Und dann sagst Du Deinen Anwendern, daß sie das betreffende Paket installieren sollen, zum Beispiel mit "sudo apt-get install <paketname>", hier also:
1 | sudo apt-get install libqt4pas5 |
Bei dem "apt-get install" werden auch noch die Abhängigkeiten automatisch installiert, bei mir waren das die Pakete
1 | libaudio2 libmng1 libqt4-network libqt4-xml libqt4-xmlpatterns libqtcore4 libqtdbus4 libqtgui4 libqtwebkit4 qtcore4-l10n |
Diese Pakete werden von der Bibliothek libqt5pas5 zwingend benötigt. Du siehst: es reicht meist nicht, einfach ein paar dynamische Bibliotheken hin- und her zu kopieren, weil dann deren Abhängigkeiten nicht befriedigt werden und das Programm deswegen trotzdem nicht funktionieren würde. Wie dem auch sei, nach der Installation zeigt ein erneuter Aufruf von "ldd ComvisuV101ARMV6Linux" nun folgende Ausgabe:
1 | linux-vdso.so.1 (0x7ef94000) |
2 | /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f34000) |
3 | libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76efd000) |
4 | libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76eea000) |
5 | libQt4Pas.so.5 => /usr/lib/arm-linux-gnueabihf/libQt4Pas.so.5 (0x76d3f000) |
6 | libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c29000) |
7 | libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aea000) |
8 | /lib/ld-linux-armhf.so.3 (0x54b9c000) |
9 | libQtWebKit.so.4 => /usr/lib/arm-linux-gnueabihf/libQtWebKit.so.4 (0x75086000) |
10 | libQtGui.so.4 => /usr/lib/arm-linux-gnueabihf/libQtGui.so.4 (0x74795000) |
11 | libQtNetwork.so.4 => /usr/lib/arm-linux-gnueabihf/libQtNetwork.so.4 (0x74667000) |
12 | libQtCore.so.4 => /usr/lib/arm-linux-gnueabihf/libQtCore.so.4 (0x743c6000) |
13 | libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x7427e000) |
14 | libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x741ff000) |
15 | libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x741d0000) |
16 | libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x741b1000) |
17 | libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x7418a000) |
18 | libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0x74179000) |
19 | libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x74124000) |
20 | libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0x740f4000) |
21 | libgstapp-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstapp-1.0.so.0 (0x740d9000) |
22 | libgstpbutils-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstpbutils-1.0.so.0 (0x740a6000) |
23 | libgstvideo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so.0 (0x74057000) |
24 | libgstaudio-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstaudio-1.0.so.0 (0x74000000) |
25 | libgstbase-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstbase-1.0.so.0 (0x73f98000) |
26 | libgstreamer-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 (0x73e92000) |
27 | libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x73e38000) |
28 | libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x73d35000) |
29 | libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 (0x73c7b000) |
30 | libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0x73c39000) |
31 | libQtXmlPatterns.so.4 => /usr/lib/arm-linux-gnueabihf/libQtXmlPatterns.so.4 (0x73894000) |
32 | libaudio.so.2 => /usr/lib/arm-linux-gnueabihf/libaudio.so.2 (0x7386f000) |
33 | libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x737d7000) |
34 | libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x737c8000) |
35 | libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x737aa000) |
36 | libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x73789000) |
37 | librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x73772000) |
38 | libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x73767000) |
39 | libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x7375b000) |
40 | liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0 (0x736db000) |
41 | libgsttag-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgsttag-1.0.so.0 (0x73696000) |
42 | libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x73682000) |
43 | libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x73672000) |
44 | libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x735ff000) |
45 | libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x735cb000) |
46 | libXt.so.6 => /usr/lib/arm-linux-gnueabihf/libXt.so.6 (0x73575000) |
47 | libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x73561000) |
Wenn Du es richtig machen wolltest, würdest Du ein Raspbian-Paket (eine .deb-Datei) Deiner Software bauen und es in einem eigenen Paket-Repository für den Paketmanager anbieten. Die Benutzer würden Dein Paket-Repository einfach als Paketquelle hinzufügen (zum Beispiel in /etc/apt/sources.list oder besser in einer eigenen Datei /etc/apt/sources.list.d/comvisu.list), danach den lokalen Cache verfügbarer Pakete mit "sudo apt-get update" aktualisieren, und könnten Dein Programm danach einfach mit "sudo apt-get install comvisu" installieren. Dabei kannst Du in dem Paket dann auch gleich die benötigten Abhängigkeiten festlegen, die der Paketmanager dann gleich automatisch mit installiert. Eine Beschreibung, wie das mit dem Paketbauen und dem Repo geht, würde hier vermutlich das Forum sprengen, aber im Internet findest Du viele gute Anleitungen dazu. Tipp: Du würdest ein "Binary Package" bauen wollen, solange Du Deinen Sourcecode nicht veröffentlichen magst. ;-)
Est Est E. schrieb: > gut dass es geklappt hat. > Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder > libqt4pas5 installiert? Die "*-dev"-Pakete sind Entwicklungspakete und enthalten die Header für die betreffende Bibliothek, damit interessierte Programme dagegen linken können. Dabei sind die "*-dev"-Pakete üblicherweise ziemlich klein und ziehen ihre Binärbibliotheken automatisch als Abhängigkeiten an. Eine Installation von "libqt4pas-dev" mit apt-get installiert also automatisch auch "libqt4pas5". Für Dein Programm wird das Entwicklungspaket allerdings nicht benötigt, es reicht daher aus, das Paket "libqt4pas5" zu installieren.
Hallo Sheeva Plug,
danke für deine detaillierte Erklärung!
Die Installation mit
"sudo apt-get install libqt4pas-dev"
ist natürlich elegant, das werde ich auf jeden Fall in die Dokumentation
aufnehmen. Wenn ich das richtig sehe muss dann die QT-Installation auch
nicht mehr getrennt aufgerufen werden, weil das ja in der Abhängigkeit
beinhaltet ist, oder?
> In allen Linux-Distributionen [...] gibt es einen Paketmanager,
Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt
andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein
Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen
nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es
händisch richtig installieren kann, also ohne den Paketmanager.
Hast du die Comvisu mal auf dem Sheevaplug getestet? Ich weiß nicht ob
der Befehlssatz kompatibel ist.
>> In allen Linux-Distributionen [...] gibt es einen Paketmanager, > Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt > andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein > Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen > nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es > händisch richtig installieren kann, also ohne den Paketmanager. Nun, es gibt tatsächlich kaum ein Linux OHNE Paketmanager - an dieser Untugend hält wohl nur noch jene Hinterhofklitsche in Redmond fest... Du willst ein Anbieter von "Binary Package(s)"? sein? Na dann obliegt es einzig DIR ALLEINE, für alle möglichen Kombinationen von CPU-Architekturen UND Linux-Kernel-ABIs (vulgo: Linuxversionen) UND Bibliotheks-ABIs (vulgo: Bilbiotheksversionen) Deine Kompilate bereit zu halten. Alternative: QUELLCODE BEREITSTELLEN. Damit kann jeder mit mehr make-mojo als Du fuer beliebeige -sprich: auch künftige- Plattformen deine Anwendung übersetzen. Nebenbei erhöht sich GANZ DRASTISCH das Potential, dass jemand Korrekturen, Verbesserungen, Erweiterungen (hier z.B. Schnittstellenvielfalt) u.v.m. zu Deinem Programm beitragen kann.
Est Est E. schrieb: > Hallo Sheeva Plug, > > danke für deine detaillierte Erklärung! > Die Installation mit > "sudo apt-get install libqt4pas-dev" > ist natürlich elegant, das werde ich auf jeden Fall in die Dokumentation > aufnehmen. Wenn ich das richtig sehe muss dann die QT-Installation auch > nicht mehr getrennt aufgerufen werden, weil das ja in der Abhängigkeit > beinhaltet ist, oder? Ja, so sollte das sein. Aber, wie gesagt, das -dev-Paket brauchst Du eigentlich nur zum Übersetzen, für Endanwender reicht libqt4pas5. >> In allen Linux-Distributionen [...] gibt es einen Paketmanager, > Die Pakete sind aber linuxabhängig, oder? D.h. ein Raspbian benötigt > andere Pakete wie bspw. Pidora? Für die QT-Bibliotheken seh ich da kein > Problem, aber die QT-Pascal-Bibliothek könnte auf einigen Plattformen > nicht verfügbar sein. Meine Frage (wenn das so ist) wäre also wie man es > händisch richtig installieren kann, also ohne den Paketmanager. Naja, "richtig" wäre es eben, dem Paketmanager Pakete bereitzustellen, die die korrekten Abhängigkeiten anziehen. Und ja, Raspbian ist ein Derivat von Debian und verwendet, wie dieses, dpkg(1) und apt(8), während Pidora ein Redhat- bzw. Fedora-Derivat ist und daher RPM und yum benutzt. Angesichts der Tatsache, daß Raspbian nun einmal die "offizielle" Distribution für den RasPi ist, die Verbreitung von Pidora nach meiner Wahrnehmung verschwindend gering ist, und Du Deine Software eventuell für Pidora auf einem Pidora -- je nach Bibliotheksversionen -- noch einmal gesondert übersetzen oder eventuell sogar anpassen müßtest, sehe ich es allerdings als durchaus fraglich, ob dieser Aufwand sich lohnt. Auf der anderen Seite kann man mit dem Programm "alien" Debian-Pakete in RPMs und umgekehrt wandeln -- dabei sollten zwar auch die Abhängigkeiten etc sauber gewandelt werden, aber ob das funktioniert, müßte man testen. > Hast du die Comvisu mal auf dem Sheevaplug getestet? Ich weiß nicht ob > der Befehlssatz kompatibel ist. Leider hab' ich im Moment keinen SheevaPlug zur Verfügung. ;-)
Est Est E. schrieb: > Hallo Günther, > > gut dass es geklappt hat. > Ich werde die Anleitung anpassen. Hast du das Paket libqt4pas-dev oder > libqt4pas5 installiert? > > Viele Grüße Hallo Est Est Est, ich hatte "libqt4pas-dev" installiert gemäß dem Ratschlag von SheevaPlug, aber er schrieb ja oben, daß für meine Anwendung "libqt4pas5" genügt hätte. Mittlerweile treten aber auch schon Probleme zutage. Ich hatte den RP zunächst über HDMI an meinem TV dran (Panasonic), jetzt wollte ich einen älteren VGA-TFT-Monitor verwenden und hatte von PiHut den "HDMI-VGA-Adapter" bezogen und die TV-Parameter in "/boot/config.txt" auf hdmi_group=2 (CEA-Modes) und hdmi_mode=11 (800*600 75 Hz) umgestellt. Der Monitor könnte im Prinzip auch 1280*1024 auflösen, aber alle höher aufgelösten Modi als 800*600 bringen den Monitor zum Flackern und sind nicht stabil; aber das ist wohl ein anderes Problem als unseres. Wenn ich nun Comvisu in einer Konsole starte, öffnet Comvisu zwar, aber im Konsolenfenster ergeben sich jede Menge Meldungen der Art "QImage::setPixel: coordinate(35,24) out of range mit unterschiedlichen Koordinaten (ca. 20 solcher Meldungen), und das Comvisu-Fenster ist größer als der Monitor-Bildschirmbereich; d.h. ich muß oben die blaue Comvisu-Leister erstmal nach links schieben, damit das Vergrößern-Icon erscheint, auf das ich dann klicke, sodaß Comvisu nun den gesamten Monitor-Bildschirm einnimmt, wie man es haben möchte, sodaß alle seine Element erreichbar sind. Trotzdem stehen die zwei Buttons "Kanalliste" und "Hintergrund" nach rechts aus dem Bild raus, aber das stört erstmal nicht. Nun kann ich mit "Schnittstelle" die "/dev/ttyUSB1" auswählen, auf 9600 bps umstellen und unter "Terminal" den Haken bei "Terminal aktiv" setzen und "Verbinden" (wird dann grün); nun sehe ich Zeichen, die ich an meinem ZOC-Terminal (Notebook) eintippe, im linken Fenster der Rohdaten. Tippe ich einen Befehl wie z.B. "#4F12.7;", dann sehe ich zusätzlich diesen Befehl im Fenster "Empfangene Befehle". Comvisu funktioniert also grundsätzlich. Nun möchte ich eine Visualisierung definieren und klicke auf "Bearbeiten". Jetzt schließt sich Comvisu und ist weg; in der Konsole erscheint die Meldung "Runtime error 120 at $xxxxxxxx ... $xxxxxxxx QPixmap: It is not safe to use pixmaps outside the GUI thread QPainter ::begin: Paint device returned engine == 0, type: 2" Für xxxxxxxx stehen insgesamt 7 32-Bit-Hex-Werte. Kann sie gerne abschreiben, wenns etwas bringt. Kann jetzt nicht sagen, ob das auch am TV mit voller Auflösung passieren würde; das kann ich gerne testen, wenn Du möchtest (muß halt den ganzen Kram runter ins Wohnzimmer tragen, wäre aber kein Problem). Das hat wohl mit Bereichsüberschreitungen des Pixel-Zeichnens zu tun wegen meiner geringen VGA-Auflösung? Günter
Ich habe vor 2 Tagen Comvisu-Linux64 mal zur Probe installiert und den Out-Of-Range-Fehler habe ich auch. Das kann man triggern, indem man mit aktivem Reiter "Ausführen" oder "Bearbeiten" den Mauszeiger aus dem Bereich der Reiter nebst zugehörigen Buttons (in einer beliebigen Richtung) heraus, oder in den Bereich hineinbewegt. An zu geringer Monitorauflösung liegt das bei mir mit Sicherheit nicht. Nach einer Weile zerlegt einem dieses Verhalten recht Zuverlässig die Console und man sollte selbige mit "reset" wieder Aufräumen. Gruß, f
es ist aber auch soo schade dass man ohne Quellcode nicht wirklich beim Fehler analysieren, beheben und allgemein Verbessern weiterhelfen kann...
@Sheevaplug: OK, dann wird es erstmal so bleiben. Mit dem Hinweis auf das "libqt4pas5"-Packet eben. Danke nochmal! @Günther: Der "Out of range" Fehler ist mir bekannt, ich dachte dass es ein Problem in QT ist (da unter Win nicht vorhanden) und dieser keinen Einfluss auf die Stabilität hat. Vor ein paar Wochen habe ich im Zusammenhang mit ein paar Experimenten unter Android festgestellt, dass diese Fehlermeldungen doch mit meinem Code zu tun haben. Das werde ich auch genauer untersuchen, dieses Jahr aber nicht mehr~ Ob der Absturz damit zu tun hat, bin ich mir auch nicht sicher. Ist das Verhalten bei dir reproduzierbar, oder sporadisch? Ich nehme an die Buttons Kanalliste und Hintergrund liegen außerhalb vom Fenster und nicht dass das Fenster über den Bildschirmrand rausragt, oder? Ist das Verhalten das gleiche wenn du die Comvisu nicht über die Shell sondern per Doppelklick startest? Zumindest eine Überlastung der Shell könnte dadurch evtl. vermieden werden. Die Fehlermeldungen hören sich aber nach einem anderen Problem an. Die Hex-Werte helfen mir erstmal nicht weiter. @Frank: Siehe oben, ich habe bei diesem Problem schon eine Spur aufgenommen. Viele Grüße
Hallo Est Est Est, wenn du ohnehin gerade am Code herumschraubst, könntest du vielleicht einen kleinen Fehler beheben. Nix wichtiges, es ist mir nur aufgefallen: Wenn man unter Linux mit einer Projektdatei startet und einen relativen Pfad angibt, also so:
1 | $ ./ComvisuV100Linux64 Anzeige.visu |
dann expandierst Du das zu einem absoluten Pfad $WorkingDir\$FileName. Da gehört natürlich kein Backslash hin sondern ein Slash, ansonsten wird die Datei nicht gefunden. Gibt man einen Pfad mit start in CWD an, also ./Anzeige.visu gehts genauso schief. Nur unter Angabe des absoluten Pfades läd er die Projektdatei. Gruß, f
Günter R. schrieb: > Mittlerweile treten aber auch schon Probleme zutage. Ich hatte den RP > zunächst über HDMI an meinem TV dran (Panasonic), jetzt wollte ich einen > älteren VGA-TFT-Monitor verwenden und hatte von PiHut den > "HDMI-VGA-Adapter" bezogen und die TV-Parameter in "/boot/config.txt" > auf > > hdmi_group=2 (CEA-Modes) und > hdmi_mode=11 (800*600 75 Hz) Möglicherweise ist die Bildwiederholfrequenz zu hoch. Vor allem ältere TFTs, aber auch einige Adapter schaffen nicht mehr als 60 Hz. Ansonsten kann sowas auch an der Qualität der Kabel liegen. YMMV. > Nun möchte ich eine Visualisierung definieren und klicke auf > "Bearbeiten". Jetzt schließt sich Comvisu und ist weg; in der Konsole > erscheint die Meldung "Runtime error 120 at $xxxxxxxx ... $xxxxxxxx > QPixmap: It is not safe to use pixmaps outside the GUI thread > QPainter ::begin: Paint device returned engine == 0, type: 2" Leider kann ich den Fehler bei mir nicht nachstellen, habe aber auch kein Serielles Gerät an meinem RasPi3. Um etwas genauer schauen zu können, was diese Probleme verursacht, könntest Du ComVisu mit strace(1) starten. Was macht das? strace(1) verfolgt das Programm und gibt dabei alle Systemcalls aus, die es aufruft. Mit "-o <dateiname>" schreibt strace(1) die Syscalls dann in die angegebene Datei, mit deren Hilfe sich Fehler häufig schnell gefunden werden können. Dein Aufruf sähe also so aus:
1 | strace -o syscalls.txt ./ComvisuV101ARMV6Linux |
Nicht verwundert sein: das Programm wird nicht gravierend, aber dennoch spürbar langsamer, wenn es unter strace(1) läuft. strace(1) hat noch einen Freund für Library-Calls namens ltrace(1), der hier vermutlich noch hilfreicher wäre. Leider scheint ltrace(1) auf ARM noch einen ungefixten Fehler zu haben. Einen kompletten Abzug von strace(1) und den Ausgaben von Comvisu kannst Du haben, indem Du es folgendermaßen aufrufst (drei Befehle):
1 | script |
2 | strace ./ComvisuV101ARMV6Linux |
3 | exit |
Dabei startet script(1) die Aufzeichnung der Ausgabekanäle und schreibt alle Ausgaben in eine Datei, die defaultmäßig "typescript" heißt; man kann das durch Angabe eines anderen Dateinamens ändern. strace(1) schreibt die aufgerufenen Systembefehle auf Stderr, solange man ihm keinen Dateinamen mitgibt, und exit beendet das Programm script(1) wieder. Est Est Est: ich weiß nicht, ob Du Dein Programm einmal als OpenSource veröffentlichen möchtest, und es ist natürlich Deine freie Entscheidung, das zu tun oder eben nicht. Mich würden die Gründe dafür interessieren, warum Du es nicht tust, aber das ist reine Neugierde meinerseits und am Ende natürlich Deine Privatsache, die ich respektiere. Allerdings möchte ich Dich daran erinnern, daß Schwierigkeiten wie die oben beschriebenen natürlich leichter gefunden und behoben werden können, wenn auch noch andere interessierte Entwickler daran mitwirken könnten.
Sheeva P. schrieb: > Einen kompletten Abzug von strace(1) und den Ausgaben von Comvisu kannst > Du haben, indem Du es folgendermaßen aufrufst (drei Befehle): > script > strace ./ComvisuV101ARMV6Linux > exit Hallo zusammen, ich habe das jetzt mal gemacht. Da kommt unheimlich viel zusammen, die typescript-Datei ist ca. 4 MByte groß und ca. 45.000 Zeilen lang. Wer will das analysieren? Ich habe mal die ersten 5000 Zeilen angehängt (nur so zum Anschauen). Bringt das wirklich etwas? Das Programm "ComvisuV101ARMV6Linux" hatte ich umbenannt in "CV", damit ich nicht soviel tippen muß. Günter
Günter R. schrieb: > ich habe das jetzt mal gemacht. Da kommt unheimlich viel zusammen, die > typescript-Datei ist ca. 4 MByte groß und ca. 45.000 Zeilen lang. Wer > will das analysieren? Ich habe mal die ersten 5000 Zeilen angehängt (nur > so zum Anschauen). Bringt das wirklich etwas? Ja -- ich würde das nicht erwähnen, wenn es nichts bringen würde. So eine Datei liest man natürlich nicht zeilenweise, sondern filtert sie etwa mit grep(1). Außerdem stehen die sinnvollsten Informationen bei einem Absturz natürlich meist irgendwo kurz vor dem Ende der Datei... ;-)
Das habe ich mir schon auch gedacht. Frage an die Moderatoren: darf ich eine so große Datei (ca. 4 MByte) hier überhaupt hochladen?
Günter R. schrieb: > Das habe ich mir schon auch gedacht. > > Frage an die Moderatoren: darf ich eine so große Datei (ca. 4 MByte) > hier überhaupt hochladen? Danke f. die Nachsicht. Andere laden Bilder mit mehr als 5MB... (technisch also keine Limits) Wie wär's aber mit den letzten 45'000 Zeilen?
1 | $ tail -45000 typescript1 > AnhangZumHochladen |
Sorry, bin kein Moder
Think different. schrieb: > Wie wär's aber mit den letzten 45'000 Zeilen? Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert ist, kannst Du die Arbeit gleich dem RasPi überlassen:
1 | zip typescript.zip typescript |
Ansonsten kann ich viele komprimierten Formate lesen: gzip, bz2, rar,
aber auch das antiquierte compress und das neuerdings beliebte 7zip.
Feel free.
> Sorry, bin kein Moder
??ß?
Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich komm ich momentan einfach nicht hin. Grüße
Sheeva P. schrieb: > Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert Ich war wohl im Dornröschenschlaf ... natürlich, das ist die Lösung. Zippen. Hier ist die gesamte Datei. Mit TotalCommander das einfachste, das es gibt.
Est Est E. schrieb: > Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich > komm ich momentan einfach nicht hin. > > Grüße Kein Problem. Eilt ja überhaupt nicht. Günter
Günter R. schrieb: > Sheeva P. schrieb: >> Wie wär's mit einer gezippten Datei? Wenn das Paket "zip" installiert > > Ich war wohl im Dornröschenschlaf ... natürlich, das ist die Lösung. > Zippen. Hier ist die gesamte Datei. Mit TotalCommander das einfachste, > das es gibt. Schade, leider enthält der Systrace nur die Syscalls des Hauptprozesses. Aber ich sehe, daß dort mehrere Kindprozesse erzeugt werden, deren Syscalls leider nicht miterfaßt werden. Könntest Du dasselbe bitte nochmal wiederholen, dabei dem strace(1)-Befehl aber den Parameter "-f" mitgeben? Danke!
Klar, mache ich heute Abend. Was bedeutet eigentlich das "(1)", das Du im Kommentar jeweils an die Befehlsnamen hängst? Das kenne ich nicht. Verweist das auf irgendetwas? Mit eingetippt wird es ja nicht?
> Was bedeutet eigentlich das "(1)", das Du im Kommentar jeweils an die > Befehlsnamen hängst? Das kenne ich nicht. Verweist das auf irgendetwas? Eine gängige Notation im *nix Umfeld. Das ist ein Hinweis in welcher Sektion der man pages die Dokumentation dazu zu finden ist. Aus Wikipedia: """ (1) User Commands and Daemons („Anwender-Kommandos und Hintergrunddienste“) (2) System Calls and Kernel Services („Systemaufrufe und -dienste“) (3) Subroutines („Unterprogramme“) (4) Special Files, Device Drivers and Hardware („Geräte“) (5) Configuration Files („Konfigurationsdateien“) (6) Games („Spiele“) (7) Miscellaneous Commands („Verschiedenes“) (8) Administrative Commands and Daemons („Verwaltung“) """ Dann gibt es noch interne Befehle der Kommandointerpreter: diese sind z.B. unter bash(1) ( also mit man bash ) im Abschnitt BUILTINS nachzuschlagen. Diese Notation hilft bei Mehrdeutigkeiten: z.B. hostname(1) und hostname(5), printf(3) und printf bei bash(1), echo(1) und echo bei bash(1), usw. > Mit eingetippt wird es ja nicht? Korrekt.
Günter R. schrieb: > Klar, mache ich heute Abend. Hallo Sheeva Plug, muß leider gestehen, daß ich damals diese Sache, wegen anderer wichtiger Dinge, total vergessen hatte und auch in den folgenden Tagen nicht mehr daran gedacht habe. Vor kurzem ist mir das wieder eingefallen, und ich wollte heute dieses verbesserte Script erzeugen und hier reinstellen, aber nun stürzt Comvisu nicht mehr in der zuvor beschriebenen Weise ab; weiß jetzt nicht, warum. Ich will jetzt mal ein Projekt anlegen und ausgiebig testen. Ich berichte dann darüber. Wenn es wieder Probleme gibt, erzeuge ich dieses Script und poste es hier. Sorry! Viele Grüße Günter
Hallo Günter, diese Woche hab ich schon ein bisschen an der Comvisu "rumgeschraubt". Die "QImage::setPixel"-Fehler habe ich soweit beseitigt, ich bin aber noch auf eine andere Fehlermeldung gestoßen, der ich erst noch nachgehen will. Viele Grüße
Hallo, ich bin gestern von Weinga Unity Klaus auf das Projekt aufmerksam gemacht worden! Super Sache das ganze. Was ich mich aber noch frage: Besteht die Möglichkeit, das interpretierte/gesendete Protokoll anzupassen? In manchen Anwendungen werden ja auch Binärdaten übertragen. Ich könnte mir das als eine Art Filter oder Plugin vorstellen, das man in den Datenstrom zwischen Comvisu und der Seriellen stöpselt. Ähnlich wie man einen sed oder grep in der Linux Shell zwischen Programme schalten kann. Irgendwie schade, wenn man auf Comvisu ganz verzichten müsste, nur weil das Protokoll der Mikrocontrolleranwendung nicht zu Comvisu passt. Est Est E. schrieb: > Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich > komm ich momentan einfach nicht hin. Hast du schon mal daran gedacht, das Projekt zu veröffentlichen? Oft nehmen sich dann engagierte Nutzer manchen Problemen an, und insgesamt geht mehr weiter. Zukunftssicher würde das Projekt dadurch auch werden. LG, Karl
Hallo Karl, ein Pluginkonzept ist mir zu kompliziert. Man kann sich aber relativ einfach selbst einen Umsetzer programmieren. In der Comvisu kann man ja einen lokalen UDP-Socket konfigurieren (127.0.0.1), den man dann mit seinem Umsetzterprogramm 'bedient'. Man ist dann auch frei darin, von wo der Umsetzer seine Daten bekommt. Ich hab mir auch schon überlegt ein Grundgerüst für einen Umsetzer zu programmieren und zu veröffentlichen, das würde die Hürde sicher niedriger setzen. Hab ich aber jetzt auch nicht fertig in der Schublade. Eine spätere Veröffentlichung ist nicht ausgeschlossen, bisher hab ich mich aber nicht dazu durchringen können. Viele Grüße
Hallo Est Est Est, hattest du mal wieder Zeit, am Comvisu für Linux weiterzuarbeiten? Mein RasPi wartet darauf noch (hat aber keine Eile). Liebe Grüße Günter
Hallo Karl, ich glaube auch, dass das das flexiblere Ansatz ist. Auch wenn es dann leider kein geschlossenes System ist. Lg, Klaus Man sieht sich.
Günter R. schrieb: > hattest du mal wieder Zeit, am Comvisu für Linux weiterzuarbeiten? Mein > RasPi wartet darauf noch (hat aber keine Eile). Ja, gibt eine neue Version, die ich aber wegen Linuxproblemen noch nicht veröffentlich habe.
Neue Version Comvisu V1.1. ComvisuV110Linux64 für Linux (Mod.: siehe Beitrag 14.10.2018 10:58) und ComvisuV110ARMV6Linux für den Raspi Die Neuerungen sind im 'Hauptthread' beschrieben: Beitrag "Re: Serielle Visualisierung mit Comvisu" Die Q-Pixmap-Fehler sollten beseitigt sein, zumindest teilweise. Wenn da noch was auffällt, bitte Bescheid geben.
:
Bearbeitet durch Moderator
Jo, das mit dem Protokoll-Wrapper mit UDP ist natürlich ein gangbarer Weg, danke für den Hinweis. Bei mir startet die neue Version leider nicht: ~/Downloads/ComvisuV110Linux64 $ ./ComvisuV110Linux64 bash: ./ComvisuV110Linux64: cannot execute binary file: Exec format error `sudo apt install libqt4pas-dev` hab ich ausgeführt. EDIT: verwende Linux Mint 18.3 (basierend auf Ubuntu 16.04)
:
Bearbeitet durch User
Hallo Karl, habs bei mir nochmal getestet, die Binary ist tatsächlich kaputt. Ist wohl beim Übertragen per USB-Stick vom Linux- auf den Windowsrechner passiert. Angehängt nun das getestet funktionierende Programm. @Mods: Bitte den (kaputten) Anhang "ComvisuV110Linux64.zip" aus folgendem Beitrag löschen: Beitrag "Re: Comvisu für Linux"
:
Bearbeitet durch User
Ja, so ist Est Est Est :-) Wenn es nur mehr davon gäbe. Schönes Wochenende. Happy Hacking
:
Bearbeitet durch User
Est Est E. schrieb: > Neue Version Comvisu V1.1. > > ComvisuV110Linux64 für Linux (Mod.: siehe Beitrag 14.10.2018 10:58) > und > ComvisuV110ARMV6Linux für den Raspi Hallo Est Est Est, gibts diese neue Version 1.1 auch für den Raspi (ARM)? Ich finde sie nicht. War sie in dem Thread vom 26.09.2018 dabei, dessen Datei die Moderatoren wegen des Fehlers gelöscht hatten? Könntest Du sie ggf. nochmals posten? Herzlichen Dank. Günter
Hallo Günter, hast recht, ist wohl mitgelöscht worden. Hier nochmal die Raspberry-Version. Die jeweils aktuelle Version gibts auch auf meiner Homepage: Comvisu.de. Grüße
Hallo Est Est Est, super! Danke für die schnelle Reaktion. Wünsche Dir einen schönen Abend. Günter
Hallo Est Est Est, ich habe jetzt mal meine Heizungs-Visualisierung, die seit mehr als 1 Jahr auf einem Mini-PC unter "Comvisu für Win" (Win7) perfekt läuft, auf den Raspi portiert, mit der neuen CV-Version 1.1. Das Projekt läuft im Prinzip, jedenfalls was numerische Anzeigen und Textboxen betrifft. Aber bei Zeitdiagrammen wird nichts geschrieben, vielmehr springt die Gitteranzeige innerhalb des Fensters wild umher (links/rechts), und die Beschriftung unten ändert sich dauernd. Das ist ein komisches Verhalten, das ich von der Win-Version überhaupt nicht kenne. Kanns jetzt leider nicht besser beschreiben. Vielleicht kannst Du damit etwas anfangen. Ich habe mal beide Projektversionen beigefügt. Vielleicht hast Du gelegentlich mal Zeit, darüber nachzudenken, was da sein könnte. Hat jemand aus dem Forum mal Comvisu unter Raspi probiert, bzw. könnte jemand mal meine Visualisierung bei seinem Raspi testen? Danke. Viele Grüße und schönen Abend Günter
Hallo Günther, habs kurz probiert, der Fehler taucht bei mir auch auf (ab zwei Diagrammen). Das ist zur Analyse schon mal gut, an was es liegt, weiß ich aber jetzt noch nicht. Ich meld mich wieder. Viele Grüße!
Hier eine neue Version für den Raspberry, bei der der Fehler mit dem Diagramm nicht mehr auftreten sollte. Es handelte sich um einen Multithreading-Fehler, der ab zwei Diagrammen relevant wird. Er ist bei allen 32-bit Versionen vorhanden, also auch bei der Windowsversion. Nur dort tritt er scheinbar seltener auf. Bei Zeit gibt es dann auch eine neue Version für Windows. Viele Grüße
Hallo Est Est Est, prima, danke! Ich teste es Anfang nächster Woche. Unter Windows (7) läuft das gepostete Projekt seit vielen Monaten rund um die Uhr störungsfrei. Ich würde es aber gerne auf den RP umstellen, aus Stromspargründen und Abnutzung der Festplatte. Ich melde mich dann. Gruß Günter
Hallo Est Est Est, ich war so gespannt, daß ich CVRPi jetzt schon ausprobiert habe. Sieht sehr gut aus. Mein Projekt läuft jetzt schon 3 Stunden störungsfrei. Danke! Gruß, Günter
Angehängte Dateien:
Hallo Est Est Est, jetzt sind doch Fehler aufgetreten, nach ca. 5 Stunden oder so; siehe Screenshots. In den Zeitdiagrammen gibt es plötzlich einen Sprung nach hinten. Die Testdaten habe ich mit einem kleinen Kommandozeilen-Programm "sertest.exe" erzeugt, das ich beigefügt habe (Lazarus). Dort eine Schnittstelle auswählen (ggf. einfach Enter drücken), dann die Option "V", danach einen Delay-Wert eingeben; ich hatte 120 Sek. gewählt; nach der 150. Messung oder so (sitze ja nicht ständig am Bildschirm) passiert es (also nach etwa 5 Stunden). Evt. kannst Du mal danach schauen. Danke. Gruß, Günter
Hallo Günter, das schau ich mir mal an. Hast du mehrere Tests gemacht und es ist wiederholt zur gleichen Zeit nach 5 Stunden aufgetreten? Du schreibst von einer Exe, schickst du die Daten von Windows an den Raspi, oder hast du es halt für den Raspi kompiliert? Viele Grüße~
Hallo Est Est Est, ich habe es zweimal getestet und erlebt, daß der Fehler nach mehreren Stunden (eben ca. 4 - 5 Stunden) aufgetreten ist. Ich probiers nachher wieder. Das beigefügte sertest.exe-Programm ist mit Lazarus für Windows compiliert, läuft hier auf einem älteren Win2000-Notebook (ist aber auf einem Win7-PC compiliert und ist dort auch lauffähig) und seriell gehen die Daten zum Raspi. Dort habe ich einen Renkforce-Seriell-Adapter (von Conrad), an den ich das Notebook-Kabel anstecke. Läuft bei 9600 bps. Beim V-Befehl des Programms habe ich mal für die Kanäle 1 - 6 linear ansteigende Werte erzeugt (und noch die Messung-Nummer und die Zahl der Sensoren, und einen Signon-Text), die nach Erreichen der Höchstgrenze wieder zurückspringen, daher die sägezahlförmige Struktur (wollte erst einen Sinus ausgeben, war mir aber auf die Schnelle zu aufwendig, so gehts ja auch). In meinem Heizraum existiert das alles ja real, dort auf einem Win7-Mini-PC mit der Windows-Comvisu, und die Daten kommen von einem ATmega328 mit 1-Wire-Sensoren (6 Stück). Was ich noch nicht getestet habe (mache ich nachher aber), ist, ob es mit der Anzahl der empfangenen Messages zu tun hat und nicht mit der langen Laufzeit. Da melde ich mich wieder. Gruß, Günter
Hallo Est Est Est, ich habe jetzt einen anderen Monitor am Raspi angeschlossen (älterer VGA-Monitor mit HDMI-VGA-Umsetzter, vorher mein Panasonic-TV mit HDMI-Eingang). Jetzt funktioniert die Anwendung störungsfrei, schon ein paar Tage rund um die Uhr. Diese Unterbrechungen sind nicht mehr aufgetreten. Ich denke, es hatte mit dem TV zu tun. Jetzt spare ich jede Menge Energie, der PC mit Festplatte bleibt aus, und der Raspi macht den Job bislang perfekt. Abermals herzlichen Dank für Deine Mühe und dieses tolle Programm. Gruß Günter
Hallo Günter, ich weiß auch nicht, was ich davon halten soll. Dass es am Monitor liegt, kann ich mir kaum vorstellen, hab aber auch keine Idee, was es sein könnte. Wenns jetzt funktioniert, toi toi toi. Du kannst dich ja wieder melden, wenn das Problem doch wieder auftritt. Viele Grüße~
Neue Version Comvisu V1.6 für Linux und ARMV6-Linux (Raspberry) Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu" Viel Spaß~
Für die (stromsparend) laufende Raspi-Version hier mal die Frage ob es möglich oder geplant ist, die Bedienoberfläche im Netz als Webseite zur Verfügung zu stellen und damit die lokale Anwesenheit des Bedieners/Betrachters überflüssig zu machen...?
Gedanken dazu habe ich mir bereits gemacht, das wäre sicher eine interessante Funktionalität. Nur ist das wohl nicht so einfach. Ein einfacher Screenshot der Anzeige und zurückschicken von Maus- und Tastatuseingaben wird nicht reichen (Bandbreite), und wenn man die Instrumente dann clientseitig zusammenbaut wird es kompliziert, das sprengt dann schnell das bestehende Programmgerüst.
Est Est E. schrieb: > Ein einfacher Screenshot der Anzeige > und zurückschicken von Maus- und Tastatuseingaben wird nicht reichen > (Bandbreite) Also das würde ich nicht ganz so eng sehen denn die Fernbedienung und erst recht die blanke Ansicht der Oberfläche funktioniert mit einer VNC Lösung wie Teamviewer (am PC) doch schon halbwegs brauchbar. Est Est E. schrieb: > und wenn man die Instrumente dann clientseitig > zusammenbaut wird es kompliziert Das müsste doch gar nicht sein. Interessant ist hier die Verwendung, nicht der Entwurf. Est Est E. schrieb: > Neue Version Comvisu V1.6 Bei dieser Gelegenheit auch von mir ein Dankeschön fürs Programm, für den Support hier und daß die Entwicklung weitergeht!
Hallo, die letzte Linux Version 1.60 beinhaltet eine Mischung aus 64 bit Programm und 32 bit Bibliothek.
1 | ComvisuV160Linux64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.4.0, stripped |
2 | |
3 | bin-qt4pas-V2.5_Qt4.5.3/libQt4Pas.so.5.2.5: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=29be979a23a403be7092dedceff46864f6b714ed, stripped |
Ich habe mir eine alte Version heruntergeladen und die Bibliothek genutzt. Aber vielleicht kann man das ja einmal aktualisieren. Grüße, Ulf
Danke für die Mitteilung. Bei der nächsten Version schau ich, dass die richtige Bibliotheksversion dabei ist.
Hallo Est Est Est, es war wieder soweit und ich hab meinen Laptop mit Ubuntu 20.04 aufgesetzt. Jetzt bekomme ich leider Comvisu nicht mehr zum Laufen. Grund ist: error while loading shared libraries: libQt4Pas.so.5: wrong ELF class: ELFCLASS32 Auch kann ich libqt4pas nicht über apt nachinstallieren. Hast du dafür bereits eine Lösung? Lg, Klaus
Hallo, hab durch den Beitrag von Ulf jetzt das Problem lösen können, indem ich die ComvisuV100Linux64.zip runtergeladen hab und die darin enthaltene Library installiert hab. Die tar.gz habe ich hier noch hinzugefügt, mit der es bei mir geklappt hat. Lg, Klaus
Bin erst gerade dazu gekommen, hier nochmal das ganze Packet mit der nun (hoffentlich :) korrekten Bibliothek. (Das ist keine neue Comvisu-Version.)
Neue Version Comvisu V1.80. Fürs Desktop-Linux gibt es diesmal zwei Versionen, basierend auf der Grafikbibliothek QT5 bzw. der Vorgängerversion QT4. Auf aktuellen Systemen ist die QT5-Version zu bevorzugen. Auf älteren Installationen (bspw. Ubuntu 18.4) kann es trotz vorhandener Bibliotheken zu Fehlern kommen (Die Comvisu kann nicht gestartet werden). Dann sollte auf die QT4-Version zurückgegriffen werden. Für den Raspi habe ich vorerst nur in QT4 kompiliert, bei wem es damit zu Problemen kommt bitte Bescheid geben. Sonstige Neuerungen siehe Hauptthread: Beitrag "Re: Serielle Visualisierung mit Comvisu"
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.