Program that can log/control many multimeters and other devices.

[hp3310a]

So I wanted to try out TestController (downloaded today from https://lygte-info.dk/pic/Projects/TestController/TestController.zip) but my macOS virus scanner (BitDefender) tells me "TestController.jar" contains malware called "Trojan.GenericKD.76162847". What now?

[TicoRussell]

Currently I am not able to have TestController to bound to my Brymen BM869s; anyway my adapter has been modified see
https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg5864597/#msg5864597
I would apreciate, if you own a BM869s, you try to bound and report the result.
Thank you

I recently started using the Test Controller program because the Brymen Bs86x Data Logging System Ver 6.0.0.3s spontaneously stops logging data at random times.

The Test Controller program has been working great so far. Because I am so satisfied with the stability I want to start using it for temperature measurements as well. Logging 1 thermocouple (T1) works fine but unfortunately I have not yet been able to log T2 as well.

[pdks]

Does it still work? I'll try it in my free time. thanks 

[HKJ]

So I wanted to try out TestController (downloaded today from https://lygte-info.dk/pic/Projects/TestController/TestController.zip) but my macOS virus scanner (BitDefender) tells me "TestController.jar" contains malware called "Trojan.GenericKD.76162847". What now?

I guess it is a false positive, TC has not been near a MAC when I work with it.
TC do not contains much native code, it is written in Java and only the serial interface uses small bits of native code supplied by jSerialComm.

[HKJ]

I recently started using the Test Controller program because the Brymen Bs86x Data Logging System Ver 6.0.0.3s spontaneously stops logging data at random times.

The Test Controller program has been working great so far. Because I am so satisfied with the stability I want to start using it for temperature measurements as well. Logging 1 thermocouple (T1) works fine but unfortunately I have not yet been able to log T2 as well.

I do only read one value from most DMM's. You can either use two DMM's or you can use a Arduino with another type of thermosensor: https://lygte-info.dk/project/TestControllerArduino2%20UK.html#DS1820_temperature_device

It is possible to make Arduino project with multiple thermosensors.

[TicoRussell]

Thank you very much for the answer, the advice and of course the great program.

[HKJ]

Thank you very much for the answer, the advice and of course the great program.

Note that using the Arduino and a DS1820 temperature sensor will often be more precise than a thermocoupler.
Also, if you are measuring room temperature you might want to check the next project after the DS1820, it will also measure humidity.

[TicoRussell]

I was planning to control a central heating system.
For this I want to measure the supply and return temperature of the system.

[HKJ]

I was planning to control a central heating system.
For this I want to measure the supply and return temperature of the system.

If it is a air system DS1820 is very good if you can put it into the airstream. For a water system where you have to measure surface temperature on pipes it is not as good (Mounting it with copper or alu-tape and covering the sensor with some thermal isolation will improve it).

Thermocoupler has a rather large tolerance, can be as much as 5C when you include the DMM. Remember that the DMM do also have a build-in sensor for zero compensation, that means the DMM must be placed in a stable or very slowly changing temperature to give best precision. https://lygte-info.dk/info/DMMThermocouplers%20UK.html

[Furna]

I recently started using the Test Controller program because the Brymen Bs86x Data Logging System Ver 6.0.0.3s spontaneously stops logging data at random times.

The Test Controller program has been working great so far. Because I am so satisfied with the stability I want to start using it for temperature measurements as well.

What adapter do you have? There are 2 models around:
- old BC-86X
- new BC-86P

It seems there is a problem using the new one.
See https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg5889736/#msg5889736

Thank you

[TicoRussell]

I have the BC-86X adapter.

[Microcheap]

Hi HKJ,

I've been trying to make a definition for a Hantek HDP3323 power supply, this is a re-badged Matrix MPS-3303S (also a GW-Instek GPD-3303S), but Hantek's PSU uses LAN to communicate.
Anyway, I have the base definition file but some query commands doesn't work and I keep getting RX timeout errors from TC (increasing the timeout time didn't solve it). So I used Wireshark to inspect the communication between the power supply and TC and I think the problem is that the PSU is replying these commands without an EOL character.

I've attached the log from wireshark. The power supply is replying the correct value, but it is missing the EOL, so TC can't process it.

I tried to use a #scpiCmd to modify the command, like:

Code: [Select]

#scpiCmd vtest1? txrxnBin? 5 vset1?\n

Not sure if it's right, it kind of worked but the value I am getting is in Hex format and I can't find a way to convert it.

Code: [Select]

Starting
;; jSerialComm version: 2.11.0
;; Start thread for: 192.168.10.185 - Hantek HDP3303
;; 192.168.10.185: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; 192.168.10.185: Rx: <MATRIX,MPS-3303S,V1.1> 4D 41 54 52 49 58 2C 4D 50 53 2D 33 33 30 33 53 2C 56 31 2E 31 0A
;; Found Hantek HDP3303 on 192.168.10.185
vset1:5.2
;; HDP3303: Tx <vset1:5.2>
;; 192.168.10.185: Tx: <vset1:5.2.> 76 73 65 74 31 3A 35 2E 32 0A
vtest1?
;; HDP3303: Tx <vtest1?>
;; HDP3303: Tx <txrxnBin? 5 vset1?\n>
;; 192.168.10.185: Tx: <vset1?.> 76 73 65 74 31 3F 0A
;; 192.168.10.185: Rx: <5.200> 35 2E 32 30 30
;; HDP3303: Rx <206967025205>
;; 206967025205
Is there a better way to make TC recognize these commands or convert the values that I am getting from #scpiCmd?

thx

[gby]

Am I using #cmdDelayTime incorrectly or is it not working properly with #driver SCPIx?

I will have to check it, but you can use the [delay] syntax in the command.

HKJ,

Thanks for the [delay] suggestion.  Putting just 1 mSec of delay between triggering and getting the values seems to have solved the communications/bad data point issue.  I now have
   #askValues REC.TRIG; [1]; REC.DATA?
for the data logging command and it seems to work fine.  Still not sure why #driver ascii works without the delay and #driver SCPIx has issues without delay on the same device.  But, all is working now with just 1 mSec.

As for using #cmdDelayTime with the SCPIx driver, I am guessing it does not get used.  In reading the web documentation pages on the differences between SCPI, SCPIx, and ascii drivers the ascii section lists a bullet point that says
   "It supports slowing down communication with #cmdDelayTime"
Since that bullet point is not listed on the SCPI, SCPIx drivers I am assuming it does not work there.

[HKJ]

Is there a better way to make TC recognize these commands or convert the values that I am getting from #scpiCmd?

Generally SCPI commands must be terminal with CR or LF, but by using the SCPIx driver there is a way around it as your have found out:
The bin function can receive any binary string of fixed length.

But the answer is not ascii formatted it is a binary answer and you have to use scripting to get it into something useful. TC has a long list of functions that can be used for that: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#String_functions
They are place in a :readmath: with the word value as input value, you can find many examples of that in definitions.

[HKJ]

Thanks for the [delay] suggestion.  Putting just 1 mSec of delay between triggering and getting the values seems to have solved the communications/bad data point issue.  I now have
   #askValues REC.TRIG; [1]; REC.DATA?
for the data logging command and it seems to work fine.  Still not sure why #driver ascii works without the delay and #driver SCPIx has issues without delay on the same device.  But, all is working now with just 1 mSec.

One ms is enough to receive the answer from REC.TRIG and because all commands that expect a answer start by flushing the rx buffer, you will not get any extra data now.
Doing it this way there is a slight risk some concurrent commands may fail. TC reserve the communication line one command at a time and if multiple treats are accessing the device you may get the ignore answer in another thread. This is usually only a risk if you use the configuration commands while logging and it is a small risk.

As for using #cmdDelayTime with the SCPIx driver, I am guessing it does not get used.  In reading the web documentation pages on the differences between SCPI, SCPIx, and ascii drivers the ascii section lists a bullet point that says
   "It supports slowing down communication with #cmdDelayTime"
Since that bullet point is not listed on the SCPI, SCPIx drivers I am assuming it does not work there.

At least some of the code is present, I will have to look at it.

[Gertjan]

Hi HKJ,

I wrote a new device configuration file for the Fluke 8845A and 8846A DMMs.


IMG_3016 Fluke 8846A DMM-2000pix.jpg

As reported here the existing device file(s) did not work with DMMs with older firmware. Also it was a skeleton driver, LAN only, without Setup Menus.

This new configuration file supports all 884xA firmware versions. Also it supports all connection options of the 8845A/8846A: LAN, COM and GPIB. There are now full Setup Menu's:


Fluke 884xA v1.0 screenshot DC & dBm menu-1000pix.png

For reading values the FETCH3? command is replaced by READ?, which is supported in all 884xA firmware versions. A further advantage of using READ? is that it functions the same as the READ? command used in HP/Agilent DMMs. This helps to get readings which are more synchronous with other DMMs. Especially important when logging slowly up- or down ramping signals with longer integration times (like 100NPLC).

I also paid extra attention to the NULL (offset) function. When switching on the NULL function, there has to be a reading in the meter buffer. This is the reading that will be subtracted from the following measurements. Now, when switching ON the NULL function, the meter also takes a measurement. So there is always a reading in the buffer for the Math.

This time no frequency response curve, as it is already in your collection .

Please find the definition file here: Fluke8845A-8846A.zip


For people that want to use this definition before it is added to TestController: You have to remove the old drivers "Fluke8845A.txt" and "Fluke8846A.txt" from the main TestController/Devices folder. The usual over-ride function for drivers in Documents/TestController/Devices does not work properly because of the use of #metadefs in this definition.

Regards, Gertjan.

[Furna]

I have programmed a small tool to make the Brymen BC-86X/P adapter for the BM869s DMM available on the network.
However, I can't manage to create a proper configuration file for the TestController. Even after a lot of reading I still don't understand how it all works.
Attached is a screenshot of a test and a ZIP archive with the tool and source code, as well as the configuration file.
Contents of the ZIP archive:
   \Linux 32-bit (LMDE6 Debian 12)
   \Linux 64-bit (Ubuntu 20.04)
   \PureBasic-Project (6.21b7)
   \Raspberry PI OS 64-bit
   \Windows 32-bit (Windows 7)
   \Windows 64-bit (Windows 7)
   BrymenHIDtoLAN.txt
   
With the Raspberry PI I was only able to use several adapters at times, after a short time there is an error and an adapter can no longer be addressed. In particular, an old BC-86X and a new BC-86P do not work at the same time for me.

The tool is written in PureBasic. I pasted most of the code from another project, only parts that were necessary.
So there is partly too much code, and on the other hand procedures for the HID and libusb libraries are missing.
The tool uses the existing hid.dll under Windows and the existing libusb-1 library under Linux.

Maybe someone has a use for the tool and can create a better configuration file and possibly a script for logging.

The tool only recognizes the following commands:
*IDN?
A? MV,MU,SV,SU

At the beginning, the displayed name from the list of adapters must be specified, e.g. A, B, C, etc.
This is followed by one or more parameters that are read in:
Main value: MV
Main unit: MU
Second value: SV
Second unit: SU

If a value cannot be read in, -999999 is sent instead.

Example:
   A? MV -> 22.3
   B? MV,SV -> 22.3;25.4
   C? MV,MU,SV,SU -> 22.3;°C;25.4;°C
   D? MV,MU,SV,SU -> 22.3;°C;-999999;°C

Peter

Thank you Peter for the software and the source code!

I am running it in Win11 and it is working reliably since about 1 hour.
I understand you have at least 4 adapters; unfortunately, I just have one adapter.

While I undesrtand you want use with multiple adapters, I would concentrate on a single adapter setup.
This should open the opportunity to re-use the already available TC device file.

I will evaluate to buy the PureBasic compiler, I looked at the website and it seems there is no "trial" version?
EDIT: there is a "free" version for "small" programs ...
I didn't download it yet ...

Thank you again!

[HKJ]

I have programmed a small tool to make the Brymen BC-86X/P adapter for the BM869s DMM available on the network.
However, I can't manage to create a proper configuration file for the TestController. Even after a lot of reading I still don't understand how it all works.

Interesting idea, you will have one limit with TC: The port is fixed, you cannot have multiple meters on different ports at the same IP address (except if you make multiple drivers).
If you have specific questions about how to write a TC driver I can help you.

[HKJ]

I wrote a new device configuration file for the Fluke 8845A and 8846A DMMs.

Thanks, I will include it.
Sadly both my 8846A have died and I cannot use it myself.

[KungFuJosh]

I wrote a new device configuration file for the Fluke 8845A and 8846A DMMs.

Thanks, I will include it.
Sadly both my 8846A have died and I cannot use it myself.

Fix them!

[Gertjan]

Sadly both my 8846A have died and I cannot use it myself.

Hi HKJ,
Sorry to hear about your 8846A's...
Did they just had too dim / burned out displays, or did you encounter a weakness in these meters we can look out for?

Regards, Gertjan.

[HKJ]

Sorry to hear about your 8846A's...
Did they just had too dim / burned out displays, or did you encounter a weakness in these meters we can look out for?

The first looks like it have trouble communicating between frontend and backend, the second one just went black. They are not that old, probably around 10 years and have been connected to power all the time).

I have a lot of other bench DMM's (Two Keithleys and two Keysights on the bench and a couple of other elsewhere), so I do not prioritize fixing them.

[dmenezes]

(...)
Secondly, I would like to make a humble suggestion: could you please change TC to ignore lines beginning with "#" when importing CSV fles?
(...)

Good idea, I will look at it.

Thank you so much! That will help a lot with my daily TC usage.

One last question, if I may: do you publish a changelog or similar anywhere? If so, please tell me where so I can monitor it for that (and possibly other) changes.

TIA!

[HKJ]

One last question, if I may: do you publish a changelog or similar anywhere? If so, please tell me where so I can monitor it for that (and possibly other) changes.

Sort of.
In this thread I publish the actual part of the changelog everytime I publish a new update.
When you start a old version of TC it will download a full changelog (From V0.74) and you can view it

If TC has internet connection it will always check for a new version and if one is found show a button to access the changelog. It is very visible, but it is designed not to interfere with the usage of TC. I.e. you do not need to update, but can see that a new version is available. 

[Gertjan]

Hi HKJ,

A feature request: “Memory Curve” or “Reference Curve” in the Chart.

Often one wants to compare a measurement with a previous one.
Or you want to plot variations in a setup/schematic.

It would be very handy if one could select a curve to become persistent, so it stays in the graph as a reference when doing the next measurement.

Most oscilloscopes and analysers are having this functionality. It would be very nice and time saving to have this functionality in TestController!
Now I have to import the tables of the measurements in Excel, and combine them to make the combined graph...

I suppose it would be something like copying the selected column in the table to memory, and (in the background) adding this column to the table of the next measurement for the graph.

Regards, Gertjan.