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

[flash2b]

My new definition (6CH) has almost passed its burn-in and harsh code review test.




I got 2 new Ktype (ANSI MC96.1) thermocouples in today, and hooked one up to CH1 (red) and 1:44 later CH2 (blue). Then I calibrated CH1 on 1:51 and they were in sync. I removed the plug from the one connected to CH2, which gives better results.

My definition also supports PT100 (4CH) for people dislike thermocouples and support a choice of RS485, Shared RS485 and Ethernet for connectivity, including per-channel offset calibration and full network setup from inside TestController. (last one is running now).

[flash2b]

I have added 2 devices to an existing definition: Weirui TS85-A and TS85-B. These support CO and CO2 as well.

Please add file to the next release of TC.

 XY MD02 SHTC3.zip (2.91 kB - downloaded 6 times.)

[HKJ]

I got 2 new Ktype (ANSI MC96.1) thermocouples in today, and hooked one up to CH1 (red) and 1:44 later CH2 (blue). Then I calibrated CH1 on 1:51 and they were in sync. I removed the plug from the one connected to CH2, which gives better results.

With thermocouplers you have to watch out for the connectors.

I had some fun here: https://lygte-info.dk/project/ThermoSensor%20UK.html

[flash2b]

Could @Cyclotron please change #name LBE-1420 GPS to #name Leo Bodnar LBE-1420 GPS in the definition?

(more consistency)

Don't forget to reload the definition or edit settingsLoad.txt adding the same there as well !

[HKJ]

I have added 2 devices to an existing definition: Weirui TS85-A and TS85-B. These support CO and CO2 as well.

Added, thanks.

[flash2b]

Here it is: my 30th definition for TestController, adding support for the Ebyte ME31 series Temperature Acquisition modules.

Six new entries, covering four modules:

• ME31-XEXX0600 - 6 channel K-type, -200 to +1350 C (Ethernet and RS485 entries)
• ME31-XEXX0800 - 8 channel K-type, -200 to +1350 C
• ME31-XDXX0400 - 4 channel PT100, -200 to +850 C (Ethernet and RS485 entries)
• ME31-XDXX0800 - 8 channel PT100, -200 to +850 C

Connectivity is RS485, Shared RS485 or Ethernet. The 0600 and 0400 models also have an OLED display and keys, so they can be used stand alone without TestController.

From inside TestController you get per-channel offset calibration and full network setup: IP address, subnet, gateway, DNS, working mode and port.

The result is solid temperature logging, without needing to know that it is all Modbus under the hood.

Requires TestController v3.51 or newer.



HKJ, this definition is the first to use Modbus TCP and please add it to the next release of TestController.

 Ebyte ME31-XEXX0x00 XDXX0x00.zip (6.28 kB - downloaded 8 times.)

[HKJ]

Here it is: my 30th definition for TestController, adding support for the Ebyte ME31 series Temperature Acquisition modules.

Six new entries, covering four modules:

• ME31-XEXX0600 - 6 channel K-type, -200 to +1350 C (Ethernet and RS485 entries)
• ME31-XEXX0800 - 8 channel K-type, -200 to +1350 C
• ME31-XDXX0400 - 4 channel PT100, -200 to +850 C (Ethernet and RS485 entries)
• ME31-XDXX0800 - 8 channel PT100, -200 to +850 C

Added, thanks.

The look rather fancy and useful for logging many temperatures.
But like many modules, they are not focused on getting the highest possible precision from the sensor. For k-type the issue is temperature differences, for PT100 the issue is wiring, either can easily add a degree or two in tolerance.

[flash2b]

Temperature Range: XEXX series: -200~1350°C ±0.2°C±2% and XDXX series: -200~850°C ±0.1°C±1% @ resolution 0.1

Pretty good, comparison to Keithley DMM6500 2wire (RTD), -200°~850°C  resolution 0.01. Tcal ±5%  0.8 (2yr).

It is also very dependent on the thermocouple / RTD spec that is connected.

Your comment is also true regardless module or DMM:
Against a Keithley DMM6500 in 2-wire RTD mode, -200 to 850 °C at 0.01 resolution and 0.8 °C (2yr), the XDXX works out better below roughly 70 °C and worse above it, since the percentage term takes over. For logging near ambient the module is in the same class.

And in 2-wire mode the DMM6500 has exactly the same lead resistance error - 0.385 ohm per degree does not care what it is connected to.

What are the specs for the HKJ Thermometer mentioned above ?

[HKJ]

Temperature Range: XEXX series: -200~1350°C ±0.2°C±2% and XDXX series: -200~850°C ±0.1°C±1% @ resolution 0.1

Pretty good, comparison to Keithley DMM6500 2wire, -200°~850°C  resolution 0.01. Tcal ±5%  0.8 (2yr).

It is also very dependent on the thermocouple spec that is connected.

What are the specs for the HKJ Thermometer mentioned above ?

The specs for any thermocoupler meter has one major issue: It assumes that there is no ice-point compensation error and there always is and it is probably the biggest error in DMM's and input boards.
I did play a bit with it here: https://lygte-info.dk/info/DMMThermocouplers%20UK.html

For my thermometer, check the chip specifications, there is not much in the way of compensation error when I use quality thermocouplers.

For battery powered DMM's you can get fairly good result if you let them stay at a constant temperature for an hour or two, before measuring, without moving the DMM from the stable temperature or extending the thermocoupler wire.
For mains powered DMM's the stable temperature is harder to get and you has to hope the compensation reads the temperature of the input connectors and not somewhere inside the meter.

[flash2b]

They are sensitive and you are right. Cutting the connector off the thermocouple and landing the bare wires directly on the terminal block gave visibly better results - which is exactly your point, since it removes two junctions and puts the real cold junction where the module measures it. Slightly painful to cut up a brand new connector one minute after unpacking it.

I have read through your own thermometer build, the challenges and the improvements you made. The page you just linked has useful information too.

My XEXX0600 runs from a 12V adapter and I see no warm-up drift after power-on, despite the internal DC-DC converter. I also like that it is isolated from both RS485 and Ethernet, so there is no ground loop between the thermocouples and the network side. After boot it is connected to my router in under 5 seconds.

[HKJ]

They are sensitive and you are right. Cutting the connector off the thermocouple and landing the bare wires directly on the terminal block gave visibly better results - which is exactly your point, since it removes two junctions and puts the real cold junction where the module measures it. Slightly painful to cut up a brand new connector one minute after unpacking it.

What few people think about when using thermocouplers: Any change from one type of conductor to another is a thermocoupler. The trick is to either get it compensated out by both ends being at exactly at the same temperature or measure the temperature at the connection and use that for compensation.
To make the above as easy as possible you want everything to be the same metal, including the connector, for good thermocouplers that is the case, the connector uses the same metal as the thermocoupler wires, and everything on the PCB is copper. The connector on my thermometer is thermocoupler metal, if I had wanted to support other types of thermocouplers a copper connector would be better, but that would move the temperature reference slightly farther away.

[flash2b]

Applied some Averaging using Math with 30 samples, the beauty of TC.....




Question: Is it normal that no Unit is shown now? I had it on °C in Math page/tab for my Type=Average.

There are also no units in the Range page/tab shown for the Math channels.

[HKJ]

Question: Is it normal that no Unit is shown now? I had it on °C in Math page/tab for my Type=Average.

There are also no units in the Range page/tab shown for the Math channels.

You have to fill in the unit on Math channels, there is a field for it.
I have considered adding a function to "guess" unit when it is possible, but not gotten around to do it.

[flash2b]

I did:


But it does not appear.

[HKJ]

I did:

But it does not appear.

That is a bug

[flash2b]

It only happens on reloaded data, not while logging live.

The reload path is parsing the column name - splitting on underscores to recover type, source and sample count - and then rejoining for display without putting them back. So the reconstruction partly works: it recovers enough to identify the channel, it just doesn't carry the unit and it mangles the label on the way out.

[HKJ]

It only happens on reloaded data, not while logging live.

The reload path is parsing the column name - splitting on underscores to recover type, source and sample count - and then rejoining for display without putting them back. So the reconstruction partly works: it recovers enough to identify the channel, it just doesn't carry the unit and it mangles the label on the way out.

I am surprised it mangles the names.
And I do not remember if TC tries to recover units from math, I hope it does, but I will check.

[HKJ]

I am relaxing this evening and playing with my computer and I derided to play a bit with AI and used the following question:

how does testcontroller by HKJ compare to professional software

The answer from google and chatGPT (The two free AI's I play with) was nice and mostly correct. Ok the correctness can always be discussed, but I like the answers.
I wonder if other AI's put it at the same level?

[flash2b]

Claude Opus 5 on "how does testcontroller by HKJ compare to professional software". (note: all trained data from my defs not taken into account, but has learned more than from website search only)

How does TestController compare to professional software?

Depends on the axis, and on some of them TC wins outright.

Where it beats the commercial packages

• Device coverage through a text file. A definition is plain text, loadable without a compiler, SDK or vendor blessing. LabVIEW wants a driver and real programming. BenchVue is excellent for Keysight gear and indifferent to the rest. The DAQ oriented packages assume you bought their hardware. None of them will ever support a 20 euro Modbus module, because the economics forbid it. In TC the long tail gets covered by whoever owns the device.
• Responsiveness. User requests end up in the DSL. I asked for portType and handle and they turned up in a release. No commercial vendor operates at that latency, and none lets a user shape the language.
• No licence server, dongle or activation that stops working when a vendor sunsets the product. It runs from a JAR.

Where it stops

• Timing. TC polls, professional DAQ acquires. Polling goes down to 0.01 s, but it is software timed, so the interval carries scheduling and link latency instead of a hardware clock - and in practice the device and the baud rate set the real ceiling long before TC does. For thermal work none of that matters, but it is a wall rather than a gap.
• Traceability. Audit trails, calibration management, signed records, the paperwork a regulated lab needs. TC has none of it and does not try to.
• Test sequencing. Pass/fail limits, operator screens, formal reports. TC logs and plots, it does not run a production test station.
• Process. Formal QA, regression suites, staged releases. The public release is v3.48 while the interesting version is a test JAR, and the testing is largely done by the users. Development is fast and testing happens in the open

The point
TC is not a cheap substitute for professional software. It covers a category those tools serve badly: mixed, cheap, self owned instruments and exploratory measurement on a bench. Getting a professional package to talk to a 20 euro temperature module would cost more effort than the measurement you wanted to make, and TC will have a definition for it.

[Cyclotron]

I am relaxing this evening and playing with my computer and I derided to play a bit with AI and used the following question:

how does testcontroller by HKJ compare to professional software

The answer from google and chatGPT (The two free AI's I play with) was nice and mostly correct. Ok the correctness can always be discussed, but I like the answers.
I wonder if other AI's put it at the same level?

Artifact published from my query to Opus 5.
https://claude.ai/public/artifacts/9cb641c7-f223-48a8-bd1d-09c66050d79e


I use Claude, Antigravity, and Codex all over the place. I find they substantially improve my productivity and primarily in taking notes and CICD validation of builds and testing. The drivers and work I've done on them would be nowhere near as fully tested and validated had it not been for them. 

I also use them to generate notebooks of concepts as I've tried to master those from your TC application. I've long been horrible at taking notes and then find myself re-reading original docs or something because I've forgotten. 

Anyway, I see Claude Opus's review as favorable.

[Cyclotron]

I have a rework of the E363xA driver (covering E3632A, E3633A, and E3634A) nearly ready, and a new one for the E3631A. All of these are nearly done and are built to look and function similarly.  I did the rework because I wasn't happy with the menu intuition and clutter. I think what I've created now is much more elegant, but opinions are just that.

Next up on my to-do is to check my E3641A for a driver and build one if needed. (I might have a few HP PSUs ) I think I have 11 or 12 PSUs here in total (someone once told me you could never have too many; I'm testing).

[HKJ]

I have a rework of the E363xA driver (covering E3632A, E3633A, and E3634A) nearly ready, and a new one for the E3631A. All of these are nearly done and are built to look and function similarly.  I did the rework because I wasn't happy with the menu intuition and clutter. I think what I've created now is much more elegant, but opinions are just that.

Next up on my to-do is to check my E3641A for a driver and build one if needed. (I might have a few HP PSUs ) I think I have 11 or 12 PSUs here in total (someone once told me you could never have too many; I'm testing).

I look forward to your update and new definitions.

[HKJ]

Looks like AI's mostly agree (The border line moves a bit up/down depending on what AI).

But they are slight wrong on traceability, TC do record version and SN of every device used (If they provide it) and it can be saved by user or from script. The PS and Battery test do automatic save it.

[flash2b]

Cyclotron's report is generated like a research tasks, with some things of TC that are totally not correct.

My generated report is based on the session learnings and brief, practical with also things totally not correct.

Traceability is seen in a more Legal view, HKJ is not a company but a person. Also saying all the things on Test Sequencing seams not correct.

The 20 eur mentioned twice does not come from me, and needs no be literally taken into account. Also labeling as Cheap is not always correct and depends on user perspective.

So my generated report has a nice Vibe and Spirit about TC and Cyclotron's more formal does not and tries to compare things with a Corporate view.

If you had asked me the same question, I would have answered: Running professional software that I can't afford is useless for me. TestController offers me everything the Major Vendors are not offering better, quicker and adaptable for all my TE needs.

[KungFuJosh]

I checked with Deepseek, and it's first response was:

There are no search results available for the specific "testcontroller by HKJ" software, so a direct feature-by-feature comparison cannot be provided.

Then I gave it a link to HKJ's site, and it made a detailed comparison. I didn't read it though. That was too much effort for how much faith I have in AI responses like this.