Comvisu für Linux

[Est Est E. (comvisu)]

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]

[Jonas G. (jstjst)]

Hallo,

schön das es eine Linuxversion gibt allerdings funktioniert es bei mir 
schon mal nicht.
Ich bekomme bei Start folgende Fehlermeldung:

./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

[Est Est E. (comvisu)]

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

[Jonas G. (jstjst)]

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

[Harry L. (mysth)]

Kleiner Tip:
Dzie Libs die man selbst händisch in eine Distribution einfügt gehören 
in /usr/local/lib ;)

[Est Est E. (comvisu)]

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~

[Est Est E. (comvisu)]

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 (Gast)]

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. (comvisu)]

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.ä.

[Weinga U. (weinga-unity)]

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. (weinga-unity)]

OK, Problem gefunden.

32bit Version von libqtwebkit verwenden, dann läuft das Programm auch.

[Est Est E. (comvisu)]

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.

[Carl D. (jcw2)]

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!

[Dennis X. (Gast)]

HAMMER!
Probiere ich ähhh nach den Klausuren direkt aus ;-)

[Est Est E. (comvisu)]

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?

[Carl D. (jcw2)]

Bei Ubuntu 14.04 mußte ich ia32-Libs nachinstallieren. Und für 16.04 ist 
es aktuell noch nicht fertig.

[Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56)]

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

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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...

[Carl D. (jcw2)]

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.

[Est Est E. (comvisu)]

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.

[Dennis X. (Gast)]

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

[Est Est E. (comvisu)]

:-)

Und plötzlich ist das Impressum die meistbesuchte Seite~~

[Est Est E. (comvisu)]

Neue Version V07.

Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

[Est Est E. (comvisu)]

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

[Est Est E. (comvisu)]

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

[Weinga U. (weinga-unity)]

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

[H. S. (Gast)]

und ?

[Est Est E. (comvisu)]

Ich hatte scheinbar die Linuxversion nicht eingestellt, der Download 
sollte jetzt wieder funktionieren!

Grüße

[R. Manfred B. (pwgdrx)]

Hallo,

läuft das Teil auch auf dem raspberry (wheezy)?

Gruß

[Est Est E. (comvisu)]

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

[OQ (Gast)]

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

[alf42 (Gast)]

hi,

wie schaut es aus, wenn du den source nicht zur verfügung stellen 
möchtest,
würdest du eventuell eine 64bit version bauen ???

[Est Est E. (comvisu)]

Hallo,

Das kann ich machen. Ich muss nur schauen, wie ich das mit den 
(gleichnamigen) QT-Bibliotheken dann mache. Also etwas Geduld~

[Est Est E. (comvisu)]

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

[GPL (Gast)]

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.

[Markus S. (blackwatcher)]

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?

[Est Est E. (comvisu)]

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

[Markus S. (blackwatcher)]

Dankeschön. Daran hat es gelegen. Es war unter meinem Xubuntu 
tatsächlich kein QT Framework installiert.Jetzt startet die Software 
einwandfrei!

[Est Est E. (comvisu)]

Neue Version Comvisu V1.0
Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Downloads auch unter Comvisu.de

Viele Grüße

[Georg B. (georgb)]

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

[Est Est E. (comvisu)]

Hallo Georg,

es hat sich in dieser Richtung nichts getan, es mangelt mir immernoch an 
einem Raspi.

Viele Grüße

[Est Est E. (comvisu)]

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

[H. S. (Gast)]

Bekomme Ich mit dem Programm auch USB-Geräte dran?

[Est Est E. (comvisu)]

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.

[Günter (galileo14)]

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

[HimboKusPokus (Gast)]

> 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.

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Sheeva P. (sheevaplug)]

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. ;-)

[Est Est E. (comvisu)]

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!

[Günter (galileo14)]

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. (comvisu)]

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

[Sheeva P. (sheevaplug)]

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:

linux-vdso.so.1 (0x7edae000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f12000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76edb000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76ec8000)
libQt4Pas.so.5 => not found
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76db2000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76c73000)
/lib/ld-linux-armhf.so.3 (0x54ae8000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76c54000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x76c49000)
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

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:

sudo apt-get install libqt4pas5

Bei dem "apt-get install" werden auch noch die Abhängigkeiten 
automatisch installiert, bei mir waren das die Pakete

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:

linux-vdso.so.1 (0x7ef94000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f34000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76efd000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76eea000)
libQt4Pas.so.5 => /usr/lib/arm-linux-gnueabihf/libQt4Pas.so.5 (0x76d3f000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76c29000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aea000)
/lib/ld-linux-armhf.so.3 (0x54b9c000)
libQtWebKit.so.4 => /usr/lib/arm-linux-gnueabihf/libQtWebKit.so.4 (0x75086000)
libQtGui.so.4 => /usr/lib/arm-linux-gnueabihf/libQtGui.so.4 (0x74795000)
libQtNetwork.so.4 => /usr/lib/arm-linux-gnueabihf/libQtNetwork.so.4 (0x74667000)
libQtCore.so.4 => /usr/lib/arm-linux-gnueabihf/libQtCore.so.4 (0x743c6000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x7427e000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x741ff000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x741d0000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x741b1000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x7418a000)
libXrender.so.1 => /usr/lib/arm-linux-gnueabihf/libXrender.so.1 (0x74179000)
libjpeg.so.62 => /usr/lib/arm-linux-gnueabihf/libjpeg.so.62 (0x74124000)
libpng12.so.0 => /lib/arm-linux-gnueabihf/libpng12.so.0 (0x740f4000)
libgstapp-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstapp-1.0.so.0 (0x740d9000)
libgstpbutils-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstpbutils-1.0.so.0 (0x740a6000)
libgstvideo-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so.0 (0x74057000)
libgstaudio-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstaudio-1.0.so.0 (0x74000000)
libgstbase-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstbase-1.0.so.0 (0x73f98000)
libgstreamer-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 (0x73e92000)
libgobject-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x73e38000)
libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x73d35000)
libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0 (0x73c7b000)
libfontconfig.so.1 => /usr/lib/arm-linux-gnueabihf/libfontconfig.so.1 (0x73c39000)
libQtXmlPatterns.so.4 => /usr/lib/arm-linux-gnueabihf/libQtXmlPatterns.so.4 (0x73894000)
libaudio.so.2 => /usr/lib/arm-linux-gnueabihf/libaudio.so.2 (0x7386f000)
libfreetype.so.6 => /usr/lib/arm-linux-gnueabihf/libfreetype.so.6 (0x737d7000)
libSM.so.6 => /usr/lib/arm-linux-gnueabihf/libSM.so.6 (0x737c8000)
libICE.so.6 => /usr/lib/arm-linux-gnueabihf/libICE.so.6 (0x737aa000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0x73789000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x73772000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x73767000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x7375b000)
liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0 (0x736db000)
libgsttag-1.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgsttag-1.0.so.0 (0x73696000)
libgmodule-2.0.so.0 => /usr/lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x73682000)
libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0x73672000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x735ff000)
libexpat.so.1 => /lib/arm-linux-gnueabihf/libexpat.so.1 (0x735cb000)
libXt.so.6 => /usr/lib/arm-linux-gnueabihf/libXt.so.6 (0x73575000)
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. ;-)

[Sheeva P. (sheevaplug)]

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.

[Est Est E. (comvisu)]

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.

[HimboKusPokus (Gast)]

>> 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.

[Sheeva P. (sheevaplug)]

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. ;-)

[Günter (galileo14)]

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

[Frank L. (florenzen)]

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

[OQ (Gast)]

es ist aber auch soo schade dass man ohne Quellcode nicht wirklich 
beim Fehler analysieren, beheben und allgemein Verbessern weiterhelfen 
kann...

[Est Est E. (comvisu)]

@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

[Frank L. (florenzen)]

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:

$ ./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

[Sheeva P. (sheevaplug)]

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:

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):

script
strace ./ComvisuV101ARMV6Linux
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.

[Günter (galileo14)]

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

[Sheeva P. (sheevaplug)]

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 (galileo14)]

Das habe ich mir schon auch gedacht.

Frage an die Moderatoren: darf ich eine so große Datei (ca. 4 MByte) 
hier überhaupt hochladen?

[Think different. (Gast)]

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?

$ tail -45000 typescript1 > AnhangZumHochladen

Sorry, bin kein Moder

[Sheeva P. (sheevaplug)]

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:

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

??ß?

[Est Est E. (comvisu)]

Sorry, dass es es von meiner Seite gerade nicht weiter geht. Zeitlich 
komm ich momentan einfach nicht hin.

Grüße

[Günter (galileo14)]

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.

[Günter (galileo14)]

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

[Sheeva P. (sheevaplug)]

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!

[Günter (galileo14)]

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?

[Kommandozeile für Alle vor dem Frühstück! (Gast)]

> 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 (galileo14)]

Okay, wieder etwas gelernt.

Vielen Dank!

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

Okay, super. Dann warte ich mal auf eine neue Version.

Vielen Dank!

Günter

[Karl Z. (griffin27)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Weinga U. (weinga-unity)]

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.

[Est Est E. (comvisu)]

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.

[Est Est E. (comvisu)]

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.

[Karl Z. (griffin27)]

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)

[Est Est E. (comvisu)]

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"

[Karl Z. (griffin27)]

Vielen Dank für den raschen Sonntagseinsatz :)
Nun läufts wieder.

[Weinga U. (weinga-unity)]

Ja, so ist Est Est Est :-)

Wenn es nur mehr davon gäbe.

Schönes Wochenende. Happy Hacking

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

Hallo Est Est Est,

super! Danke für die schnelle Reaktion.

Wünsche Dir einen schönen Abend.

Günter

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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!

[Günter (galileo14)]

Prima, danke.

Gruß Günter

[Est Est E. (comvisu)]

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

[Günter (galileo14)]

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

[Günter (galileo14)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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~

[Günter (galileo14)]

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

[Günter (galileo14)]

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

[Est Est E. (comvisu)]

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~

[Günter (galileo14)]

Klar, das mache ich.

Gruß, Günter

[Est Est E. (comvisu)]

Neue Version Comvisu V1.6 für Linux und ARMV6-Linux (Raspberry)
Neuerungen siehe Hauptthread:
Beitrag "Re: Serielle Visualisierung mit Comvisu"

Viel Spaß~

[Hans (Gast)]

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...?

[Est Est E. (comvisu)]

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.

[Hans (Gast)]

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!

[Ulf (Gast)]

Hallo,

die letzte Linux Version 1.60 beinhaltet eine Mischung aus 64 bit 
Programm und 32 bit Bibliothek.

ComvisuV160Linux64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 2.4.0, stripped

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

[Est Est E. (comvisu)]

Danke für die Mitteilung. Bei der nächsten Version schau ich, dass die 
richtige Bibliotheksversion dabei ist.

[Weinga U. (weinga-unity)]

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

[Weinga U. (weinga-unity)]

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

[Est Est E. (comvisu)]

Bin erst gerade dazu gekommen, hier nochmal das ganze Packet mit der nun 
(hoffentlich :) korrekten Bibliothek.

(Das ist keine neue Comvisu-Version.)

[Est Est E. (comvisu)]

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"