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
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! :-)
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:
1 | [ 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>' |
2 | [ 128s] 540 | }; |
3 | [ 128s] | ^ |
4 | [ 128s] | | |
5 | [ 128s] | <brace-enclosed initializer list> |
6 | [ 128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:580:38: error: 'JOULE' is not a member of 'sigrok::Unit' |
7 | [ 128s] 580 | { Unit::Joule, sigrok::Unit::JOULE }, |
8 | [ 128s] | ^~~~~ |
9 | [ 128s] /home/abuild/rpmbuild/BUILD/smuview-0.0.5/src/data/datautil.hpp:581:40: error: 'COULOMB' is not a member of 'sigrok::Unit' |
10 | [ 128s] 581 | { Unit::Coulomb, sigrok::Unit::COULOMB }, |
11 | [ 128s] | ^~~~~~~ |
12 | [ 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' |
13 | [ 128s] 582 | { Unit::AmpereHour, sigrok::Unit::AMPERE_HOUR }, |
14 | [ 128s] | ^~~~~~~~~~~ |
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.
:
Bearbeitet durch User
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.
Beitrag #6912629 wurde vom Autor gelöscht.
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
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
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.