Program that can log/control many multimeters and other devices.

[HKJ]

Just discovered your software and work , really impress by the performance

I hope you will enjoy it.
You are always welcome to ask question or post ideas.

[MrPete]

I'm hoping to set up (NiMH) battery characterization via TC. I have many of the needed parts, but missing one key:
* NiMH charging can be tricky in the arena of Charge Termination. "They" recommend monitoring all three of: time, -deltaV, and temperature (eg rapid increase in a minute, AND overall temp)...

What about: https://lygte-info.dk/project/TestControllerArduino2%20UK.html#DS1820_temperature_device

Maybe...

Others are using Riden DP60xx -- I see it has a temp sensor, and tracks temp  in the supplied software, which sounds great.

BUT TC does not support that.

Any idea why?

[Gertjan]

I have started on a more general explanation on how some stuff works in TC.

All people are welcome to comment on it and add ideas about what to include and if I need to expand some areas.

My first version is here http://lygte-info.dk/project/TestControllerProgramming%20UK.html

Hi HKJ,

Thank you for this very welcome expansion of the TestController documentation.

What I would also like is a documentation of the basic syntax for a TC definition file. Now a lot of these very basic things are not clear. For example: I see that sometimes a ; (semicolon) is used on the end of a line. But not always.....

If it is the syntax of an existing language, that would be good to know which one. Then we could look there for syntax etc.

regards, Gertjan.

[HKJ]

Others are using Riden DP60xx -- I see it has a temp sensor, and tracks temp  in the supplied software, which sounds great.

BUT TC does not support that.

Any idea why?

Many device definitions in TC are written by users and I have no control over what they want to support.
It is fairly easy to modify a definition or make a new definition to fix some shortcomings.

[HKJ]

Thank you for this very welcome expansion of the TestController documentation.

What I would also like is a documentation of the basic syntax for a TC definition file. Now a lot of these very basic things are not clear. For example: I see that sometimes a ; (semicolon) is used on the end of a line. But not always.....

There is no common syntax for all definition files, it depends on the driver that uses the file.
But there are many common elements shared between the drivers, the programming language is one.
The semicolon is a optional statement termination, the parser can generally work out when a statement ends and the next begins.

If it is the syntax of an existing language, that would be good to know which one. Then we could look there for syntax etc.

It is not from any existing language.

[Gertjan]

Hi HKJ,

The idea behind my question was that for you basic language and syntax for the definition files are obvious (too basic to even think about).
But please realise that for users who are writing a definition for TC, it is not. Often they aren't even experienced programmers.

So some help in that department would be welcome. Now too often we struggle along by copying from your examples and existing definitions, hoping to get it right...

regards, Gertjan.

[HKJ]

The idea behind my question was that for you basic language and syntax for the definition files are obvious (too basic to even think about).
But please realise that for users who are writing a definition for TC, it is not. Often they aren't even experienced programmers.

So some help in that department would be welcome. Now too often we struggle along by copying from your examples and existing definitions, hoping to get it right...

I agree the documentation could be better, what I have been thinking about is isolate the common part in one page and then put all the driver specific parts in on or two pages, that would not really change the contents, but might make it easier to understand.

[Pukker]

Others are using Riden DP60xx -- I see it has a temp sensor, and tracks temp  in the supplied software, which sounds great.

BUT TC does not support that.

Any idea why?

Many device definitions in TC are written by users and I have no control over what they want to support.
It is fairly easy to modify a definition or make a new definition to fix some shortcomings.

When you want to modify the device defenitions for the Ridens to readout Temperature sensor,
look at these registers.

0023 TEMP PROBE C RO
0024 0
0025 TEMP PROBE F RO
RO means Read-Only

Complete list attached as PDF.

[xduan]

I have a hantek hdm3065 I used the software made available by hantek but the software is very blocked, it does not allow me to control the multimeter physically and is also very slow, has anyone already implemented this multimeter in the topic owner's software?

[Messtechniker]

Since the hdm3065 has an USB device interface and no virtual COM interface, integration via USB with Test Controller will not be possible. Integrating instruments from the same family with a RS 232 interface or a LAN interface should be possible. Test controller should be able handle these ports and the SCPI commands of this instrument.
Just give it a try. HKJ is very helpful and resposive to any questions you may have.

[HKJ]

I have a hantek hdm3065 I used the software made available by hantek but the software is very blocked, it does not allow me to control the multimeter physically and is also very slow, has anyone already implemented this multimeter in the topic owner's software?

It may be a bit tricky, the only manual I have seen for its SCPI is mostly in Chinese.

[Microcheap]

The Hantek HDM3065(B) works fine with TestController using RS232 or LAN. As there's no specific definition for these devices yet, you can just select the Keysight 34461A on the device list in TC and then change the SCPI command set on your DMM to "Agilent".  ([Shift]+Utility -> I/O Config -> SCPI).

I have its SCPI programming guide in English and I'm trying to write the definition file for TC but I didn't have the time to finish it yet.

it does not allow me to control the multimeter physically

Just press [Shift]+Local to regain access to the keyboard when the DMM is in remote mode

[xduan]

I tried using LXI and it didn't work, I'll try to get an RS232 to USB cable to try this way, the friend below got the codes in English, if necessary and you have Paypal, I'll pay you so you can implement the codes for me , as it would be of great help to me here, so I think it's worth contributing, as the program you made is very complete, my interest is to use the reading to be captured in obstudio.

[xduan]

Good afternoon friend, would you be able to make this PDF available in English?

[HKJ]

I tried using LXI and it didn't work, I'll try to get an RS232 to USB cable to try this way, the friend below got the codes in English, if necessary and you have Paypal, I'll pay you so you can implement the codes for me , as it would be of great help to me here, so I think it's worth contributing, as the program you made is very complete, my interest is to use the reading to be captured in obstudio.

There are two network connections: Socket and LXI, they are independent of each other and Socket may work, even if LXI do not.
It is me that have written the program, but it is not me working on a driver for the meter. You are welcome to pay somebody to help your with a definition, it is fine by me (Just to make it clear). The help I provide is free, but then it is fairly limited when I do not have any good documentation or the device.
People are welcome to donate some money to me  , but it is not required in any way.

[gby]

Hi HKJ,

I am trying to write a script and TestController is doing something that is confusing me.  Hopefully you can easily explain it?

When I run the below code I am getting read's and writes to my connected device.

Code: [Select]

#logcmds 0
=var n = 0
=var done = 0

#while (done == 0)
   = done = 1
#endwhile
Results from running the above in debug mode:

Code: [Select]

;; AKD2GS: Tx <REC.TRIG>
;; AKD2GS: Tx <txrx REC.TRIG>
;; 192.168.1.197: Tx: <REC.TRIG..> 52 45 43 2E 54 52 49 47 0D 0A
;; 192.168.1.197: Rx: <> 0D
;; AKD2GS: Tx <REC.DATA?>
;; AKD2GS: Tx <txrxn? 2 REC.RETRIEVEDATA 0
:readmath: getElement(value,1,"\n")>
;; 192.168.1.197: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 192.168.1.197: Rx: <1> 31 0D
;; 192.168.1.197: Rx: <5490269972.049,0.001,3742633071,0.000,-0.005,1119> 35 34 39 30 32 36 39 39 37 32 2E 30 34 39 2C 30 2E 30 30 31 2C 33 37 34 32 36 33 33 30 37 31 2C 30 2E 30 30 30 2C 2D 30 2E 30 30 35 2C 31 31 31 39 0D
;; AKD2GS: Rx <5490269972.049,0.001,3742633071,0.000,-0.005,1119>
;; AKD2GS: Rx as numbers <5.490269972049E9 0.001 3.742633071E9 0.0 -0.005 1119.0>
The above is the sequence of communications to the attached device as if TestController is logging one point and executing the driver file #askValues line.

If I comment out the #while, #endwhile and then run this simple script the debug window is empty/no communications to the attached device.

If I change the #while, #endwhile to #if, #endif the same behavior of communicating with the device.

I would not expect any communications to the connected device when running "pure script commands".  Can you explain why the #while or #if script lines seems to kick off an #askValues connected device communications sequence?

In my more complete script that is doing real work these extra data requests make it not work.  So, is there a way to prevent talking to the connected devices except when explicitly communicating to them or logging data while running a script?

For reference, I am using TestController Ver 2.44 with my device "Kollmorgen AKD2G.txt" device.  All operations were done while on the Commands Tab with data logging off.

[HKJ]

If I comment out the #while, #endwhile and then run this simple script the debug window is empty/no communications to the attached device.

If I change the #while, #endwhile to #if, #endif the same behavior of communicating with the device.

I would not expect any communications to the connected device when running "pure script commands".  Can you explain why the #while or #if script lines seems to kick off an #askValues connected device communications sequence?

It is by design, as I expect you will often test on device values like this:

#while Load.voltage>=3.6
...
#endwhile

But it do not directly request a new value, it checks how long time ago it last requested a value and uses that to decide if a new read of device values is required. I.e. when doing fast logging it will not request new values, but use the ones already present.

In my more complete script that is doing real work these extra data requests make it not work.  So, is there a way to prevent talking to the connected devices except when explicitly communicating to them or logging data while running a script?

The only way is to switch to the programming language, it is not a integrated part (It is a separate software package I have linked in) of TC and do not communicate with the devices except on explicit requests. Due to its limited access to TC commands, it is not as useful for regular scripting.
Have you seen this: http://lygte-info.dk/project/TestControllerProgramming%20UK.html
Note that using = to activate programming is one line at a time and using #calc is a block (in scripts), i.e. statements can spread over multiple lines. Defining programming functions with addFuncGlobal() will make the code much faster.

[gby]

Hi HKJ,

Thanks for the quick explanation.  The idea of keeping the log values reasonably current in the background for #while, #if makes sense.

Like many bench DVM's this device can trigger and record values to a local memory with up to a very fast sample rate.  I am working to write a script to set up the device to trigger, record and then read back the acquired data into an array.  Unfortunately, the #askValues process restarts the trigger and loses my data when done again.  So, I will have to work around that issue.

Another question.  In TestController is there any way to take a bunch of data points stored in an array and store them as CSV values in a file?  Right now I am printing to the console and then copy pasting them into a file manually and it would be great to automate that step.

[HKJ]

Like many bench DVM's this device can trigger and record values to a local memory with up to a very fast sample rate.  I am working to write a script to set up the device to trigger, record and then read back the acquired data into an array.  Unfortunately, the #askValues process restarts the trigger and loses my data when done again.  So, I will have to work around that issue.

I do not know how you plan to implement it, but check the end of the "KeysightU1461A.txt" file for usage of the #other... definitions.
It is code to fetch logs from DMMs.

Another question.  In TestController is there any way to take a bunch of data points stored in an array and store them as CSV values in a file?  Right now I am printing to the console and then copy pasting them into a file manually and it would be great to automate that step.

There are two ways:
1) You can use direct file operations, this means you must do your own CSV formatting: https://lygte-info.dk/project/Calculator%20UK.html#File_access
2) You can fill data into the table from the programming language: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#tableAddCSVText and then use script to save it.

Note: There are ways to escape from programming language to script and also the other way around.
You can also do script or programming language in external files and then run them from TC.

[Martin72]

Hi,

My ET3502 is recognized in the sense of being displayed, but I cannot send any commands because the device is not in the "Device List".
Is there a way to address it without first creating a script for it and saving it in the list?

[HKJ]

My ET3502 is recognized in the sense of being displayed, but I cannot send any commands because the device is not in the "Device List".
Is there a way to address it without first creating a script for it and saving it in the list?

TC only works with devices in the device list, adding it to the device list may be easy if there are similar (Same brand, same function) devices.

[Martin72]

I had now taken the ET44xx file and changed everything beginning with ET44 to ET35xx.
But that doesn't work...

[HKJ]

I had now taken the ET44xx file and changed everything beginning with ET44 to ET35xx.
But that doesn't work...

What you need is the answer from the device, it must be written after the #idString tag
One #metadef section is all that is needed to define a similar device.

But looking at you screen dump the answer is null and that is not a real answer, but instead a indication that no answer is received.
Possible reasons: RS232 settings (Baudrate, parity)

[Martin72]

 

[HKJ]

I have made a HTML version of the build-in command help file, it is considerable easier to browse script commands on this page, than using the build-in help.
The contents is basically the same, except I have added a few links.

http://lygte-info.dk/project/TestControllerScriptCommands%20UK.html

It is a bit rough yet.