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

[NoDisintegrations]

Corrected and tested!

(Updated V1.31 definition file attached)

Thanks, I have added it.

When reading you comments i the file I starting wondering? Do KUAIQU  also sell these supplies marked NICE-POWER?
If they do, you are allowed to double you metadefs and use that name also (But keep the filename).
Generally people must be able to find the device from its marking, and do not need to know the OEM.
I do not know how many brands for single definition is record in TC, but there are some with multiple brands.

Grand. Thank you for writing the actual Test Controller software and making it available, with documentation!

I had a look into the KUAIQU vs NICE-POWER branding, from what I could see the model numbers aren't interchangeable between the two.
It seems like they're both actively offered by the same manufacturer but targeting different use cases/markets.

The closest physical match to the KUAIQU SPPS3010D that I found was the NICE-POWER SPPS-A3010D model (which doesn't have the 4 memory buttons). Then there's also a NICE-POWER R-SPS3010D, and a NICE-POWER SPS3010D.
All completely different products.

Then when looking into the KUAIQU product pdfs, I noticed yet another series with very similar naming, the KUAIQU SPPS-D series (SPPS-D305, SPPS-D3010, etc).
https://cdn.shopify.com/s/files/1/0705/8027/3329/files/SPPS-D-232_Memory_Type_Manual.pdf?v=1751964116

I wouldn't be surprised if they all use the same protocol, so long as they have the USB / RS232 comms interfaces.

I suspect the most sensible approach may be to duplicate and modify the "KUAIQU SPPS Series.txt", using it as a base, specifically for each series or brand, as required. (i.e. "KUAIQU SPPS-D Series.txt", "KUAIQU SPS-C-S Series.txt", "NICE-POWER SPPS-C-C Series.txt" etc).
Otherwise the resulting file might become a barely maintainable naming nightmare. I can already imagine the definitions folder looking crazy with all the different KUAIQU and NICE-POWER series, nevermind the #metadefs in each file. And with enough of those altogether, the Load Devices dropdown will be 60% KUAIQU and NICE-POWER all with very similar names...

[flash2b]

Yes and if you type only 3010 or 305 you will also see all the other competitor brands. In china they like to use the same number for different brands, even if the number doesn't mean anything unlike for the PSU example.

Now many KUAIQU/NICE-POWER PSUs do not have a usb/rs232 port standard. Same with the many eTommens series.

[flash2b]

One more device then... we want to hit the 1000 devices support mark this year !

I will probably happen.
Current it is at 970 with NoDisintegrations contribution, but I need to subtract a bit from that for my own private devices and virtual devices. I.e. about 60 devices more and I will officially say 1000 devices supported.

Well I will release a new definition this month for sure, and maybe more. So you can put with pencil +3 already 

[HKJ]

Grand. Thank you for writing the actual Test Controller software and making it available, with documentation!

I could not have made all the definitions, I did make definitions for most of my equipment. But some people have made better definitions that have replace a few of them.
There are also people that are good at making nice configurations, KungFuJosh has haunted me for some nicer UI elements on the popup and he uses them to make them look very nice.

I suspect the most sensible approach may be to duplicate and modify the "KUAIQU SPPS Series.txt", using it as a base, specifically for each series or brand, as required. (i.e. "KUAIQU SPPS-D Series.txt", "KUAIQU SPS-C-S Series.txt", "NICE-POWER SPPS-C-C Series.txt" etc).
Otherwise the resulting file might become a barely maintainable naming nightmare. I can already imagine the definitions folder looking crazy with all the different KUAIQU and NICE-POWER series, nevermind the #metadefs in each file. And with enough of those altogether, the Load Devices dropdown will be 60% KUAIQU and NICE-POWER all with very similar names...

You know what #metadef can do now and it is the most sensible solution when devices are very similar, TC will load them considerable faster, than a separate file.
I do not really worry about the dropdown, put a few letter or a number in the search box and only a few entries are left.

[flash2b]

I do see a Java exception when previewing the new KUAIQU definitions.

Code: [Select]

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at dk.hkj.devices.SetupFormats$IndicatorField.syncValue(SetupFormats.java:3967)
        at dk.hkj.devices.SetupFormats.syncValue(SetupFormats.java:459)
        at dk.hkj.devices.SetupFormats.syncher(SetupFormats.java:511)
        at dk.hkj.devices.SetupFormats.requestSync(SetupFormats.java:538)
        at dk.hkj.devices.SetupFormats.requestSync(SetupFormats.java:519)
        at dk.hkj.devices.SetupFormats$UpdaterField.actionPerformed(SetupFormats.java:4177)
        at javax.swing.Timer.fireActionPerformed(Unknown Source)
        at javax.swing.Timer$DoPostEvent.run(Unknown Source)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$500(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at dk.hkj.devices.SetupFormats$IndicatorField.syncValue(SetupFormats.java:3967)
        at dk.hkj.devices.SetupFormats.syncValue(SetupFormats.java:459)
        at dk.hkj.devices.SetupFormats.syncher(SetupFormats.java:511)
        at dk.hkj.devices.SetupFormats.requestSync(SetupFormats.java:538)
        at dk.hkj.devices.SetupFormats.requestSync(SetupFormats.java:519)
        at dk.hkj.devices.SetupFormats$UpdaterField.actionPerformed(SetupFormats.java:4177)
        at javax.swing.Timer.fireActionPerformed(Unknown Source)
        at javax.swing.Timer$DoPostEvent.run(Unknown Source)
        at java.awt.event.InvocationEvent.dispatch(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$500(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Caused by ?

[HKJ]

I do see a Java exception when previewing the new KUAIQU definitions.

Thanks, it is fixed from next version.

[flash2b]

It was not caused by the defintion then ?

:update:Output_State;High_Voltage_Warning; should be :update: Output_State High_Voltage_Warning or does it work both ?

[HKJ]

It was not caused by the defintion then ?

It was not due to a issue in the definition, but because I tried defining variables for port, when no port are defined!

:update:Output_State;High_Voltage_Warning; should be :update: Output_State High_Voltage_Warning or does it work both ?

I always uses a space after a tag, but I am not sure it is necessary.

[NoDisintegrations]

That Java exception didn't appear for me during any of my tests, but I was using the latest .jar file.

However, I did manage to catch a couple mistakes which I've now corrected.
One was a horror that was causing peaks and dips when the definition was used in a sweep test.

I've also corrected the :update: syntax, pointed out by flash2b.

(Updated V1.32 definition file attached) with screenshots.

[HKJ]

That Java exception didn't appear for me during any of my tests, but I was using the latest .jar file.

You did not try a preview. This is activated by selecting the device in the combobox on the "Load Devices", then right-click and select preview. It will show the mode and setup popups without anything connected, it will also show a bit more information.

Also: Exceptions are only shown in debug mode, because they are output to console and usually TC do not have a console window. You can always check if you can see exceptions, type: =1/0 on the command line, it will dump a lot of exception lines (I checked, I get about 100 lines).

However, I did manage to catch a couple mistakes which I've now corrected.
One was a horror that was causing peaks and dips when the definition was used in a sweep test.

I've also corrected the :update: syntax, pointed out by flash2b.

File updated, thanks.

Note: Always look for my updated/added or similar post, it has a couple of purposes:
1) It shows I did not miss the definition.
2) Do not do silent updates to the file after I have posted the message and if you did one within the last hour, it is probably a good idea to notify me about it.

My general workflow is: Download the file, copy it to the devlop version of TC, update the "Versions.dat" file, then post the message.

[NoDisintegrations]

File updated, thanks.

Note: Always look for my updated/added or similar post, it has a couple of purposes:
1) It shows I did not miss the definition.
2) Do not do silent updates to the file after I have posted the message and if you did one within the last hour, it is probably a good idea to notify me about it.

My general workflow is: Download the file, copy it to the devlop version of TC, update the "Versions.dat" file, then post the message.

Sure, I'll keep the above in mind.

[flash2b]

Dear HKJ,

I have added the full Tasi TDB and TDC series PSU's to an existing definition. New version supports: Tasi TDB155, TDB305, TDB3010, TDB605, TDB1003, TDC4020, TDC8010 and TDC1605.

So 8 more devices supported by TC !

[ Attachment Invalid Or Does Not Exist ]

PS.
I now also get the same java error on preview as the KUAIQU definitions, but probably the same fix will fix it.

[HKJ]

I have added the full Tasi TDB and TDC series PSU's to an existing definition. New version supports: Tasi TDB155, TDB305, TDB3010, TDB605, TDB1003, TDC4020, TDC8010 and TDC1605.

So 8 more devices supported by TC !

PS.
I now also get the same java error on preview as the KUAIQU definitions, but probably the same fix will fix it.

Added, thanks.
I expect it is the same reason for the exception.

[flash2b]

Did you see this: https://www.eevblog.com/forum/testgear/open-source-optical-interface-for-brymen-bm86x-multimeters/

and interface here: https://github.com/Tykyo/qt-brymen-86x-firmware

I do not have any Brymen stuff, but sounds interesting. Did not investigate if it is a pro version of some interface already posted.

[HKJ]

Did you see this: https://www.eevblog.com/forum/testgear/open-source-optical-interface-for-brymen-bm86x-multimeters/

and interface here: https://github.com/Tykyo/qt-brymen-86x-firmware

I do not have any Brymen stuff, but sounds interesting. Did not investigate if it is a pro version of some interface already posted.

I do not know how interesting they are, you can easily buy Brymen interfaces and they all work with TC.

Something for UNI-T that uses serial instead of HID would be more interesting.

[flash2b]

Someone should make a Bluepill implementation using https://docs.tinyusb.org/en/latest/examples/dual/host_hid_to_device_cdc.html for that.

As I understand it, that could potentially bridge any HID to appear as CDC.

[HKJ]

Someone should make a Bluepill implementation using https://docs.tinyusb.org/en/latest/examples/dual/host_hid_to_device_cdc.html for that.

As I understand it, that could potentially bridge any HID to appear as CDC.

That is one part of it, the other part is making a adapter. 3D print is good for that and 3D printers are common today.

[linux-works]

I just created some esp32 code to implement a touch-hold feature for one of my meter (agilent) and am planning to add others.  if you have not used a meter with touch-hold, the idea is that it tracks the values and knows what 'lift up probes' means (inf. ohms on that mode, near 0 volts on volts mode, etc) and then when it sees a value, it waits for some convergence factor and then freezes the value, along with a tone/beep.  you are probing a close area and dont want to short probes, so you want to keep your eyes on them.  but you need to capture a value.  touch-hold lets you do that, wait for the beep and then remove probes and look at the display.

would this fit into this eco-system at all? 

[HKJ]

I just created some esp32 code to implement a touch-hold feature for one of my meter (agilent) and am planning to add others.  if you have not used a meter with touch-hold, the idea is that it tracks the values and knows what 'lift up probes' means (inf. ohms on that mode, near 0 volts on volts mode, etc) and then when it sees a value, it waits for some convergence factor and then freezes the value, along with a tone/beep.  you are probing a close area and dont want to short probes, so you want to keep your eyes on them.  but you need to capture a value.  touch-hold lets you do that, wait for the beep and then remove probes and look at the display.

would this fit into this eco-system at all?

TC has this build in, it is the popup "Auto hold"
It can even type the value into another program each time it holds.

[linux-works]

this is the esp32 solution I came up with, its fully standalone but can also talk to a pc (python) over serial console.

its the famous CYD module and I divided the screen into the current value (big green), last value (smaller yellow, above) and then further back history is the stack on the left.  top buttons let you show it in EE mode, full digit mode, or rounded and the number buttons are the sig figs.  M is manual mode (tap screen to take value) or A for auto mode (polls continuously to find converged value). 

so you dont need a pc and this can be wired or BLE connected to a few meters and the cyd is battery powered, so its fully portable.

I did not want to have to use a pc just to have this feature.

full disc: claude helped me put together various modules I wrote before and did the UI coding for me.  some may like that, some may not.

I can put my source up if anyone wants.  currently it talks to agilent handheld optical ports but a few consumer BLE models are planned.  again, I dont want to have to have a pc there, but a pc connected does add value.

[flash2b]

With support of Claude AI Opus 4.8, I've reviewed all my 29 definitions previously released, so 18,291 lines of definition code analyzed in total.

My changelog is a follows:

New version released — functional fix shipped (12)
BSide I8.txt 1.08 389 setOPP write factor /1000 → *1000
XY MD02 SHTC3.txt 1.04 248 corrHumi read /100 → /10
Qixin QXDOxx.txt 1.01 656 toggleDutyCycleCH3 var + DO12 setAllOff
Elecdemo YKAO23xxx.txt 1.03 1114 3 toggle-vars + 2 scaled-current factors
Eletechsup DM56A04 DM36B06.txt 1.04 916 displayFloat +2 digit target
Eletechsup NT38D01.txt 1.03 277 KOHM → OHM selector + readValue
Eletechsup PT21x01.txt 1.03 251 #replaceText → #replacetext (case-sensitive)
ComWinTop BSRxA02B.txt 1.02 463 toggleVoltageCH2 saved to wrong variable
Eletechsup 10IOAxx.txt 1.04 507 CH5-8 input matchBits + tips
Eletechsup N4IOA01.txt 1.05 294 scaleCurrentCH2 → scaleCurrent + vars
Eletechsup N4DBA06.txt 1.05 601 Input-ratio CH2 wrong channel + 4 missing write cmds
Ebyte EID511xx.txt 1.03 890 && → & decode + lastValue saving

No new version — fixed in-place, cosmetic, or clean (17)
Eletechsup NT18B07.txt 1.03 247 Clean
Eletechsup NT28B16.txt 1.03 587 Clean
Eletechsup NT48xxx.txt 1.04 956 CH22 widget name (cosmetic)
Ebyte EID041-G01x.txt 1.02 166 Clean
LC Tech LCUSx.txt 1.00 421 Clean
Eletechsup UD2xx0x N22xx0x.txt 1.00 518 Clean
Analogic DP100.txt 1.03 373 Clean
Hameg HM8112.txt 1.06 567 Clean
Owon LCR2000.txt 1.02 919 Clean
Eletechsup N4DAC02.txt 1.04 395 Clean
Eletechsup DM18xxx.txt 1.02 1028 Ask2 Special0 out-of-range writeDigit (fixed in-place)
eTommens eTMP.txt 1.02 546 eTM-1003P MaxCurrent 2.10 → 3.10 (fixed in-place)
eTommens eTMMP.txt 1.03 657 TDB155 / TDC8010 / TDC1605 / 1003 fixes (in-place)
Elecdemo YKLED230xxM.txt 1.01 694 Clean (cosmetic only)
Elecdemo YKLED36xxM 56xxM 4006M TMLED3904M MILED3906M.txt 1.01 795 Clean (cosmetic only)
Ebyte MA0xxxCXxxx0.txt 1.03 873 XACX0420 follow In3/In4 + AI3/AI4 cleanup (in-place)
Yokogawa 75517552.txt 1.10 1435 KB cache var + HZ/Hz removes + AC-current dB check (in-place)

So 29 updated files are attached, for the next release of TestController.

I did the fixes/updates myself and checked/discussed the AI verdict and remarks. Most errors were copy/paste mistakes and a lot were not critical.

[ Attachment Invalid Or Does Not Exist ]

[HKJ]

With support of Claude AI Opus 4.8, I've reviewed all my 29 definitions previously released, so 18,291 lines of definition code analyzed in total.

Updated, thanks

[HKJ]

V3.48 is up
The main feature is a new test popup, but there is also a nice selection of new devices and updates in addition to a bug fix.
   Updated: Flash2b has updated 29 of his definitions mostly minor stuff (Thanks Flash2b)
   Added: Tasi TDB155, TDB305, TDB3010, TDB605, TDB1003, TDC4020, TDC8010, TDC1605 Power supply (Thanks Flash2b)
   Added: KUAIQU (NICE-POWER) SPPS305D, SPPS3010D, SPPS605D, SPPS1203D, SPPS3206D, SPPS2001D, SPPS3001D, SPPS4001D Power supply  (Thanks NoDisintegrations)
   Updated: EByte module names to avoid conflict with other EByte modules (Thanks Flash2b)
   Updated: Eletechsup DM56A04 DM36B06 Remote readouts (Thanks Flash2b)
   Added: Agilent E4428C, Agilent E4438C Signal generator (Thanks KungFuJosh)
   Fixed: Saving script on function keys, it could only handle one line.
   Added: Steps popup, this is a popup that makes it possible to do multichannel timed sequences
   Updated Owon LCR, more unicode characters (Thanks Flash2b)
   Updated: Elecdemo devices to avoid timeout errors (Thanks Flash2b)
   Added: Agilent 33250A ARB (Thanks Cyclotron)
   Updated: HIOKI LCR meters (Thanks KungFuJosh)
   Updated: Owon LCR (Thanks Flash2b)
   Added: Anbai AT810A, Applent AT810A, LCR (Thanks Flash2b)
   Added: Leo Bodnar LBE-1420 GPS (Thanks Cyclotron)



The new test popup is a table, with a time list and values that is send to devices at specific times. It support more device settings than param sweeper, i.e. it is possible to turn devices on/off or switch relays. It can generate slopes and there is a preview function of the settings.
Manual: https://lygte-info.dk/project/TestControllerPopupSteps%20UK.html

The devices from NoDisintegrations is a interesting story in developing a definition, it starts here: https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg6327516/#msg6327516

If some people missed it: Cyclotron has published a very interesting project https://github.com/Cyclotronic/VMSG that makes it possible for TC to connect to VISA devices.

[flash2b]

The new Steps popup is also very handy for regression testing while coding a definition and since you can save the setup, you can easily re-run your test after making changes.

I like the graphical output a lot.

[KungFuJosh]

It's receiving all zeros, right? What does TC show?