Author Topic: Program that can log/control many multimeters and other devices.  (Read 1495134 times)

Salient666, Cyclotron, gby and 694 Guests are viewing this topic.

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6375 on: May 15, 2026, 07:13:38 pm »
Hi,
    i'd like to use TC to read the value of a sensor via a multimeter, convert it to a usable value and log it.
    The sensor is a DIY RF power sensor ( dl5neg design, see http://www.herbert-dingfelder.de/?page_id=68) that gives a voltage.
    i've a calibration table and i guess i need to interpolate between values. Nothing fancy.
    Can TC do that ? What would be the best way to implement that ?
Thanks in advance !

TC do not really have a specific way to do that. You can easily add any expression (on the Math page) to adjust the value, that will give you a extra value/curve with the adjusted value.
If you have a idea for a way to make a interpolation function, please post it, I may be able to add it. What I do not like is a long list of value pairs, that need a lin/log/whatever interpolation between, it is fairly slow to parse that list each time a point is logged (It is possible). Using some tool to make a expression that will match the curve is usually a better solution and the Math page on TC can easily handle that.
 

Offline squirrax

  • Contributor
  • Posts: 14
  • Country: fr
Re: Program that can log/control many multimeters and other devices.
« Reply #6376 on: May 16, 2026, 10:18:21 am »
Thanks for the answer.
I tried several regression types on the data but the errors are way to high for this type of sensor...
I'll try something else.
Thanks again.
 

Offline flash2b

  • Frequent Contributor
  • **
  • Posts: 938
  • Country: nl
  • Everything I like about myself is better with you.
Re: Program that can log/control many multimeters and other devices.
« Reply #6377 on: May 17, 2026, 02:03:48 pm »
Dear HKJ,

I have made several new definitions for readout and relay devices to strengthen the supported equipment (2+8+7 = 17 extra !)  list of TestController.

Elecdemo YK-LED23004M 4digit and YK-LED23006M 6digit 7 segment display module
Elecdemo YK-LED36xxM 56xxM 4006M TMLED3904M MILED3906M 7 segment display module
Ebyte AXCX4020 4DI2DO, XACX0420 4AI2DO, AACX2220 2DI2AI2DO, AXCX4040 4DI4DO, XACX0440 4AI4DO, AACX2240 2DI2AI4DO and XXCX0080 8DO Isolation AI-DI-DO relay module


The Elecdemo display 2300x is a large 2.3 inch display in a metal case. Nice for showing (alternating) values. The other displays are smaller, however they share the same Modbus commands. The floating point is very good so I did not bother to implement my definition based floating point #pgm# this time.

The Ebyte modules are AI-DI-DO but the definition is setup as #interfaceType Relay but also Analog Input and Digital Input is supported by the definition. Price/Value wise, they are very interesting and housed in a nice case as well.

Please add these definitions to the next release of the wonderful world of TestController.

PS. I will not release any definitions in June.

[ Attachment Invalid Or Does Not Exist ]

Part of TestController v3.04
« Last Edit: May 26, 2026, 03:40:35 pm by flash2b »
They say attention is a shovel. It's time to dig 'em out.
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6378 on: May 17, 2026, 02:56:47 pm »
I have made several new definitions for readout and relay devices to strengthen the supported equipment (2+8+7 = 17 extra !)  list of TestController.

It was a long list, they are added, thanks.

PS. I will not release any definitions in June.

Sad, but you have made a lot of definitions lately.
 

Offline flash2b

  • Frequent Contributor
  • **
  • Posts: 938
  • Country: nl
  • Everything I like about myself is better with you.
Re: Program that can log/control many multimeters and other devices.
« Reply #6379 on: May 19, 2026, 07:06:58 pm »
I've found a (very) small bug  :o

When multiple toggleButton's are grouped as one object, you cannot set a :tip: on the grouped name. (which is fine....)



In the example above the group is called Output, hovering with the mouse on that text reveals that the :tip: is not suppressed, instead a . is shown (see red circle).

I recon this is the case for all #cmdSetup that can be grouped, but I did not verify this. It is happening with toggleButton.
« Last Edit: May 19, 2026, 07:12:56 pm by flash2b »
They say attention is a shovel. It's time to dig 'em out.
 
The following users thanked this post: 2X

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6380 on: May 19, 2026, 07:51:17 pm »
I've found a (very) small bug  :o

I got the impression you where not doing any definition at the current time?

I will have to setup something with the toggle button to check it out.
 

Offline flash2b

  • Frequent Contributor
  • **
  • Posts: 938
  • Country: nl
  • Everything I like about myself is better with you.
Re: Program that can log/control many multimeters and other devices.
« Reply #6381 on: May 19, 2026, 07:56:37 pm »
I was playing around with my LCUS relays when I spotted it. I remembered that I have seen it before so I just wanted to let you know.
They say attention is a shovel. It's time to dig 'em out.
 

Offline MrPete

  • Regular Contributor
  • *
  • Posts: 152
  • Country: us
Re: Program that can log/control many multimeters and other devices.
« Reply #6382 on: May 21, 2026, 10:53:36 pm »
@HKJ Two new Q's: I am working on some new/old argorithms.

1) There is a Math tab "type" called "Slope". Any examples of correct use, or  documentation?

2) To more carefully calculate dynamic iR (internal resistance), I need to (generically):

(after some setup)
a) read existing current and voltage; bump load amount to a specific value
b) After (ideally) a careful # of milliseconds (probably 40 or 50)
c) read voltage again

crucial values include the specific delay between the two readings. Ideally that is a repeatable number.

Any thoughts about how best to carefully control the delay from load change to second reading??                                                                                                         
« Last Edit: May 22, 2026, 04:01:39 am by MrPete »
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6383 on: May 22, 2026, 03:59:04 am »
Two new Q's: I am working on some new/old argorithms.

1) There is a Math tab "type" called "Slope". Any examples of correct use, or  documentation?

It basically take the the current sample and one n steps back and calculates the best fitting slope (Using least square method for all points in between).

2) To more carefully calculate dynamic iR (internal resistance), I need to (generically):

(after some setup)
a) read existing current and voltage; bump load amount to a specific value
b) After (ideally) a careful # of milliseconds (probably 40 or 50)
c) read voltage again

crucial values include the specific delay between the two readings. Ideally that is a repeatable number.

Any thoughts about how best to carefully control the delay from load change to second reading??                                                                                                       

That is basically not possible for a couple of reasons:
1) Devices may convert at fixed intervals or they may convert when a value is requested. The first type will always decide the interval by itself, not based on what you want.
2) TC sort of optimize reading of values, i.e. if you request a value very soon after another read, it might return the same value again. This is a dynamic process depending on actual device sample rates.
3) Not all devices support sample rates as fast as 50ms.

The most time stable readings TC does is when logging, but it might slip other readings in between depending on sample rate and how fast the attached devices are.

Note: TC's readings are generally done in parallel for all active devices, i.e. the sample time is determined by the slowest active device.

Using SCPI commands directly goes around TC's control of readings, but are not compatible between different devices.
 
The following users thanked this post: 2X, MrPete

Offline MrPete

  • Regular Contributor
  • *
  • Posts: 152
  • Country: us
Re: Program that can log/control many multimeters and other devices.
« Reply #6384 on: May 22, 2026, 04:02:53 am »
What do I put into Source Formula for this (slope) type of math calc?
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6385 on: May 22, 2026, 04:17:01 am »
What do I put into Source Formula for this (slope) type of math calc?

It might be as simple as just a column name: Press F2 on the formula to enter editing, then INS or right click to get a list of all column names.
 
The following users thanked this post: MrPete

Offline MrPete

  • Regular Contributor
  • *
  • Posts: 152
  • Country: us
Re: Program that can log/control many multimeters and other devices.
« Reply #6386 on: May 22, 2026, 04:37:16 am »
2) To more carefully calculate dynamic iR (internal resistance), I need to (generically):

(after some setup)
a) read existing current and voltage; bump load amount to a specific value
b) After (ideally) a careful # of milliseconds (probably 40 or 50)
c) read voltage again

crucial values include the specific delay between the two readings. Ideally that is a repeatable number.

Any thoughts about how best to carefully control the delay from load change to second reading??                                                                                                       

That is basically not possible for a couple of reasons:
1) Devices may convert at fixed intervals or they may convert when a value is requested. The first type will always decide the interval by itself, not based on what you want.
2) TC sort of optimize reading of values, i.e. if you request a value very soon after another read, it might return the same value again. This is a dynamic process depending on actual device sample rates.
3) Not all devices support sample rates as fast as 50ms.

The most time stable readings TC does is when logging, but it might slip other readings in between depending on sample rate and how fast the attached devices are.

Note: TC's readings are generally done in parallel for all active devices, i.e. the sample time is determined by the slowest active device.

Using SCPI commands directly goes around TC's control of readings, but are not compatible between different devices.
Thanks...

If I put all of that together, I'm hearing I can perhaps come closest to what is needed through something like:
1) Use a single device if possible
2) Attempt to evaluate available sample rate for the DUT -- in this case minimally the Load

Using tools easily available to me, my simplistic idea for evaluating sample rates:
* For a given device, find a mode that produces continuously slowly-changing readings for TC
* Experiment with high speed logging rates.
* Determine from repeated same-value samples and/or time stamps, what the actual data sampling rate can be for the DUT

In the case of Owon 15xx loads, it has a continuous change mode, and I can set a slow slew rate.

Then, we'll see what is possible.

The only remaining challenge will be the need to filter table samples for the slope calculation. I only want to incorporate a tiny fraction of log samples for the iR slope. For this, I'm guessing:
* I can add a table column with some form of filtering marker for the rows to be used
* In the Math slope calculation, somehow the data source will need to pay attention to the filter mark column

Haven't seen an example of this, but it seems staightforward ;)
 
The following users thanked this post: 2X

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6387 on: May 22, 2026, 05:04:56 am »
Using tools easily available to me, my simplistic idea for evaluating sample rates:
* For a given device, find a mode that produces continuously slowly-changing readings for TC
* Experiment with high speed logging rates.
* Determine from repeated same-value samples and/or time stamps, what the actual data sampling rate can be for the DUT

The log function will not reuse values*, but instead slow down the logging rate.

*TC has a class of devices that work different: TC read the value in the background and any official read will just return the last obtained value. They always has a very fast response and will repeat the same value until a new value arrives. This do not happen with any of the SCPI devices, only with some streaming or poll protocols: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Device_drivers_overview
 

Offline MrPete

  • Regular Contributor
  • *
  • Posts: 152
  • Country: us
Re: Program that can log/control many multimeters and other devices.
« Reply #6388 on: May 22, 2026, 05:46:31 pm »
The log function will not reuse values*, but instead slow down the logging rate.
I am talking about "normal" logging, whatever that is. Not the log math function.

I asume scripted logging can be quite fast, i.e.
Code: [Select]
#log N {filename}
(ASIDE: the docs still say the shortest log interval is 1 second. In 2020 your reduced it to 0.005 -- I assume that's still true? ALSO, that log filename isn't documented. Two key questions: a) does that cause appending to a log file at some interval? b) Does that seriously slow down logging?)

Two related questions/ideas:
* In Math: is it possible to incorporate some kind of filtering function into a math formula, to decide whether or not a given sample should be incorporated into the result? I'm thinking of the equivalent to if(testvar,Device.Voltage,)  ie if testvar==true, return the voltage, else nothing. Then I could have a column that calculates testvar based on whatever conditions I like.

* For my particular case, I'm realizing I have no need to try to squeeze iR calculations into the Math system. This whole thing kinda HAS to be scripted, so I can just write the needed code. ;) -- happy to later help incorporate it into your Battery Test subsystem.
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6389 on: May 24, 2026, 05:27:15 pm »
I am talking about "normal" logging, whatever that is. Not the log math function.

I asume scripted logging can be quite fast, i.e.
Code: [Select]
#log N {filename}
(ASIDE: the docs still say the shortest log interval is 1 second. In 2020 your reduced it to 0.005 -- I assume that's still true? ALSO, that log filename isn't documented. Two key questions: a) does that cause appending to a log file at some interval? b) Does that seriously slow down logging?)

You can always use #COMMANDTIME? to see how fast logging is.
https://lygte-info.dk/project/TestControllerScriptCommands%20UK.html##COMMANDTIME?


Two related questions/ideas:
* In Math: is it possible to incorporate some kind of filtering function into a math formula, to decide whether or not a given sample should be incorporated into the result? I'm thinking of the equivalent to if(testvar,Device.Voltage,)  ie if testvar==true, return the voltage, else nothing. Then I could have a column that calculates testvar based on whatever conditions I like.
A line in math has to produce data for each sample, but you can send a 0 or another dummy value.
The ?: operator can be used for if statements.

* For my particular case, I'm realizing I have no need to try to squeeze iR calculations into the Math system. This whole thing kinda HAS to be scripted, so I can just write the needed code. ;) -- happy to later help incorporate it into your Battery Test subsystem.

I am not sure if I want it :)
 
The following users thanked this post: 2X

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6390 on: May 25, 2026, 02:10:13 am »
I'm nearly done/testing a definition for the Keithley 2010. It should also cover the 2001 and 2002, but I don't have either to test with. If somebody wants to test those meters with this, please let me know.

Thanks,
Josh
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 

Online gby

  • Frequent Contributor
  • **
  • Posts: 272
  • Country: us
Re: Program that can log/control many multimeters and other devices.
« Reply #6391 on: May 25, 2026, 03:54:02 pm »
Heh Josh,

I made a driver file for Keithley 2010 a while ago but have been meaning to improve it some more before sharing.  I don't have Keithley 2001 or 2002 meters...but I could try your driver file with my 2010 and compare to the in progress one I have been using.  My file 2010 only file is attached for your reference.  It is pretty bare bones.
 
The following users thanked this post: KungFuJosh

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6392 on: May 25, 2026, 04:08:11 pm »
Mine's a little more advanced than that, but I didn't include diode. Should I?

ETA: I added Diode.

Thanks,
Josh
« Last Edit: May 25, 2026, 08:16:44 pm by KungFuJosh »
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6393 on: May 25, 2026, 04:08:44 pm »
I found a typo
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6394 on: May 25, 2026, 05:42:05 pm »
I found a typo

That is a word I cannot spell and I forgot to look it up. Now it says customizable in both instances where I use it.
 
The following users thanked this post: KungFuJosh

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6395 on: May 25, 2026, 09:15:27 pm »
Here's my definition for the K2010, K2001, K2002. I don't know yet if this is final.

It's mostly tested on K2010, but I didn't do any temperature testing besides error testing. Feedback would be appreciated from other K2010 users as well.

I would appreciate it if somebody with a K2001 and/or K2002 could test this and let me know if there are any issues.

Check the NOTES: up top if you're using COM port on K2010. Some COM specific commands cause errors with GPIB.

Thanks,
Josh
« Last Edit: May 25, 2026, 09:18:42 pm by KungFuJosh »
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 
The following users thanked this post: 2X

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6396 on: May 26, 2026, 07:03:20 am »
Here's my definition for the K2010, K2001, K2002. I don't know yet if this is final.

I have added them, thanks.

Check the NOTES: up top if you're using COM port on K2010. Some COM specific commands cause errors with GPIB.

It is possible to modify definition behavior depending on connection, there is a "portType" variable.
 
The following users thanked this post: KungFuJosh

Offline HKJTopic starter

  • Super Contributor
  • ***
  • Posts: 4777
  • Country: dk
    • Tests
Re: Program that can log/control many multimeters and other devices.
« Reply #6397 on: May 26, 2026, 07:34:19 am »
V3.04 is up
It got a new automatic test function, more bench meters and a lot of modules

   Added: Keithley 2001, 2002, 2010 Bench DMM's (Thanks KungFuJosh)
   Added: PS and DC/DC converter automatic test, it controls a load, a source, thermometers and DMM's
   Updated: Minor modifications to battery test
   Added: Elecdemo YK-LED23004M, YK-LED23006M 4 & 6 digit 7 segment display module (Thanks Flash2b)
   Added: Elecdemo YK-LED3604M, YK-LED3605M, YK-LED3606M, YK-LED5604M, YK-LED5605M, YK-LED4006M, YK-TMLED3904M, YK-MILED3906M 7 segment display module (Thanks Flash2b)
   Added: Ebyte AXCX4020, XACX0420, AACX2220, AXCX4040, XACX0440, AACX2240 and XXCX0080 Isolation AI-DI-DO module (Thanks Flash2b)
   Added: UNI-T UT8805 DMM (Thanks squirrax)
   Updated: HSPY-400-1 and Kunkin KP184 to support modbus sharing interface (Thanks Flash2b)
   Updated: Flash2b has updated all Eletechsup and a few other to support the modbus sharing
   Updated: GWInstek GPP-4323 Power supply, names adjusted (Thanks flash2b)



It works in a way very similar to the battery test.

The new automatic test function can test power supplies and DC/DC converters, it will do 3 type of test:
Point: Test a specific working point and record all data in a table.
Load sweep: Sweep load from 0 to maximum while recording data
Load test: Run for some time with a specific load (Useful for logging working temperature).
All tests can automatic be performed at a couple of different voltage and currents.
Charts and CSV files are saved of all tests.

Help page for function: https://lygte-info.dk/project/TestControllerPopupPSTest%20UK.html
Power supply test example: https://lygte-info.dk/project/TestControllerPopupPSTestExampleAC%20UK.html
DC/DC converter example: https://lygte-info.dk/project/TestControllerPopupPSTestExample%20UK.html

The popup may still have issues, it support a wide variety of configuration and I have not tested all of them.
Also not default parameters are for testing the popup, the test time must be much longer to do real tests.
 
The following users thanked this post: flash2b, KungFuJosh

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6398 on: May 27, 2026, 03:12:43 pm »
It is possible to modify definition behavior depending on connection, there is a "portType" variable.
Thanks. I checked the Fluke 8846A definition and see how they used it. I'll do that for a future version.

Thanks,
Josh
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 

Online KungFuJosh

  • Super Contributor
  • ***
  • Posts: 8203
  • Country: us
  • TEAS is real.
Re: Program that can log/control many multimeters and other devices.
« Reply #6399 on: May 27, 2026, 03:26:27 pm »
The future is now! 🤯

if somebody using a COM port wants to test these, that'd be great, thanks. 😉

No issues with this change using my 2010 on GPIB. I can't test on a 2700 anymore.

Thanks,
Josh
« Last Edit: May 27, 2026, 06:20:56 pm by KungFuJosh »
"Experience is something you don't get until just after you need it." - Steven Wright
Best Continuity Tester Ever
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf