Program that can log from many multimeters.

[HKJ]

Hello again!

It seems to work now, thanks! I modded the already existing file and added a changelog. Continuity is now an option too (strangely the meter returns values in volts rather than ohms).

Best wishes!

Replace these two lines:
#value VoltageDC V D4 VDC, VACDC, DIODE

#value Resistance OHMS si OHMS, CONT

and report back.

[Messtechniker]

Found a bit of annoyance.
In the window "Scales for chart" and in "Maximum", the entered value there is only visibly retained provided 8 digits after the decimal point is not exceeded.

When entering more than 8 digits after the decimal point "0" is always displayed. But even so, an entered value having 11 digits after the decimal, for example, is honoured in the "Chart" window.

This came to light when measuring small capacitances of around 4 pF. Here "Auto" scaling does not work, so that the maximum chart value needs to be entered manually. 11 digits after the decimal points are needed in my case (UT622E) to display the 1 to 10 pF range, for example.

Multiplying such a small value - 4 pF - by 1000, for example, won't work.
Averaging will obviously not work too. But the graph can be readied to show averaged values in the pF range.

[kblue]

Hello again!

These changes do not work, still reporting in "voltages". Even in the manual (and on the display) the value is reported in "voltage" rather than "ohms". So i guess it works as intended, just some oddity with this meter.

[bdunham7]

Does anyone have a Fluke 45 working properly with TestController?  I'm trying to connect one now and not having any luck.

I set the meter for 9600 N 8 1 and connected to a terminal program and in response to *IDN? I get "Fluke, 45, (and them more stuff)".  When I try to load it in TestController, I get the response that there isn't a match to ID Fluke, 45,  .  The response I get is exactly as specified in the ID string in the configuration file supplied, written by author Bad Drive in Nov 2020.

Any clues appreciated.

Edit:  Got it!  In case anyone else has this issue I'll leave the post.  The issue was that you have to set the meter configuration to Echo = OFF.   

[the Chris]

With the 34401A attached via RS232, starting TC normally and opening the setup causes an ERROR 101 on the Agilent and the setup dialog box to remain unfilled.

However, starting TC via debug mode and opening the setup causes no error and the dialog box to be filled successfully.

Could this behavior be timing related?

This is currently on Windows 7 32-bit using a full-handshake serial cable as I wanted to exclude any causes by serial handshake errors.

[HKJ]

Found a bit of annoyance.
In the window "Scales for chart" and in "Maximum", the entered value there is only visibly retained provided 8 digits after the decimal point is not exceeded.

When entering more than 8 digits after the decimal point "0" is always displayed. But even so, an entered value having 11 digits after the decimal, for example, is honoured in the "Chart" window.

This came to light when measuring small capacitances of around 4 pF. Here "Auto" scaling does not work, so that the maximum chart value needs to be entered manually. 11 digits after the decimal points are needed in my case (UT622E) to display the 1 to 10 pF range, for example.

Multiplying such a small value - 4 pF - by 1000, for example, won't work.
Averaging will obviously not work too. But the graph can be readied to show averaged values in the pF range.

I have been thinking about it, I may consider lowering the clamp level a bit. It is used to avoid near zero values where a null is supposed to show.

[HKJ]

Does anyone have a Fluke 45 working properly with TestController?  I'm trying to connect one now and not having any luck.

I set the meter for 9600 N 8 1 and connected to a terminal program and in response to *IDN? I get "Fluke, 45, (and them more stuff)".  When I try to load it in TestController, I get the response that there isn't a match to ID Fluke, 45,  .  The response I get is exactly as specified in the ID string in the configuration file supplied, written by author Bad Drive in Nov 2020.

Any clues appreciated.

Edit:  Got it!  In case anyone else has this issue I'll leave the post.  The issue was that you have to set the meter configuration to Echo = OFF.   

To hopefully avoid this in the future I have added a note to the Fluke 45 definition saying echo must be off.

[HKJ]

With the 34401A attached via RS232, starting TC normally and opening the setup causes an ERROR 101 on the Agilent and the setup dialog box to remain unfilled.

However, starting TC via debug mode and opening the setup causes no error and the dialog box to be filled successfully.

Could this behavior be timing related?

This is currently on Windows 7 32-bit using a full-handshake serial cable as I wanted to exclude any causes by serial handshake errors.

This do sound like a timing problem, I wonder why the handshake do not work. You can add [xx] (where xx is a time in ms) after the commands to probably get around it.

[Messtechniker]

Found a bit of annoyance.
In the window "Scales for chart" and in "Maximum", the entered value there is only visibly retained provided 8 digits after the decimal point is not exceeded.

When entering more than 8 digits after the decimal point "0" is always displayed. But even so, an entered value having 11 digits after the decimal, for example, is honoured in the "Chart" window.

This came to light when measuring small capacitances of around 4 pF. Here "Auto" scaling does not work, so that the maximum chart value needs to be entered manually. 11 digits after the decimal points are needed in my case (UT622E) to display the 1 to 10 pF range, for example.

Multiplying such a small value - 4 pF - by 1000, for example, won't work.
Averaging will obviously not work too. But the graph can be readied to show averaged values in the pF range.

I have been thinking about it, I may consider lowering the clamp level a bit. It is used to avoid near zero values where a null is supposed to show.

Maybe leave the default at 8 decimal places. But with the option of say 12 decimal places selectable for a specific case.

[HKJ]

Maybe leave the default at 8 decimal places. But with the option of say 12 decimal places selectable for a specific case.

Another option is to display it as SI values (i.e. with Mkm... etc.) prefix, then you will not get more digits (this depends on actual SI format used https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Data_type_definitions, something like SI10p may work nicely), but you will get greater range for low values.

[the Chris]

The 34401A and E3632A are finally working flawless via RS232. I've been troubleshooting various errors for hours until I found out that in the end, two problems were interfering with each other. As these were immanent at two very differently spec'd computers, two OS (Linux and Win7) and with two different cables, I guess others might have the same issues, which is why I include my working device files.

Details regarding the issues found:

1. For communication via RS232, all commands need a delay. For the E3632A, 20ms is needed for a continuously flawless operation. For the 34401A, 10ms seems to work reliable if operated alone or in combination with just one E3632A. If operated together with two E3632A, a reliable continuous readout of values requires 20ms as well. The config files therefore are set to 20ms for both devices. The SAVe and ReCaL procedures on the E3632A require more time, which is why they are set to 200ms. It might be that the time can be shortened further, but 100ms did not work out and as I do not regard that procedure time-critical, I just played save and left it at 200ms that worked.

2. Some commands defined in the device files are transmitted with a trailing value. In cases where these commands are defined as single commands (i.e. without a second command in direct sequence), the definition contains just the command without any further trailing addition. In cases of a definition that contains two commands in one single sequence in which at least the first requires a value to be inserted, there is a placeholder in-between for the position of the value within the sequence. The placeholder is called "(value)". If one now adds a delay in form of [20] to a single command, is necessary to insert the "(value)" placeholder after the command before finishing it with "," and adding the delay [20] afterwards. Otherwise, TC will transmit the command without a value and then transmit the delay as a second sequence via RS232, leading to errors on the device.

Example for case No. 2:

Original: Does not work: Right way:

":write: OUTP" ":write: OUTP;[20]" ":write: OUTP (value);[20]"

One should be aware that the debug mode slows the operation of TC down so that seemingly working delay timings found while testing them in debug mode can cause errors in non-debug mode.

Best wishes,
Christian

[the Chris]

Not to cause a mix-up with my previous post, here are the same files but with the added functionality to be able to switch the display off and on again on the 34401A and the E3632A.

Long life the VFD!

[HKJ]

The 34401A and E3632A are finally working flawless via RS232.

I will replace the definitions with your updated version in the next release, thanks.

2. Some commands defined in the device files are transmitted with a trailing value. In cases where these commands are defined as single commands (i.e. without a second command in direct sequence), the definition contains just the command without any further trailing addition. In cases of a definition that contains two commands in one single sequence in which at least the first requires a value to be inserted, there is a placeholder in-between for the position of the value within the sequence. The placeholder is called "(value)". If one now adds a delay in form of [20] to a single command, is necessary to insert the "(value)" placeholder after the command before finishing it with "," and adding the delay [20] afterwards. Otherwise, TC will transmit the command without a value and then transmit the delay as a second sequence via RS232, leading to errors on the device.

Example for case No. 2:

Original: Does not work: Right way:

":write: OUTP" ":write: OUTP;[20]" ":write: OUTP (value);[20]"

You are correct in this. The full line is processed for adding the value, later in the process the line is split on ; and each item is transmitted, except for a few virtual commands (Like [20])
Also note that not all drivers work the same way.

One should be aware that the debug mode slows the operation of TC down so that seemingly working delay timings found while testing them in debug mode can cause errors in non-debug mode.

It does, even though I have tried to minimize it.

[Pukker]

Made some modifications in my Powersupply-Test and Battery-Test scripts.
No spectaculair changes, but added some checks.
Removed some small faillures.
Changed information in command window after finishing tests.

[Gulftown]

Hello,

i found an error in the RND KEL103v2 definition.
When i tried to use the Battery Mode, TestController did not update the values, because a part of the parameters was missing in the UDP transmission.
I fixed it and the battery settings are working flawlessly now.

[Pukker]

PowerSupply Test script with making BurnIn test after testing Voltage and Current depedence.
Test can be started with an Internal Resistance check.
See the graph.
First Internal resistance check.
Then Voltage - Current test.
Then BurnIn test.
In Result in Command Window.txt the results in Testcontroller Command Window.