SmuView 0.0.5 veröffentlicht

[Frank S. (knarfs)]

Hallo zusammen.

Am Wochenende konnte ich endlich Version 0.0.5 von SmuView fertig 
stellen:

https://github.com/knarfS/smuview/releases/tag/v0.0.5

SmuView ist eine GUI, welche die sigrok Library verwendet und es 
ermöglicht Netzteile, elektronische Lasten, Multimeter, LCR Meter, 
Waagen, usw. zu steuern und Daten zu erfassen.

Neben vielen Bugfixes und einer aktuellen Version von sigrok in den zu 
Verfügung stehenden Binaries sind u.A. folgende Neuerungen zu erwähnen:
- Einstellungen wie z.B. die angezeigten Ansichten (Plots, Steuerungen, 
Messwerte, ...) und deren Größe und Position werden pro Gerät 
gespeichert. Somit kann die Oberfläche besser personalisiert werden.
- Neue Python-Bindings um Messaufgaben noch besser zu scripten.
- Kurven können jetzt umbenannt werden (PlotView).
- Suchen- und Ersetzen-Dialog für den Python-Editor.

Hier findet ihr das aktuelle Handbuch mit einen recht guten Überblick 
über die Features von SmuView:
https://knarfs.github.io/doc/smuview/0.0.5/manual.html
Dokumentation der Python-Bindings:
https://knarfs.github.io/doc/smuview/0.0.5/python_bindings_api.html

Als nächstes wird die Unterstützung von Oszilloskopen implementiert.

Viel Spaß beim Testen und ich freue mich auf Rückmeldungen von euch!

Viele Grüße
Frank

[E. H. (emax)]

Hallo Frank,

ich habe mir das gebaut und bin begeistert, besten Dank!

Ein paar Rückmeldungen noch:
- Das Appimage geht bei mir nicht, weil die darin enthaltene libserial 
buggy ist (s.u.).
- Das Bauen mit dem Kombi-Build (libserial, sigrok und smuview) war ein 
Albtraum und hat final nicht funktioniert (Ubuntu 20.xx ..). U.a. z.B. 
tonnenweise nicht aufgelöste Referenzen zu QWT.
- Mit dem dedizierten Build für smuview alleine ging es dann problemlos 
- man muss allerdings eine funktionierende libserial haben oder sich 
bauen.
- Dabei ist zu beachten, dass manche Versionen der libserial eine 
Struktur "termiox" verwenden, die final dazu führt, dass der Fehler 
"inappropiate ioctl call" ausgeworfen wird, und das Ganze nicht 
funktioniert. Bei mir führte das dazu, dass ich mein Brymen 257s nicht 
seriell via /dev/ttyUSBx ansprechen konnte. Wenn man diese Struktur 
deaktiviert (configure.ac), dann geht das. Es gibt aber auch (irgendwo) 
einen Patch, der das erledigt. Den kann man aber nicht 1:1 anwenden, 
weil er sich auf andere Zeilennummern bezieht, deshalb musste ich das 
für den libserial Eigenbau von Hand ändern.
- cmake ist leider etwas intransparent. Im "single build" für smuview 
war das kein kein Problem. Aber im Kombi-build blieben die Pfade zu 
"QWT_INCLUDE_DIR" und "QWT_LIBRARY" "UNDEFINED". Man kann das 
nachtragen, aber dazu muss man erst mal kapieren, was cmake überhaupt so 
treibt.

Ansonsten ein schönes Stück Software, danke dafür!

Eins noch (s.a. eevblog): Es wäre schön, wenn man sein Setup als 
"Setting" unter einem individuellem Namen sichern könnte. Also Geräte, 
Device Einstellungen (/dev/ttyxyz ...), Kanäle usw., evt. auch das 
Bildschirmlayout. Mit einem "File" Menu das dann "Open recent setting 
..." anbietet, wäre es perfekt.

Ich werde smuview für alle Geräte verwenden, die ich damit Kontrollieren 
kann. Unter Linux z.Zt. aus meiner Sicht die beste Lösung fürs Logging 
(mehr habe ich noch nicht genutzt).

Danke! :-)

[Frank K. (frank)]

Ich habe auch versucht das zu kompilieren. Kann es sein dass dafür eine 
neuere libsigrok als die offiziell releaste Version 0.5.2 benötigt wird? 
Wenn ja, welche?

Ich bekomme einige dieser Fehler:

[  128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:540:1: error: could not convert '{{sigrok::Unit::VOLT, sv::data::Unit::Volt}, {sigrok::Unit::AMPERE, sv::data::Unit::Ampere}, {sigrok::Unit::OHM, sv::data::Unit::Ohm}, {sigrok::Unit::FARAD, sv::data::Unit::Farad}, {sigrok::Unit::KELVIN, sv::data::Unit::Kelvin}, {sigrok::Unit::CELSIUS, sv::data::Unit::Celsius}, {sigrok::Unit::FAHRENHEIT, sv::data::Unit::Fahrenheit}, {sigrok::Unit::HERTZ, sv::data::Unit::Hertz}, {sigrok::Unit::PERCENTAGE, sv::data::Unit::Percentage}, {sigrok::Unit::BOOLEAN, sv::data::Unit::Boolean}, {sigrok::Unit::SECOND, sv::data::Unit::Second}, {sigrok::Unit::SIEMENS, sv::data::Unit::Siemens}, {sigrok::Unit::DECIBEL_MW, sv::data::Unit::DecibelMW}, {sigrok::Unit::DECIBEL_VOLT, sv::data::Unit::DecibelVolt}, {sigrok::Unit::UNITLESS, sv::data::Unit::Unitless}, {sigrok::Unit::DECIBEL_SPL, sv::data::Unit::DecibelSpl}, {sigrok::Unit::CONCENTRATION, sv::data::Unit::Concentration}, {sigrok::Unit::REVOLUTIONS_PER_MINUTE, sv::data::Unit::RevolutionsPerMinute}, {sigrok::Unit::VOLT_AMPERE, sv::data::Unit::VoltAmpere}, {sigrok::Unit::WATT, sv::data::Unit::Watt}, {sigrok::Unit::WATT_HOUR, sv::data::Unit::WattHour}, {sigrok::Unit::METER_SECOND, sv::data::Unit::MeterPerSecond}, {sigrok::Unit::HECTOPASCAL, sv::data::Unit::HectoPascal}, {sigrok::Unit::HUMIDITY_293K, sv::data::Unit::Humidity293K}, {sigrok::Unit::DEGREE, sv::data::Unit::Degree}, {sigrok::Unit::HENRY, sv::data::Unit::Henry}, {sigrok::Unit::GRAM, sv::data::Unit::Gram}, {sigrok::Unit::CARAT, sv::data::Unit::Carat}, {sigrok::Unit::OUNCE, sv::data::Unit::Ounce}, {sigrok::Unit::TROY_OUNCE, sv::data::Unit::TroyOunce}, {sigrok::Unit::POUND, sv::data::Unit::Pound}, {sigrok::Unit::PENNYWEIGHT, sv::data::Unit::Pennyweight}, {sigrok::Unit::GRAIN, sv::data::Unit::Grain}, {sigrok::Unit::TAEL, sv::data::Unit::Tael}, {sigrok::Unit::MOMME, sv::data::Unit::Momme}, {sigrok::Unit::TOLA, sv::data::Unit::Tola}, {sigrok::Unit::PIECE, sv::data::Unit::Piece}, {<expression error>, sv::data::Unit::Joule}, {<expression error>, sv::data::Unit::Coulomb}, {<expression error>, sv::data::Unit::AmpereHour}}' from '<brace-enclosed initializer list>' to 'std::map<const sigrok::Unit*, sv::data::Unit>'
[  128s]   540 | };
[  128s]       | ^
[  128s]       | |
[  128s]       | <brace-enclosed initializer list>
[  128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:580:38: error: 'JOULE' is not a member of 'sigrok::Unit'
[  128s]   580 |         { Unit::Joule, sigrok::Unit::JOULE },
[  128s]       |                                      ^~~~~
[  128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:581:40: error: 'COULOMB' is not a member of 'sigrok::Unit'
[  128s]   581 |         { Unit::Coulomb, sigrok::Unit::COULOMB },
[  128s]       |                                        ^~~~~~~
[  128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:582:43: error: 'AMPERE_HOUR' is not a member of 'sigrok::Unit'
[  128s]   582 |         { Unit::AmpereHour, sigrok::Unit::AMPERE_HOUR },
[  128s]       |                                           ^~~~~~~~~~~

[E. H. (emax)]

Es gibt wohl Unterschiede zwischen CLANG und gcc. Ich hatte gcc, und 
meine, irgendwo muss das auch angegeben werden - aber ich weiß nicht 
mehr wo.

Und sigrok hatte ich zuvor auch komplett selbst kompiliert und vor allem 
auch "make install" durchgeführt. Danach ein "sudo ldconfig", weils 
sonst mit den libs nicht klappt. Was Du da hast ist aber kein 
Linker-Problem, sondern compiler-Gemecker. Für mich sieht das sehr nach 
der clang/gcc Frage aus.

[J. S. (engineer)]

Frank S. schrieb:
> SmuView ist eine GUI, welche die sigrok Library verwendet und es
> ermöglicht Netzteile, elektronische Lasten, Multimeter, LCR Meter,
> Waagen, usw. zu steuern und Daten zu erfassen.
Kannst du auch in Datenbanken schreiben? Am Besten in MS-Access. Geht 
über ODBC. Mit Python weiß ich nicht, ob und wie das geht, aber mit C++ 
/ wxWidgets ist das kein Problem.

Sowas wäre klasse, weil man dann auch unregelmäßige Daten erfassen und 
direkt verarbeiten kann, also mit Zeitstempel, Nutzer, und einigem 
anderen und das ohne den Umweg über ein offline-Datenformat, das erst 
importiert werden müsste.

[Frank S. (knarfs)]

Hallo E. H.,

danke für deine Rückmeldung und es freut es mich, dass du SmuView 
nützlich findest!

> - Das Appimage geht bei mir nicht, weil die darin enthaltene libserial
> buggy ist (s.u.).

Du hast wahrscheinlich das AppImage von SmuView 0.0.5 verwendest, 
welches von Januar 2021 ist und noch ein "fehlerhaftes" libserialport 
beinhaltet.
Ich biete seit einiger Zeit auch einen Continiuous Build an, welcher 
automatisch bei jeden Push in den master-Branch erzeugt wird und somit 
immer die neuesten Bugfixes und Features enthält (z.B. auch eine neue 
Version von libserialport).

Ich empfehle deshalb die Verwendung des Continuous Build: 
https://github.com/knarfS/smuview/releases/tag/continuous

> - Das Bauen mit dem Kombi-Build (libserial, sigrok und smuview) war ein
> Albtraum und hat final nicht funktioniert (Ubuntu 20.xx ..). U.a. z.B.
> tonnenweise nicht aufgelöste Referenzen zu QWT.

Ich nehme an, du meinst das Build-Script, dessen Verwendung ich in der 
SmuView-Doku Kapitel 2.1.2 beschreibe?
Du musst vorher die dort verlinkten Abhängigkeiten installieren. Ich 
werde die Dokumentation überarbeiten, da das nicht so deutlich aus der 
Doku hervor geht.
Es müssen alle Abhängigkeiten für libserialport, libsigrok und SmuView 
installiert werden: 
https://sigrok.org/wiki/Linux#Building_.28manually.29

Ein weiterer Punkt, der in der Doku nicht erwähnt ist: Du benötigst 
Python3 als Default. Bei Ubuntu 20.04 geht das z.B. mit "sudo apt 
install python-is-python3"

> - Mit dem dedizierten Build für smuview alleine ging es dann problemlos
> - man muss allerdings eine funktionierende libserial haben oder sich
> bauen.
> - Dabei ist zu beachten, dass manche Versionen der libserial eine
> Struktur "termiox" verwenden, die final dazu führt, dass der Fehler
> "inappropiate ioctl call" ausgeworfen wird, und das Ganze nicht
> funktioniert. Bei mir führte das dazu, dass ich mein Brymen 257s nicht
> seriell via /dev/ttyUSBx ansprechen konnte. Wenn man diese Struktur
> deaktiviert (configure.ac), dann geht das. Es gibt aber auch (irgendwo)
> einen Patch, der das erledigt. Den kann man aber nicht 1:1 anwenden,
> weil er sich auf andere Zeilennummern bezieht, deshalb musste ich das
> für den libserial Eigenbau von Hand ändern.

Vor einiger Zeit wurde die termiox-API aus dem Kernel entfernt, welche 
von libserialport verwendet wurde. Der von dir angesprochene Patch ist 
seit Juli im libserialport-Repository. Wenn du das Build-Script 
verwendest, wird sowieso der aktuellste git-Stand gebaut. Wenn du selber 
baust, musst du darauf achten immer den neuesten Stand zu bauen.

> - cmake ist leider etwas intransparent. Im "single build" für smuview
> war das kein kein Problem. Aber im Kombi-build blieben die Pfade zu
> "QWT_INCLUDE_DIR" und "QWT_LIBRARY" "UNDEFINED". Man kann das
> nachtragen, aber dazu muss man erst mal kapieren, was cmake überhaupt so
> treibt.

Das ist komisch, da bei beiden Builds die Erkennung von Qwt identisch 
ist.
Ich habe gerade SmuView per Build-Script mit einem frisch aufgesetzten 
Ubuntu 20.04 gebaut und nach dem Installieren der Abhängigkeiten (z.B. 
Qwt 6.1.4: libqwt-qt5-dev, siehe Wiki) hatte ich diesen Fehler nicht.

> Eins noch (s.a. eevblog): Es wäre schön, wenn man sein Setup als
> "Setting" unter einem individuellem Namen sichern könnte. Also Geräte,
> Device Einstellungen (/dev/ttyxyz ...), Kanäle usw., evt. auch das
> Bildschirmlayout. Mit einem "File" Menu das dann "Open recent setting
> ..." anbietet, wäre es perfekt.

Aktuell werden all diese Dinge schon gespeichert und u.A. das Layout bei 
bereits bekannten Geräten wieder geladen.
Das die Settings in/aus einer Datei gespeichert/geladen werden fehlt 
noch, ist aber auf meiner ToDo Liste.

Viele Grüße
Frank

[Frank S. (knarfs)]

Hi Frank,

Dein Fehler weisst darauf hin, das du eine alte SmuView-Version baust 
(wahrscheinlich Tag 0.0.5), sowie eine zu alte libsigrok Version.

Du solltest immer den aktuellsten git-Stand von libserialport, libsigrok 
und SmuView bauen (Jeweils HEAD von Branch "master").

Am besten du verwendest das Build-Script (wie oben beschrieben: vorher 
die Dependencies installieren): 
https://knarfs.github.io/doc/smuview/continuous/manual.html#_linux

Viele Grüße
Frank

[Frank S. (knarfs)]

Hallo Jürgen,

ich plane derzeit keine Datenbankanbindung von SmuView. Aktuell musst du 
deine Daten als CSV exportieren und dann in Access importieren.

Eine direkte Anbindung von Access ist aber sehr unwahrscheinlich, da ich 
auf die Schnelle keine Bibliothek gefunden habe, welche die 
Lizenzanfordungen erfüllt (GPLv3).

Viele Grüße
Frank

[E. H. (emax)]

Hallo Frank (S.),

vielen Dank für Deine Kommentare.

Es stimmt, ich war etwas zack-zack mit dem Bauen, und hatte einige 
Abhängigkeiten vermutlich nicht sauber vorbereitet. Die Details sind mir 
aber entfallen. Python 3 läuft hier übrigens als Standard, das war nicht 
das Problem, nur die QWT Sache bleibt mir unklar.

Das ist aber kein Problem, es läuft ja jetzt - und das sehr schön :-)

> Das die Settings in/aus einer Datei gespeichert/geladen werden
> fehlt noch, ist aber auf meiner ToDo Liste.

Supa! Serialisieren und feddisch. ;-)

> ich plane derzeit keine Datenbankanbindung von SmuView.
> Aktuell musst du deine Daten als CSV exportieren und
> dann in Access importieren.

Das ist nun zwar nicht meine Baustelle, aber ich finde das richtig so. 
Das Paradigma "kleine, unabhängige Module" garantiert eine gewisse 
Unabhängigkeit von Versionen, und ist m.E. auch kein Showstopper. Denn 
auch Access dürfte einen CSV-Import erlauben. Unter Linux "pipe"-t man 
das ggf. einfach per script durch. Und wenn das unter Windows nicht 
geht, dann sollte sich smuview das nicht zum eigenen Problem machen.

Dann kommen auch schnell die MySQL- und die Postgres-Anfragen, und 
irgendwann ist das Programm so aufgebläht, dass der Code sich am Ende zu 
80 Prozent mit anderen Problemen befasst. Es wäre natürlich bequem, das 
stimmt schon. Aber der Preis (Versionsabhängigkeiten et.al.) wäre mir zu 
hoch.

Ich finds gut so, und würde mich auf den Kern der Sache konzentrieren, 
absolute Zustimmung.