newer version of QtDMM called QtDMM2 and CDMM

[dlarue]

Thanks for the Qt5 port, it's made it easier to build since that's the env I'm running now. Not sure if you know that the original author did an update he calls QtDMM2 and I believe he breaks out the code into a commandline tool( CDMM ) and a GUI display(QTDMM2). It's built with Qt4 so I've not been able to try it yet.

I found it while looking for a commandline tool since I'd like to stick a single lithium cell powering an rPiZW and do some data logging without a big laptop connected and using ssh and scp to see what's going on.

Again, thanks for the Qt5 port.
http://www.mtoussaint.de/qtdmm2.html#description

[tuxmaster5000]

It is very strange, because the code of dmm2 and cdmm is much older then the code of dmm. So I don't know of which versiob the focus of the original author will be. But when more people has an interest on it, then I think it will be an good idea to create an QtDMM project on gh with the 3 repos (QtDMM, QtDMM2, CDMM)

[dlarue]

The QtDMM author started on the next-gen version which split the frontend/backend into separate codebases with the goal of the backend supporting more than one DMM simultaneous AND to provide a network interface so the frontend(QtDMM2) could be run remotely. SigRok was supposed to take over development of QtDMM when they wanted to use it in one of their products but that seemed to end up with them just using the code and not supporting nor updating so he jumped back in and update in 2016.

I was looking for a commandline tool so I could connect a little headless Raspberry Pi ZW to my Metex meter and either log data or run the logging remotely. QtDMM2 would fit that need perfectly but wouldn't compile with qt5 tools. Maybe I'll spin up a Ubuntu 16.04 virtual machine and see if that'll work.

[tuxmaster5000]

I try to port it to Qt5/Qt6 but my reference systems are all rhel/fedora based. So you must then check if it will work under the Debian family.

[dlarue]

I booted an Lubuntu 18.04 iso and was able to compile with qt4 but it took me 2 hours to figure it all out.
I don't know if QtDMM has all the meter support QtDMM2 has but I really like the idea of being able to have a backend commandline server connected to a meter( or meters) and then have a GUI on another machine. Like remote X11.

I can build on ubuntu/qt5 if you get it to compile on rhel/fedora and then test if that's something you're up for.
Right now I have cdmm built and running via qt4 but still trying to figure out how to get the GUI running. so far it looksl ike cdmm-0.4 and qtdmm2-0.3 are both just the backend/cdmm but I've asked the dev how to get the GUI going.

[tuxmaster]

I have created an repo for cdmm. I will try to build an qt5 or Qt6 port. And use cmake instant of qmake

[tuxmaster5000]

cdmm was only native c++ code, so the port to cmake was easily.
Please take a look at:
https://github.com/tuxmaster/CDMM

[dlarue]

I'm building cmake 3.25.1 now and will give it a shot. I've not heard back from Matthias yet and will try to see if the Qt UI is in the qtdmm2-0.3 version.

update: I found the source files for the client/server version of QtDMM in qtdmm2 directory of the v0.2 package: http://www.mtoussaint.de/qtdmm2-0.2.tgz

[dlarue]

after building and installing cmake 3.25.1 I had an error running cmake because of missing doxygen and dot executable. So I installed the following:
sudo apt install doxygen graphviz

After trying to compile I received link errors related to pthread:
... [100%] Linking CXX executable cdmm /usr/bin/ld: CMakeFiles/cdmm.dir/src/mutex.cpp.o: in function Mutex::tryLock()':
mutex.cpp:(.text+0x88): undefined reference to pthread_mutex_trylock' /usr/bin/ld: CMakeFiles/cdmm.dir/src/mutex.cpp.o: in function Mutex::isLocked()':
mutex.cpp:(.text+0xac): undefined reference to pthread_mutex_trylock' /usr/bin/ld: CMakeFiles/cdmm.dir/src/thread.cpp.o: in function Thread::start()':
thread.cpp:(.text+0x103): undefined reference to pthread_create' /usr/bin/ld: CMakeFiles/cdmm.dir/src/thread.cpp.o: in function Thread::wait()':
thread.cpp:(.text+0x13f): undefined reference to pthread_join' collect2: error: ld returned 1 exit status

[tuxmaster5000]

Do you have another cmake/gcc version? I have tested it, with the versions from the read me file.

[dlarue]

Kubuntu 20.04 has cmake 3.16 and you required 3.24 so I got the latest source for cmake, built and installed it. gcc is at version 9.4.0

[tuxmaster5000]

It looks like your os use an old glibc. :(
see:
https://gitlab.kitware.com/cmake/cmake/-/issues/23092
Fedora use 2.35 of glibc

[dlarue]

I suppose I can boot a ubuntu 22.04 iso and try to build there. My gcc isn't latest/greatest either(9.4.x vs 12.2.x).

[tuxmaster5000]

you can also to add this line into to cmake file:
find_package(Threads REQUIRED)

[dlarue]

I tried adding the find_package(xx) entry and while it says it finds pthreads, it still fails the same way. It built fine using lubuntu 22.04 which has the required versions of cmake and gcc and apparently other required libs.

$ cmake -B myBuild/
-- The CXX compiler identification is GNU 9.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found components: doxygen dot mscgen dia
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Install binary to /usr/local/bin
-- Configuring done
-- Generating done
-- Build files have been written to: /home/maker/Downloads/Metex-ME-11/cdmm/myBuild

[dlarue]

While I know 22.04 is the latest LTSP version there's been lots of packages which don't move so fast and it's why I recently moved from 18.04 to 20.04 instead of 22.04. Booting an iso to build or booting a vm isn't so bad, just an annoyance so it seems you have the backend(cdmm) building and since I found the source to the frontend(qtdmm2) I'm going to go back to booting a lubuntu 18.04 iso and seeing if I can build his qtdmm2-0.2.tgz source. I was able to build the cdmm source(0.2) after fixing 4 files and if successful it will prove the client/server version is available.

[dlarue]

I was able to get the QtDMM2 GUI working with cdmm. I didn't try it with your cmake port( the 0.3 version) but since it outputs to the console data like this(see below) it should be a-ok. Currently qtdmm2 spawns a cdmm process and grabs the output/stdio stream for processing. It has no UDP capabilities and only the cdmm-0.4 version of that backend has the UDP option. I've tested that with a python UDP client and it does send the meter output lines(one at a time) on any UDP char sent from the UDP client. But instead of "V0: 124.6 mV AC" which is sent to the console, the UDP stream gets "124.6 V AC" so fixing the GUI is just a bit more than being able to read a UDP stream vs stdout stream.

./cdmm --port=/dev/ttyUSB0 --device="Metex ME-11" --interval=0.2
port = /dev/ttyUSB0
device = Metex ME-11
interval = 0.2
opening: /dev/ttyUSB0:600:7:n:2:DSR:DTR:CTS
V0: -020.2 mV DC
V0: -020.2 mV DC
V0: -020.2 mV DC
V0: -020.8 mV DC

[dlarue]

I recall you mentioning that the cdmm/qtdmm2 stuff was older than the Qt5 stuff but when I looked at the supported DMMs( cdmm -L ) it support lots more than what's shown in the README for the Qt5 version of QtDMM. The output list from cdmm 0.4 is:

./bin$ ./cdmm -L
Digitek DT-9062
Digitech QM-1350
Digitech QM-1538
Digitech QM-1537
ELV M9803R
Escort 95
Escort 97
Fluke 45
IOCB UV Monitor
Iso-Tech IDM73
MASTECH M9803R
MASTECH MAS-345
MASTECH MAS-343
McVoice M-345pro
McVoice M-980T
Metex M-3360D
Metex M-3830D
Metex M-3850D
Metex M-3850M
Metex M-4650CR
Metex M-4660M
Metex M9803R
Metex ME-11
Metex ME-22
Metex ME-32
Metex ME-42
Metex Universal System 9140
Metex Universal System 9160
Metrel MD9015
PeakTech 3330
PeakTech 4010
PeakTech 4360
PeakTech 4390
PeakTech 451
Protek 504
Protek 505
Protek 506
Radioshack 22-805 DMM
Radioshack RS22-168A
Sinometer MAS-343
TekPower TP 4000ZC
UNI-T UT30A
UNI-T UT30E
UNI-T UT60G
UNI-T UT70B
UNI-T UT71A
UNI-T UT71B
UNI-T UT71C
UNI-T UT71D
UNI-T UT71E
Vichy VC99
Vichy VC8145
Voltcraft GDM703
Voltcraft GDM704
Voltcraft GDM705
Voltcraft M-3610D
Voltcraft M-3650D
Voltcraft M-3830
Voltcraft M-3850
Voltcraft M-3860
Voltcraft M-4660
Voltcraft M-4660A
Voltcraft M-4660M
Voltcraft M-465CR
Voltcraft ME-11
Voltcraft ME-22T
Voltcraft ME-32
Voltcraft ME-42
Voltcraft MS-9140
Voltcraft MS-9160
Voltcraft MXD-4660A
Voltcraft VC 630
Voltcraft VC 650
Voltcraft VC 670
Voltcraft VC 635
Voltcraft VC 655
Voltcraft VC 820
Voltcraft VC 840
Voltcraft VC 870
Voltcraft VC 920
Voltcraft VC 940
Voltcraft VC 960

[tuxmaster5000]

Where do you have found the QtDMM2 GUI part?
In tar archive I only found an older release of cdmm

[dlarue]

In qtdmm2-0.2.tgz found http://www.mtoussaint.de/qtdmm2.html#download
in the directory QtDMM2-0.2/qtdmm2/ is where I found it. For some reason he didn't put it in qtdmm2-0.3 download.

It presents a more simplistic GUI without much of the Window decorations and layout of the QtDMM package but does spawn the cdmm server process and uses the stdout stream from it as input to the GUI parts. Matthias had responded to my email and said QtDMM2 was just a prototype and he'd not finished it and didn't expect to do anything with it. Because the GUI part of QtDMM2 doesn't have UDP stream support I couldn't use it for my current project needs, and instead used cdmm along with inotifywait and rsync. Later I wrote a simple python based UDP client to get and display the multimeter data.

[dlarue]

Did you find the GUI sources in the qtdmm2-0.2.tgz archive?

[tuxmaster5000]

Due to lack of time, I have not look into it. But I have it on my "to do" list.

[tuxmaster]

Today I have found time so create the "base" check in https://github.com/tuxmaster/QtDMM2

[tuxmaster]

Now you can build the code, but I can't test the result.

[dlarue]

Do you think it will build with Qt version 5.12.8 ?

I tried changing 5.15 in CMakeLists.txt to 5.12
find_package(Qt5 5.12 COMPONENTS Core Gui Widgets REQUIRED)

and running cmake -B build but got this about not finding Core:

$ cmake -B build
-- The CXX compiler identification is GNU 9.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Creating makefile for QDMM2 0.3.0
-- Using Qt 5.12.8
-- Install binary to /usr/local
-- Configuring done
CMake Error at CMakeLists.txt:69 (target_link_libraries):
Target "QDMM2" links to:

Qt::Core                                                                                                                                                                      

but the target was not found. Possible reasons include:

* There is a typo in the target name.                                                                                                                                         
* A find_package call is missing for an IMPORTED target.                                                                                                                      
* An ALIAS target is missing.                                                                                                                                                 

[tuxmaster]

I think the upstream developers of Qt has changed many thinks in Qt5 line over the time. So I think you will need an newer Qt5 version. You can try an newer from: https://www.qt.io/download-qt-installer

[dlarue]

I'll boot into Lubuntu 22.04 again and see how building and testing goes.

[dlarue]

Booted into Lubuntu 22.04, installed build env, got cmake 2.25 and when it was compiling it threw errors about xpm files having unknown command, 'version' and upon looking at the xpm files they start with the line "version https://git-lfs.github.com/spec/v1"

I could not find an explanation for what that was all about.

[tuxmaster]

Ah, then you git installation is incomplete. You need the git and the git lfs package.
Under Fedora the package is called "git-lfs"

[dlarue]

ah, it's git-lfs on Ubuntu also. Gotta head out for a few hours and not sure if I'll be able to get back to this until tomorrow sometime. But I will get back to it.

[dlarue]

I was able to build them( analog, digital and displayTest ) but had to edit each of the main.cpp.* files because references to local header files were using system references instead of local references( had <....> instead of "...." ).

I changed the digitalapp.cpp and analogapp.cpp so it was loading from ttyUSB0 and the Metex ME-11 device but it didn't seem to connect. I could get cdmm to connect and it was in the local directory... I was surprised it didn't complain about not finding cdmm backend service to start or something but I'm guessing there wasn't much error reporting coded into it.

FWIW, here's my script to build on Lubuntu 22.04:

#!/bin/bash

sudo apt update
sudo apt install -y build-essential libtool autoconf unzip wget libssl-dev git git-lfs
sudo apt clean

cd
version=3.25
build=1
## don't modify from here
mkdir ~/temp
cd ~/temp
wget https://cmake.org/files/v$version/cmake-$version.$build.tar.gz
tar -xzvf cmake-$version.$build.tar.gz
cd cmake-$version.$build/
./bootstrap 
make -j$(nproc)
sudo make install
sudo ln -s /usr/local/bin/cmake /usr/bin/cmake

cd
git clone https://github.com/tuxmaster/QtDMM2
cd QtDMM2/
cmake -B myBuild
cmake --build myBuild/ --parallel $(nproc --all)

[tuxmaster]

On my system no modifications are need. So I think it is an issue with your system.
Reading the gcc manual:
https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
The " will be the correct one for none system headers.
Today I have find out, that some parts of the code are optional. So I have enable it. (See the ReadMe)

[dlarue]

I will have to look at the build system more closely. I have been linking the 3 code files, main.cpp.analog, main.cpp.digital, and main.cpp.displayTest each to main.cpp and running make clean then running the build to make each of the 3 versions. Looking like the build system will do that with directives DIGITAL and DISPLAYTEST.