SmuView - Eine sigrok GUI für Netzteil, Multimeter und mehr

[Frank S. (knarfs)]

Hallo Zusammen,

ich mochte gern mein Projekt SmuView vorstellen:

https://sigrok.org/wiki/SmuView
https://github.com/knarfS/smuview

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.
Das SMU in SmuView steht für Source Measure Unit. Aktuell wird das noch 
nicht erfüllt, doch ich arbeite daran ;)

Leider werden momentan noch nicht alle Netzteile und Lasten unterstützt, 
da eine Codeanpassung in der sigrok Library notwendig ist (fehlender 
Mutex). Die unterstützten Geräte sind im Wiki (s.o.) gelistet.
Damit die Liste erweitert werden kann, bin ich auf Unterstützung 
angewiesen, um die Änderungen in sigrok zu testen.

SmuView befindet sich in einem frühen Entwicklungsstadium und ist 
sicherlich noch nicht fehlerfrei, aber bei meinen Tests auf 
verschiedenen Plattformen lief es stabil.

Was bereits geht:
- Steuerung von Geräten
- Daten der Geräte erfassen
- Multiplikation, Division, Integration über Zeit von einen oder 
mehreren Daten-Kanälen.
- Diverse Darstellungen der Kanäle (Panels, Plots, Listen, ...)
- Export der gesammelten Daten als CSV

Was ich noch implementieren will:
- Verbesserung der GUI (z.B. der Plot-Ansicht)
- Programmierbarkeit der angeschlossenen Geräte mithilfe eines 
Flowgraphs
- Programmierbarkeit der angeschlossenen Geräte mithilfe eines Python 
Scripts

Executables der letzten Entwicklerversion können hier herunter geladen 
werden:

https://github.com/knarfS/smuview/releases/

Sicherlich habe ich einiges vergessen, aber da werdet ihr hoffentlich 
nach hacken. Ich freue auf eure Reaktionen.


Viele Grüße
Frank

[Gerd E. (robberknight)]

Sieht interessant aus.

Kann ich mir damit auch berechnete Werte als Grafik plotten lassen?

Sagen wir mal ich möchte die Effizienz eines DC/DC-Wandlers vermessen. 
Ich schließe 4 von Sigrok unterstützte Multimeter an (Spannung und Strom 
Eingang, Spannung und Strom Ausgang). Jetzt möchte ich gerne einen 
X/Y-Plot angezeigt bekommen, in dem ich z.B. Leistung Ausgang und die 
Effizienz sehe. Also keine direkt von einem der Multimeter abrufbare 
Größe, sondern eine, die aus mehreren Messwerten durch einfache 
mathematische Operationen berechnet werden muss.

[Frank S. (knarfs)]

Gerd E. schrieb:
> Kann ich mir damit auch berechnete Werte als Grafik plotten lassen?

Ja das funktioniert.
Die Kanäle für Widerstand, Leistung, sowie Ah und Wh (siehe Bild oben) 
werden z.B. bei Netzteile und Lasten automatisch berechnet und sind 
natürlich plotbar oder können bei weiteren "MathChannels" verwendet 
werden.

> Sagen wir mal ich möchte die Effizienz eines DC/DC-Wandlers vermessen.
> Ich schließe 4 von Sigrok unterstützte Multimeter an (Spannung und Strom
> Eingang, Spannung und Strom Ausgang). Jetzt möchte ich gerne einen
> X/Y-Plot angezeigt bekommen, in dem ich z.B. Leistung Ausgang und die
> Effizienz sehe. Also keine direkt von einem der Multimeter abrufbare
> Größe, sondern eine, die aus mehreren Messwerten durch einfache
> mathematische Operationen berechnet werden muss.

Das war der ursprüngliche Gedanke bei dem Projekt. Damit das aber gut 
funktioniert fehlt noch die Programmierbarkeit (s.o.).
X/Y-Graphen sind schon implementiert.

[Gerd E. (robberknight)]

Frank S. schrieb:
> Das war der ursprüngliche Gedanke bei dem Projekt.

sehr gut

> Damit das aber gut
> funktioniert fehlt noch die Programmierbarkeit (s.o.).

wie darf ich das verstehen?

Meinst Du damit daß der momentan z.B. noch keinen automatischen Sweep 
der El. Last macht? Es wäre für mich momentan durchaus zu verschmerzen 
das einmal manuell durchzkurbeln.

Oder gibt es noch andere Probleme die zum "gut funktioniert" fehlen?

Bevor ich meine E-Last fernsteuern kann, müsste ich das Sigrok zuerst um 
GPIB-Adapter allgemein und dann Support für meine konkrete Last 
(Kikusui) erweitern. Das wäre doch noch nen Stück Arbeit.

[Frank S. (knarfs)]

Gerd E. schrieb:
> Meinst Du damit daß der momentan z.B. noch keinen automatischen Sweep
> der El. Last macht? Es wäre für mich momentan durchaus zu verschmerzen
> das einmal manuell durchzkurbeln.

Ja, das habe ich damit gemeint. Manuell ist kein Problem.
Wenn du auch die Eingangsspannung in die Charakterisierung einbeziehen 
willst, dann ist die Automatisierung von großem Vorteil.

> Bevor ich meine E-Last fernsteuern kann, müsste ich das Sigrok zuerst um
> GPIB-Adapter allgemein und dann Support für meine konkrete Last
> (Kikusui) erweitern. Das wäre doch noch nen Stück Arbeit.

GPIB-Adapter werden von sigrok unter Linux über linux-gpib unterstützt. 
Ich selbst habe einen Agilent 82357B China Klon erfolgreich im Einsatz.

[Gerd E. (robberknight)]

Frank S. schrieb:
> Manuell ist kein Problem.

klingt gut. Werde das dann mal ausprobieren.

> Wenn du auch die Eingangsspannung in die Charakterisierung einbeziehen
> willst, dann ist die Automatisierung von großem Vorteil.

Klar, mit 2 Parametern macht das keinen Spaß mehr.

Dann reicht aber auch der X/Y-Plot nicht mehr, dann brauchst Du einen 
3D-Plot.

> GPIB-Adapter werden von sigrok unter Linux über linux-gpib unterstützt.
> Ich selbst habe einen Agilent 82357B China Klon erfolgreich im Einsatz.

Ist das nicht ein ständiger Ärger mit den Kerneltreibern für die? 
Außerdem sind die ziemlich teuer wenn man mehrere davon haben möchte.

Ich dachte daher eher an sowas hier:
https://sigrok.org/wiki/Galvant_GPIBUSB

[Frank S. (knarfs)]

Gerd E. schrieb:
>> GPIB-Adapter werden von sigrok unter Linux über linux-gpib unterstützt.
>> Ich selbst habe einen Agilent 82357B China Klon erfolgreich im Einsatz.
>
> Ist das nicht ein ständiger Ärger mit den Kerneltreibern für die?

Da in keiner mir bekannten Linux Distribution linux-gpib dabei sind, 
muss selber compiliert werden. Der Aufwand ist gering, muss aber nach 
jedem Kernel Update erneut gemacht werden. Das nervt ein bisschen...

> Außerdem sind die ziemlich teuer wenn man mehrere davon haben möchte.

Mein Adapter hat ca. 80€ gekostet (eBay) und es sind 2 Geräte daran 
angeschlossen (1x HP6632B und 1x HP3478A). Funktioniert super, obwohl 
der Adapter nur ein China Klon ist :)

[Gerd E. (robberknight)]

So, ich wollte es mal ausprobieren. Das einzige von Sigrok fertig 
unterstützte Multimeter was ich auf die schnelle auftreiben konnte, war 
ein Agilent U1252A mit passendem USB-Adapter.

Mit sigrok-cli getestet - funktioniert

Im smuview:
"Add new device"
Driver: agilent-dmm
Interface: Serial port, /dev/ttyUSB0
-> Scan

Das smuview beendet sich dann, auf der Konsole kommt:

Configurable::init(): Init  "Agilent U1252A"  - key  "Data Source"
Configurable::init(): Init  "Agilent U1252A"  - key  "Samplerate"
Trying to close device  "Agilent U1252A V0.89 (/dev/ttyUSB0)"
Caught exception: std::bad_cast

[Frank S. (knarfs)]

Gerd E. schrieb:
> Das smuview beendet sich dann, auf der Konsole kommt:
>

> Configurable::init(): Init  "Agilent U1252A"  - key  "Data Source"
> Configurable::init(): Init  "Agilent U1252A"  - key  "Samplerate"
> Trying to close device  "Agilent U1252A V0.89 (/dev/ttyUSB0)"
> Caught exception: std::bad_cast
>

Hast du selber compiliert?
Ich kann mir gerade nicht vorstellen, wo der Cast schief läuft.
Wenn du Zeit und Lust hast, wäre es super, wenn du mit dem gdb einen 
Backtrace erstellen könntest, damit ich den Fehler nachvollziehen und 
fixen kann.

Ganz oben auf meiner ToDo-Liste steht boost:stacktrace, damit bei 
Abstürzen automatisch ein Stacktrace erstellt wird...

[Gerd E. (robberknight)]

So, ich hoffe Du hast ausreichend Bildschirmbreite um dieses 
Musterbeispiel eines C++-Stacktraces in all seiner Schönheit zu 
bewundern ;)

#0  0x00007ffff4d6a170 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) (obj=0x14e7750, tinfo=0x7ffff505b750 <typeinfo for std::bad_cast>, dest=0x7ffff4d68460 <std::bad_cast::~bad_cast()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:77
#1  0x00000000007867a2 in Glib::VariantBase::cast_dynamic<Glib::Variant<unsigned int> >(Glib::VariantBase const&) (v=...) at /usr/include/glibmm-2.4/glibmm/variant.h:644
#2  0x0000000000787a74 in Glib::VariantBase::cast_dynamic<Glib::Variant<unsigned long> >(Glib::VariantBase const&) (v=...) at /usr/include/glibmm-2.4/glibmm/variant.h:220
#3  0x0000000000788c6b in sv::devices::properties::UInt64Property::list_config() (this=0x1590790) at /home/gerd/opensource/smuview/src/devices/properties/uint64property.cpp:88
#4  0x0000000000788e08 in sv::devices::properties::UInt64Property::UInt64Property(std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey) (this=0x1590790, configurable=..., config_key=<optimized out>) at /home/gerd/opensource/smuview/src/devices/properties/uint64property.cpp:41
#5  0x00000000007777d3 in __gnu_cxx::new_allocator<sv::devices::properties::UInt64Property>::construct<sv::devices::properties::UInt64Property, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(sv::devices::properties::UInt64Property*, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (this=<optimized out>, __p=0x1590790) at /usr/include/c++/8/new:169
#6  0x00000000007777d3 in std::allocator_traits<std::allocator<sv::devices::properties::UInt64Property> >::construct<sv::devices::properties::UInt64Property, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::allocator<sv::devices::properties::UInt64Property>&, sv::devices::properties::UInt64Property*, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=..., __p=0x1590790) at /usr/include/c++/8/bits/alloc_traits.h:475
#7  0x00000000007777d3 in std::_Sp_counted_ptr_inplace<sv::devices::properties::UInt64Property, std::allocator<sv::devices::properties::UInt64Property>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::allocator<sv::devices::properties::UInt64Property>, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=..., this=0x1590780) at /usr/include/c++/8/bits/shared_ptr_base.h:541
#8  0x00000000007777d3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<sv::devices::properties::UInt64Property, std::allocator<sv::devices::properties::UInt64Property>, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::_Sp_make_shared_tag, sv::devices::properties::UInt64Property*, std::allocator<sv::devices::properties::UInt64Property> const&, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=..., this=<optimized out>) at /usr/include/c++/8/bits/shared_ptr_base.h:658
#9  0x00000000007777d3 in std::__shared_ptr<sv::devices::properties::UInt64Property, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<sv::devices::properties::UInt64Property>, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::_Sp_make_shared_tag, std::allocator<sv::devices::properties::UInt64Property> const&, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=..., __tag=..., this=<optimized out>) at /usr/include/c++/8/bits/shared_ptr_base.h:1324
#10 0x00000000007777d3 in std::shared_ptr<sv::devices::properties::UInt64Property>::shared_ptr<std::allocator<sv::devices::properties::UInt64Property>, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::_Sp_make_shared_tag, std::allocator<sv::devices::properties::UInt64Property> const&, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=..., __tag=..., this=<optimized out>) at /usr/include/c++/8/bits/shared_ptr.h:360
#11 0x00000000007777d3 in std::allocate_shared<sv::devices::properties::UInt64Property, std::allocator<sv::devices::properties::UInt64Property>, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::allocator<sv::devices::properties::UInt64Property> const&, std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) (__a=...)
    at /usr/include/c++/8/bits/shared_ptr.h:707
#12 0x00000000007777d3 in std::make_shared<sv::devices::properties::UInt64Property, std::shared_ptr<sv::devices::Configurable>, sv::devices::ConfigKey&>(std::shared_ptr<sv::devices::Configurable>&&, sv::devices::ConfigKey&) () at /usr/include/c++/8/bits/shared_ptr.h:723
#13 0x00000000007777d3 in sv::devices::Configurable::init() (this=0x1062ba0) at /home/gerd/opensource/smuview/src/devices/configurable.cpp:108
#14 0x000000000077e5b8 in sv::devices::Configurable::create<std::shared_ptr<sigrok::Device>&, QString, sv::devices::DeviceType&>(std::shared_ptr<sigrok::Device>&, QString&&, sv::devices::DeviceType&) () at /usr/include/c++/8/bits/shared_ptr_base.h:513
#15 0x000000000077e5b8 in sv::devices::HardwareDevice::init() (this=0x13be590) at /home/gerd/opensource/smuview/src/devices/hardwaredevice.cpp:107
#16 0x000000000074c324 in sv::devices::MeasurementDevice::create<std::shared_ptr<sigrok::Context>&, std::shared_ptr<sigrok::HardwareDevice>&>(std::shared_ptr<sigrok::Context>&, std::shared_ptr<sigrok::HardwareDevice>&) () at /usr/include/c++/8/ext/atomicity.h:82
#17 0x000000000074c324 in sv::DeviceManager::driver_scan[abi:cxx11](std::shared_ptr<sigrok::Driver>, std::map<sigrok::ConfigKey const*, Glib::VariantBase, std::less<sigrok::ConfigKey const*>, std::allocator<std::pair<sigrok::ConfigKey const* const, Glib::VariantBase> > >) (this=0x7fffffffd090, sr_driver=std::shared_ptr<sigrok::Driver> (use count 4, weak count 1) = {...}, drvopts=...)
    at /home/gerd/opensource/smuview/src/devicemanager.cpp:265
#18 0x00000000007aa141 in sv::ui::dialogs::ConnectDialog::scan_pressed() (this=0x7fffffffc0b0) at /usr/include/c++/8/ext/atomicity.h:96
#19 0x00007ffff52e384e in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5
#20 0x00007ffff6082b91 in QAbstractButtonPrivate::emitPressed() () at /lib64/libQt5Widgets.so.5
#21 0x00007ffff60832e5 in QAbstractButton::mousePressEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#22 0x00007ffff5fda10f in QWidget::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#23 0x00007ffff5f9a565 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#24 0x00007ffff5fa1ec8 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#25 0x000000000074b9fb in Application::notify(QObject*, QEvent*) (this=<optimized out>, receiver=<optimized out>, event=<optimized out>) at /home/gerd/opensource/smuview/src/application.cpp:42
#26 0x00007ffff52bb676 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#27 0x00007ffff5fa11bd in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () at /lib64/libQt5Widgets.so.5
#28 0x00007ffff5ff43f8 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#29 0x00007ffff5ff6f9e in QWidgetWindow::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#30 0x00007ffff5f9a565 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#31 0x00007ffff5fa1c80 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#32 0x000000000074b9fb in Application::notify(QObject*, QEvent*) (this=<optimized out>, receiver=<optimized out>, event=<optimized out>) at /home/gerd/opensource/smuview/src/application.cpp:42
#33 0x00007ffff52bb676 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#34 0x00007ffff5856183 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () at /lib64/libQt5Gui.so.5
#35 0x00007ffff5858285 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /lib64/libQt5Gui.so.5
#36 0x00007ffff58333bb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Gui.so.5
#37 0x00007fffdf119b6f in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5XcbQpa.so.5
#38 0x00007ffff52ba5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#39 0x00007ffff618bafd in QDialog::exec() () at /lib64/libQt5Widgets.so.5
#40 0x00000000007579a9 in sv::MainWindow::on_action_add_device_tab_triggered() (this=0x7fffffffd0d0) at /home/gerd/opensource/smuview/src/mainwindow.cpp:327
#41 0x00000000007d62b5 in sv::MainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
    at /home/gerd/opensource/smuview/build/smuview_autogen/UVLADIE3JM/moc_mainwindow.cpp:86
#42 0x00007ffff52e384e in QMetaObject::activate(QObject*, int, int, void**) () at /lib64/libQt5Core.so.5
#43 0x00007ffff6082896 in QAbstractButton::clicked(bool) () at /lib64/libQt5Widgets.so.5
#44 0x00007ffff6082abe in QAbstractButtonPrivate::emitClicked() () at /lib64/libQt5Widgets.so.5
#45 0x00007ffff6083f13 in QAbstractButtonPrivate::click() () at /lib64/libQt5Widgets.so.5
#46 0x00007ffff60840e5 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#47 0x00007ffff6171ede in QToolButton::mouseReleaseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#48 0x00007ffff5fd9658 in QWidget::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#49 0x00007ffff6171f87 in QToolButton::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#50 0x00007ffff5f9a565 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#51 0x00007ffff5fa1ec8 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#52 0x000000000074b9fb in Application::notify(QObject*, QEvent*) (this=<optimized out>, receiver=<optimized out>, event=<optimized out>) at /home/gerd/opensource/smuview/src/application.cpp:42
#53 0x00007ffff52bb676 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#54 0x00007ffff5fa11bd in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () at /lib64/libQt5Widgets.so.5
#55 0x00007ffff5ff43f8 in QWidgetWindow::handleMouseEvent(QMouseEvent*) () at /lib64/libQt5Widgets.so.5
#56 0x00007ffff5ff6f9e in QWidgetWindow::event(QEvent*) () at /lib64/libQt5Widgets.so.5
#57 0x00007ffff5f9a565 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#58 0x00007ffff5fa1c80 in QApplication::notify(QObject*, QEvent*) () at /lib64/libQt5Widgets.so.5
#59 0x000000000074b9fb in Application::notify(QObject*, QEvent*) (this=<optimized out>, receiver=<optimized out>, event=<optimized out>) at /home/gerd/opensource/smuview/src/application.cpp:42
#60 0x00007ffff52bb676 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /lib64/libQt5Core.so.5
#61 0x00007ffff5856183 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () at /lib64/libQt5Gui.so.5
#62 0x00007ffff5858285 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /lib64/libQt5Gui.so.5
#63 0x00007ffff58333bb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Gui.so.5
#64 0x00007fffdf119b6f in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5XcbQpa.so.5
#65 0x00007ffff52ba5bb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt5Core.so.5
#66 0x00007ffff52c2686 in QCoreApplication::exec() () at /lib64/libQt5Core.so.5
#67 0x00000000004cafac in main (argc=<optimized out>, argv=<optimized out>) at /home/gerd/opensource/smuview/main.cpp:212
#68 0x00007ffff438f11b in __libc_start_main () at /lib64/libc.so.6
#69 0x000000000074ae9a in _start () at /home/gerd/opensource/smuview/src/application.cpp:49

Ich war eben auch mal so frei in dem UInt64Property::list_config() ein 
gvar.get_type_string() nach dem ersten next_value() einzubauen: ich 
bekomme dann "{sv}" zurück, also anscheinend ein string variant 
dictionary. Daß sich das nicht so einfach in UInt64 casten lässt wundert 
mich nicht. Ein gvar.print(true) gibt "{'samplerate-steps', <[uint64 1, 
20, 1]>}" zurück.

Mir scheint es also als ob das Sigrok sich hier die Freiheit nimmt diese 
Daten noch eine Stufe weiter zu verschachteln. Verwendete libsigrok ist 
libsigrok-0.5.1-1.fc28.x86_64 so wie bei Fedora 28 gepackaged.

[Frank S. (knarfs)]

Alles klar, danke!
Den Fehler werde ich in den nächsten Tagen fixen und dir dann Bescheid 
geben. Sollte kein großes Ding sein.

Allerdings sind die beiden ConfigKeys der Agilent DMMs (Samplerate und 
DataSource) in SmuView noch nicht konfigurierbar (steht aber ebenfalls 
auf der ToDo Liste).

[Frank S. (knarfs)]

Hi Gerd,

der Fehler sollte behoben sein.

Viele Grüße
Frank

[Frank S. (knarfs)]

Die angehängten Bilder zeigen die Charakterisierung eines 
Buck-Converters mit einem LM2596 (Eingangsspannung 8V, Ausgangsspannung 
5V, Ausgangsstrom 0-2A).

Ich habe hier meinen experimentellen "Flow Controller" Code verwendet 
(siehe Bild SmuView-DCDC-Load.png) um die Last von 0A bis 2A 
durchzufahren.
Natürlich kann der Ausgangsstrom auch von Hand hoch gedreht werden.

Da nicht die P-Kanäle des Netzteils und der Last genommen wurden, sind 
P_in und P_out berechnet.
Die Beschriftungen der Plots sind nicht immer aussagekräftig 
(ToDo-Liste...).

Verwendete Geräte: HP 6632B (Netzteil), Arachnid Labs ReLoadPro (Last), 
EEVBlog 121GW (U_in), HP 3478A (I_in), Metex M-3860M (U_out). I_out 
wurde mit der ReloadPro gemessen.

[Alex E. (tecnologic)]

Moin Zusammen,

könnte ich darüber auch eigene Netzteile/Geräte einbinden? Wir basteln 
gerade an einem leistungsfähigen DC/DC für Server-NTs als "LaborNT" und 
ich suche noch ein Gui dafür. Wenn ich über Uart/Usb seriell oder 
ähnliches dein SmuView nutzen könnte wäre das natürlich top. Gibt es 
dort irgend welche Informationen wie man eigene Geräte einbinden kann?

Wir wollen solche Effizienz Untersuchungen mit Motoren machen und 
brauchen deshalb etwas andere Leistungen als ein Übliches LaborNT.

Gruß

Alex

[Frank S. (knarfs)]

Hi Alex,

Alexander B. schrieb:
> könnte ich darüber auch eigene Netzteile/Geräte einbinden? Wir basteln
> gerade an einem leistungsfähigen DC/DC für Server-NTs als "LaborNT" und
> ich suche noch ein Gui dafür. Wenn ich über Uart/Usb seriell oder
> ähnliches dein SmuView nutzen könnte wäre das natürlich top. Gibt es
> dort irgend welche Informationen wie man eigene Geräte einbinden kann?

Die Geräte werden nicht direkt von SmuView angesprochen sondern durch 
die sigrok Bibliothek. Dort musst du dann auch einen Treiber 
implementieren.

Wenn dein Netzteil SCPI (oder einen SCPI-ähnlichen Dialekt) spricht, 
dann musst du im vorhandenen "scpi-pps"-Treiber 
(https://github.com/sigrokproject/libsigrok/tree/master/src/hardware/scpi-pps) 
nur ein paar Definitionen hinzufügen.

Viele Grüße
Frank

[Alex E. (tecnologic)]

Hi Frank,

Das scpi Protokoll sieht gut aus das kann ich einbauen.

Danke

[Frank S. (knarfs)]

Hallo Gerd,

kommt der Pull Request ("add .spec-file to package smuview for Fedora") 
von dir?
Wenn ja, würde ich ein paar Dinge ändern (automatisches setzten der 
Version, des Git Hashes, ...), die du dann testen müsstest.

Grüße
Frank

[Gerd E. (robberknight)]

Ja, ist von mir.

Wenn Du Verbesserungsvorschläge hast - immer her damit.

Diskutieren wir am besten im Pull-Request auf github selbst, dort passt 
es denke ich am besten hin.

[Sebastian E. (s-engel)]

Hallo

das Projekt gefällt mir sehr gut.
Werde das mal antesten, wobei ich anscheinend bisher nur mein Multimeter 
(Voltcraft VC-820) einbinden kann.

Durch dein Projekt habe ich zudem überlegt eine Hardware-API für das 
Netzteil "ELV DPS 5315" zu schreiben. Ich wollte da eh was machen und 
sigrok bietet da denke ich eine ideale Plattform.
In wie weit lässt sich dann, sofern das mit der API klappt, das Netzteil 
in SmuView integrieren?

Vg
Sebastian

[Frank S. (knarfs)]

Hi Sebastian,

Sebastian E. schrieb:
> das Projekt gefällt mir sehr gut.

Danke :)

> Durch dein Projekt habe ich zudem überlegt eine Hardware-API für das
> Netzteil "ELV DPS 5315" zu schreiben. Ich wollte da eh was machen und
> sigrok bietet da denke ich eine ideale Plattform.
> In wie weit lässt sich dann, sofern das mit der API klappt, das Netzteil
> in SmuView integrieren?

Da ich mit SmuView nur die (generische) API von sigrok einbinde, sollte 
das ohne Probleme funktionieren. D.h. die Integration ist so gut wie der 
Treiber in sigrok.
Evtl. müssen noch GUI Elemente für fehlende Optionen eingebaut werden 
(bei dem DPS5315 z.B. Serienbetrieb der 2 Kanäle), aber das ist eine 
Kleinigkeit.

Allerdings muss in sigrok in den Treiber ein Mutex eingebaut werde, 
damit Messwerte über die API gesendet werden können und gleichzeitig 
Einstellungen geändert werden können (zwei Threads in SmuView).
Der Mutex ist von mir schon in den Treibern für die Korad KAxxxxP 
Netzteile und dem generischen Treiber "scpi-pps" (getestet mit einem HP 
6632B) eingebaut.

Wenn du Fragen zu den Treiber hast, kannst du dich einfach hier melden.

Viele Grüße
Frank

[Gerd E. (robberknight)]

So, nachdem es jetzt bei mir auf dem Rechner & mit meinen Multimetern 
funktioniert, hab ich heute mal ein wenig damit rumgespielt.

Es gefällt mir ziemlich gut und auch ohne Programmierung von 
angeschlossenen Geräten ist das schon sehr sinnvoll nutzbar.

Allerdings sind mir bei der Bedienung noch ein paar Dinge aufgefallen 
die mich stören:

- wie kann ich die gesamten Daten in einem Kanal (oder von mir aus auch 
allen) löschen? Ein Klick auf "Reset Data" bewirkt bei mir nur, daß die 
Wertanzeige kurz zurückgesetzt wird, die Daten in den Plots bleiben alle 
weiterhin vorhanden.

- wie kann ich ein "Gerät" in dem linken Baum wieder löschen?

- Kann man das Sampeln aller Geräte kurz anhalten und dann später an der 
selben Stelle fortsetzen? Ich hatte ein paar dicke Sprünge mit 
unsinnigen Werten drin als mein Multimeter den Messbereich wechselte und 
kurzzeitig unpassende Werte kamen. Die haben dann die ganze Skalierung 
des Plots versaut und ich musste das manuell wieder hindrehen.

- Kann man die gesamte Konfiguration mit Geräten, Math-Kanälen, Plots 
etc. irgendwie speichern und später wieder laden?

- Kann man mit den Math-Kanälen auch einen konstanten Offset zu einem 
Kanal hinzufügen? Z.B. ein bekannter Messfehler oder ähnliches. Ich habe 
nur feste Faktoren gefunden.

- Wenn man ein neues Gerät hinzufügt, wird beim Wechsel des Treibers 
wohl ein Lookup auf die passenden vorhandenen seriellen Ports gemacht. 
Wenn man den ersten Treiber in der Liste (bei mir agilent-dmm) verwenden 
möchte, wird dieser Lookup nicht direkt gemacht. Man muss erst einen 
anderen Treiber wählen, dann zurückwechseln, dann geht es.

- Schön wäre auch noch, wenn man einfache Filter über die Messwerte 
laufen lassen könnte, z.B. ein gleitender Durchschnitt über eine 
einstellbare Anzahl von Werten. Wenn es dafür eine Schnittstelle & GUI 
gibt, kann man sich da dann natürlich später noch weiter austoben und 
mehr Filterarten implementieren (z.B. scipy.signal)

Von mir getestete Version war b1ba16c1fe229339a2e36af497339474a5d9bc63 
von gestern.

Falls irgendwas an der Beschreibung unklar sein sollte, Du das lieber 
als Bugreports auf github haben möchtest oder ähnliches dann sag 
Bescheid.

[Frank S. (knarfs)]

Hi Gerd,

vielen Dank für die Rückmeldung.

Gerd E. schrieb:
> - wie kann ich die gesamten Daten in einem Kanal (oder von mir aus auch
> allen) löschen? Ein Klick auf "Reset Data" bewirkt bei mir nur, daß die
> Wertanzeige kurz zurückgesetzt wird, die Daten in den Plots bleiben alle
> weiterhin vorhanden.

"Reset Data" setzt nur die Min/Max-Werte der entsprechenden LCD-Ansicht 
zurück.
Das Löschen eines Kanals wird über den linken Baum per Kontext Menü 
implementiert werden (siehe nächster Punkt), ich bin mir aber nicht 
sicher, wie nützlich diese Funktion ist.
Kannst du evtl. erläutern, wann/für was du die Daten eines Kanals 
löschen würdest?

> - wie kann ich ein "Gerät" in dem linken Baum wieder löschen?

Ich bin gerade dabei die Baumansicht zu überarbeiten und das wird eine 
der Funktionen sein, die über den Baum zu erreichen ist.

> - Kann man das Sampeln aller Geräte kurz anhalten und dann später an der
> selben Stelle fortsetzen? Ich hatte ein paar dicke Sprünge mit
> unsinnigen Werten drin als mein Multimeter den Messbereich wechselte und
> kurzzeitig unpassende Werte kamen. Die haben dann die ganze Skalierung
> des Plots versaut und ich musste das manuell wieder hindrehen.

Eins meiner Multimeter (das Metex M-3860M) hat das selbe Problem und 
meine Überlegung war, das man nachträglich (z.B. über die 
Tabellenansicht) einzelne Messwerte löschen kann. Allerdings müssen die 
Math Channels das dann auch berücksichtigen.

Wenn aber z.B. Messungen automatisiert gemacht werden (libsigrokflow, 
s.u.), dann können solche Sprünge recht simpel behandelt werden: Bevor 
ein Wert gelesen und in ein "Signal" gespeichert wird, wird einfach kurz 
gewartet.

> - Kann man die gesamte Konfiguration mit Geräten, Math-Kanälen, Plots
> etc. irgendwie speichern und später wieder laden?

Nein, aktuell geht das noch nicht.
Leider bietet sigrok noch kein Format an, welches das alles unterstützt. 
Es gibt zwar einen Entwurf für ein neues Format 
(https://sigrok.org/wiki/File_format:Sigrok/v3), aber das ist noch nicht 
implementiert.
Wahrscheinlich werde ich deshalb erst einmal mit Qt-Klassen arbeiten und 
Geräte + UI-Konfiguration speichern und evlt. später das neue Format in 
libsigrok implementieren.

Ich bin mir aber noch nicht 100%ig sicher, welchen Weg ich hier gehen 
werde.

> - Kann man mit den Math-Kanälen auch einen konstanten Offset zu einem
> Kanal hinzufügen? Z.B. ein bekannter Messfehler oder ähnliches. Ich habe
> nur feste Faktoren gefunden.

Das werde ich implementieren, ist relativ einfach und unproblematisch.

> - Wenn man ein neues Gerät hinzufügt, wird beim Wechsel des Treibers
> wohl ein Lookup auf die passenden vorhandenen seriellen Ports gemacht.
> Wenn man den ersten Treiber in der Liste (bei mir agilent-dmm) verwenden
> möchte, wird dieser Lookup nicht direkt gemacht. Man muss erst einen
> anderen Treiber wählen, dann zurückwechseln, dann geht es.

Das ist mir noch nicht aufgefallen, wahrscheinlich weil ich kein Agilent 
DMM habe und immer einen Treiber auswählen muss :)
Schau ich mir an!

> - Schön wäre auch noch, wenn man einfache Filter über die Messwerte
> laufen lassen könnte, z.B. ein gleitender Durchschnitt über eine
> einstellbare Anzahl von Werten. Wenn es dafür eine Schnittstelle & GUI
> gibt, kann man sich da dann natürlich später noch weiter austoben und
> mehr Filterarten implementieren (z.B. scipy.signal)

Einen Moving Average habe ich auch schon vermisst und werde ich recht 
bald als Math Channel einbauen, aber in Zukunft soll das dann über 
libsigrokflow gelöst werden.

Das sigrok-Team arbeitet gerade an libsigrokflow, welches auf gstreamer 
basiert. Damit kannst du dann z.B. für Logicanalyzer mehrere Decoder 
hintereinander hängen, oder aber analoge Signale in einer Pipeline 
manipulieren.
Das würde dann die Math Channels ersetzten und es sehr einfach machen, 
weitere Filter zu implementieren.
Auch die Automatisierung/Programmierbarkeit würde dann darauf basieren 
(libsigrokflow + NodeEditor). Die einzelnen Elemente/Nodes der Pipeline 
würden dann über Trigger/Signale gesteuert.

Da ist aber noch nicht klar, wie das letztendlich aussehen wird. Ich 
werde erst mal den jetzigen Stand stabilisieren, noch ein paar Features 
einbauen (s.o.), Bugs fixen und das Handbuch/Doku fertig machen. Dann 
werde ich mit libsigrokflow experimentieren, mich an dessen Entwicklung 
beteiligen und in SmuView integrieren.

PS: Das Spec-File konnte ich heute testen und hat gut funktioniert. 
Werde ich die nächsten Tage übernehmen.

Viele Grüße
Frank

[Gerd E. (robberknight)]

Hallo Frank,

Frank S. schrieb:
> Das Löschen eines Kanals wird über den linken Baum per Kontext Menü
> implementiert werden (siehe nächster Punkt), ich bin mir aber nicht
> sicher, wie nützlich diese Funktion ist.
> Kannst du evtl. erläutern, wann/für was du die Daten eines Kanals
> löschen würdest?

Sagen wir ich baue mein Experiment auf, schließe die Multimeter an, 
bereite alles vor etc. Dann laufen am Anfang schon Messwerte auf, die 
sind aber unbrauchbar, sondern sind noch vom Aufbau.

Da würde ich einmal alles löschen wollen und dann mit dem eigentlichen 
Experiment loslegen.

Oder ich habe einen Aufbau vermessen, speichere die Messwerte ab und 
verändere mein Device under Test. Jetzt würde ich die Daten im Smuview 
löschen wollen, den Test erneut laufen lassen und jetzt die Ergebnisse 
vergleichen.

Richtig schön wäre natürlich, wenn man früher gespeicherte Messwerte 
wieder als Referenzwerte ins Smuview laden könnte. Die sollten dann z.B. 
mit anderer Farbe und frei beschriftbarer Legende wieder in die Plots 
eingefügt werden. So wie das viele Oszis und Spekkis auch bieten.

Auch hier wäre die von mir gewünschte "Messung anhalten"/"Messung 
fortsetzen"-Funktion hilfreich: Man kann dann deutlich leichter zu einem 
definierten Zeitpunkt die Messung beginnen und bekommt so auch bei den 
Zeit-Plots vergleichbare Werte zwischen den Messungen.

>> - wie kann ich ein "Gerät" in dem linken Baum wieder löschen?
>
> Ich bin gerade dabei die Baumansicht zu überarbeiten und das wird eine
> der Funktionen sein, die über den Baum zu erreichen ist.

sehr gut.

>> - Kann man das Sampeln aller Geräte kurz anhalten und dann später an der
>> selben Stelle fortsetzen?
>
> Eins meiner Multimeter (das Metex M-3860M) hat das selbe Problem und
> meine Überlegung war, das man nachträglich (z.B. über die
> Tabellenansicht) einzelne Messwerte löschen kann. Allerdings müssen die
> Math Channels das dann auch berücksichtigen.

Das hinterher Löschen ist praktischer für die Fälle, bei denen man nicht 
vorher weiß daß es zu dem Fehler kommen wird. Wenn man aber vorher weiß 
daß es zu dem Fehler kommen wird (z.B. weil man den Wert kennt zu dem 
Umgeschaltet wird oder weil man weiß, daß sich das System mit den neuen 
Werten erst einschwingen muss oder so), dann ist vermutlich das Anhalten 
mit einem Klick schneller zu machen.

Ich finde daher beide Varianten sinnvoll.

>> - Kann man die gesamte Konfiguration mit Geräten, Math-Kanälen, Plots
>> etc. irgendwie speichern und später wieder laden?
>
> Nein, aktuell geht das noch nicht.
> Leider bietet sigrok noch kein Format an, welches das alles unterstützt.
> Es gibt zwar einen Entwurf für ein neues Format
> (https://sigrok.org/wiki/File_format:Sigrok/v3), aber das ist noch nicht
> implementiert.
> Wahrscheinlich werde ich deshalb erst einmal mit Qt-Klassen arbeiten und
> Geräte + UI-Konfiguration speichern und evlt. später das neue Format in
> libsigrok implementieren.

Aus dem Bauch raus würde ich sagen, daß das eher etwas für Smuview als 
für libsigrok ist. Denn Du hast da ja nicht nur libsigrok-Objekte, 
sondern auch Math-Channel, GUI-Elemente wie Plots und Fenster, 
Skalierungen der Plots,... - alles Dinge, die es in der libsigrok gar 
nicht gibt.

>> - Kann man mit den Math-Kanälen auch einen konstanten Offset zu einem
>> Kanal hinzufügen? Z.B. ein bekannter Messfehler oder ähnliches. Ich habe
>> nur feste Faktoren gefunden.
>
> Das werde ich implementieren, ist relativ einfach und unproblematisch.

Danke

> Das sigrok-Team arbeitet gerade an libsigrokflow, welches auf gstreamer
> basiert. Damit kannst du dann z.B. für Logicanalyzer mehrere Decoder
> hintereinander hängen, oder aber analoge Signale in einer Pipeline
> manipulieren.
> Das würde dann die Math Channels ersetzten und es sehr einfach machen,
> weitere Filter zu implementieren.
> Auch die Automatisierung/Programmierbarkeit würde dann darauf basieren
> (libsigrokflow + NodeEditor). Die einzelnen Elemente/Nodes der Pipeline
> würden dann über Trigger/Signale gesteuert.

Das klingt ja vielversprechend.

Um bisherige Kanäle zu verknüpfen, Math-Channel und Filter etc. 
hinzuzufügen klingt das plausibel.

Was mir aber noch nicht ganz klar ist, wie damit dann die Programmierung 
der Messungen ablaufen sollen.

Sagen wir ich hab eine typische SMU-Schleife:

for (i=0V; i<10V; i+=0.25V)
{
   set_output(i);
   sleep(2s);
   result[i]=measure_amp();
   if (measure_temp() > 30°)
       break;
}

Ist sowas nicht mit graphischen Blöcken, Signalen etc. viel 
komplizierter und unübersichtlicher als das kurz in einer Skriptsprache 
als Code hinzuschreiben? Vor allem wenn die Skriptsprache, wie z.B. bei 
Python, schon riesige Mathe-Bibliotheken mitbringt und man die bei 
Bedarf direkt verwenden kann.

Was auch noch dazukommt, ist daß ich kurze Codeblöcke viel leichter 
dokumentieren, archivieren, publizieren, vergleichen kann als so ein 
grafisches Knotengeflecht, wenn es über vielleicht 10 Elemente oder so 
hinausgeht.

> PS: Das Spec-File konnte ich heute testen und hat gut funktioniert.
> Werde ich die nächsten Tage übernehmen.

Danke.

[Frank S. (knarfs)]

Hallo zusammen,

ich habe heute Version 0.0.2 von SmuView veröffentlicht:

https://github.com/knarfS/smuview/releases

Einige der Anregungen von Gerd sind schon in die neue Version 
eingeflossen, weitere werden in den nächsten Wochen integriert.
Ein kurzes Changelog ist hier zu finden:

https://github.com/knarfS/smuview/blob/master/NEWS

Die letzten Wochen habe ich mit pybind11 experimentiert und damit ist es 
sehr einfach, Pythonscripte interaktiv in SmuView auszuführen.
Das bedeutet, dass in absehbarer Zeit SmuView über ein Pythonscript 
steuerbar sein wird und dann das "Smu" im Namen wirklich verdient :)

Viele Grüße
Frank

[Frank S. (knarfs)]

Hallo,

gestern habe ich Version 0.0.3 veröffentlicht:

https://github.com/knarfS/smuview/releases

Der Segfault mit den Korad Netzteilen ist gefixt und ich habe die LCD 
Displays durch Monospace Schriften ersetzt.

Wenn jemand Vorschläge hat, wie der vorhandene Platz besser genutzt 
werden kann oder sonstige Ideen für die Oberfläche hat, wäre ich echt 
froh!

Viele Grüße
Frank

[Nico W. (nico_w)]

Hallo Frank,

der neue Font gefällt mir ganz gut.

Sobald ich ein neues Panel erzeuge und mit das rausziehe, zerreißt es 
ein wenig das Layout. Ich habe hier das Korad.

Panels habe ich alle vorher rausgezogen, so wie im github-issue 
beschrieben, damit das bei meinem kleinen Laptop alles sichtbar ist. Nun 
bin ich im PowerPanel und möchte 2 weitere Panels testweise hinzufügen. 
(z.B. nochmal VDC und ADC). Diese beiden werden rechts im PowerPanel 
hinzugefügt und sind nicht ganz sichtbar. Ich ziehe jetzt ein Fenster 
raus (VDC). In dem Moment geht SmuView aus dem Maximierten Fenstermodus 
raus und verändert seine Breite.

Zudem habe ich gerade gesehen, dass der Status On/Off vom Netzteil nicht 
ordentlich synchronisiert wird. Habe die Debugausgabe auf 4 gestellt.

Manchmal wenn ich das Netzteil an oder ausschalten möchte, wird der 
Befehl einfach nicht gesendet. Im GUI wird dann zwar ON oder OFF 
angezeigt, aber das Netzteil bleibe aus bzw. an.

[Nico W. (nico_w)]

Hier einmal das Log mit angehängt. Habe es jetzt mit -l 5 gestartet.

Ich habe bei diesem mal mehrere Male (>5) das Korad an und aus mit der 
GUI geschaltet. Manchmal ging es nicht mehr aus, manchmal nicht mehr an.

Man erkennt das ganz gut. Normal sollte er zwischen OUT0 und OUT1 
toggeln.

...
sr: [00:27.263615] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:28.869661] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:30.235060] korad-kaxxxxp: Sending 'OUT0'.
sr: [00:32.643961] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:34.089240] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:35.614844] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:36.899764] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:38.024216] korad-kaxxxxp: Sending 'OUT1'.
sr: [00:39.148393] korad-kaxxxxp: Sending 'OUT0'.

[Frank S. (knarfs)]

Nico W. schrieb:
> Sobald ich ein neues Panel erzeuge und mit das rausziehe, zerreißt es
> ein wenig das Layout. Ich habe hier das Korad.

könntest bitte du einen Screenshot von dem fehlerhaften Layout hier 
anhängen:
https://github.com/knarfS/smuview/issues/8

Meine aktuelle Idee um das Problem mit kleinen Auflösungen zu beheben 
ist, dass im Standard weniger/kleinere Views angezeigt werden (bei 
Netzteilen/Lasten bspw. kein Powerpanel).
Der User kann sich dann die Views so einrichten wie er möchte und das 
wird (automatisch) in einer Sessiondatei gespeichert und beim Starten, 
bzw. verbinden des Gerätes (automatisch/manuell) geladen.
Allerdings muss ich das Speichern/Laden in eine Session noch 
implementieren.

> Panels habe ich alle vorher rausgezogen, so wie im github-issue
> beschrieben, damit das bei meinem kleinen Laptop alles sichtbar ist. Nun
> bin ich im PowerPanel und möchte 2 weitere Panels testweise hinzufügen.
> (z.B. nochmal VDC und ADC). Diese beiden werden rechts im PowerPanel
> hinzugefügt und sind nicht ganz sichtbar. Ich ziehe jetzt ein Fenster
> raus (VDC). In dem Moment geht SmuView aus dem Maximierten Fenstermodus
> raus und verändert seine Breite.

Dieses Verhalten habe ich auch schon festgestellt, muss ich bei 
Gelegenheit genauer untersuchen.

> Zudem habe ich gerade gesehen, dass der Status On/Off vom Netzteil nicht
> ordentlich synchronisiert wird. Habe die Debugausgabe auf 4 gestellt.
>
> Manchmal wenn ich das Netzteil an oder ausschalten möchte, wird der
> Befehl einfach nicht gesendet. Im GUI wird dann zwar ON oder OFF
> angezeigt, aber das Netzteil bleibe aus bzw. an.

Der Fehler ist bekannt 
(https://github.com/knarfS/smuview/issues/7#issuecomment-478157260) und 
ich habe auch schon einen Patch dafür 
(https://github.com/knarfS/libsigrok/commits/patches2).
Es gibt aber noch weitere Probleme mit dem Korad Treiber (siehe Issue 
#7). Sobald die gelöst sind, mache ich einen Pull Request an das 
sigrok-Team.

Wäre toll wenn du die Änderungen testen würdest, sobald ich die 
restlichen Probleme behoben habe.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Du könntest ja nochn Modus einbauen um mit einem NT und einer Last DC/DC 
Wandler zu testen.

Das hab ich letztens in Python zusammengehackt und das spricht jetzt ein 
DPS5005 und meine Eigenbau E-last über Modbus an.
Konfigurierbar ist das über yaml (Welche Diagramme und was da reinkommt, 
sowie welche Messpunkte aufgenommen werden).

edit, fast vergessen.
Eine Anmerkung zur GUI:
Drehregler sind mit der Maus nun etwas schlecht zu bedienen, wärs 
möglich da Schieberegler einzubauen?

Links in der Kategorieleiste:
Pro Unterpunkt ist nur ein Element, das verbraucht unnötig viel Platz.
Wenns nur ein Subelement gibt, dann die Gruppe nicht anzeigen.

Ansonsten noch etwas zu grau, Bolt/Amp/Watt/Leistung sollten einen 
leichten Farbanstrich bekommen mit man auf einem BLck sieht was das ist.

[Nico W. (nico_w)]

Frank S. schrieb:
> Wäre toll wenn du die Änderungen testen würdest, sobald ich die
> restlichen Probleme behoben habe.

So, bin eben mal dazu gekommen deine libsigrok/patches2 zu testen. Habe 
jetzt keine Probleme mehr mit dem Einstellen. Output funktioniert jedes 
mal, auch OCP/OVP.

Auch die Einstellungen in smuview, bestätigen mit Enter, scheint 
zuverlässig zu laufen. Zumindest mein erstes wildes Rumgeklicke macht 
das was es soll :)

Frank S. schrieb:
> könntest bitte du einen Screenshot von dem fehlerhaften Layout hier
> anhängen

Frank S. schrieb:
>> In dem Moment geht SmuView aus dem Maximierten Fenstermodus
>> raus und verändert seine Breite.
>
> Dieses Verhalten habe ich auch schon festgestellt, muss ich bei
> Gelegenheit genauer untersuchen.

Zerrissen ist ein bisschen viel. Aber du hast das Problem ja schon 
gesehen. Hänge aber gleich noch ein paar Bilder ran.

Kann es sein, dass bei der Widerstandsanzeige eine andere Schriftart 
verwendet wird? Die Null sieht da anders aus.  Siehe Screenshot.

[Gerd E. (robberknight)]

Nico W. schrieb:
> Kann es sein, dass bei der Widerstandsanzeige eine andere Schriftart
> verwendet wird? Die Null sieht da anders aus.  Siehe Screenshot.

Das sieht mir nicht nach einer Null aus, sondern nach einem O, für Over 
Limit.

[Frank S. (knarfs)]

Mw E. schrieb:
> Du könntest ja nochn Modus einbauen um mit einem NT und einer Last DC/DC
> Wandler zu testen.

Das ist gerade in Arbeit (integrierter Pythoninterpreter und Bindings 
mit pybind11).
Es fehlen noch Funktionen (z.B. um die Oberfläche zu manipulieren) und 
noch ein paar andere Dinge, aber die Entwicklung ist schon recht weit 
und ich hoffe, dass ich das in ein paar Wochen ins Release mit aufnehmen 
kann.

> Eine Anmerkung zur GUI:
> Drehregler sind mit der Maus nun etwas schlecht zu bedienen, wärs
> möglich da Schieberegler einzubauen?

Da bist du nicht der Erste, der das vorschlägt ;) Diese Änderung kommt 
in den nächsten Tagen.
Schieberegler haben den weiteren Vorteil, dass sie nicht so viel Platz 
wegnehmen und auf kleinen Monitoren der Platz besser genutzt wird.

> Links in der Kategorieleiste:
> Pro Unterpunkt ist nur ein Element, das verbraucht unnötig viel Platz.
> Wenns nur ein Subelement gibt, dann die Gruppe nicht anzeigen.

Je nachdem was du für Geräte anschliesst, kann der Baum ganz anders 
aussehen.
Die einzelnen Elemente im Baum haben Funktionen und die werden in 
Zukunft über den Toolbar (evtl. auch Maus-Kontextmenü) erreichbar sein. 
Deshalb werde ich Elemente nicht ausblenden können.

> Ansonsten noch etwas zu grau, Bolt/Amp/Watt/Leistung sollten einen
> leichten Farbanstrich bekommen mit man auf einem BLck sieht was das ist.

Das werde ich in Zukunft einstellbar machen, da hier die Meinungen 
sicherlich weit auseinander gehen werden ;)

[Frank S. (knarfs)]

Mw E. schrieb:
> [...]
> Das hab ich letztens in Python zusammengehackt und das spricht jetzt ein
> DPS5005 und meine Eigenbau E-last über Modbus an.

Ganz vergessen:
Das DPS5005 hat aktuell noch Fehler in sigrok / SmuView, aber evtl. gibt 
es dafür bald eine Lösung.

[Frank S. (knarfs)]

Nico W. schrieb:
> Frank S. schrieb:
>> Wäre toll wenn du die Änderungen testen würdest, sobald ich die
>> restlichen Probleme behoben habe.
>
> So, bin eben mal dazu gekommen deine libsigrok/patches2 zu testen. Habe
> jetzt keine Probleme mehr mit dem Einstellen. Output funktioniert jedes
> mal, auch OCP/OVP.
>
> Auch die Einstellungen in smuview, bestätigen mit Enter, scheint
> zuverlässig zu laufen. Zumindest mein erstes wildes Rumgeklicke macht
> das was es soll :)

Super!
Habe heute nochmal ein Test-Release in dem Issue-Thread verlinkt, 
welcher hoffentlich die letzten Probleme mit dem Korad löst. Wenn alles 
gut geht, werde ich eine Pullrequest ans sigrok-Team machen.

> Kann es sein, dass bei der Widerstandsanzeige eine andere Schriftart
> verwendet wird? Die Null sieht da anders aus.  Siehe Screenshot.

Wie Gerd schon gesagt hat, ist das ein O, für "Over Limit". Das stammt 
noch von der LCD-Anzeige, bei der die darstellbaren Buchstaben begrenzt 
waren.
Da ich es noch nicht übers Herz gebracht habe, den LCD-Code komplett zu 
entfernen (Nostalgie :) ) und sich beide Anzeigen Code teilen, werde ich 
das "OL" in etwas lesbares ändern, sobald ich den LCD-Code raus 
geschmissen habe...

[Nico W. (nico_w)]

Overlimit... Ich hab 0L gelesen wie Null Long XD

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Frank S. schrieb:
> Ganz vergessen:
> Das DPS5005 hat aktuell noch Fehler in sigrok / SmuView, aber evtl. gibt
> es dafür bald eine Lösung.

Welche denn?
Ich habs eben per pymodbus direkt angesprochen mit seinen Registern.
Das lief bestens.
Nur ist die CPU auf dem Teil wohl auf Anschlag so manche Modbus Antwort 
braucht sichtlich Bedenkzeit wenn ich auf die RX/TX LEDs meines RS485 
Wandlers gucke.
Meine selbstbau Modbusgeräte antworten da deutlich schneller.

Frank S. schrieb:
> Mw E. schrieb:
>> Du könntest ja nochn Modus einbauen um mit einem NT und einer Last DC/DC
>> Wandler zu testen.
>
> Das ist gerade in Arbeit (integrierter Pythoninterpreter und Bindings
> mit pybind11).
> Es fehlen noch Funktionen (z.B. um die Oberfläche zu manipulieren) und
> noch ein paar andere Dinge, aber die Entwicklung ist schon recht weit
> und ich hoffe, dass ich das in ein paar Wochen ins Release mit aufnehmen
> kann.

Na ich red davon, dass deine SW das DCDC testen nativ kann und man nicht 
erst in Python rumhacken muss ;)
(oder man klickt sich das über deine Blöcke da)

Frank S. schrieb:
> Da bist du nicht der Erste, der das vorschlägt ;) Diese Änderung kommt
> in den nächsten Tagen.
> Schieberegler haben den weiteren Vorteil, dass sie nicht so viel Platz
> wegnehmen und auf kleinen Monitoren der Platz besser genutzt wird.

Dann ist alles gut.

Der Rest ist Geschmackssache, ich persönlich mag dieses neue Flat alles 
in grau Design nicht wirklich, aber quietschbunt auch nicht ;)

[Frank S. (knarfs)]

Mw E. schrieb:
> Frank S. schrieb:
>> Ganz vergessen:
>> Das DPS5005 hat aktuell noch Fehler in sigrok / SmuView, aber evtl. gibt
>> es dafür bald eine Lösung.
>
> Welche denn?
> Ich habs eben per pymodbus direkt angesprochen mit seinen Registern.
> Das lief bestens.
> Nur ist die CPU auf dem Teil wohl auf Anschlag so manche Modbus Antwort
> braucht sichtlich Bedenkzeit wenn ich auf die RX/TX LEDs meines RS485
> Wandlers gucke.

Im Modbus-Teil von libsigrok ist ein Timeout zu niedrig. Das DPS5005 
benötigt Timeouts von >1000ms. Siehe hier: 
https://github.com/knarfS/smuview/issues/9
Das deckt sich mit also deinen Erfahrungen.

> Na ich red davon, dass deine SW das DCDC testen nativ kann und man nicht
> erst in Python rumhacken muss ;)
> (oder man klickt sich das über deine Blöcke da)

Das wird für mich leider nicht mit vertretbaren Aufwand umsetzbar sein, 
da sigrok so viele verschiedene Geräte unterstützt und jedes einen 
anderen Funktionsumfang und andere Eigenheiten hat.
Ich müsste letztendlich für jedes Gerät Sonderregeln einbauen, damit 
eine generisch konfigurierbare Messung überhaupt funktioniert.

Die Steuerung über Funktionsblöcke werde ich weiter verfolgen, aber das 
wird noch ein Weilchen dauern. Dafür muss erst noch Einigens entwickelt 
werden.

Mit pybind11 war der embedded Pythoninterpreter wirklich sehr einfach 
und schnell integriert und auch die Scripte zum Steuern sind klein und 
simpel. Das war jetzt erst mal der schnellste, einfachste und 
flexibelste Weg.

[bianchifan (Gast)]

Irgendwann im März bin ich auf der Sigrokseite über smuview gestolpert, 
als ich mich über evtl. Unterstützung der RDTechModule bzw. alternativen 
OpenDPS Firmware erkundigen wollte.
Die seinerzeit heruntergeladene Version ließ sich einwandfrei 
übersetzen.
Ich bestellte seinerzeit noch zwei weitere Module, das DPH5005 mit "Comm 
Port".
Dieses Modul habe ich letztes WE in Betrieb genommen, es wurde von 
SMUView nicht erkannt.
Ich habe daraufhin die aktuelle Version von GIT geladen, sie ließ sich 
nicht übersetzen. Daraufhin saugte ich mir zusätzlich von die letzte 
Releaseversion (0.0.3), auch diese ließ sich nicht compilieren.
Der Feheler war der gleiche: OFFSET is not a member of ..ConfigKey 
zuzügl. eines samplerate convert errors.

Nur die 0.0.2 lässt sich bei mir compilieren -> Ubuntu 19.04 x64

In dem INSTALL "Readme" fehlt der Hinweis auf "make manual".

[Nico W. (nico_w)]

Ich hab hier gerade nochmal git aktuallisiert bei mir. Habe jetzt keine 
Probleme beim übersetzen.

Ubuntu Mate 18.04

➜  build git:(master) cc --version | head -n1
cc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
➜  build git:(master) cmake ../
-- Found Qwt: /usr/lib/libqwt-qt5.so (6.1.3)
-- Boost version: 1.65.1
-- SmuView version: 0.0.3-git-b6183c9
-- Configuring done
-- Generating done
-- Build files have been written to: /home/nico/Documents/projects/smuview/build

[Frank S. (knarfs)]

bianchifan schrieb:
> Ich habe daraufhin die aktuelle Version von GIT geladen, sie ließ sich
> nicht übersetzen. Daraufhin saugte ich mir zusätzlich von die letzte
> Releaseversion (0.0.3), auch diese ließ sich nicht compilieren.
> Der Feheler war der gleiche: OFFSET is not a member of ..ConfigKey

Du benötigst die aktuelle Entwicklerversion von libsigrok (siehe 
https://sigrok.org/wiki/Linux#Building_.28manually.29), um ein aktuelles 
SmuView zu bauen.

Der Treiber in libsigrok für die RDTech Netzteile (original Firmware) 
hat aktuell noch Fehler (siehe 
https://github.com/knarfS/smuview/issues/9). Vllt. nimmst du zum Testen 
besser meinen libsigrok Branch "patches2": 
https://github.com/knarfS/libsigrok/tree/patches2
Ich denke, das meine Patches in den nächsten 1-2 Wochen soweit sind, 
dass ich einen Pull Request machen kann.
Ich werde dann zusätzlich auch ein neues Release (0.0.4) raus bringen.

> zuzügl. eines samplerate convert errors.

Der Fehler würde mich jetzt genauer interessieren! Kannst du evtl. die 
genaue Ausgabe posten?

> In dem INSTALL "Readme" fehlt der Hinweis auf "make manual".

Danke, das werde ich ergänzen. Im Manual gibt es aber noch nicht so viel 
zum lesen :)

[bianchifan (Gast)]

Frank S. schrieb:

> Du benötigst die aktuelle Entwicklerversion von libsigrok (siehe
> https://sigrok.org/wiki/Linux#Building_.28manually.29), um ein aktuelles
> SmuView zu bauen.
Danke für den Link!
Ich hatte am WE für mein aufgerüstetes DSLogic Basic zwar die aktuellste 
libsigrok gebaut, nicht jedoch die im Link erwähnte libserialport.
Ich hatte mich an dem INSTALL-Text von Pulseview orientiert.

> Der Treiber in libsigrok für die RDTech Netzteile (original Firmware)
> hat aktuell noch Fehler (siehe
> https://github.com/knarfS/smuview/issues/9). Vllt. nimmst du zum Testen
> besser meinen libsigrok Branch "patches2":
> https://github.com/knarfS/libsigrok/tree/patches2
Kurz nach dem Schreiben meines Beitrags hatte ich den erwähnten issue 
entdeckt und Deine Version ausprobiert..
Es hat damit gefunzt!!
Allerdings wurde das Gerät nicht automatisch gefunden, auch ein 
Anschluss nach Programmstart wurde nicht erkannt.
Ich musste das Netzteil zunächst anschließen, einschalten, smuview 
starten,  neues Gerät auswählen und mit selektiertem RD-Treiber 
USB-serial scannen.

Außerdem wurden sämtliche Werte offensichtlich auf "Null" gesetzt.
Das hatte zur Folge, dass sich zwar die gewünschten Werte einstellen 
ließen und auch auch am PSU angezeigt wurden, der Ausgang allerdingt 
nicht freigeschaltet werden konnte.
In smuview wechselte die virtuelle LED zwar auf grün, am PSU blieb sie 
jedoch auf rot.
Auch abgeklemmt im Standalone-Betrieb ließ sich die Ausgangsspannung 
nicht mehr aktievieren, die LED flackterte nur kurzzeitig grün, weniger 
als 0,1 sec.
Die Lösung fand ich erst gestern abend: Die Werte für 
Overvoltageprotection(OVP), Overcurrentprotection(OCP) sowie 
Overpowerprotection (OPP) waren genullt!
Es wäre IMHO sicherlich sinnvoll, sie auf ihren Defaultwerten zu 
belassen.

>> zuzügl. eines samplerate convert errors.
>
> Der Fehler würde mich jetzt genauer interessieren! Kannst du evtl. die
> genaue Ausgabe posten?
Da muss ich heute abend erst wieder eine Compilierung starten...

[bianchifan (Gast)]

Nico W. schrieb:
> Ich hab hier gerade nochmal git aktuallisiert bei mir. Habe jetzt
> keine
> Probleme beim übersetzen.
>
> Ubuntu Mate 18.04
> ➜  build git:(master) cc --version | head -n1

Wie oben geschrieben, benutze ich Ubuntu 19.04
build git habe ich noch nie benutzt, entweder git clone oder meistens, 
wie in diesem Fall, download zip.
Dann in ~/tmp entpacken und peu a peu dadurch wurschteln...

[Nico W. (Gast)]

Sorry für die Verwirrung. Build git Ist nur meine Console mit Ordner. 
Kein Befehl.

[bianchifan (Gast)]

Sodele...Also..des Rätsels Lösung ist und war die -patches2!
Damit tritt der o.a. Compilierfehler nicht auf!
Ich habe die master vom 05.05 dann auch gleich mal getestet..
OVP und OCP sind unverändert geblieben und die AQusgangssspannung 
konnte mittels smuview an- und abgeschaltet werden..
Die Potis wurden durch Schieber ersetzt, welche bei mir allerdings noch 
träger reagieren als die bereits unerträglich langsamen Potis zuvor.

--------------

Der Vollständigkeit halber habe ich dann noch die patches2 deinstalliert 
(make uninstall) und die libsigrok mit Stand 05.05.2019 erneut 
installiert.
Und schwupps war der Fehler wieder da, sowohl mit der master vom 05.05 
als auch mit vERSION 0.0.3...

...
Scanning dependencies of target smuview
[  2%] Building CXX object CMakeFiles/smuview.dir/main.cpp.o
[  3%] Building CXX object 
CMakeFiles/smuview.dir/src/devicemanager.cpp.o
In file included from 
/home/majo/tmp/smuview-master/src/devices/basedevice.hpp:34,
                 from 
/home/majo/tmp/smuview-master/src/devicemanager.cpp:38:
/home/majo/tmp/smuview-master/src/devices/deviceutil.hpp:492:23: error: 
‘OFFSET’ is not a member of ‘sigrok::ConfigKey’
  { sigrok::ConfigKey::OFFSET, ConfigKey::Offset },
                       ^~~~~~
/home/majo/tmp/smuview-master/src/devices/deviceutil.hpp:510:1: error: 
could not convert ‘{{sigrok::ConfigKey::SAMPLERATE, Samplerate}, 
{sigrok::ConfigKey::CAPTURE_RATIO, CaptureRatio}, 
{sigrok::ConfigKey::PATTERN_MODE, PatternMode}, {sigrok::ConfigKey::RLE, 
RLE}, {sigrok::ConfigKey::TRIGGER_SLOPE, TriggerSlope}, 
{sigrok::ConfigKey::AVERAGING, Averaging}, 
{sigrok::ConfigKey::AVG_SAMPLES, AvgSamples}, 
{sigrok::ConfigKey::TRIGGER_SOURCE, TriggerSource}, 
{sigrok::ConfigKey::HORIZ_TRIGGERPOS, HorizTriggerPos}, 
{sigrok::ConfigKey::BUFFERSIZE, BufferSize}, 
{sigrok::ConfigKey::TIMEBASE, TimeBase}, {sigrok::ConfigKey::FILTER, 
Filter}, {sigrok::ConfigKey::VDIV, VDiv}, {sigrok::ConfigKey::COUPLING, 
Coupling}, {sigrok::ConfigKey::TRIGGER_MATCH, TriggerMatch}, 
{sigrok::ConfigKey::SAMPLE_INTERVAL, SampleInterval}, 
{sigrok::ConfigKey::NUM_HDIV, NumHDiv}, {sigrok::ConfigKey::NUM_VDIV, 
NumVDiv}, {sigrok::ConfigKey::SPL_WEIGHT_FREQ, SplWeightFreq}, 
{sigrok::ConfigKey::SPL_WEIGHT_TIME, SplWeightTime}, 
{sigrok::ConfigKey::SPL_MEASUREMENT_RANGE, SplMeasurementRange}, 
{sigrok::ConfigKey::HOLD_MAX, HoldMax}, {sigrok::ConfigKey::HOLD_MIN, 
HoldMin}, {sigrok::ConfigKey::VOLTAGE_THRESHOLD, VoltageThreshold}, 
{sigrok::ConfigKey::EXTERNAL_CLOCK, ExternalClock}, 
{sigrok::ConfigKey::SWAP, Swap}, {sigrok::ConfigKey::CENTER_FREQUENCY, 
CenterFrequency}, {sigrok::ConfigKey::NUM_LOGIC_CHANNELS, 
NumLogicChannels}, {sigrok::ConfigKey::NUM_ANALOG_CHANNELS, 
NumAnalogChannels}, {sigrok::ConfigKey::VOLTAGE, Voltage}, 
{sigrok::ConfigKey::VOLTAGE_TARGET, VoltageTarget}, 
{sigrok::ConfigKey::CURRENT, Current}, 
{sigrok::ConfigKey::CURRENT_LIMIT, CurrentLimit}, 
{sigrok::ConfigKey::ENABLED, Enabled}, 
{sigrok::ConfigKey::CHANNEL_CONFIG, ChannelConfig}, 
{sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_ENABLED, 
OverVoltageProtectionEnabled}, 
{sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_ACTIVE, 
OverVoltageProtectionActive}, 
{sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_THRESHOLD, 
OverVoltageProtectionThreshold}, 
{sigrok::ConfigKey::OVER_CURRENT_PROTECTION_ENABLED, 
OverCurrentProtectionEnabled}, 
{sigrok::ConfigKey::OVER_CURRENT_PROTECTION_ACTIVE, 
OverCurrentProtectionActive}, 
{sigrok::ConfigKey::OVER_CURRENT_PROTECTION_THRESHOLD, 
OverCurrentProtectionThreshold}, 
{sigrok::ConfigKey::OVER_TEMPERATURE_PROTECTION, 
OverTemperatureProtectionEnabled}, 
{sigrok::ConfigKey::OVER_TEMPERATURE_PROTECTION_ACTIVE, 
OverTemperatureProtectionActive}, 
{sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION, 
UnderVoltageConditionEnabled}, 
{sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION_ACTIVE, 
UnderVoltageConditionActive}, 
{sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION_THRESHOLD, 
UnderVoltageConditionThreshold}, {sigrok::ConfigKey::CLOCK_EDGE, 
ClockEdge}, {sigrok::ConfigKey::AMPLITUDE, Amplitude}, {<expression 
error>, Offset}, {sigrok::ConfigKey::REGULATION, Regulation}, 
{sigrok::ConfigKey::OUTPUT_FREQUENCY, OutputFrequency}, 
{sigrok::ConfigKey::OUTPUT_FREQUENCY_TARGET, OutputFrequencyTarget}, 
{sigrok::ConfigKey::MEASURED_QUANTITY, MeasuredQuantity}, 
{sigrok::ConfigKey::EQUIV_CIRCUIT_MODEL, EquivCircuitModel}, 
{sigrok::ConfigKey::TRIGGER_LEVEL, TriggerLevel}, 
{sigrok::ConfigKey::EXTERNAL_CLOCK_SOURCE, ExternalClockSource}, 
{sigrok::ConfigKey::SESSIONFILE, SessionFile}, 
{sigrok::ConfigKey::CAPTUREFILE, CaptureFile}, 
{sigrok::ConfigKey::CAPTURE_UNITSIZE, CaptureUnitSize}, 
{sigrok::ConfigKey::POWER_OFF, PowerOff}, 
{sigrok::ConfigKey::DATA_SOURCE, DataSource}, 
{sigrok::ConfigKey::PROBE_FACTOR, ProbeFactor}, 
{sigrok::ConfigKey::ADC_POWERLINE_CYCLES, ADCPowerlineCycles}, 
{sigrok::ConfigKey::DATALOG, DataLog}, {sigrok::ConfigKey::DEVICE_MODE, 
DeviceMode}, {sigrok::ConfigKey::TEST_MODE, TestMode}}’ from 
‘<brace-enclosed initializer list>’ to ‘std::map<const 
sigrok::ConfigKey*, sv::devices::ConfigKey>’
 };
 ^
/home/majo/tmp/smuview-master/src/devices/deviceutil.hpp:561:42: error: 
‘OFFSET’ is not a member of ‘sigrok::ConfigKey’
  { ConfigKey::Offset, sigrok::ConfigKey::OFFSET },
                                          ^~~~~~
/home/majo/tmp/smuview-master/src/devices/deviceutil.hpp:579:1: error: 
could not convert ‘{{Samplerate, sigrok::ConfigKey::SAMPLERATE}, 
{CaptureRatio, sigrok::ConfigKey::CAPTURE_RATIO}, {PatternMode, 
sigrok::ConfigKey::PATTERN_MODE}, {RLE, sigrok::ConfigKey::RLE}, 
{TriggerSlope, sigrok::ConfigKey::TRIGGER_SLOPE}, {Averaging, 
sigrok::ConfigKey::AVERAGING}, {AvgSamples, 
sigrok::ConfigKey::AVG_SAMPLES}, {TriggerSource, 
sigrok::ConfigKey::TRIGGER_SOURCE}, {HorizTriggerPos, 
sigrok::ConfigKey::HORIZ_TRIGGERPOS}, {BufferSize, 
sigrok::ConfigKey::BUFFERSIZE}, {TimeBase, sigrok::ConfigKey::TIMEBASE}, 
{Filter, sigrok::ConfigKey::FILTER}, {VDiv, sigrok::ConfigKey::VDIV}, 
{Coupling, sigrok::ConfigKey::COUPLING}, {TriggerMatch, 
sigrok::ConfigKey::TRIGGER_MATCH}, {SampleInterval, 
sigrok::ConfigKey::SAMPLE_INTERVAL}, {NumHDiv, 
sigrok::ConfigKey::NUM_HDIV}, {NumVDiv, sigrok::ConfigKey::NUM_VDIV}, 
{SplWeightFreq, sigrok::ConfigKey::SPL_WEIGHT_FREQ}, {SplWeightTime, 
sigrok::ConfigKey::SPL_WEIGHT_TIME}, {SplMeasurementRange, 
sigrok::ConfigKey::SPL_MEASUREMENT_RANGE}, {HoldMax, 
sigrok::ConfigKey::HOLD_MAX}, {HoldMin, sigrok::ConfigKey::HOLD_MIN}, 
{VoltageThreshold, sigrok::ConfigKey::VOLTAGE_THRESHOLD}, 
{ExternalClock, sigrok::ConfigKey::EXTERNAL_CLOCK}, {Swap, 
sigrok::ConfigKey::SWAP}, {CenterFrequency, 
sigrok::ConfigKey::CENTER_FREQUENCY}, {NumLogicChannels, 
sigrok::ConfigKey::NUM_LOGIC_CHANNELS}, {NumAnalogChannels, 
sigrok::ConfigKey::NUM_ANALOG_CHANNELS}, {Voltage, 
sigrok::ConfigKey::VOLTAGE}, {VoltageTarget, 
sigrok::ConfigKey::VOLTAGE_TARGET}, {Current, 
sigrok::ConfigKey::CURRENT}, {CurrentLimit, 
sigrok::ConfigKey::CURRENT_LIMIT}, {Enabled, 
sigrok::ConfigKey::ENABLED}, {ChannelConfig, 
sigrok::ConfigKey::CHANNEL_CONFIG}, {OverVoltageProtectionEnabled, 
sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_ENABLED}, 
{OverVoltageProtectionActive, 
sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_ACTIVE}, 
{OverVoltageProtectionThreshold, 
sigrok::ConfigKey::OVER_VOLTAGE_PROTECTION_THRESHOLD}, 
{OverCurrentProtectionEnabled, 
sigrok::ConfigKey::OVER_CURRENT_PROTECTION_ENABLED}, 
{OverCurrentProtectionActive, 
sigrok::ConfigKey::OVER_CURRENT_PROTECTION_ACTIVE}, 
{OverCurrentProtectionThreshold, 
sigrok::ConfigKey::OVER_CURRENT_PROTECTION_THRESHOLD}, 
{OverTemperatureProtectionEnabled, 
sigrok::ConfigKey::OVER_TEMPERATURE_PROTECTION}, 
{OverTemperatureProtectionActive, 
sigrok::ConfigKey::OVER_TEMPERATURE_PROTECTION_ACTIVE}, 
{UnderVoltageConditionEnabled, 
sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION}, 
{UnderVoltageConditionActive, 
sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION_ACTIVE}, 
{UnderVoltageConditionThreshold, 
sigrok::ConfigKey::UNDER_VOLTAGE_CONDITION_THRESHOLD}, {ClockEdge, 
sigrok::ConfigKey::CLOCK_EDGE}, {Amplitude, 
sigrok::ConfigKey::AMPLITUDE}, {Offset, <expression error>}, 
{Regulation, sigrok::ConfigKey::REGULATION}, {OutputFrequency, 
sigrok::ConfigKey::OUTPUT_FREQUENCY}, {OutputFrequencyTarget, 
sigrok::ConfigKey::OUTPUT_FREQUENCY_TARGET}, {MeasuredQuantity, 
sigrok::ConfigKey::MEASURED_QUANTITY}, {EquivCircuitModel, 
sigrok::ConfigKey::EQUIV_CIRCUIT_MODEL}, {TriggerLevel, 
sigrok::ConfigKey::TRIGGER_LEVEL}, {ExternalClockSource, 
sigrok::ConfigKey::EXTERNAL_CLOCK_SOURCE}, {SessionFile, 
sigrok::ConfigKey::SESSIONFILE}, {CaptureFile, 
sigrok::ConfigKey::CAPTUREFILE}, {CaptureUnitSize, 
sigrok::ConfigKey::CAPTURE_UNITSIZE}, {PowerOff, 
sigrok::ConfigKey::POWER_OFF}, {DataSource, 
sigrok::ConfigKey::DATA_SOURCE}, {ProbeFactor, 
sigrok::ConfigKey::PROBE_FACTOR}, {ADCPowerlineCycles, 
sigrok::ConfigKey::ADC_POWERLINE_CYCLES}, {DataLog, 
sigrok::ConfigKey::DATALOG}, {DeviceMode, 
sigrok::ConfigKey::DEVICE_MODE}, {TestMode, 
sigrok::ConfigKey::TEST_MODE}}’ from ‘<brace-enclosed initializer list>’ 
to ‘std::map<sv::devices::ConfigKey, const sigrok::ConfigKey*>’
 };
 ^
make[2]: *** [CMakeFiles/smuview.dir/build.make:131: 
CMakeFiles/smuview.dir/src/devicemanager.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/smuview.dir/all] 
Fehler 2
make: *** [Makefile:130: all] Fehler 2

[Frank S. (knarfs)]

> Allerdings wurde das Gerät nicht automatisch gefunden, auch ein
> Anschluss nach Programmstart wurde nicht erkannt.
> Ich musste das Netzteil zunächst anschließen, einschalten, smuview
> starten,  neues Gerät auswählen und mit selektiertem RD-Treiber
> USB-serial scannen.

Ja, das ist bei seriellen Geräten leider so. Nur USB Geräte werden 
automatisch gefunden.
Aber das Gerät kannst du auch erst bei laufendem SmuView 
anschliessen/anschalten. Im Connect-Dialog wird die Liste mit den 
vorhandenen seriellen Anschlüssen bei jeden Wechsel des Geräten in der 
DropDown neu geladen.

> Außerdem wurden sämtliche Werte offensichtlich auf "Null" gesetzt.
> Das hatte zur Folge, dass sich zwar die gewünschten Werte einstellen
> ließen und auch auch am PSU angezeigt wurden, der Ausgang allerdingt
> nicht freigeschaltet werden konnte. [...]
> Die Lösung fand ich erst gestern abend: Die Werte für
> Overvoltageprotection(OVP), Overcurrentprotection(OCP) sowie
> Overpowerprotection (OPP) waren genullt!
> Es wäre IMHO sicherlich sinnvoll, sie auf ihren Defaultwerten zu
> belassen.

Weder SmuView noch die Treiber in libsigrok ändern von sich aus Werte 
oder setzten Default-Werte.

bianchifan schrieb:
> Ich habe die master vom 05.05 dann auch gleich mal getestet..
> OVP und OCP sind unverändert geblieben und die AQusgangssspannung
> konnte mittels smuview an- und abgeschaltet werden..

Evtl. war auch der master-Branch von libsigrok schuld. Da fehlt ein 
RW-Mutex, den ich in meinem patches2-Branch hinzugefügt habe.
Aber gut zu hören, dass es funktioniert!

> Die Potis wurden durch Schieber ersetzt, welche bei mir allerdings noch
> träger reagieren als die bereits unerträglich langsamen Potis zuvor.

Hier werde ich wohl den GUI-Prozess vom Setzten der Werte entkoppeln 
müssen. Das ist bisher kein Problem gewesen, aber mit den sehr trägen 
RDTech Netzteilen, kann das pro Wert schon mal 1,5s dauern...

Was dem libsigrok Treiber noch fehlt, ist das Updaten von Werten die am 
Gerät selber geändert werden (OVP/OCP/OPP + Thresholds, Output state, 
Voltage/Current setting). Da ich keins der RDTech Netzteile besitze und 
das regelmässige Lesen dieser Werte ein Performance-Problem werden 
könnte, muss das jemand anderes einbauen :)

PS: Der "could not convert" steht im direkten Zusammenhang zu dem 
fehlenen ConfigKey.

[bianchifan (Gast)]

Frank S. schrieb:
>
> Ja, das ist bei seriellen Geräten leider so. Nur USB Geräte werden
> automatisch gefunden.

Gut, so genau kannte ich mich nicht aus.
Bei meinem zum DPH parallel erworbenen DSLogic war es zunächst genauso, 
dort musste ich erst im Code rumfrickeln, allerdings ist dort ein 
USB-Kommunikationschip verbaut;)

> Aber das Gerät kannst du auch erst bei laufendem SmuView
> anschliessen/anschalten. Im Connect-Dialog wird die Liste mit den
> vorhandenen seriellen Anschlüssen bei jeden Wechsel des Geräten in der
> DropDown neu geladen.
>
Gestern erneut getestet, stimmt!
K.A., warum es zuvor anders war, vielleicht hat ja zwischenzeitliches 
neubooten was gebracht.

>> Außerdem wurden sämtliche Werte offensichtlich auf "Null" gesetzt.
..
> Weder SmuView noch die Treiber in libsigrok ändern von sich aus Werte
> oder setzten Default-Werte.
>
Ich kann hier nur meine Beobachtungen schildern, bevor ich mit smuview 
rumgespielt habe waren die Spannung auf 5V und der Strom auf 2A 
eingestellt, nach der erstmaligen Erkennung in smuview waren beide 
genullt.

> Evtl. war auch der master-Branch von libsigrok schuld. Da fehlt ein
> RW-Mutex, den ich in meinem patches2-Branch hinzugefügt habe.
> Aber gut zu hören, dass es funktioniert!
>
K.A., aktuell funzt es.

>> Die Potis wurden durch Schieber ersetzt, welche bei mir allerdings noch
>> träger reagieren als die bereits unerträglich langsamen Potis zuvor.
>
> Hier werde ich wohl den GUI-Prozess vom Setzten der Werte entkoppeln
> müssen. Das ist bisher kein Problem gewesen, aber mit den sehr trägen
> RDTech Netzteilen, kann das pro Wert schon mal 1,5s dauern...
>
Das erstmakige Ein- bzw Abschalten der Ausgangsspannung dauert ca. 1sec, 
alle weiteren ca. 0,5 sec..
Bei den Stellern dagegen werden jenach Drehwinkel/Strecke noch 2-3 
Zwischenwerte berücksichtigt, die Zeit also ver3- oder sogar ver4facht..
unbrauchbar!
Intuitiv bedienbar wäre ein entkoppeltes Mehrgangpoti mit 2 oder 
3Umdrehungen.

> Was dem libsigrok Treiber noch fehlt, ist das Updaten von Werten die am
> Gerät selber geändert werden (OVP/OCP/OPP + Thresholds, Output state,
> Voltage/Current setting). Da ich keins der RDTech Netzteile besitze und
> das regelmässige Lesen dieser Werte ein Performance-Problem werden
> könnte, muss das jemand anderes einbauen :)
>
Das (Standard-)DPS3005 gibt es für ca. 25$

> PS: Der "could not convert" steht im direkten Zusammenhang zu dem
> fehlenen ConfigKey.

Ist schon klar.., sollte nur noch einmal verdeutlichen, dass mit die 
aktuelle libsigrok mit RDtech offensichtlich net funzt und dass die 
Verwendung Deiner patches-2 z.Z zwingend vonnöten ist.

[bianchifan (Gast)]

Nachdem gestern endlich die Micro_JSTs eingetroffen sind, konnte ich mit 
dem DPS5015 Modul noch eine weitere Eigenheit verifizieren:
Wenn smuview gestartet und das DPS-Modul erkannt ist, bzw. die GUI 
gestartet ist, sind keine Eingaben am DPS mehr möglich, auch nicht nach 
Trennen der USB-Verbindung.
Mit dem DPS5015 selbst werden die Werte für den Strom eine Zehnerpotenz 
zu niedrig angezeigt:
Strom steht auf 1,1A, smuview zeigt 0.1100A an, OCP steht auf 15,2A, 
smuview zeigt 1,520A.

[Frank S. (knarfs)]

bianchifan schrieb:
> Wenn smuview gestartet und das DPS-Modul erkannt ist, bzw. die GUI
> gestartet ist, sind keine Eingaben am DPS mehr möglich, auch nicht nach
> Trennen der USB-Verbindung.

Sieht so aus, würde im Treiber (api.c, dev_open() und dev_close()) die 
Tastensperre (REG_LOCK) aktiviert/deaktiviert.
Vielleicht ist das Gerät zu träge um data acquisition und Bedienung 
gleichzeitig zu handeln?
Du kannst die Sperre ja mal deaktivieren und dann testen, ob das Gerät 
noch bedienbar ist.

> Mit dem DPS5015 selbst werden die Werte für den Strom eine Zehnerpotenz
> zu niedrig angezeigt:
> Strom steht auf 1,1A, smuview zeigt 0.1100A an, OCP steht auf 15,2A,
> smuview zeigt 1,520A.

Bei deinem DPH5005 werden die Werte aber korrekt angezeigt? Wenn ja, 
dann gibt es einen Unterschied im Protokoll der verschiedenen Modelle.

[Frank S. (knarfs)]

Frank S. schrieb:
> bianchifan schrieb:
>> Mit dem DPS5015 selbst werden die Werte für den Strom eine Zehnerpotenz
>> zu niedrig angezeigt:
>> Strom steht auf 1,1A, smuview zeigt 0.1100A an, OCP steht auf 15,2A,
>> smuview zeigt 1,520A.
>
> Bei deinem DPH5005 werden die Werte aber korrekt angezeigt? Wenn ja,
> dann gibt es einen Unterschied im Protokoll der verschiedenen Modelle.

Ok, die verschiedenen Modelle haben tatsächlich eine unterschiedliche 
Kodierung der Stromwerte.
In meinem patches2-Branch habe ich gerade einen Patch dafür hochgeladen. 
Teste das mal mit deinen DPH5005 und DPS5015. Eingestellter Strom und 
OCP, aber auch der aktuelle Ausgangsstrom sollten jetzt bei beiden 
Modellen korrekt angezeigt werden.
Als Nebeneffekt sind jetzt evtl. die beiden Schieberegler ein bisschen 
besser bedienbar!?

[bianchifan (Gast)]

Frank S. schrieb:
> Sieht so aus, würde im Treiber (api.c, dev_open() und dev_close()) die
> Tastensperre (REG_LOCK) aktiviert/deaktiviert.
Da hast Du wohl recht...
Ich habe es nochmal getestet, am DPS taucht auch ein geschlossenes 
Vorhängeschloss Smbol auf ;)

Frank S. schrieb:
> Vielleicht ist das Gerät zu träge um data acquisition und Bedienung
> gleichzeitig zu handeln?
So schaut es wohl aus.
Das erste Einschalten der Ausgangsspannung dauert ca. 3sec, das 
nachfolgende Ausschalten knappe 2sec. Je öfter ich schalte, umso träger 
reagiert das Gerät, irgendwann überhhaupt nicht mehr.
Dann benötigt es eine längere pause, bevor es wieder Kommandos annimmt.

Und so lässt sich auch das Vorhängeschloss deaktivieren:
Pause.., smuview beenden. nach ca. 3sec verschwindet das LOCK-Symbol und 
das Gerät lässt sich wieder bedienen.

Trennt man die USB-Verbindung bei laufendem smuview, bleibt das Gerät 
gesperrt.


Frank S. schrieb:
> Bei deinem DPH5005 werden die Werte aber korrekt angezeigt? Wenn ja,
> dann gibt es einen Unterschied im Protokoll der verschiedenen Modelle.
Beim DPH ist alles gut :)
Ich habe mal die Communications Protolle verglichen, in den 
Beispieldaten für das DPH5005 bzw DPS5015/20 haben 1,5 A (DPH) und 15 A 
DPSse den gleichen Wert!! -> 05DCH

Frank S. schrieb:
> In meinem patches2-Branch habe ich gerade einen Patch dafür hochgeladen.
> Teste das mal mit deinen DPH5005 und DPS5015.
Uff.. dann muss ich das nachher mal laden

[Frank S. (knarfs)]

bianchifan schrieb:
> Das erste Einschalten der Ausgangsspannung dauert ca. 3sec, das
> nachfolgende Ausschalten knappe 2sec. Je öfter ich schalte, umso träger
> reagiert das Gerät, irgendwann überhhaupt nicht mehr.
> Dann benötigt es eine längere pause, bevor es wieder Kommandos annimmt.

Dann ist die Tastensperre (leider) sinnvoll.

> Trennt man die USB-Verbindung bei laufendem smuview, bleibt das Gerät
> gesperrt.

Ja, das ist logisch, da dann der libsigrok-Treiber keine Chance hat, die 
Tastensperre aufzuheben.
Wenn du das Gerät in SmuView trennst (im Baum auswählen und dann das 
"Entfernen"-Symbol klicken), sollte die Tastensperre aufgehoben werden.

[bianchifan (Gast)]

Frank S. schrieb:
> Eingestellter Strom und
> OCP, aber auch der aktuelle Ausgangsstrom sollten jetzt bei beiden
> Modellen korrekt angezeigt werden.
Passt..:)

Frank S. schrieb:
> Als Nebeneffekt sind jetzt evtl. die beiden Schieberegler ein bisschen
> besser bedienbar!?
Leider nein, eher noch schlechter..
Beispiel:
Eingestellt waren 1,5 A, ich wollte auf 2,5 A erhöhen..
Slider angeklickt, verschoben, losgelassen .. nix passiert
2.Versuch
angeklickt, auf Farbwechsel gewartet, etwas Extrazeit gegönnt, 
verschoben losgelassen... nach ca. 10 sec ändert sich der Wert, nach 
weiteren ca. 10 Sekunden blieb die Anzeige bei 2,134 A stehen
3. Versuch, etwas energischer..nach ca 30 sec sowie zwei Zwischenwerten 
wurden 5,345 A angezeigt..

Direkte numerische Eingabe bzw. Inkrement/Dekrement
Wenn Ausgang aus, dann wird der Wert beim Einschalten mit einigen 
Sekunden Verzögerung übernommen.
Ist der Ausgang eingeschaltet, dauert es eine halbe Ewigkeit, min. 30sec

Frank S. schrieb:
> Wenn du das Gerät in SmuView trennst (im Baum auswählen und dann das
> "Entfernen"-Symbol klicken), sollte die Tastensperre aufgehoben werden.
Stimmt, geht sogar recht zügig, 2-3sec ....

Etwas anderes..
Welche Fuhnktion haben die "LED"s OVP und OCP?
Sie sind immer grau und lassen sich nichrt anklicken

[Frank S. (knarfs)]

bianchifan schrieb:
> Frank S. schrieb:
>> Als Nebeneffekt sind jetzt evtl. die beiden Schieberegler ein bisschen
>> besser bedienbar!?
> Leider nein, eher noch schlechter..

Schade, aber viel kann da nicht mehr verbessert werden. Hier ist das 
Netzteil selbst das Problem...
Leider gibt es (noch) keinen libsigrok-Treiber für die alternative 
Firmware OpenDPS (https://github.com/kanflo/opendps). Wäre interessant, 
ob es da die gleichen Probleme gibt.

> Welche Fuhnktion haben die "LED"s OVP und OCP?
> Sie sind immer grau und lassen sich nichrt anklicken

Die LEDs oberhalb der Spannungs-/Strom-Einstellung zeigen dir den 
aktuellen Zustand für OverVoltage-Schutz (OVP), OverCurrent-Schutz 
(OCP), OverTemperature-Schutz (OTP) und UnderVoltage-Schutz (UVP) an.
OTP und UVP gibt es bei den RDTech Netzteilen nicht, OVP und OCP gibt es 
zwar, werden aber momentan bei einer Zustandsänderung nicht automatisch 
übertragen, sondern müssen abgefragt werden. SmuView verlässt sich hier 
ausschliesslich auf die automatische Übertragung (alles andere wäre auch 
nicht sinnvoll).

Die Button/LED-Kombination unterhalb der Spannungs-/Strom-Einstellung 
ist zum an-/ausschalten der diversen Schütze.

[Frank S. (knarfs)]

Ich habe alle Commits für die RDTech-Netzteile in den Branch "patches" 
verschoben (https://github.com/knarfS/libsigrok/commits/patches) und 
bereinigt.

Ausserdem habe ich die fehlende automatische Übertragung u.a. von 
CC/CV/OVP/OCP eingebaut. Keine Ahnung wie sich das auf die Performance 
auswirkt :)
Wäre super, wenn du (oder auch andere) die Änderungen testen und evtl. 
ein Log-File mit Loglevel 5 (./smuview -l 5) auf github 
(https://github.com/knarfS/smuview/issues/9) (oder hier) anhängen 
könntet.

[bianchifan (Gast)]

Frank S. schrieb:
> Ich habe alle Commits für die RDTech-Netzteile in den Branch "patches"
> verschoben (https://github.com/knarfS/libsigrok/commits/patches) und
> bereinigt.

Heute nachmittag herunter geladen, soeben compiliert und mit gewünschtem 
loglevel gestartet... :((

1. Es wird kein DPS-Gerät mehr gefunden
2. Das Gerät ist halb blockiert, genauer, die Ausgangsspannung lässt 
sich an- und abschalten, es können aber keine Parameter geändert werden, 
das Menu ist nicht erreichbar.
3. Nach Beendigung der Verbindung mit dem Sperrsymbol ist das Gerät 
wieder "ansprechbar"

~/tmp/libsigrok-patches$ smuview -l 5
sr: [00:00.000002] log: libsigrok loglevel set to 5.
Settings: "/home/majo/.config/sigrok/SmuView.conf" format 
QSettings::NativeFormat
sr: [00:00.000218] backend: libsigrok 0.6.0/4:0:0.
sr: [00:00.000276] backend: Libs: glib 2.60.0 (rt: 2.60.0/6000:0), 
libzip 1.5.1, libserialport 0.1.1/1:0:1 (rt: 0.1.1/1:0:1), libusb-1.0 
1.0.22.11312 API 0x01000106, libftdi 1.4.
sr: [00:00.000294] backend: Host: x86_64-pc-linux-gnu, little-endian.
sr: [00:00.000307] backend: SCPI backends: TCP, RPC, serial, USBTMC.
sr: [00:00.000318] backend: Firmware search paths:
sr: [00:00.000351] backend:  - /home/majo/.local/share/sigrok-firmware
sr: [00:00.000373] backend:  - /usr/local/share/sigrok-firmware
sr: [00:00.000383] backend:  - /usr/share/ubuntu/sigrok-firmware
sr: [00:00.000394] backend:  - /usr/local/share/sigrok-firmware
sr: [00:00.000406] backend:  - /usr/share/sigrok-firmware
sr: [00:00.000416] backend:  - /var/lib/snapd/desktop/sigrok-firmware
sr: [00:00.000449] backend: Sanity-checking all drivers.
sr: [00:00.000471] backend: Sanity-checking all input modules.
sr: [00:00.000483] backend: Sanity-checking all output modules.
sr: [00:00.000500] backend: Sanity-checking all transform modules.
sr: [00:00.057193] hwdriver: Scan found 0 devices (agilent-dmm).
sr: [00:00.062471] hwdriver: Scan found 0 devices (appa-55ii).
sr: [00:00.153600] hwdriver: Scan found 0 devices 
(arachnid-labs-re-load-pro).
sr: [00:00.154494] hwdriver: Scan found 0 devices (atten-pps3203).
sr: [00:00.155083] hwdriver: Scan found 0 devices (baylibre-acme).
sr: [00:00.155334] hwdriver: Scan found 0 devices (bbcgm-2010).
sr: [00:00.155568] hwdriver: Scan found 0 devices (brymen-bm25x).
sr: [00:00.155817] hwdriver: Scan found 0 devices (brymen-bm857).
sr: [00:00.157772] hwdriver: Scan found 0 devices (brymen-bm86x).
sr: [00:00.158108] hwdriver: Scan found 0 devices (cem-dt-885x).
sr: [00:00.158983] hwdriver: Scan found 0 devices (center-309).
sr: [00:00.159222] hwdriver: Scan found 0 devices (colead-slm).
sr: [00:00.159460] hwdriver: Scan found 0 devices (conrad-digi-35-cpu).
sr: [00:00.159671] demo: Generating square pattern.
sr: [00:00.159727] demo: Generating sine pattern.
sr: [00:00.159864] demo: Generating triangle pattern.
sr: [00:00.160036] demo: Generating sawtooth pattern.
sr: [00:00.160113] hwdriver: Scan found 1 devices (demo).
Configurable::init(): Init  "A0"  - key  "Offset"
Configurable::init(): Init  "A0"  - key  "Measured Quantity"
Configurable::init(): Init  "A0"  - key  "Amplitude"
Configurable::init(): Init  "A0"  - key  "Pattern Mode"
sr: [00:00.160401] hwdriver: sr_config_list(): key 30002 (pattern) sdi 
0x55ae5181e390 cg A0 -> ['square', 'sine', 'triangle', 'sawtooth']
Configurable::init(): Init  "A1"  - key  "Offset"
Configurable::init(): Init  "A1"  - key  "Measured Quantity"
Configurable::init(): Init  "A1"  - key  "Amplitude"
Configurable::init(): Init  "A1"  - key  "Pattern Mode"
sr: [00:00.160584] hwdriver: sr_config_list(): key 30002 (pattern) sdi 
0x55ae5181e390 cg A1 -> ['square', 'sine', 'triangle', 'sawtooth']
Configurable::init(): Init  "A2"  - key  "Offset"
Configurable::init(): Init  "A2"  - key  "Measured Quantity"
Configurable::init(): Init  "A2"  - key  "Amplitude"
Configurable::init(): Init  "A2"  - key  "Pattern Mode"
sr: [00:00.160752] hwdriver: sr_config_list(): key 30002 (pattern) sdi 
0x55ae5181e390 cg A2 -> ['square', 'sine', 'triangle', 'sawtooth']
Configurable::init(): Init  "A3"  - key  "Offset"
Configurable::init(): Init  "A3"  - key  "Measured Quantity"
Configurable::init(): Init  "A3"  - key  "Amplitude"
Configurable::init(): Init  "A3"  - key  "Pattern Mode"
sr: [00:00.160920] hwdriver: sr_config_list(): key 30002 (pattern) sdi 
0x55ae5181e390 cg A3 -> ['square', 'sine', 'triangle', 'sawtooth']
Configurable::init(): Init  "Analog"  - key  "Offset"
Configurable::init(): Init  "Analog"  - key  "Amplitude"
Configurable::init(): Init  "Logic"  - key  "Pattern Mode"
sr: [00:00.161075] hwdriver: sr_config_list(): key 30002 (pattern) sdi 
0x55ae5181e390 cg Logic -> ['sigrok', 'random', 'incremental', 
'walking-one', 'walking-zero', 'all-low', 'all-high', 'squid', 
'graycode']
Configurable::init(): Init  "Demo device"  - key  "Trigger Match"
sr: [00:00.161186] hwdriver: sr_config_list(): key 30014 (triggermatch) 
sdi 0x55ae5181e390 cg NULL -> [1, 2, 3, 4, 5]
Configurable::init(): Init  "Demo device"  - key  "Averaging Samples"
Configurable::init(): Init  "Demo device"  - key  "Averaging"
Configurable::init(): Init  "Demo device"  - key  "Capture Ratio"
Configurable::init(): Init  "Demo device"  - key  "Samplerate"
sr: [00:00.161359] hwdriver: sr_config_list(): key 30000 (samplerate) 
sdi 0x55ae5181e390 cg NULL -> {'samplerate-steps': <[uint64 1, 
1000000000, 1]>}
sr: [00:00.161607] hwdriver: Scan found 0 devices (deree-de5000).
sr: [00:00.161935] hwdriver: Scan found 0 devices (digitek-dt4000zc).
sr: [00:00.162168] hwdriver: Scan found 0 devices (eevblog-121gw).
sr: [00:00.174577] hwdriver: Scan found 0 devices (fluke-45).
sr: [00:00.175105] hwdriver: Scan found 0 devices (fluke-dmm).
sr: [00:00.175432] hwdriver: Scan found 0 devices (gmc-mh-1x-2x-rs232).
sr: [00:00.175671] hwdriver: Scan found 0 devices (gmc-mh-2x-bd232).
sr: [00:00.175969] hwdriver: Scan found 0 devices (gwinstek-gpd).
sr: [00:00.182400] hwdriver: Scan found 0 devices (hp-3457a).
sr: [00:00.188982] hwdriver: Scan found 0 devices (hpib-pps).
sr: [00:00.189944] hwdriver: Scan found 0 devices (iso-tech-idm103n).
sr: [00:00.190236] hwdriver: Scan found 0 devices (kecheng-kc-330b).
sr: [00:00.190464] hwdriver: Scan found 0 devices (kern-ew-6200-2nm).
sr: [00:00.190669] hwdriver: Scan found 0 devices (korad-kaxxxxp).
sr: [00:00.190871] hwdriver: Scan found 0 devices (lascar-el-usb).
sr: [00:00.191090] hwdriver: Scan found 0 devices (manson-hcs-3xxx).
sr: [00:00.191292] hwdriver: Scan found 0 devices (mastech-mas345).
sr: [00:00.191499] hwdriver: Scan found 0 devices (mastech-ms2115b).
sr: [00:00.191707] hwdriver: Scan found 0 devices (mastech-ms5308).
sr: [00:00.192004] hwdriver: Scan found 0 devices (mastech-ms8250b).
sr: [00:00.192217] hwdriver: Scan found 0 devices (mastech-ms8250d).
sr: [00:00.192432] hwdriver: Scan found 0 devices (maynuo-m97).
sr: [00:00.192633] hwdriver: Scan found 0 devices (metex-m3640d).
sr: [00:00.192829] hwdriver: Scan found 0 devices (metex-m3860m).
sr: [00:00.193028] hwdriver: Scan found 0 devices (metex-m4650cr).
sr: [00:00.193222] hwdriver: Scan found 0 devices (metex-me31).
sr: [00:00.193419] hwdriver: Scan found 0 devices (metrix-mx56c).
sr: [00:00.193629] hwdriver: Scan found 0 devices (mic-98581).
sr: [00:00.193819] hwdriver: Scan found 0 devices (mic-98583).
sr: [00:00.194023] serial: No serial device specified.
sr: [00:00.194057] hwdriver: Scan found 0 devices (motech-lps-301).
sr: [00:00.194237] hwdriver: Scan found 0 devices (norma-dmm).
sr: [00:00.194432] hwdriver: Scan found 0 devices (pce-322a).
sr: [00:00.194638] hwdriver: Scan found 0 devices (pce-pce-dm32).
sr: [00:00.194841] hwdriver: Scan found 0 devices (peaktech-2170).
sr: [00:00.195039] hwdriver: Scan found 0 devices (peaktech-3330).
sr: [00:00.195242] hwdriver: Scan found 0 devices (peaktech-3410).
sr: [00:00.195441] hwdriver: Scan found 0 devices (peaktech-3415).
sr: [00:00.195642] hwdriver: Scan found 0 devices (peaktech-4370).
sr: [00:00.195842] hwdriver: Scan found 0 devices (peaktech-4390a).
sr: [00:00.196075] hwdriver: Scan found 0 devices (radioshack-22-168).
sr: [00:00.196292] hwdriver: Scan found 0 devices (radioshack-22-805).
sr: [00:00.196506] hwdriver: Scan found 0 devices (radioshack-22-812).
sr: [00:00.196704] hwdriver: Scan found 0 devices (rdtech-dps).
sr: [00:00.208430] hwdriver: Scan found 0 devices (scpi-dmm).
sr: [00:00.223531] hwdriver: Scan found 0 devices (scpi-pps).
sr: [00:00.225016] hwdriver: Scan found 0 devices (siemens-b102x).
sr: [00:00.227112] hwdriver: Scan found 0 devices (sparkfun-70c).
sr: [00:00.230549] hwdriver: Scan found 0 devices (tecpel-dmm-8061).
sr: [00:00.232244] hwdriver: Scan found 0 devices (tecpel-dmm-8061-ser).
sr: [00:00.235484] hwdriver: Scan found 0 devices (tekpower-tp4000ZC).
sr: [00:00.237662] hwdriver: Scan found 0 devices (teleinfo).
sr: [00:00.238523] hwdriver: Scan found 0 devices (tenma-72-7730).
sr: [00:00.241758] hwdriver: Scan found 0 devices (tenma-72-7730-ser).
sr: [00:00.242699] hwdriver: Scan found 0 devices (tenma-72-7732).
sr: [00:00.244093] hwdriver: Scan found 0 devices (tenma-72-7732-ser).
sr: [00:00.244961] hwdriver: Scan found 0 devices (tenma-72-7745).
sr: [00:00.246974] hwdriver: Scan found 0 devices (tenma-72-7745-ser).
sr: [00:00.247857] hwdriver: Scan found 0 devices (tenma-72-7750).
sr: [00:00.253490] hwdriver: Scan found 0 devices (tenma-72-7750-ser).
sr: [00:00.254830] hwdriver: Scan found 0 devices (tenma-72-9380a).
sr: [00:00.256065] hwdriver: Scan found 0 devices (tenma-72-9380a-ser).
sr: [00:00.358127] hwdriver: Scan found 0 devices (testo).
sr: [00:00.361850] hwdriver: Scan found 0 devices (tondaj-sl-814).
sr: [00:00.362911] hwdriver: Scan found 0 devices (uni-t-ut32x).
sr: [00:00.364102] hwdriver: Scan found 0 devices (uni-t-ut372).
sr: [00:00.365187] hwdriver: Scan found 0 devices (uni-t-ut60a).
sr: [00:00.366268] hwdriver: Scan found 0 devices (uni-t-ut60a-ser).
sr: [00:00.367326] hwdriver: Scan found 0 devices (uni-t-ut60e).
sr: [00:00.368394] hwdriver: Scan found 0 devices (uni-t-ut60e-ser).
sr: [00:00.370041] hwdriver: Scan found 0 devices (uni-t-ut60g).
sr: [00:00.371094] hwdriver: Scan found 0 devices (uni-t-ut60g-ser).
sr: [00:00.372185] hwdriver: Scan found 0 devices (uni-t-ut61b).
sr: [00:00.373306] hwdriver: Scan found 0 devices (uni-t-ut61b-ser).
sr: [00:00.374380] hwdriver: Scan found 0 devices (uni-t-ut61c).
sr: [00:00.375443] hwdriver: Scan found 0 devices (uni-t-ut61c-ser).
sr: [00:00.376407] hwdriver: Scan found 0 devices (uni-t-ut61d).
sr: [00:00.377365] hwdriver: Scan found 0 devices (uni-t-ut61d-ser).
sr: [00:00.378298] hwdriver: Scan found 0 devices (uni-t-ut61e).
sr: [00:00.379244] hwdriver: Scan found 0 devices (uni-t-ut61e-ser).
sr: [00:00.381563] hwdriver: Scan found 0 devices (uni-t-ut71a).
sr: [00:00.383233] hwdriver: Scan found 0 devices (uni-t-ut71a-ser).
sr: [00:00.384316] hwdriver: Scan found 0 devices (uni-t-ut71b).
sr: [00:00.385802] hwdriver: Scan found 0 devices (uni-t-ut71b-ser).
sr: [00:00.386736] hwdriver: Scan found 0 devices (uni-t-ut71c).
sr: [00:00.387686] hwdriver: Scan found 0 devices (uni-t-ut71c-ser).
sr: [00:00.388635] hwdriver: Scan found 0 devices (uni-t-ut71d).
sr: [00:00.389920] hwdriver: Scan found 0 devices (uni-t-ut71d-ser).
sr: [00:00.391155] hwdriver: Scan found 0 devices (uni-t-ut71e).
sr: [00:00.392356] hwdriver: Scan found 0 devices (uni-t-ut71e-ser).
sr: [00:00.393584] hwdriver: Scan found 0 devices (va-va18b).
sr: [00:00.394829] hwdriver: Scan found 0 devices (va-va40b).
sr: [00:00.395867] hwdriver: Scan found 0 devices (velleman-dvm4100).
sr: [00:00.397642] hwdriver: Scan found 0 devices (victor-dmm).
sr: [00:00.398809] hwdriver: Scan found 0 devices (victor-dmm-ser).
sr: [00:00.400141] hwdriver: Scan found 0 devices (voltcraft-k204).
sr: [00:00.401554] hwdriver: Scan found 0 devices (voltcraft-m3650cr).
sr: [00:00.402812] hwdriver: Scan found 0 devices (voltcraft-m3650d).
sr: [00:00.404035] hwdriver: Scan found 0 devices (voltcraft-m4650cr).
sr: [00:00.404866] hwdriver: Scan found 0 devices (voltcraft-me42).
sr: [00:00.406832] hwdriver: Scan found 0 devices (voltcraft-vc820).
sr: [00:00.408492] hwdriver: Scan found 0 devices (voltcraft-vc820-ser).
sr: [00:00.409759] hwdriver: Scan found 0 devices (voltcraft-vc830).
sr: [00:00.411537] hwdriver: Scan found 0 devices (voltcraft-vc830-ser).
sr: [00:00.412656] hwdriver: Scan found 0 devices (voltcraft-vc840).
sr: [00:00.413972] hwdriver: Scan found 0 devices (voltcraft-vc840-ser).
sr: [00:00.415015] hwdriver: Scan found 0 devices (voltcraft-vc870).
sr: [00:00.425745] hwdriver: Scan found 0 devices (voltcraft-vc870-ser).
sr: [00:00.429044] hwdriver: Scan found 0 devices (voltcraft-vc920).
sr: [00:00.430149] hwdriver: Scan found 0 devices (voltcraft-vc920-ser).
sr: [00:00.431340] hwdriver: Scan found 0 devices (voltcraft-vc940).
sr: [00:00.432431] hwdriver: Scan found 0 devices (voltcraft-vc940-ser).
sr: [00:00.433575] hwdriver: Scan found 0 devices (voltcraft-vc96).
sr: [00:00.434891] hwdriver: Scan found 0 devices (voltcraft-vc960).
sr: [00:00.436154] hwdriver: Scan found 0 devices (voltcraft-vc960-ser).
sr: [00:00.440786] hwdriver: Scan found 0 devices (zketech-ebd-usb).
sr: [00:17.814114] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi 
(nil) cg NULL -> [uint32 20000, 20001, 20002]
sr: [00:17.814179] modbus: Opening serial_rtu device .
sr: [00:17.814202] serial: Opening serial port '' (flags 1).
sr: [00:17.814225] serial: Attempt to open serial port with invalid 
parameters.
sr: [00:17.814243] modbus: Couldn't open Modbus device.
sr: [00:17.814266] hwdriver: Scan found 0 devices (rdtech-dps).
sr: [01:09.472239] hwdriver: Scan found 0 devices (rdtech-dps).
sr: [01:12.127944] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi 
(nil) cg NULL -> [uint32 20000, 20001, 20002]
sr: [01:12.128006] modbus: Opening serial_rtu device .
sr: [01:12.128036] serial: Opening serial port '' (flags 1).
sr: [01:12.128058] serial: Attempt to open serial port with invalid 
parameters.
sr: [01:12.128108] modbus: Couldn't open Modbus device.
sr: [01:12.128166] hwdriver: Scan found 0 devices (rdtech-dps).
sr: [01:36.293910] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi 
(nil) cg NULL -> [uint32 20000, 20001]
sr: [01:36.293974] serial: Opening serial port '' (flags 1).
sr: [01:36.293992] serial: Attempt to open serial port with invalid 
parameters.
sr: [01:36.294004] hwdriver: Scan found 0 devices (agilent-dmm).
sr: [01:57.814265] hwdriver: sr_config_list(): key 2147418112 (NULL) sdi 
(nil) cg NULL -> [uint32 20000, 20001, 20002]
sr: [01:57.814316] modbus: Opening serial_rtu device .
sr: [01:57.814335] serial: Opening serial port '' (flags 1).
sr: [01:57.814349] serial: Attempt to open serial port with invalid 
parameters.
sr: [01:57.814360] modbus: Couldn't open Modbus device.
sr: [01:57.814374] hwdriver: Scan found 0 devices (rdtech-dps).
BaseDevice::~BaseDevice():  "Demo device"
BaseDevice::close(): Trying to close device  "Demo device"

[Klaus H. (nikolaus10)]

Hallo

Schoenen Dank fuer die Muehe dieses sehr schoene Program zu schreiben.

Eine Frage:
Ich will viele rote LED pruefen. 0-3V ; 0-10ma
Dazu wollte ich einen Arduino Due nehmen, wg DA Wandler und 12 bit ADC.
So ganz genau muss es nicht sein, aber ein automatisierter Messvorgang( 
durch wobeln von 0-2V)

Geht das damit oder soll ich besser was anderes nehmen?
Welche Bibliotheken muss ich fuer den Arduino verwenden ?
Notfalls kann ich auch einen Arduino Nano mit PWM/DA Wandler nutzen.
Hat das schon mal jemand gemacht ?

Danke fuer die Antworten und 73

[SEN-Meister (Gast)]

Klaus H. schrieb:
> Geht das damit oder soll ich besser was anderes nehmen?

Das geht nicht direkt. SmuView nutzt eine begrenzte Auswahl an Geräten, 
welche wiederum von Sigrok unterstützt werden.
Konkret steht alles hier kurz zusammengefasst: 
https://sigrok.org/wiki/SmuView

Dennoch wäre es möglich, aber du müsstes einen eigenen Sigrok-Treiber 
schreiben und ein eigenes Arduino-Programm schreiben (inkl. Protokoll).

Für deine Anwendung wäre wahrscheinlich am einfachsten die komplette 
Wobbel-Logic direkt in dem Arduino umzusetzen und ergebnisse per UART an 
den PC zu senden.
Oder Ein Labornetzgerät und ein Multimeter aussuchen, welche schon 
unterstützt werden.

[Klaus H. (nikolaus10)]

Danke fuer die Antwort.

Ist es vielleicht moeglich eines der Instrumente oder die PSU mit dem 
Arduino DUE zu emulieren?
Ich wollte mir nicht nochmal ein DVM oder Labornetzteil kaufen.

Schoene Gruesse und 73

[bianchifan (Gast)]

Nachdem das Upgrade auf Ubuntu 20.10 nicht so gelaufen ist wie geplant 
musste ich komplett neu aufsetzen. Nebst divesen anderen Problemen lässt 
sich auch smuview nicht mehr kompilieren.
Versucht habe ich den aktuellen master brach sowie die letzte 
"offizielle" Version 0.04. Beide brechen mit einem 
error=deprecated-declarations ab, in beiden Fällen scheint es Probleme 
mit QT5 zu geben.
Auszug aus dem build der 0.0.4:
.
.
.
[ 69%] Building CXX object 
CMakeFiles/smuview.dir/src/ui/dialogs/connectdialog.cpp.o
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp: In member 
function ‘void sv::ui::dialogs::ConnectDialog::populate_drivers()’:
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp:200:32: error: 
‘QVariant qVariantFromValue(const T&) [with T = 
std::shared_ptr<sigrok::Driver>]’ is deprecated: Use 
QVariant::fromValue() instead. [-Werror=deprecated-declarations]
  200 |     qVariantFromValue(sr_driver));
      |                                ^
In file included from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlocale.h:43,
                 from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qtextstream.h:46,
                 from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qdebug.h:49,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QDebug:1,
                 from 
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp:30:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:528:17: note: 
declared here
  528 | inline QVariant qVariantFromValue(const T &t)
      |                 ^~~~~~~~~~~~~~~~~
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp: In member 
function ‘void sv::ui::dialogs::ConnectDialog::on_scan_pressed()’:
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp:343:55: error: 
‘QVariant qVariantFromValue(const T&) [with T = 
std::shared_ptr<sv::devices::HardwareDevice>]’ is deprecated: Use 
QVariant::fromValue() instead. [-Werror=deprecated-declarations]
  343 |   item->setData(Qt::UserRole, qVariantFromValue(device));
      |                                                       ^
In file included from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlocale.h:43,
                 from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qtextstream.h:46,
                 from 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qdebug.h:49,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QDebug:1,
                 from 
/home/majo/tmp/smuview/src/ui/dialogs/connectdialog.cpp:30:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvariant.h:528:17: note: 
declared here
  528 | inline QVariant qVariantFromValue(const T &t)
      |                 ^~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/smuview.dir/build.make:1231: 
CMakeFiles/smuview.dir/src/ui/dialogs/connectdialog.cpp.o] Fehler 1
.
.
.

[Frank S. (knarfs)]

Klaus H. schrieb:
> Hallo
>
> Schoenen Dank fuer die Muehe dieses sehr schoene Program zu schreiben.

Danke :)

> Eine Frage:
> Ich will viele rote LED pruefen. 0-3V ; 0-10ma
> Dazu wollte ich einen Arduino Due nehmen, wg DA Wandler und 12 bit ADC.
> So ganz genau muss es nicht sein, aber ein automatisierter Messvorgang(
> durch wobeln von 0-2V)
>
> Geht das damit oder soll ich besser was anderes nehmen?
> Welche Bibliotheken muss ich fuer den Arduino verwenden ?
> Notfalls kann ich auch einen Arduino Nano mit PWM/DA Wandler nutzen.
> Hat das schon mal jemand gemacht ?

Wie SEN-Meister schon geschrieben hat, geht das nicht out-of-the-box. 
Natürlich kannst du einen Treiber für sigrok mit einem von dir 
entworfenen Protokoll schreiben, welcher mit dem Arduino kommuniziert. 
Aber ob das den Aufwand lohnt, da bin ich mir nicht sicher.
Wenn du das trotzdem machen willst, dann würde ich ein SCPI basiertes 
Protokoll empfehlen und auf den scpi-pps Treiber von sigrok aufsetzten.

SmuView selber ist für solche automatisierten Messaufgaben sehr gut 
geeignet und du kannst über einfache Python-Scripte den Messvorgang nach 
deinen Wünschen gestalten.
Die aktuellen Entwicklungsversionen von libsigrok und SmuView 
unterstützen mittlerweile mehr Netzteile und sehr viele Multimeter. Auch 
sind weitere Möglichkeiten hinzu gekommen, über die Python-Schnittstelle 
die GUI von SmuView zu beeinflussen (z.B. Eingabe-Fenster).

Ich bin gerade dabei die Version 0.0.5 fertig zu machen und hoffe diese 
noch in diesem Jahr zu veröffentlichen.

Viele Grüße
Frank

[Frank S. (knarfs)]

bianchifan schrieb:
> Nachdem das Upgrade auf Ubuntu 20.10 nicht so gelaufen ist wie geplant
> musste ich komplett neu aufsetzen. Nebst divesen anderen Problemen lässt
> sich auch smuview nicht mehr kompilieren.
> Versucht habe ich den aktuellen master brach sowie die letzte
> "offizielle" Version 0.04. Beide brechen mit einem
> error=deprecated-declarations ab, in beiden Fällen scheint es Probleme
> mit QT5 zu geben.

Dieser Fehler sollte eigentlich seit Mitte August (Commit 1cb3bd8) 
gefixt sein.
Bist du sicher, dass du den aktuellen master-Branch baust? Evtl. hilft 
es, dein build-Verzeichnis zu bereinigen.

Viele Grüße
Frank

[bianchifan (Gast)]

Frank S. schrieb:
> Bist du sicher, dass du den aktuellen master-Branch baust? Evtl. hilft
> es, dein build-Verzeichnis zu bereinigen.

Das build Verzeichnis wird bei problemen immer komplett gelöscht und neu 
erstellt...
Es war der Branch vom letzen Samstag.
Ich muss mich trotzdem entschuldigen, denn das Problem ist beim master 
ein anderes, ich habe nicht genau hingeschaut.
Die Comlilierung bricht relativ früh nach einigen Sekunden(18%) ab:

/home/majo/tmp/smuview/src/data/datautil.hpp:409:22: error: ‘ENERGY’ is 
not a member of ‘sigrok::Quantity’
  409 |  { sigrok::Quantity::ENERGY, Quantity::Energy },
      |                      ^~~~~~

.
.
.
plus jede Menge Folgefehler..could not convert, is not a member, e.t.c

LG, Markus

[Klaus H. (nikolaus10)]

Frank S. schrieb:
> Wenn du das trotzdem machen willst, dann würde ich ein SCPI basiertes
> Protokoll empfehlen und auf den scpi-pps Treiber von sigrok aufsetzten.
....
>
> Ich bin gerade dabei die Version 0.0.5 fertig zu machen und hoffe diese
> noch in diesem Jahr zu veröffentlichen

Gut das es weiter geht .
Freue mich schon.

Versuche das mal mit SCPI auf einem Arduino.
Kann jemand eine SCPI Libary empfehlen ?

Gruesse und 73

[Frank S. (knarfs)]

Hi Markus,

bianchifan schrieb:
> Die Comlilierung bricht relativ früh nach einigen Sekunden(18%) ab:
>
> /home/majo/tmp/smuview/src/data/datautil.hpp:409:22: error: ‘ENERGY’ is
> not a member of ‘sigrok::Quantity’
>   409 |  { sigrok::Quantity::ENERGY, Quantity::Energy },
>       |                      ^~~~~~
>
> .
> .
> .
> plus jede Menge Folgefehler..could not convert, is not a member, e.t.c

Du benötigst eine aktuelle Version von libsigrok.
Leider habe ich bis jetzt noch keine praktikable Möglichkeit gefunden, 
auf Zwischenversionen von libsigrok anhand des Commit-Hashes mit CMake 
zu prüfen. Deshalb meckert CMake leider nicht das zu alte libsigrok 
an...

Viele Grüße
Frank

[Frank S. (knarfs)]

Hallo Klaus,

Klaus H. schrieb:
> Versuche das mal mit SCPI auf einem Arduino.
> Kann jemand eine SCPI Libary empfehlen ?

Eine Arduino SCPI-Library kann ich dir leider nicht empfehlen.
Für den libsigrok Treiber wirst du keine benötigen, das ist alles schon 
vorhanden. Du wirst lediglich deine verwendeten Kommandos definieren 
müssen.

Viele Grüße
Frank

[bianchifan (Gast)]

Frank S. schrieb:
> Deshalb meckert CMake leider nicht das zu alte libsigrok
> an...

Danke für den Tip, er mir letztendlich weitergeholfen.

Durchblicken tu ich die ganzen Kram jedenfalls schon lange nicht mehr...
- libsigrok hatte ich als allererstes gemaket
- Dann war pulseview an der Reihe, leider wollte dieses nicht starten
- Eine Analyse erschien mir zu aufwendig, ich habe mich dann schlicht 
und ergreifend für die "offiziellen" Weg via apt entschieden, die 
korrespondierenden 0.5.2-2 sind unter /usr/lib, /usr/include... auch 
noch vorhanden
- Anschließend startete das offizielle pulseview, smuview und 
DSView(0.99) ließen sich danach nicht mehr compilieren.
----
Ich habe nun die aktuellen git-master-branches erneut kompiliert und mit 
"make install" in /usr/local geschubst.
smuview ließ sich compilieren und schubsen, starte aber nicht.
Gleiches Bild bei pulseview, Start wurde verweigert.
DSView ließ sich erneut nicht compilieren, die Fehlermeldungen verhießen 
nichts gutes, glib.h wurde vermisst.
Ich habe dann die aktuelle Version von DSView(1.1.2) gesaugt, wohl 
wissend, dass sie mit mein gehacktes DSLogic nicht mag.
Diese ließ sich problemlos übersetzen, installieren und starten.
Ein Start von der Kommasdozeile offenbart lediglich vier Dekoder, welche 
gen API Versionsproblemen nicht geladen werden können.
Kurioserweise startet pulseview nun ebenfalls und vermisst gleichfalls 
zwei Dekoder, wenn auch andere.
smuview startet nun problemlos.
???
DSView bringt eigentlich eigene libs mit..4DSL (libsigrokxxx for 
DSLogic)

[SmuView (Gast)]

SmuView hat seit Ende August keine Änderungen mehr gesehen. Auch ist in 
https://github.com/knarfS bei den anderen Projekten nichts getan worden. 
Geht es Frank gut?

[Frank S. (knarfs)]

SmuView schrieb:
> Geht es Frank gut?

Danke der Nachfrage, mir geht es gut ;)

Habe gerade leider viel um die Ohren, bin aber nebenher am entwickeln 
neuer Features.
Als nächste grosse Neuerung wird die Integration von Oszilloskopen in 
SmuView kommen. Ich bin damit zwar schon relativ weit, aber ist trotzdem 
noch einiges an Arbeit...

Viele Grüsse
Frank

[Klaus H. (nikolaus10)]

Hallo Frank

Dir geht es immernoch gut ?
:-)

Gruesse

[Saleae-User (Gast)]

Frank S. schrieb:
> Als nächste grosse Neuerung wird die Integration von Oszilloskopen in
> SmuView kommen.

Das könnte man ja mal ein wenig unterstützen, oder?

[René D. (Firma: www.dossmatik.de) (dose)]

Saleae-User schrieb:
> Frank S. schrieb:
>> Als nächste grosse Neuerung wird die Integration von Oszilloskopen in
>> SmuView kommen.
>
> Das könnte man ja mal ein wenig unterstützen, oder?

Ich habe so was für mein Oszi schon mal gesucht.

Mein RTM1054 hat ein Lan Anschluss. Darauf laufen mehrere LAN Dienste. 
Letztendlich habe ich nur den Webserver genutzt und Screenshots erzeugt.

Die Daten konnte ich nirgends einbinden. Ich glaube ein Labview treiber 
gibt es. Das Tool nutze ich aber nicht.