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]
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
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
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.
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?
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
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.
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
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
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 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
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
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
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
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:
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
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:
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
@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...
;-)
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?
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
??ß?
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
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.
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)
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"
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,
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
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~
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 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
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"