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

[HKJ]

with TC you can easily do a computer controlled sweep and using math channels make a curve that shows the difference between the reference and a voltmeter.

Yes, that is exactly what I intend to do when I have the 3458A again at my disposal .

Take a look at the "Param sweeper" popup for it. You can also do scripting, but that is not necessary.

[Gertjan]

Take a look at the "Param sweeper" popup for it.

The "Param sweeper" popup is my most used popup. I use it for all kind of curves. Driving generators, power supplies, current sinks etc. Very happy with that popup, thank you for that!


It is a pity that I can not support the older PDVS versions with my driver.
On the other hand, I can understand why Johannes of Wrytech decided to "clean-up" the communication commands. Being backwards compatible from the early PDVS to the PVDS2mini,  it became a bit convoluted. Still, it is a pity when backward compatibility is lost....

Best regards, Gertjan.

[KungFuJosh]

It is a pity that I can not support the older PDVS versions with my driver.
On the other hand, I can understand why Johannes of Wrytech decided to "clean-up" the communication commands. Being backwards compatible from the early PDVS to the PVDS2mini,  it became a bit convoluted. Still, it is a pity when backward compatibility is lost....

In that case, it would be simpler for 2 separate driver files.

[Gulftown]

Thank you HKJ for the quick implementation!
Unfortunately, it seems that the initial command gets parsed correctly, but the AR488Lan driver / GPIB diver is still splitting the command:

Code: [Select]

;; ESP-GPIB: Rx: <HEWLETT-PACKARD,6811A,0,A.00.14> 48 45 57 4C 45 54 54 2D 50 41 43 4B 41 52 44 2C 36 38 31 31 41 2C 30 2C 41 2E 30 30 2E 31 34 0A
;; AR488Lan A:5: Tx <*CLS>
;; ESP-GPIB: Tx: <*CLS.> 2A 43 4C 53 0A
;; Found HP 6811A on AR488Lan A:5
;; HP6811A: Tx <MEAS:VOLT:DC?;:MEAS:VOLT:AC?;:MEAS:CURR:DC?;:MEAS:CURR:AC?;:MEAS:FREQ?;:MEAS:POW?;:MEAS:POW:AC?;:MEAS:POW:AC:APP?;:MEAS:POW:AC:PFAC?>
;; ESP-GPIB: Tx: <MEAS:VOLT:DC?.> 4D 45 41 53 3A 56 4F 4C 54 3A 44 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <-1.51097E-2> 2D 31 2E 35 31 30 39 37 45 2D 32 0A
;; ESP-GPIB: Tx: <:MEAS:VOLT:AC?.> 3A 4D 45 41 53 3A 56 4F 4C 54 3A 41 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <8.31698E-2> 38 2E 33 31 36 39 38 45 2D 32 0A
;; ESP-GPIB: Tx: <:MEAS:CURR:DC?.> 3A 4D 45 41 53 3A 43 55 52 52 3A 44 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <-4.89496E-4> 2D 34 2E 38 39 34 39 36 45 2D 34 0A
;; ESP-GPIB: Tx: <:MEAS:CURR:AC?.> 3A 4D 45 41 53 3A 43 55 52 52 3A 41 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <3.60809E-3> 33 2E 36 30 38 30 39 45 2D 33 0A
;; ESP-GPIB: Tx: <:MEAS:FREQ?.> 3A 4D 45 41 53 3A 46 52 45 51 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <6.00000E+1> 36 2E 30 30 30 30 30 45 2B 31 0A
;; ESP-GPIB: Tx: <:MEAS:POW?.> 3A 4D 45 41 53 3A 50 4F 57 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <7.01771E-6> 37 2E 30 31 37 37 31 45 2D 36 0A
;; ESP-GPIB: Tx: <:MEAS:POW:AC?.> 3A 4D 45 41 53 3A 50 4F 57 3A 41 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <3.75550E-5> 33 2E 37 35 35 35 30 45 2D 35 0A
;; ESP-GPIB: Tx: <:MEAS:POW:AC:APP?.> 3A 4D 45 41 53 3A 50 4F 57 3A 41 43 3A 41 50 50 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <3.00628E-4> 33 2E 30 30 36 32 38 45 2D 34 0A
;; ESP-GPIB: Tx: <:MEAS:POW:AC:PFAC?.> 3A 4D 45 41 53 3A 50 4F 57 3A 41 43 3A 50 46 41 43 3F 0A
;; ESP-GPIB: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; ESP-GPIB: Rx: <1.13244E-1> 31 2E 31 33 32 34 34 45 2D 31 0A
;; HP6811A: Rx <-1.51097E-28.31698E-2-4.89496E-43.60809E-36.00000E+17.01771E-63.75550E-53.00628E-41.13244E-1>
;; HP6811A: Rx as numbers <NaN>
When i send it directly as one string via telnet i get:

Code: [Select]

MEAS:VOLT:DC?;:MEAS:VOLT:AC?;:MEAS:CURR:DC?;:MEAS:CURR:AC?;:MEAS:FREQ?;:MEAS:POW?;:MEAS:POW:AC?;:MEAS:POW:AC:APP?;:MEAS:POW:AC:PFAC?                                                                                                           
++read                                                                                                                 
-1.54987E-2;8.27992E-2;-4.94024E-4;3.59399E-3;6.00000E+1;7.61880E-6;4.36555E-5;3.01366E-4;1.31592E-1 
Best regards

[flash2b]

Why is there a #gpibReadEol and not a #gpibWriteEol ?

My device I work on, using AR488, has a GPIB termination for read and write as a single choice. It is set to EOI, but TC sends a LF + EOI and therefore is not accepted since the LF is also interpreted by the device. For reading it can be changed using #gpibReadEol but for writing there is no command.

I would really like to set the #gpibWriteEol to EOI.

[HKJ]

Thank you HKJ for the quick implementation!
Unfortunately, it seems that the initial command gets parsed correctly, but the AR488Lan driver / GPIB diver is still splitting the command:

What driver do you use: SCPI or SCPIx?

I only implemented it in SCPI, but I am worked on including it SCPIx

The interface drivers do not modify lines, they must support a lot of protocols and modifying anything would be bad.

[HKJ]

Why is there a #gpibReadEol and not a #gpibWriteEol ?

My device I work on, using AR488, has a GPIB termination for read and write as a single choice. It is set to EOI, but TC sends a LF + EOI and therefore is not accepted since the LF is also interpreted by the device. For reading it can be changed using #gpibReadEol but for writing there is no command.

I would really like to set the #gpibWriteEol to EOI.

I will take a look at it.

[HKJ]

Why is there a #gpibReadEol and not a #gpibWriteEol ?

My device I work on, using AR488, has a GPIB termination for read and write as a single choice. It is set to EOI, but TC sends a LF + EOI and therefore is not accepted since the LF is also interpreted by the device. For reading it can be changed using #gpibReadEol but for writing there is no command.

You make be able to change the eol character to something innocent, try:
#eol \_

That will prevent the driver from working with a serial connection and probably also a socket connection, but if the device only support GPIB it is not a issue.

[flash2b]

Set this in the definition:

#eol \_
;#gpibReadEol 10

But it did not work 

Code: [Select]

;; HM8112_1: Tx <txrx? L1
;; COM4: Tx: <++addr 7.> 2B 2B 61 64 64 72 20 37 0A
;; COM4: Tx: <L1.> 4C 31 0A
;; COM4: Tx: <++read_tmo_ms 11950.> 2B 2B 72 65 61 64 5F 74 6D 6F 5F 6D 73 20 31 31 39 35 30 0A
;; COM4: Tx: <++read eoi.> 2B 2B 72 65 61 64 20 65 6F 69 0A
;; COM4: Rx: timeout, in buffer: 2B 30 30 30 30 30 30 31 2E 45 2D 32 56 44 52 35 41 30 54 32 53 30 51 30 4D 4F
;; HM8112_1: Rx Timeout

[Gulftown]

Ah perfect, thanks!
The SCPI driver is working correctly.
I think i don't use the extra features of the SCPIx driver anyway in this case.
The new method got my measurement time down to 0.7s from 2.4s per iteration, a massive improvement.

I've attached the defintion of the HP 6811A as well as one for a Gossen Metrahit PM XTRA i did a while ago

[flash2b]

Hi HKJ and others,

I have made a Final Version definition for the for Hameg HM8112-1/HM8112-2 and Prema 4000/5000 System Multimeter.





Since all these meters share the same interface commands it was possible to create one definition to support all these meter models.

Please note that you need to change the Termination mode into <LF> (Mode 3) on the meter to be able to use it in TestController.

I hope that HKJ will add an option in TC to allow gpibWriteEol to a value that support EOI only, just like gpibReadEol. If he does, I will change the definition to use the default instead, so without the need to put the meter into the CAL setting to change it permanently (which is kind of scary).

The definition file is attached below. Just copy it into the $documents\TestController\Devices folder.

Definition is part of the latest version of TestController.

HKJ, please add this 1.00 Final version to the next release of the wonderful TestController !

[csvke]

anyone has any success using Victor 86C? It's listed as a supported Multimeter but all I get after adding the device is

Code: [Select]

;; Found Victor 86C on CP2102 USB to UART Bridge Controller (Dial-In) (tty.usbserial-0001)
;; V86C: Rx as numbers <No data (timeout?)>
;; V86C: Rx as numbers <No data (timeout?)>
;; V86C: Rx as numbers <No data (timeout?)>
I suspect it could be a clone of Victor 86C so I use CoolTerm to look at the raw data of the serial data. Unlike what Sigrok suggests the Victor protocol being a payload of 14 byte data protocol, I think I am seeing a 5-byte payload pattern when dumping the hex of the data with a

Code: [Select]

FF byte being the separator or padding byte.

Here is the hex data.

Code: [Select]

22 6B 22 02 02
22 6A 22 02 82
22 62 22 02 02
22 62 22 02 06
22 E6 22 02 82
22 66 22 02 02
22 66 22 02 82
22 E6 22 02 02
22 66 22 02 02
22 66 22 02 02
I am very new to this wonderful software and in my use case I would like to use multiple measurements tools for testing. I have a Riden RD6006 bench power supply that works well with TestController but I need an inexpensive multimeter that can cover the µA range. It's a bit wasteful to sweep aside this Victor 86C multimeter, but my trusted UNI-T U61E+ doesn't seem to support TestController.

Any hint of getting this multimeter working with TestController will be appreciated. I have prompted AI and it suggests the following:

This 5-byte repeating pattern is the hallmark of a different multimeter chip, most likely the Fortune Semiconductor FS9721 (or a clone like the Richtek RT9801), which uses a compact 5-byte data packet.

Or any suggestion for a cheap multimeter that can cover the µA range and works out of the box with TestController will be great too.

[Ruprect]

I have never seen an FS9721 chip that uses a 5 byte protocol. Most meters using this chip are 19 or 14 bytes.

Why do you say your UT61E+ isn't supported by TC?
UT61E is listed in supported devices, am sure its the same unit hardware wise.

The logging of this DMM is well understood and documented.

https://github.com/4x1md/ut61e_py

[KungFuJosh]

AI lies and guesses when it doesn't actually know the answer. It's like digital fortune tellers. 🤣

[csvke]

Thanks - I will look into the Victor 86C in details. I just got on to the serial communications of equipments with TC.

As for UNI-T UT61E+, I think it appears to be a HID device, so TC do not support it, am I correct to say that?

[Ruprect]

According to this page it should come up as a COM port


https://www.hw2sw.com/2012/08/30/uni-t-ut61e-data-logging-programs/#more-4591

You might need the correct driver

[HKJ]

Ah perfect, thanks!
The SCPI driver is working correctly.
I think i don't use the extra features of the SCPIx driver anyway in this case.
The new method got my measurement time down to 0.7s from 2.4s per iteration, a massive improvement.

I've attached the defintion of the HP 6811A as well as one for a Gossen Metrahit PM XTRA i did a while ago

I have added them, thanks.

[HKJ]

I have made a Final Version definition for the for Hameg HM8112-1/HM8112-2 and Prema 4000/5000 System Multimeter.

It will be included, thanks.

[HKJ]

anyone has any success using Victor 86C? It's listed as a supported Multimeter but all I get after adding the device is

It might be one of the meters that is included because somebody listen it as the same as another meter, i.e. it has never been tested.

A 5 byte message looks rather short.

TC includes a driver for defining your own multimeter: https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html#Binary_DMM_protocol
But it requires you have some idea of the actual data format (Most of it can be guessed if you have the correct byte stream, but it is faster if you have some documentation).

[HKJ]

As for UNI-T UT61E+, I think it appears to be a HID device, so TC do not support it, am I correct to say that?

The interface on the meter is serial, but the cable has a chip that converts it to USB-serial or USB-HID.

Uni T has a couple of different cables, some present them self as serial ports other as HID devices. The original UT61E used a serial cable, I believe most if not all never UNI-T meters use HID.

[Ruprect]

Digitech QM1571 device file attached. Tested with said meter but according to other script files, may also work with:

Altronics Q1079,
DT4000ZC,
Harbor Freight 98674,
Mastech MS8229,
PCE-DM32,
Tecpel DMM-8061,
Tecpel DMM-8061,
Tenma 72-7745,
TP4000ZC,
UT60A,
UT60E,
Vichy VC97,
Voltcraft MT-52,
Voltcraft VC-820,
Voltcraft VC-840

[Gulftown]

I also got a working definition for a Voltcraft VC 870.
The original cable is a USB-HID based one, so it won't work with test controller.
But i think the cable from the other Voltcraft multimeters should work just fine.
I like my meters to be in the network for remote measurements so i use an IR phototransistor and an ESP8266 as a bridge.
The multimeter uses 9600 baud and a standard serial interface, so its pretty easy to implement.
I attached the code for the esp8266 and uploaded my case here:
https://www.thingiverse.com/thing:7124615

[HKJ]

Digitech QM1571 device file attached. Tested with said meter but according to other script files, may also work with:

Thanks, I have added it.

[HKJ]

I also got a working definition for a Voltcraft VC 870.
The original cable is a USB-HID based one, so it won't work with test controller.
But i think the cable from the other Voltcraft multimeters should work just fine.
I like my meters to be in the network for remote measurements so i use an IR phototransistor and an ESP8266 as a bridge.
The multimeter uses 9600 baud and a standard serial interface, so its pretty easy to implement.
I attached the code for the esp8266 and uploaded my case here:
https://www.thingiverse.com/thing:7124615

Thanks, could you post a pair of pictures of your interface, both open and close. That would look nice on my user project page.

[Gulftown]

It's no the prettiest thing, but its reliable.
I used a generic ir phototransistor with a 1k pullup, a USB cable for the supply with a MCP1700 LDO and a 10uF tantalum capacitor.