Program that can log from many multimeters.

[KungFuJosh]

HKJ, edited the SDM 30xxx and attached, have commented out the (hacked) 3055X-E version, also renamed the file slightly to add a space to change it from "SiglentSDM30xxx" to "Siglent SDM30xxx", so it matches the naming conventions of other units, watch out if you just drop it into the folder as you may end up with 2 versions.

If you want to leave the *RST command in there, I'd suggest adding a note that it defaults the meters to factory defaults, and that *RST should be removed to avoid that. Personally, I prefer it removed.

Thanks,
Josh

[KungFuJosh]

Is there a way to get TC to do that auto-discovery when the device list isn't empty? I like the way that works better than manually adding devices.

Not really.

Call it a feature request then. 😉

Understanding its limitations, etc., it's still a nice feature and discovers / adds most devices. It takes less time to delete all devices and have it find them all, and it avoids an issue with manually adding devices that's weird sometimes.

I have 6 devices on my desk connected to TC right now. I need to add a definition eventually for a 7th.

Thanks,
Josh

[HKJ]

Is there a way to get TC to do that auto-discovery when the device list isn't empty? I like the way that works better than manually adding devices.

Not really.

Call it a feature request then. 😉

Understanding its limitations, etc., it's still a nice feature and discovers / adds most devices. It takes less time to delete all devices and have it find them all, and it avoids an issue with manually adding devices that's weird sometimes.

I have 6 devices on my desk connected to TC right now. I need to add a definition eventually for a 7th.

Thanks,
Josh

Generally you are supposed to have all your devices on the loaded page and then checkmark the ones you want to use.

If the devices has changing IP address, use LXI connection. If a device is missing LXI on the #port line in the definition, try adding it and see if it works. If it does please post a notice here.

I am not that happy about the discovery command, it stops some of my LXI devices and that is a big issue if they are part of a automatic test setup (I am running multiple concurrent test setups on my network).

I have been thinking about adding a discovery button to the "Load devices" page, but because I don't see that much use for it (and the above issue), I have not done it.

[HKJ]

Understanding its limitations, etc., it's still a nice feature and discovers / adds most devices. It takes less time to delete all devices and have it find them all, and it avoids an issue with manually adding devices that's weird sometimes.

You can make TC start with a empty device list by deleting the file:

...\Documents\TestController\Settings\settingsLoad.txt

I.e. using a .bat file to delete the file and then start TC would make it start empty each time.
But be warned it will trigger a few extra things because it is the way TC detect a new installation.

Note: Each page in TC has its own configuration file, deleting that file will reset that page to initial state, but not change other settings in TC.

[KungFuJosh]

For me it would be useful when adding new devices.

I would think you can add logic to the feature to ignore devices/IP addresses already listed settingsLoad.txt?

The issue I had was adding the DAQ6510. When I manually added it by IP, it came up with 2 device options, with odd labels. I cleared the device list, and used the automatic LXI discovery, and it detected it properly.

Thanks,
Josh

[TheDefpom]

HKJ here is the video where I show Test Controller on the SDM4306X (towards the end of the video), in case you want to add it to your videos list.

https://www.youtube.com/watch?t=1396&v=25uQlBI0REg

[HKJ]

I would think you can add logic to the feature to ignore devices/IP addresses already listed settingsLoad.txt?

Of course, but what if I have device X on IP1 and next time find device X on IP2? Is it the same device or another device (TC do not remember serial numbers)?

The issue I had was adding the DAQ6510. When I manually added it by IP, it came up with 2 device options, with odd labels. I cleared the device list, and used the automatic LXI discovery, and it detected it properly.

Can you give a better explanation of this, there is not supposed to be any difference between automatic and manual.

[HKJ]

HKJ here is the video where I show Test Controller on the SDM4306X (towards the end of the video), in case you want to add it to your videos list.

https://www.youtube.com/watch?t=1396&v=25uQlBI0REg

I have seen the video and added it.
I am a bit disappointed you do not use the logging facilities, but if you do not need to do longer or automatic test, you do not need it.
TC can do the step function can with any power supply and it can be done two ways:
1) Param sweeper (this can only vary one parameter at a time).
2) Script. This is very simple to configure (TC writes most of the script) and very flexible. I can explain more about it if anybody wants to know more.

[KungFuJosh]

I would think you can add logic to the feature to ignore devices/IP addresses already listed settingsLoad.txt?

Of course, but what if I have device X on IP1 and next time find device X on IP2? Is it the same device or another device (TC do not remember serial numbers)?

You could add a note that the function works better with static IPs. Or that devices with dynamic IPs that changed should be removed first so they can either be readded via this new function, or adjusted manually for their new IP address(es).

My device IPs will always be static, dynamic IPs don't make sense to me for equipment that needs to be connected to regularly.

The issue I had was adding the DAQ6510. When I manually added it by IP, it came up with 2 device options, with odd labels. I cleared the device list, and used the automatic LXI discovery, and it detected it properly.

Can you give a better explanation of this, there is not supposed to be any difference between automatic and manual.

I should have taken a screenshot, but I didn't. I manually added the DAQ6510 via the IP. When I restarted TC, it discovered two devices at the IP. One was name DAQ6510_40 and the other DAQ6510_2 or something like that. IIRC, only one of them was pushing data.

I could try to make it happen again if you want.

Thanks,
Josh

[Hexley]

I am a bit disappointed you do not use the logging facilities, but if you do not need to do longer or automatic test, you do not need it.
TC can do the step function can with any power supply and it can be done two ways:
1) Param sweeper (this can only vary one parameter at a time).
2) Script. This is very simple to configure (TC writes most of the script) and very flexible. I can explain more about it if anybody wants to know more.

Yes, please -- a tutorial on TC scripting would be very nice to have!

[KungFuJosh]

HKJ here is the video where I show Test Controller on the SDM4306X (towards the end of the video), in case you want to add it to your videos list.

I think you might enjoy spending some more time messing with TC. In the current value screen, right-click the value for any given item in that list, and you can choose the digits and type of display. Click SI as an example. Then make a popup for a specific device, and you'll get some great info to go with whatever you're doing.

As HKJ said, it would be good also to use the chart function. Edit the values on the Scales for chart tab, then start the Log from the Commands tab, and finally view the Chart tab. It might be a little boring for a DC PSU, but it's quite useful in general. Attached is a comparison test I used it for. It shows an example of the chart and the awesome popups.

Thanks,
Josh

[HKJ]

I should have taken a screenshot, but I didn't. I manually added the DAQ6510 via the IP. When I restarted TC, it discovered two devices at the IP. One was name DAQ6510_40 and the other DAQ6510_2 or something like that. IIRC, only one of them was pushing data.

I could try to make it happen again if you want.

I would like to know more.

[HKJ]

Yes, please -- a tutorial on TC scripting would be very nice to have!

It was not a full tutorial I was thinking about, but only how to configure devices.

Here is the first version of it:
https://lygte-info.dk/project/TestControllerScript1%20UK.html

It do also contains some general information about how to use scripting in TC.

I will probably refine it a bit over time and then add it to the general list of TC pages.
Everybody is welcome to post suggestions, questions, etc. to and about it.

[Bad_Driver]

Sorry for coming up with a very simple problem but I'm lost in the mighty possibilities of TestController.
My programming abilities end 40 years ago with PASCAL (someone remembering PASCAL?)

I want to setup a simple device driver for a device which sends via net socket Port 23 all 2 seconds a value (Temperature, looks like "21.4" CR/LF) - checked with a Telnet client. The device is only sending.
I went through the forum and the web pages and assume that I have to use the singleValue driver.

My setup looks like:
----------------------------------------------------------------------------------------------------------------
#author bad_driver
#idString ESPeasy,Temp
#name ESPeasy Temp
#handle ESP1
#port 23
#eol \_
#driver SingleValue

#value Temperature °C d4 TEMPC

#askValues poll
--------------------------------------------------------------------------------------------------------------
Starting
;; jSerialComm version: 2.10.3
;; Start thread for: 192.168.178.48 - ESPeasy Temp
;; Found ESPeasy Temp on 192.168.178.48
;; Mode reported: <>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
-----------------------------------------------------------------------------------------
I'm pretty sure that #askValues is wrong but I can't find the right command for polling the values.
Please help!

[HKJ]

Sorry for coming up with a very simple problem but I'm lost in the mighty possibilities of TestController.
My programming abilities end 40 years ago with PASCAL (someone remembering PASCAL?)

I liked Pascal and Delphi as it evolved into (Not really correctly formulated, the Delphi Pascal was evolved into a significantly extended version of regular Pascal).

I want to setup a simple device driver for a device which sends via net socket Port 23 all 2 seconds a value (Temperature, looks like "21.4" CR/LF) - checked with a Telnet client. The device is only sending.
I went through the forum and the web pages and assume that I have to use the singleValue driver.

SingleValue driver is fine for this (AsciiBlock could also be used, but it a bit more complicated).
But:
Get rid of the #eol that do not match a CR/LF (A "#eol \r\n" would, but it not needed).
Only use a #askValues if you need to poll for the value and then you need to put the actual poll after the #askValues, for devices that sends automatic your do not want a #askValues.

[Bad_Driver]

SingleValue driver is fine for this (AsciiBlock could also be used, but it a bit more complicated).
But:
Get rid of the #eol that do not match a CR/LF (A "#eol \r\n" would, but it not needed).
Only use a #askValues if you need to poll for the value and then you need to put the actual poll after the #askValues, for devices that sends automatic your do not want a #askValues.

Thanks for the fast reply! Is Delphi still existing?
I cleaned up my definition, but it is not working. There is still the Tx-command.
See definition and report:
-------------------------------------------------------------------------------------
#author bad_driver
#idString ESPeasy1,Temp
#name ESPeasy1 Temp
#handle ESP1
#port 23
;#eol \r\n
#driver SingleValue

#value Temperature °C d4 TEMPC
------------------------------------------------------------------------------------

;; jSerialComm version: 2.10.3
;; Start thread for: 192.168.178.38 - ESPeasy1 Temp
;; Found ESPeasy1 Temp on 192.168.178.38
;; Mode reported: <>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout

[KungFuJosh]

I should have taken a screenshot, but I didn't. I manually added the DAQ6510 via the IP. When I restarted TC, it discovered two devices at the IP. One was name DAQ6510_40 and the other DAQ6510_2 or something like that. IIRC, only one of them was pushing data.

I could try to make it happen again if you want.

I would like to know more.

I tried to recreate the bug, and instead it worked the way it's supposed to. Maybe I had tried with a previous version or something. 🤷

Thanks,
Josh

[HKJ]

Thanks for the fast reply! Is Delphi still existing?

Maybe, but it moved away from a Pascal development system to a more application development system. I dropped it long time ago.

I cleaned up my definition, but it is not working. There is still the Tx-command.
See definition and report:
-------------------------------------------------------------------------------------
#author bad_driver
#idString ESPeasy1,Temp
#name ESPeasy1 Temp
#handle ESP1
#port 23
;#eol \r\n
#driver SingleValue

#value Temperature °C d4 TEMPC
------------------------------------------------------------------------------------

;; jSerialComm version: 2.10.3
;; Start thread for: 192.168.178.38 - ESPeasy1 Temp
;; Found ESPeasy1 Temp on 192.168.178.38
;; Mode reported: <>
;; ESP1: Tx <VALUE?>
;; ESP1: Rx Timeout
;; ESP1: Rx as numbers <No data (timeout?)>

There is a few issues:
1) The TEMPC in the #value line prevent it from being displayed, except if you receive a line with "TEMPC" in it.
2) Your update rate is too slow for default settings, a #readingDelay line is needed to handle that.
3) Do not worry about the TX log message, that is internal communication in TC.

Try this:
#author bad_driver
#idString ESPeasy1,Temp
#name ESPeasy1 Temp
#handle ESP1
#port 23
;#eol \r\n
#driver SingleValue
#readingDelay 3000
#value Temperature °C d4

[HKJ]

I tried to recreate the bug, and instead it worked the way it's supposed to. Maybe I had tried with a previous version or something. 🤷

I suspect you might have queried twice, there is no interlock on sockets to prevent that.

[Bad_Driver]

Try this:
#author bad_driver
#idString ESPeasy1,Temp
#name ESPeasy1 Temp
#handle ESP1
#port 23
;#eol \r\n
#driver SingleValue
#readingDelay 3000
#value Temperature °C d4

Thanks! Got it working! But I changed "d4" to "d1" which makes more sense and I reduced the cycle time of the sensor to 1 sec.
I have now a simple way for connecting sensors without cabling (no USB or Serial) but via WiFi to TestController with "Low-Coding".
I will later report how it works. Maybe it's interesting for others.

Last question: what is #readingDelay 3000 doing?
I can log with 1 sec and get every second a value.

[HKJ]

Thanks! Got it working! But I changed "d4" to "d1" which makes more sense and I reduced the cycle time of the sensor to 1 sec.
I have now a simple way for connecting sensors without cabling (no USB or Serial) but via WiFi to TestController with "Low-Coding".
I will later report how it works. Maybe it's interesting for others.

I have a project page associated with TC where I publish project from other people.
https://lygte-info.dk/project/TestControllerUserProjects1%20UK.html

Last question: what is #readingDelay 3000 doing?
I can log with 1 sec and get every second a value.

#readingDelay sets the communication timeout for reading values, there is another delay that can be used for mode changes.

A high value of #readingDelay may slow TC down when the connection fails. With 1 sec transmission a #readingDelay 1500 or #readingDelay 2000 would be fine (Time is on milli seconds).


One of the ideas with TC was to make it easy to connect home-made sensors, but my examples are mostly for serial:
https://lygte-info.dk/project/TestControllerArduino1%20UK.html
https://lygte-info.dk/project/TestControllerArduino2%20UK.html

[le_avion]

I am having a problem getting the program to work with my BM869s in Linux. The program works fine in Windows 11 but my main machine is a Linux machine.

USB-HID is only supported on Windows, sorry about that.

I am not sure why I didn't get a notification when you posted your reply so I didn't see it until now.

Is this a limitation of Linux, the application, or the library used?

[HKJ]

Is this a limitation of Linux, the application, or the library used?

I am not quite sure. The library works fine for finding devices, but I could not get communication working. On windows you can access the device as a file (With the found name) instead and that is not possible on Linux.

[ZhuraYuk]

Does anyone figured a way for TestController to work with NI GPIB-USB-HS adapters? These are cheap  and available everywhere.

[Messtechniker]

Cheap at $ 1000+ ?