V0.17 is uploaded, it hopefully fixes the problems. I found a deadlock in the code and I reinitalized most of the user interface for each sample, this is fixed now. Logging with the 3 virtual generators at 0.01s sample interval and the chart page visible shows a total CPU usage of 3% on my machine (Nearly everything else is minimized)
Some troubles with AC voltage measurements, including period and frequency. The software switches to the mode ok and the current values tab reflects the mode change, but the data doesn’t update on the current values table rather the data is ouput to the commands log window.
Outputting a 50Hz triangle wave. Log window shows that the program does read the values from the meter.
First I manually read the value from the meter and then switch to the current values tab, which isn’t updating.
First is period (20ms), then frequency (50Hz), then AC voltage (0.29V), which are correctly shown here in the log.
But all the realtime readings are zero.
When it gets extra measurements they will be put into the log window. It may be due to a timeout on reading the data or because it receives two lines of data.
You can change the timeout with (Default is 1 second):
#readingDelay 5
#modeChangeDelay 10
That seems to have helped. Every mode looks to be working now!
Here’s a link to my current config file for the 34401A: HKJ TestController HP/Agilent 34401A configuration file - Pastebin.com
I could possibly shorten the delays some, but it’s not too slow as it is.
Would it be difficult to add a popup button for zeroing out the meter? It needs the following commands:
calc:func null
calc:state on
Sometimes I have to start the program a couple of times (2-4) before the meter is initialized at startup.
I’m liking the math function too. Easy to filter out some noise from a current probe.
Just before sending the *idn? command I send a CR LF to be sure any half received commands are cleared, maybe that is the problem. I have build a JAR file without that CR LF you can try: http://lygte-info.dk/pic/Projects/TestController/TestController.jar
For other commands it is bet to use the “Setup” menu, try adding this to the definition:
#cmdSetup button Zero
:write: calc:func null;calc:state on
:tip: Zero the reading
The “button” is the control type, that are many different controls depending on application.
The words between colons are tags with special meaning, there are a couple of different types.
#cmdMode are designed for changing modes, this means changing the result type and they are blocked while logging.
#cmdSetup are designed to change parameters and they can be used while logging. They are also much much more flexible.
Something like this:
Is done with #cmdSetup
That didn’t help for the startup problem.
I made a config file for the Rigol DP811A bench PSU and it’s working fine. There’s just one issue. The PSU has two ranges 20V/10A and 40V/5A. The range is switched with the following command and the setup popup works fine for switching:
:OUTPUT:RANGE LOW
:OUTPUT:RANGE HIGH
But when you query the status with :OUTPUT:RANGE? It replies with 20V/10A or 40V/5A, not LOW or HIGH.
How do I make the UI reflect the status of the range when the commands to set it and what the PSU replies are different?
This is what I currently have:
#cmdSetup radio Range
:read: :OUTPUT:RANGE?
:readFormat:
:write: :OUTPUT:RANGE
:update: Output
20V_10A LOW
40V_5A HIGH
Link to the setup file: TestController Rigol DP811A setup file - Pastebin.com
Sad. I have been thinking about how to make the startup better, my idea now is to first send a *idn? and if I do not receive and answer, then wait maybe half a second and try once more. But I will first look at at tomorrow.
That was fast you got that working. You can make more pages in the the setup menu by adding a parameter more to the #cmdSetup, that will be used as a page name. This way you can move the over—- to another page and make it a bit simpler to look at.
For you problem you need some programming, it can be done with:
index=listIndex(value,“20V/10A 40V/5A”,” “);
getElement(”LOW HIGH”,index,” “);
This is packed into this:
:readmath: getElement(“LOW HIGH”,listIndex(value,“20V/10A 40V/5A”,” “),” “);
And just a note:
You can test these expressions on the command line, just stick a = before the expression and replace value with the input value in quotes.
Also be aware that the forum modifies the quotes, they are all the standard double quote, not the opening/closing types that the forum replaces it with.
This doesn’t seem to be working. Similar behavior as without the readmath. Switching works but the UI can’t read the status.
#cmdSetup radio Range
:read: :OUTPUT:RANGE?
:readFormat:
:readmath: getElement(“LOW HIGH”,listIndex(value,“20V/10A 40V/5A”," “),” ")
:write: :OUTPUT:RANGE
:update: Output
20V_10A LOW
40V_5A HIGH
Sorry for bombing you with questions.
I’d like to integrate power over time (Wh). I assume this is the way to configure this from the Math page:
It seems to work for the Current values:
But not when logging:
I wonder about that Math problem, but I did miss a reset of the sum when starting logging and now I have also added code to ignore overflow values. I hope it helps.
I have not explanation on why the translation does not work, I am missing some more detailed debug information. For this reason I have added a debug setting. On the command line use:
#debug device item
Use “#debug device” to get a list of possible items and their current state.
The debug state for the setup menu will be set when opening the menu and can first change next time the “Setup” button is pressed.
I have modified the initial *idn? as I described above.
Use the link from post #46 to download V0.19
I will like to include both your definitions in the software, but I will prefer to wait until you are finished with them.
This is after opening the setup menu:
#debug dp811a otherComm
;; DP811A: Tx <:VOLT?>
;; DP811A: Rx <5.000>
;; DP811A: Rx as number <5.0>
;; DP811A: Tx <:CURRENT?>
;; DP811A: Rx <1.0000>
;; DP811A: Rx as number <1.0>
;; DP811A: Tx <:OUTPUT:RANGE?>
;; DP811A: Rx <40V/5A>
;; DP811A: Rx after :readmath:
;; DP811A: Rx as number
;; DP811A: Tx <:OUTPUT?>
;; DP811A: Rx
;; DP811A: Rx as number
;; DP811A: Cache Tx: <:VOLT?> Rx: <5.000>
;; DP811A: Rx as number <5.0>
;; DP811A: Cache Tx: <:CURRENT?> Rx: <1.0000>
;; DP811A: Rx as number <1.0>
;; DP811A: Tx <:VOLT:PROT?>
;; DP811A: Rx <12.000>
;; DP811A: Rx as number <12.0>
;; DP811A: Tx <:CURRENT:PROT?>
;; DP811A: Rx <1.2000>
;; DP811A: Rx as number <1.2>
Here I switch the range from HIGH to LOW:
;; DP811A: Tx <:OUTPUT:RANGE LOW>
;; DP811A: Tx <:OUTPUT:RANGE?>
;; DP811A: Rx <20V/10A>
;; DP811A: Rx after :readmath:
;; DP811A: Rx as number
;; DP811A: Tx <:OUTPUT?>
;; DP811A: Rx
;; DP811A: Rx as number
Wh math works now. The startup behavior didn’t change for me. Rigol is always detected, 34401A often not.
I have added a “#debug *idn” domain to capture initial behaviour and data, it works the same way as for devices. I have also added code to strip any spurious control characters received during initialization.
It is now possible to add a :string: tag to your definition, place it on the line below :write:
This tag is only support for: radio, checkbox, buttonson
Use the link from post #46 to download V0.20
Reading the range works now!
#debug *idn serial
#debug *idn socket
;; 192.168.0.119: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; 192.168.0.119: Rx: 52 49 47 4F 4C 20 54 45 43 48 4E 4F 4C 4F 47 49 45 53 2C 44 50 38 31 31 41 2C 44 50 38 44 31 39 31 30 30 30 30 34 30 2C 30 30 2E 30 31 2E 31 36
;; Found Rigol DP811A on 192.168.0.119 sn: DP8D191000040
;; COM8: Set params: 9600
;; COM8: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; COM8: Rx: timeout
edit: I don’t seem to be able to reconnect again to the Agilent if I try to reconnect from the load devices page even if the program detects the device in startup.
edit2: putting #port com8 in the config file seems to fix the issue, but it still doesn’t work every time I start the program
#debug *idn serial
#debug *idn socket
;; 192.168.0.119: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; 192.168.0.119: Rx: 52 49 47 4F 4C 20 54 45 43 48 4E 4F 4C 4F 47 49 45 53 2C 44 50 38 31 31 41 2C 44 50 38 44 31 39 31 30 30 30 30 34 30 2C 30 30 2E 30 31 2E 31 36
;; Found Rigol DP811A on 192.168.0.119 sn: DP8D191000040
;; COM8: Tx: <*IDN?.> 2A 49 44 4E 3F 0A
;; COM8: Tx: 48 45 57 4C 45 54 54 2D 50 41 43 4B 41 52 44 2C 33 34 34 30 31 41 2C 30 2C 31 31 2D 35 2D 32
;; COM8: Tx: <:SYSTEM:REMOTE.> 3A 53 59 53 54 45 4D 3A 52 45 4D 4F 54 45 0A
;; Found Agilent HP34401A on 19H2KP0 (COM8)
Next update, now it will ask twice.
With the #debug you can do:
#debug *idn serial socket
Same goes for devices
You can also use:
#debug *idn -serial -socket
To turn debug off again
I have now started the program 10 times and it has always found the DMM. And then on the 11th try it failed 
But it seems quite a bit more reliable. I’m not sure if it’s because of my USB-RS232 adapter. Don’t have another to test.
I noticed that the program always saves its settings in C:\Documents\TestController\Settings regardless where the actual program is stored. It would be useful to save them to the same directory as the program for portability.
I can delay the second try a bit more. I have change it from 500ms to 700ms.
It uses the document directory for the current user. Storing it at the program location will fail if you put it in the Windows program directories.
I will probably add a command line options that can specify the current working directory.
Another detail: you multimeter definition is for Agilent, I expect that is because you have a Agilent name on the meter. It would be nice to also have this definition with a HP name and it is very easy to do:
Just add these lines to the start of your definition:
#metadef
#metadef
#name Hewlett-Packard HP34401A
#meta
The #meta tag says the following definition must not be used directly for a device. It is required when having #metadef in the same file.
#metadef source name
Takes a existing definition and modifies it, it can do a couple of operations, see the IT85xx definition for examples. Empty source name means use the current file.
Seems to have fixed it!