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!
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.
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.
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.
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.
Original: Does not work: Right way: | ":write: OUTP" ":write: OUTP;[20]" ":write: OUTP (value);[20]" |
The 34401A and E3632A are finally working flawless via RS232.
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.
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.
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.
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.
Here are three updated definitions.
I added a few math functions to the HP / Agilent 3458A setup menu. (I needed the NULL / offset function):
Also I found a small bug in this definition. Checking my other definitions, I also found this small bug in the Racal-Dana counter definitions. So I updated those too.
I wrote a device definition file for the Rigol DG1000Z series ARB Generators (DG1022Z, DG1032Z and DG1062Z)
V2.44 is up
Changed: Scales for chart uses SI prefix in numbers.