Program that can log from many multimeters.

[bateau020]

Some feedback:

[000] does not seem to work. Tried various forms.

About a cmd control driving a selector:

* one can debug the value sent to the selector but entering displayVar({page}.{control name}) instead of {page}.{control name}, on the "expression" line, the line just under the #cmdSetup.
* other functions like getExpression or match do not work there. They work in other situations, but cannot read from another control.
* :readmath: on the next line does not work

About the types of controls that drive the selector:
* combobox works as it should. Unfortunately for my use case, it is 3 clicks.
* checkbox sends "{text behind the checkbox}:{undefined number of spaces}{selected value}" to the selector, but that cannot be exploited since I do not have access to functions like match. No matter if :string: is added. The control does send the selected data via :write:
* comboboxhot sends "0" to the selector, no matter the selection. Otherwise, same as checkbox.
* radio sends "0" to the selector, no matter the selection. Otherwise, same as checkbox.
* slider sends nothing or empty string to the selector, no matter the selection Otherwise, same as checkbox.
* buttons sends nothing or empty string to the selector, no matter the selection. Otherwise, same as checkbox.

Can you look into this? It is not a blocker since combobox works, but it reeks like a (series of) bug(s) to me.

And moving it to the Mode popup would require even more clicks. So for now, I'm just keeping the device file roughly unchanged. Cleaned up slightly, and attached.

[TheDefpom]

In regards to the E5810A.

I have been playing around with it the past couple of days, I can talk to instruments using Python making use of the vxi11 system to specify the device by GPIB address, so if you can support vxi11 (if you don't already) that might mean that it can be used for a bunch of GPIB adaptors, as it seems pretty common.

For instance in Python I am making use of code written by Marco Reps as shown below to define the vxi11 address:

Code: [Select]

vxi_ip = "192.168.5.150"

instruments["R6581T"]=R6581T(ip=vxi_ip, gpib_address=22, lock=gpiblock, title="R6581T")
Which seems to indicate all it needs to know is the IP of the GPIB controller, and the GPIB address of the instrument.
The actual code to talk to the instrument is simple, such as:

Code: [Select]

self.instr =  vxi11.Instrument(self.ip, "gpib0,"+str(self.gpib_address))
self.instr.clear()
print("*IDN? -> "+self.instr.ask("*IDN?"))
print("TEMP? -> "+str(float(self.instr.ask(":SENSe:ITEMperature?")))+"˚C")
self.close_instr_conn()

[HKJ]

[000] does not seem to work. Tried various forms.

Ok.

About a cmd control driving a selector:

* one can debug the value sent to the selector but entering displayVar({page}.{control name}) instead of {page}.{control name}, on the "expression" line, the line just under the #cmdSetup.
* other functions like getExpression or match do not work there. They work in other situations, but cannot read from another control.
* :readmath: on the next line does not work

The expression line is similar to :readmath:, it uses the same code to evaluate the expression.
Try using: displayVar(split(getVarList(1),"[\\n]")); on it. It will give you an error and prevent the selector from working, but will also show your all defined variables and their values.

About the types of controls that drive the selector:
* combobox works as it should. Unfortunately for my use case, it is 3 clicks.
* checkbox sends "{text behind the checkbox}:{undefined number of spaces}{selected value}" to the selector, but that cannot be exploited since I do not have access to functions like match. No matter if :string: is added. The control does send the selected data via :write:
* comboboxhot sends "0" to the selector, no matter the selection. Otherwise, same as checkbox.
* radio sends "0" to the selector, no matter the selection. Otherwise, same as checkbox.
* slider sends nothing or empty string to the selector, no matter the selection Otherwise, same as checkbox.
* buttons sends nothing or empty string to the selector, no matter the selection. Otherwise, same as checkbox.

Can you look into this? It is not a blocker since combobox works, but it reeks like a (series of) bug(s) to me.

It is not really bugs, but I will guess you are missing a :read: on the control. On most controls the variable will be updated when a value is returned from the device.

You can get around that by using #scpiCmd (Driver must be SCPIx) and a local variable:

#scpiCmd init none
:setvar: varf1=0;

#scpiCmd f1 none (value)
:setvar: varf1=inputValue;

#scpiCmd f1? none?
:readmath: varf1;

#initCmd init;

#cmdSetup checkbox check
:read: f1?
:write: f1
on 0 1

[HKJ]

I have been playing around with it the past couple of days, I can talk to instruments using Python making use of the vxi11 system to specify the device by GPIB address, so if you can support vxi11 (if you don't already) that might mean that it can be used for a bunch of GPIB adaptors, as it seems pretty common.

I do use vxi11 when selecting lxi as comm interface, but I do not have any port specifications to use with it.
If anybody now where it goes in the protocol I can probably add it very easy.

[bateau020]

It is not really bugs, but I will guess you are missing a :read: on the control. On most controls the variable will be updated when a value is returned from the device.

The displayVar(split(getVarList(1),"[\\n]")); only confirms what I already deducted.
And indeed, I think a :read: is missing on the control, but the whole idea of using a control as source was just that I would not need a :read:.
I now understand that combobox working is in fact an "undocumented feature", and that the others work as designed, and that I should move the driver to SCPIx.

It still would have been nice to have access to local variables without needing to change the driver.

Changing the driver looks like a major enterprise, when I look at the files that use SCPIx. So I'm putting improving this (be it Mode or SCPIx) on my TODO list with "nice to have" priority.

[HKJ]

Changing the driver looks like a major enterprise, when I look at the files that use SCPIx. So I'm putting improving this (be it Mode or SCPIx) on my TODO list with "nice to have" priority.

It is not, you just put the #driver SCPIx line in and that's it.

#scpiCmd is a option, not something you have to use for every command.

Internally an extra layer will be added in the communication, that will intercept txrx... (and some other) commands and process them locally (i.e. allow non-standard communication).

[bateau020]

Aha! that makes it a lot easier, thanks.

Attached is the improved file, and I'll leave it to that for now. For me it is good to publish.

One remark: One cannot use #forceUpperCase with SCPIx, as then "none" will be translated to "NONE" and sent to the device, and then one must wait until a timeout. That looks like a bug, since #forceUpperCase is explicitly noted as something to use with SCPIx.

[HKJ]

Attached is the improved file, and I'll leave it to that for now. For me it is good to publish.

I am not allowed to access it (I can access you previous upload).

It works now and I will include it with the next release.

One remark: One cannot use #forceUpperCase with SCPIx, as then "none" will be translated to "NONE" and sent to the device, and then one must wait until a timeout. That looks like a bug, since #forceUpperCase is explicitly noted as something to use with SCPIx.

That will be fixed in the next release.

[HKJ]

A test release https://lygte-info.dk/pic/Projects/TestController/TestController.jar it is version 2.28

It makes it possible to send commands depending on connection:

The device must use a driver that supports #scpiCmd, this can be "#driver SCPIx".
Then a command must be defined:

#scpiCmd MyInit #pgm#
if (portType!="GPIB")
  deviceWrite(handle,"SYST:REM");
endif;

This command can then be used:
 #initCmd *RST;MyInit;



And I have made a guess about how the E5810A works.
It must be configured as a normal GPIB controller:



And the the address field of the device must contains the ID letter (here E), colon and the local GPIB address (i.e. E:22)

Is I said above, this is a guess on how it works and I need somebody to test it and report back.

[bateau020]

The driver dependent stuff works for me.
New file attached.

[TheDefpom]

I downloaded the 2.28 version and see the E5810 option there, BUT it won't let me enter something like A:0 or A:22 in the ID field, it is not accepting the colon and stripping that out. so it ends up being A0 or A22.

I am keen to help you get this E5810A device up and running in TC.

[HKJ]

I downloaded the 2.28 version and see the E5810 option there, BUT it won't let me enter something like A:0 or A:22 in the ID field, it is not accepting the colon and stripping that out. so it ends up being A0 or A22.

I am keen to help you get this E5810A device up and running in TC.

On the GPIB you only use the E, the E:22 is in the device address field and the type must be GPIB.

Something else: If you need ideas for videos, some about TC would be nice (Like installing it and adding the first devices, saving configuration or doing automated tests with the "Log Event" or "Param sweeper" popup).

[TheDefpom]

Something is working, but I cant communicate with the DMM properly, I likely dont have the definition right as I have never done a GPIB def file.

using wireshark I can see TC is sending some commands to the E5810A, but im not getting a reply from the DMM, interestingly if I send a *IDN? from the command line in TC that doesn't get sent to the DMM, but I see a result in the window which matches the def file name, if I send READ? the DMM doesn't see it but I see it sent to the E5810A in wireshark.

I tried reading the info on the site relating to GPIB but there wasn't much said about it.

Attached is the file I am working on right now, most of it is commented out until I can get the basic comms working, maybe you can take a look and tell me what stupid mistakes I am making.

UPDATE:
It just occurred to me that when sending commands from python it included the GPIB interface and Device ids in its comms, such as “gpib0,22”, I didn’t see that in the comms from TC

[bateau020]

It just occurred to me that when sending commands from python it included the GPIB interface and Device ids in its comms, such as “gpib0,22”, I didn’t see that in the comms from TC

.. which looks like which is needed, when looking at https://edadocs.software.keysight.com/kkbopen/e5810a-can-i-use-the-e5810a-without-installing-the-keysight-io-libraries-suite-589739309.html

[HKJ]

Something is working, but I cant communicate with the DMM properly, I likely dont have the definition right as I have never done a GPIB def file.

using wireshark I can see TC is sending some commands to the E5810A, but im not getting a reply from the DMM, interestingly if I send a *IDN? from the command line in TC that doesn't get sent to the DMM, but I see a result in the window which matches the def file name, if I send READ? the DMM doesn't see it but I see it sent to the E5810A in wireshark.

I tried reading the info on the site relating to GPIB but there wasn't much said about it.

Attached is the file I am working on right now, most of it is commented out until I can get the basic comms working, maybe you can take a look and tell me what stupid mistakes I am making.

UPDATE:
It just occurred to me that when sending commands from python it included the GPIB interface and Device ids in its comms, such as “gpib0,22”, I didn’t see that in the comms from TC

The *idn? answer is generated by TC when using the ascii driver, this can be a advantage when testing stuff. Using SCPI or SCPIx driver will transfer it to the device.

It look like it might have a protocol, try using the lxi interface instead and send the gpib0,22 manually.
Note: The current test E5810 driver uses portmapper with the specified GPIB address as port to get a lxi connection, if you specify GPIB port as 0 it will be the same as using a standard lxi comm driver. You can see this in wireshark if you study the communication.

[jmurray]

Are there any known bugs with the text controls for device definitions?

I'm in the process of developing a device definition and my text fields only appear to read from the device, but not write, despite defining the write command.

Below is an example of a text field:

Code: [Select]

#cmdSetup text Voc_List SAS_List
:write: LIST:SAS:VOC
:read: LIST:SAS:VOC?
:textwidth: 18
:tip: Enter comma-separated list of up to 512 Voc values
1000
Monitoring in debug shows that pressing the set button only triggers a read, not a write.

Also, any suggestions on how best to tidy up the readback with :readFormat: or :readmath: ?
It returns each number in the comma-separated list in scientific notation, which isn't particularly human-readable. This would be straight-forward with a number field, but I'm concerned I might have to try and shoehorn some standard java into the definition file to operate on an array or something!

This is the debug output when manually setting/reading the parameters:
TestController Window (debug mode)

Code: [Select]

LIST:SAS:VOC 64,63,62,61
;; E4360A: Tx <LIST:SAS:VOC 64,63,62,61>
LIST:SAS:VOC?
;; E4360A: Tx <LIST:SAS:VOC?>
;; E4360A: Rx <+6.400000E+01,+6.300000E+01,+6.200000E+01,+6.100000E+01>
;; +6.400000E+01,+6.300000E+01,+6.200000E+01,+6.100000E+01

TestController cmd window

Code: [Select]

LIST:SAS:VOC 64,63,62,61
;; E4360A: Tx <LIST:SAS:VOC 64,63,62,61>
LIST:SAS:VOC?
;; E4360A: Tx <LIST:SAS:VOC?>
;; E4360A: Rx <+6.400000E+01,+6.300000E+01,+6.200000E+01,+6.100000E+01>
;; +6.400000E+01,+6.300000E+01,+6.200000E+01,+6.100000E+01

[HKJ]

Are there any known bugs with the text controls for device definitions?

Oops, I damaged it in V2.26 when I added the SET control.
You can get a new .jar file here: https://lygte-info.dk/pic/Projects/TestController/TestController.jar it is V2.29 where it is fixed.

Also, any suggestions on how best to tidy up the readback with :readFormat: or :readmath: ?
It returns each number in the comma-separated list in scientific notation, which isn't particularly human-readable. This would be straight-forward with a number field,

For numeric controls it is handled automatic, but for a text control try one of these:
:readmath: formatSI(getElement(value,0))+","+formatSI(getElement(value,1))+","+formatSI(getElement(value,2))+","+formatSI(getElement(value,3))

:readmath: formatDouble(getElement(value,0),0,5,0,5)+","+formatDouble(getElement(value,1),0,5,0,5)+","+formatDouble(getElement(value,2),0,5,0,5)+","+formatDouble(getElement(value,3),0,5,0,5)

The formatSI will need reformatting when transmitting data back, it will not be needed with formatDouble.
If the number of elements is variable you need to use #scpiCmd #pgm# and a script.

but I'm concerned I might have to try and shoehorn some standard java into the definition file to operate on an array or something!

The scripting language is not Java or JavaScript, but something unique to TestController.

[jmurray]

That's great, thanks!

I'm getting close on this device definition, however I'm unclear on the limitations for issuing commands within a device definition.

I've managed to pull the data into the table, but is there anyway I can set the chart parameters from within the same function instead of doing it manually?
I'm trying to build all the necessary scripting/GUI so that my colleagues don't have to be fully versed in operating the software.

Below is the snippet that I'm working with - it all works except for the last two lines:

Code: [Select]

#otherList
menuItem[0] = "Pull_DAC_Table.csv";

#otherData
var samples = 0;
var cmd = "CURR:DTAB:SAS?";
var currentTable = array(deviceRead(handle,cmd));
cmd = "VOLT:DTAB:SAS?";
var tempString = deviceRead(handle,cmd);
var voltageTable = array(tempString);
samples = countMatch(tempString,",");
tableInitHeader("index,Voltage,Current,Power");
var i;
for i = 0 to samples do
var v = voltageTable[i];
var c = currentTable[i];
var p = voltageTable[i] * currentTable[i];
tableAddRow(i,v,c,p);
i=i+1;
endfor;
chartx("Voltage");
chartCurves("Current","Power");

[HKJ]

I'm trying to build all the necessary scripting/GUI so that my colleagues don't have to be fully versed in operating the software.

Below is the snippet that I'm working with - it all works except for the last two lines:

Code: [Select]

...
chartx("Voltage");
chartCurves("Current","Power");

Generally I will not recommend doing that from the device driver, but instead from a menu item.

You need to use #... commands, you can use the generate functions to get an idea about them (Setup it up and use the "Chart/Hist/Range script"):

They are also documented in the help window when you start typing the name of the command.

If you really insist on putting it in the device driver you need to use, it uses the same #... commands as above:
runScript("#cmd");
or
runScript("#cmd1\n#cmd2\n#cmd3");

[jmurray]

Generally I will not recommend doing that from the device driver, but instead from a menu item.
If you really insist on putting it in the device driver you need to use, it uses the same #... commands as above:
runScript("#cmd");
or
runScript("#cmd1\n#cmd2\n#cmd3");

I can understand that recommendation and 99% of the time it would be very sensible. This particular piece of equipment though generates two sets of either 256 or 4096 data points to create an I-V curve, which I wanted to be able to visualise as part of the setup process for a quick visual representation.
Ideally I'd make it a button in the #cmdSetup popup instead of being in the #otherList, but I haven't worked that out just yet.

It was the runScript syntax that I was struggling with. Works really well now.
I still haven't gotten to working on the comma separated lists I mentioned previously. Trying my best to understand the use of #scpiCmd and #pgm#.

This software is great!
Once I get this definition polished enough, I'll upload it here.
- On that note, is metadef limited to IDN? responses? *IDN returns the mainframe model number, but the module model numbers are returned by SYST:CHAN:MOD? (and then there's the option list which is another sub-set)!

[HKJ]

It was the runScript syntax that I was struggling with. Works really well now.
I still haven't gotten to working on the comma separated lists I mentioned previously. Trying my best to understand the use of #scpiCmd and #pgm#.

The scripting is the same as you have already done, but the #scpiCmd is supposed to return a result in the form of "value1 value2 value2...", at least when it ends with ?
This result can be made by putting it on the last line of the script (As a variable/expression/function call/value) or by use a couple of print() to build it in the script.

- On that note, is metadef limited to IDN? responses? *IDN returns the mainframe model number, but the module model numbers are returned by SYST:CHAN:MOD? (and then there's the option list which is another sub-set)!

The #meta/#metadef system generates multiple definitions from one file and the *idn? is usually to verify the correct one is selected.
At the current time there is no way to dynamically modify a definition file, but you can adjust the #cmdSetup menus with the selector control.

[vladobac]

Hi HKJ.
I ordered a replacement Atorch DL24M-H electronic load from China. However, the Chinese sent me an upgraded version of the DL24MP, which works on its own, but does not connect to the TC. I wrote to the Chinese that it wasn't working for me, so they sent me a communication protocol full of Chinese characters that mean nothing to me as a layman. You probably know from the last time you helped me that I don't know how to program, so I'm asking for your help again. I am connecting Chinese communication protocol. Thank you, Vladimir.

I tried adding it to ATorchPX100Devices and it didn't help. And that's probably the maximum of my programming skills.

#metadef
; 600Watt discharge power
#idString ATorch,ATorch DL24MP,
#name ATorch DL24MP
#handle ATDL24MP
#sections Protocol2
#replaceText MinCurrent 0.2
#replaceText MinVoltage 0
#replaceText MaxCurrent 40
#replaceText MaxVoltage 200

[HKJ]

Hi HKJ.
I ordered a replacement Atorch DL24M-H electronic load from China. However, the Chinese sent me an upgraded version of the DL24MP, which works on its own, but does not connect to the TC. I wrote to the Chinese that it wasn't working for me, so they sent me a communication protocol full of Chinese characters that mean nothing to me as a layman. You probably know from the last time you helped me that I don't know how to program, so I'm asking for your help again. I am connecting Chinese communication protocol. Thank you, Vladimir.

I tried adding it to ATorchPX100Devices and it didn't help. And that's probably the maximum of my programming skills.

The PX100 protocol has been changed again, try downloading the new version:
https://lygte-info.dk/pic/Projects/TestController/TestController.jar
Check it is V2.30 on the configuration/about menu

Then add the line:
#PXVersion 3
Just after the #driver line in the PX100 definition

This will prevent it from working on older versions of the load, but I will fix that when you confirm that it works with your #metadef
I am also very curious if setting of values from the computer works, they are not documented in the protocol you posted, but maybe they are still here?

[vladobac]

Thanks, I'll try and get back to you.
Vladimir

[vladobac]

I installed version 2.30, added the above line and will now connect via any Atorch load. That's great, you have a couple of big beers at my place! 

However, entering values ​​from a PC is very bad. Only time input works correctly.

Setting the cut-off voltage via the PC does not work well. For example, when I require a cut-off voltage of 1V, 25.6V is set on the load. It always sets to 25.6 times the set point on the load and I can't do anything about it.

 There is a non-linear error when setting the current with Protocol1. For example, I require 200mA, the load is set to 20mA. But when 1000mA is required, 256mA is set on the load. When 10A is requested, 2.56A is set on the load. Up to 1A, 0.1 times the desired value is set on the load, and from 1A it is 0.256 times. With Protocol2, the error is 10x larger, but the nonlinearity remains.

  The load should also be able to be switched on, off and reset the measured values ​​via the PC. Reset and shutdown work (discharge of the load occurs when any On/Off button is pressed). Switching on the load via PC does not work with any button.

 I am still in contact with the Chinese store Atorch. I have something to ask them that would help us eliminate the mentioned problems. Well thank you.

Vladimir