Program that can log from many multimeters.

[HKJ]

I agree and it is exactly what I would make in a standard programming language. Unfortunately I never understood how to make variables working in Test Controller. Their scope is something simply I don't understand. I can create a variable, but after I am not able to retrieve it, or I am not able to retrieve WHERE I need it. I made a lot of testing also with global variables, but without  success.
Only variables in function #pgm# work as expected, anyway I was not able to pass the content of a variable to the custom function, just immediate values. So, after several days I gived up......

Now I simply try to avoid them, that's why my question, although I understand that in this way what I can do in Test Controller programming is quite basic.

I forgot to say variables only works in #scpiCmd, they share a common context and will share variables.

Note: Using printLog(getVarList(1)) after a :readmath: will show all defined variable (and trigger an error after that). printLog() only exist in the newest release of TC.

[KungFuJosh]

The attached adds basic support for Siglent SDS2000X Plus and HD models.

Thanks,
Josh

[fricci]

I forgot to say variables only works in #scpiCmd, they share a common context and will share variables.

Note: Using printLog(getVarList(1)) after a :readmath: will show all defined variable (and trigger an error after that). printLog() only exist in the newest release of TC.

Interesting......
So, if I correctly understand there is no way to pass the content of a variable as parameter to a custom function (#pgm#). I succeeded to make it working only passing immediate values (it didn't work using a variable as parameters), but this was completely useless for what I had to do.

[fricci]

Stating your last clarifications, I succeeded to successfully use some variables inside #scpiCmd commands so I wrote a working code to manage the scale changes. 
I would like to ask you some more questions:
1) Any chance to call an #scpiCmd inside another #scpiCmd?
2) Time ago I wrote a working function using #pgm# that accepted some input parameters and it was called inside a #cmdSetup. Unfortunately it worked only if I pass immediate values, I didn't succeed to pass it the content of a variable, the function got the variable name (as a string), instead of its content. The use of parenthesis around the variable name did not change the result. Is this the expected behavior?

[HKJ]

Interesting......
So, if I correctly understand there is no way to pass the content of a variable as parameter to a custom function (#pgm#). I succeeded to make it working only passing immediate values (it didn't work using a variable as parameters), but this was completely useless for what I had to do.

You cannot pass variables from a context where no variables are defined.
Using the command from the command line or a script you can pass variables.

[HKJ]

Stating your last clarifications, I succeeded to successfully use some variables inside #scpiCmd commands so I wrote a working code to manage the scale changes. 
I would like to ask you some more questions:
1) Any chance to call an #scpiCmd inside another #scpiCmd?

Don't, I believe you can do it, but all #scpiCmd for a device shares the same execution context, so it will not work reliable.

2) Time ago I wrote a working function using #pgm# that accepted some input parameters and it was called inside a #cmdSetup. Unfortunately it worked only if I pass immediate values, I didn't succeed to pass it the content of a variable, the function got the variable name (as a string), instead of its content. The use of parenthesis around the variable name did not change the result. Is this the expected behavior?

I do not remember exactly what places I handle expressions or not, but I do handle them in most places. A simple test is to use (3*5) as a parameter, if the result is 3*5 no expressions are processed, if the result is 15 expressions are processed and variables can be used (Global variables can be access from all contexts, but it is very bad style to use them in a device definition).

[HKJ]

The attached adds basic support for Siglent SDS2000X Plus and HD models.

Thanks, it will be include in the next release.
Of course anybody can download the file and replace the existing file of the same name, if they want it now.

[fricci]

Stating your last clarifications, I succeeded to successfully use some variables inside #scpiCmd commands so I wrote a working code to manage the scale changes. 
I would like to ask you some more questions:
1) Any chance to call an #scpiCmd inside another #scpiCmd?

Don't, I believe you can do it, but all #scpiCmd for a device shares the same execution context, so it will not work reliable.

Anyway I didn't succeeded to make it working.

2) Time ago I wrote a working function using #pgm# that accepted some input parameters and it was called inside a #cmdSetup. Unfortunately it worked only if I pass immediate values, I didn't succeed to pass it the content of a variable, the function got the variable name (as a string), instead of its content. The use of parenthesis around the variable name did not change the result. Is this the expected behavior?

I do not remember exactly what places I handle expressions or not, but I do handle them in most places. A simple test is to use (3*5) as a parameter, if the result is 3*5 no expressions are processed, if the result is 15 expressions are processed and variables can be used (Global variables can be access from all contexts, but it is very bad style to use them in a device definition).

I absolutely agree....... but if there is no way to pass the content of a variable to a custom #pgm# function , this could be the last resort.

[HKJ]

I absolutely agree....... but if there is no way to pass the content of a variable to a custom #pgm# function , this could be the last resort.

Variable in a device content can be access from all #scpiCmd, i.e. they are nearly global within your device definition, you generally do not need global variable.
I.e. set a variable where you change range, then you can use it in all #scpiCmd that process data from that range. No parameters required.

[adso85swe]

I see that TestController has support for Riden power supplies RD6006, RD6012 and RD6018, but does anyone know if their higher current versions RD6024 and RD6030 will work with one of these communication protocols?
If not, I guess the question goes to HKJ, is there a plan to add these in the future? Is it easy or difficult for you to do?

[HKJ]

I see that TestController has support for Riden power supplies RD6006, RD6012 and RD6018, but does anyone know if their higher current versions RD6024 and RD6030 will work with one of these communication protocols?
If not, I guess the question goes to HKJ, is there a plan to add these in the future? Is it easy or difficult for you to do?

Take a look in the Riden60xx.txt file, each #meta defines a version of the power supply, you may be lucky that you can just copy a #meta section and modify it.
But you might have to adjust some scale factors, this can be done with the #replacetext function or you can make a copy of the definition file and dedicate it for the higher power version.

[adso85swe]

Take a look in the Riden60xx.txt file, each #meta defines a version of the power supply, you may be lucky that you can just copy a #meta section and modify it.
But you might have to adjust some scale factors, this can be done with the #replacetext function or you can make a copy of the definition file and dedicate it for the higher power version.

I see. Well, I don't own one of those higher current supllies at the moment, so I can't really test and verify it for now, but then I know the possible proceedure that may or may not work. Thanks.

I do own the lowest end device though, RD6006, and another question related to this device is, I don't seem to be able to log data faster than one point per second with it, even if I choose faster logging in TestController. Is this a limitation of the RD6006 hardware or communication protocol? Or is it something that may be adjusted in the RD60XX text file?

[HKJ]

I do own the lowest end device though, RD6006, and another question related to this device is, I don't seem to be able to log data faster than one point per second with it, even if I choose faster logging in TestController. Is this a limitation of the RD6006 hardware or communication protocol? Or is it something that may be adjusted in the RD60XX text file?

Test controller can generally handle a sample rate up to about 100/sec from each connected device.
I would expect the Riden supplies to be faster than once a second, but then each sample from the supply is 9 commands, that mat be the reason.
If you want to experiment with sampling fewer samples, copy the definition to ...\Documents\TestController\Devices, change filename and device names (Like adding a letter to all names), and you can play with the definition without affecting the original definition.

[adso85swe]

Test controller can generally handle a sample rate up to about 100/sec from each connected device.
I would expect the Riden supplies to be faster than once a second, but then each sample from the supply is 9 commands, that mat be the reason.
If you want to experiment with sampling fewer samples, copy the definition to ...\Documents\TestController\Devices, change filename and device names (Like adding a letter to all names), and you can play with the definition without affecting the original definition.

Yes, I know TestController can indeed log quite quickly, I have tried that myself with other devices without issues.

For the Riden supply, in one way Im not too surprised to be honest, because even with the official software the logging frequency is locked to 1 Hz, you can’t change it up or down. That’s why I suspect that this is locked in the firmware somehow and that the data is only sent once per second through the USB interface. In that case tweaking the device file won’t help I guess, but I might play around with it as you suggested just to confirm that.

Thanks for your input, as always.

[HKJ]

For the Riden supply, in one way Im not too surprised to be honest, because even with the official software the logging frequency is locked to 1 Hz, you can’t change it up or down. That’s why I suspect that this is locked in the firmware somehow and that the data is only sent once per second through the USB interface. In that case tweaking the device file won’t help I guess, but I might play around with it as you suggested just to confirm that.

Be aware that there can be two parameters when talking about logging rate:
1) How fast the communication read the data.
2) How frequent the device samples the actual value.

They do not have to be the same, a device can have internal registers where it stores the sampled values and you might be able to read them lots of times each second, even if they are only refreshed with new samples each second. This is device specific, on some devices each request for data will do a new sample on other it will read from a register.

[Huluvu]

Hello HKJ
Is there any reason why my Keysight U1233A does not connect? Not even listed under add devices   
Command response text = 

;; USB-Serial Controller (COM3) Did not find any match for: Keysight Technologies,U1233A,MY52290012,V3.00

OS = Win10

Thanks in advance

[HKJ]

Hello HKJ
Is there any reason why my Keysight U1233A does not connect? Not even listed under add devices   
Command response text = 

;; USB-Serial Controller (COM3) Did not find any match for: Keysight Technologies,U1233A,MY52290012,V3.00

OS = Win10

I have no idea why there is a bug in the definition.
Find the file: KeysigtU123xA.txt
and open it in notepad.

Add the lines:

#meta
#idString Keysight Technologies,U1233A,
#name Keysight U1233A
#handle K1233

Above the line:
#port com

I have not written the definition and have no idea how well it works, but with the above change you can use the definition.

Please report back how well it works.

[Huluvu]

Up and running again 
Thanks for the fast support 

[AndreasF78]

Hi all,

I set up TestController with my recently acquired Agilent 34401A today, and noticed that the Agilent 34401A Enhanced device is really useful (I activated the hidden features for sure.) 

However, I was missing the "hidden" 10 mA ACI range discussed here: https://www.eevblog.com/forum/testgear/agilent-34401a-hidden-10ma-ac-current-range/

The setup window in TestController only shows the 1A and 3A ranges for AC Current. So I tried a small (probably dirty) fix to AgilentHP34401A.txt and modified the radio Range AC_Current definition to

#cmdSetup radio Range AC_Current
:write: (getElement("DIAG:POKE 25,0,1_CURR:AC:RANG 1_CURR:AC:RANG 3",(value==0.01?0:(value==1.0?1:2)),"[_]+"));[20]
:read: CURR:AC:RANG?;[20]
:updatedelayed: 0.5
:update: Range_Auto AC_Current
10mA 0.01
1A 1
3A 3
:updatemodechange:

It is a bit ugly because the mode change to 10 mA AC requires the DIAG:POKE command instead of the usual CURR:AC:RANG command (it does not seem possible to switch to the "hidden" 10 mA range through CURR:AC:RANGE.) Maybe there is a more elegant way to distinguish this in the :write: statement?
Perhaps this can be included in the next TestController release, I think it adds useful functionality for this nice instrument.

[HKJ]

The setup window in TestController only shows the 1A and 3A ranges for AC Current. So I tried a small (probably dirty) fix to AgilentHP34401A.txt and modified the radio Range AC_Current definition to

It is a nice addition and I will include it.

[japasetelagoas]

My apologies for the newb question, especially considering that there are several pages contanining code discussion but how exactly am I supposed to interface my computer with the Fluke 87V that I have? Do I need to solder wires on specific ICs on the DMM?

[HKJ]

My apologies for the newb question, especially considering that there are several pages contanining code discussion but how exactly am I supposed to interface my computer with the Fluke 87V that I have? Do I need to solder wires on specific ICs on the DMM?

Only the original 87 supports serial connection to TC, the serial connection was migrated to the 187 and 287 meters.

[japasetelagoas]

Thanks for the reply HKJ, there's a 287 at the company that I work at, I'll give it a try.

[HKJ]

Thanks for the reply HKJ, there's a 287 at the company that I work at, I'll give it a try.

It requires a special Fluke cable to connect.
Nearly all DMM's with computer connection requires a special cable, because the connection is optical.

[Knoonan]

I'm new to TC and not much of a programmer. I have an HP 3457A DMM, which is very similar to the 3458A. The main difference is it is only 6.5 digits, and lacks the high performance pulse measurement features and speed. Is it possible to configure the 3457a by copying the 3458a configuration file, and simply changing the two model numbers?
If not, can you assist in editing the configuration?