Program that can log from many multimeters.

[HKJ]

Thank you. Unfortunate to need the resources of an entire OS or VM for one app, but I also completely understand.

Do a windows emulator use all resources, TC do not?

I see in the About section "Uses hid4Jave to scan for HID devices (Could not get reading to work)," so sounds like the "can't read" behavior is not entirely unexpected. If I can find/make time, maybe I can dig into why hid4java won't work, or maybe look into http://usb4java.org/

I would be nice.

Anyone have luck attempting to run TC on Mac using Wine? I made a quick effort to run the Brymen app in Wine, but it didn't even get to the point of recognizing the device.

I believe some people has posted, in this thread, about using windows emulator to run TC with Brymen, but I do no remeber if it was on Linux or Mac.

[jmurray]

Hi HKJ,

I might be missing something: Is it possible to use the matchBitsList function as a formula on the math page? I've tried a few variations and it keeps getting disabled and highlighted in red.
I'm trying to return different short strings based on the bit specification to make it easier to write a script.

[HKJ]

I might be missing something: Is it possible to use the matchBitsList function as a formula on the math page? I've tried a few variations and it keeps getting disabled and highlighted in red.
I'm trying to return different short strings based on the bit specification to make it easier to write a script.

It is, but all formulas must return numbers, not strings. You can do that with matchBitsList().

All regular values (i.e. values that goes into table or chart) must be numbers. You can use deviceRead() to get the string answer directly from the device. For settings you can define get/set functions and they can return strings https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#A_generic_interface.

[Curious]

Hi HKJ,

I finally got TC to work great for running battery capacity tests with East Tester 5410 Electronic Load, see https://www.eevblog.com/forum/index.php?action=post;quote=4765331;topic=228058.25

So now wanting to plot I-V curves for Solar Panels.  Thought that would involve many days of understanding how to write scripts, but then saw your "Parameter Sweep" pop-up, awesome!

Practicing usage, I started with Parameter sweeping (in Constant Current mode) current set point from 0-1.0 amps in 100 steps while recording a battery voltage. I'm having a strange problem running parameter sweeps while logging..randomly TC reports Current and voltage dropping to precisely 0.00, then recovering to actual values.  Please see attached Chart image, as well as Parameter Sweep popup windows images.  The ET5410 LCD display does NOT show 0volts, 0amps but actual values.  Any idea why TC is randomly recording 0, 0?  I'm guessing there might be a USB communications collision, since log sampling interval >=10 seconds seems to mostly resolves the problem, but takes much time.

Thanks!

[HKJ]

Practicing usage, I started with Parameter sweeping (in Constant Current mode) current set point from 0-1.0 amps in 100 steps while recording a battery voltage. I'm having a strange problem running parameter sweeps while logging..randomly TC reports Current and voltage dropping to precisely 0.00, then recovering to actual values.  Please see attached Chart image, as well as Parameter Sweep popup windows images.  The ET5410 LCD display does NOT show 0volts, 0amps but actual values.  Any idea why TC is randomly recording 0, 0?  I'm guessing there might be a USB communications collision, since log sampling interval >=10 seconds seems to mostly resolves the problem, but takes much time.

You might be able to ignore the problem by using the configuration "Delay timeout by x samples" and use a value of 1 or 2 for x.

The actual problem may very well be a communication problem where the load has trouble with the intermixing of settings and readouts.
A check in the definition:

#cmdSetup number Set_I_
:read: CURR:CC?;
:readmath: trim(replace(value,"R",""))
:write: CURR:CC #;[300];
:tip: Set CC mode current value
Amps 0 40
:updatemodechange:

Shows a 300ms [300] delay after setting a new current value, you can try increase that value and see if it helps

When looking for communication issues using debug mode may help show it, but be aware that debug mode may slow down the communication and this by itself can fix the issue (The code is written so debug in itself do not slow down the code by any significant amount, but the increased workload on the computer may).

[Curious]

Thanks for your response.

You might be able to ignore the problem by using the configuration "Delay timeout by x samples" and use a value of 1 or 2 for x.

Looks like "delay timeout by x samples"  was defaulted to 1 samples.  Increasing to 2 samples seems to have reduced the 0.00 samples somewhat.

To see if I understand the expected behavior, does "Delay timeout by x samples" mean IF the ET5410 does not respond when values requested, then the previously received value will be recorded again?  Does this configuration setting also apply when sending current (I) setting to ET5410?

If the requested value is not received, is the index incremented anyway?  I'm asking because the 0.00 values can occur every other sample, even though Delay timeout = 3samples.  Pls see attached chart, zoomed into timeout samples.  I don't see any indication that the log skipped 3 samples (3 seconds at 1 sample/sec).

Considering the time delay after sending current I value to ET5410,

The actual problem may very well be a communication problem where the load has trouble with the intermixing of settings and readouts.
A check in the definition:

#cmdSetup number Set_I_
:read: CURR:CC?;
:readmath: trim(replace(value,"R",""))
:write: CURR:CC #;[300];
:tip: Set CC mode current value
Amps 0 40
:updatemodechange:

Shows a 300ms [300] delay after setting a new current value, you can try increase that value and see if it helps

does this mean 300ms delay until any other command is sent or received?  For example, does this mean to receive the next log sample must wait a minimum of 300ms? I've been trying to avoid learning the scripting, is there to change [300] to [400] without running a script?

When looking for communication issues using debug mode may help show it, but be aware that debug mode may slow down the communication and this by itself can fix the issue (The code is written so debug in itself do not slow down the code by any significant amount, but the increased workload on the computer may).

I'll wait on this approach for now. Thanks!

[HKJ]

Looks like "delay timeout by x samples"  was defaulted to 1 samples.  Increasing to 2 samples seems to have reduced the 0.00 samples somewhat.

Default is supposed to be 0 on this setting. That way it is easier to see communication problems.

To see if I understand the expected behavior, does "Delay timeout by x samples" mean IF the ET5410 does not respond when values requested, then the previously received value will be recorded again?  Does this configuration setting also apply when sending current (I) setting to ET5410?

The setting only applies when logging and will reuse the old value when recording that sample.

If the requested value is not received, is the index incremented anyway?  I'm asking because the 0.00 values can occur every other sample, even though Delay timeout = 3samples.  Pls see attached chart, zoomed into timeout samples.  I don't see any indication that the log skipped 3 samples (3 seconds at 1 sample/sec).

The index is incremented, the build-in timeout in the definition will also affect the result.

The actual problem may very well be a communication problem where the load has trouble with the intermixing of settings and readouts.
A check in the definition:

#cmdSetup number Set_I_
:read: CURR:CC?;
:readmath: trim(replace(value,"R",""))
:write: CURR:CC #;[300];
:tip: Set CC mode current value
Amps 0 40
:updatemodechange:

Shows a 300ms [300] delay after setting a new current value, you can try increase that value and see if it helps

does this mean 300ms delay until any other command is sent or received?  For example, does this mean to receive the next log sample must wait a minimum of 300ms? I've been trying to avoid learning the scripting, is there to change [300] to [400] without running a script?

The [300] will basically stop the communication to the device for 300ms exactly where it is placed in the communication stream.

When looking for communication issues using debug mode may help show it, but be aware that debug mode may slow down the communication and this by itself can fix the issue (The code is written so debug in itself do not slow down the code by any significant amount, but the increased workload on the computer may).

I'll wait on this approach for now. Thanks!

Using debug mode and posting the log may help me to see the problem.

[Oleksii]

The Block https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html#Binary_with_fixed_communication_blocks_(Block) driver is perfect for this.

This driver is used for: "Devices\Mastech 6514.txt" and "Devices\ADC10F103C.txt"
But in both cases it is in is in streaming mode and you need to use polled mode, this means the configuration is slightly different.

I tried hard and probably now I should ask for a help  :'(
What I did so far and what result reached.

I use Test Controller V2.3 on Linux. I pass my serial device ttyUSB0 through a "fake network bridge" to be able see data packets exchange in Wireshark (you should know this tool I guess).
I'm sharing this technic as it may be usefull for you too. I run these 2 commands in 2 terminals:

Code: [Select]

socat PTY,link=/dev/ttyACM1,mode=777,group=dialout,unlink-close=0  TCP:localhost:23000,forever,interval=3
socat TCP-LISTEN:23000,reuseaddr,fork file:/dev/ttyUSB0,echo=0,b9600,raw

Now I'm connecting to a serial device ttyACM1 in TC.
Note - I tested this "fake network bridge" technic with TC for example with Atorch-DL24P and it worked perfectly!
And I can see all data packets exchanges in Wireshark on both directions by filtering on localhost:23000 (tcp.port == 23000 && tcp.flags.push == 1)

So, in Wireshark I can see how TC is polling data and I can see how my Tasi device is sending expected data back!

The Tasi device response structure is described in my original  Reply #2880
Just in case, I also tried to communicate directly with ttyUSB0 but it does not help in any way.

Debuglog in TC, in particular, when I used ttyUSB0 directly:

Code: [Select]

$ java -jar TestController.jar debugTime=2
Starting
;; 2326.15ms jSerialComm version: 2.9.1
;; 3286.83ms Start thread for: ttyUSB0 - Tasi TA612C
;; 4008.81ms ttyUSB0: Tx: AA 55 01 03 03
;; 4008.81ms ttyUSB0: Set params: 9600
;; 5060.36ms ttyUSB0: Tx: AA 55 01 03 03
;; 7336.41ms ttyUSB0: Tx: AA 55 01 03 03
;; 11048.25ms Stopping thread for: ttyUSB0 - Tasi TA612C
;; 11363.91ms ttyUSB0: Close

Definition file I tried to use:

Code: [Select]

#idString TA612C
#name Tasi TA612C
#handle TA612C
#port comfixedbaud
#baudrate 9600
#driver block
#author Zalex
; Version 0.1   23-03-2023
#notes Other names: 4 Channels K/J Thermometer

#value Temperature  C SI
#rxStart 0x55 0xAA 0x01 0x0B
#rxLength 13
#rxFormat 3u2 5u2
#poll 0xAA 0x55 0x01 0x03 0x03
#askValues values?

Am I missing something important here or what?

I'm not sure that "block" driver is working correctly in "pool" mode.
I need to get at least some sign that it's reading data or so, to be sure that I can work further with Values definitions and numbers parsing.

I've tried to set something correct for rxFormat but I'm not sure it's mandatory to be fully specified and fully correct at this stage of troubleshooting.
Help please.

[Oleksii]

I'm not sure that "block" driver is working correctly in "pool" mode.
I need to get at least some sign that it's reading data or so, to be sure that I can work further with Values definitions and numbers parsing.

I've figured out that rxStart definition accepts only one byte! So this helped be to see actual RX packets in TC and TC started to detect my Tasi as connected.

Code: [Select]

#rxStart \x55If I define the value as "\x55\xAA" or "\x55 \xAA"  or "0x55 0xAA"  - neither does work.
Note: in definition files for Mastech 6514, they use 2 bytes: #rxStart \x65\x14. That's what I followed and hoped it works, but it's not!

Current working definition file:

Code: [Select]

#idString TA612C
#name Tasi TA612C
#handle Tasi
#port comfixedbaud
#baudrate 9600
#driver block
#author Zalex
; Version 0.2   26-03-2023

#notes 4 Channels K/J Thermometer

#rxStart \x55
#rxLength 13
#rxFormat 4i2/10 6i2/10 8i2/10 10i2/10
#poll 0xAA 0x55 0x01 0x03 0x03

#value CH1 C D1
#value CH2 C D1
#value CH3 C D1
#value CH4 C D1

#askValues values?

Graph:

[Oleksii]

A feature request - "Adjustable pool interval for Block driver".

Well, I'm using Block driver with poll mode. Request: 5 bytes, reply: 13 bytes.
TC does ~14 pools in a seconds: 20-25ms delay of device reply, 50 ms delay before next pool.

My Tasi device updates state with 2Hz frequency, so polling it with ~75ms interval is basically ~7 times more redundant that it makes sense. Also, TC is more busy by doing unnecessary work.

I've tried to use cmdDelayTime to increase the pool, but it does not work for Block driver, as I expected. I could not fond any other related option to try.

So, having an option to adjust pool interval would be really helpful!
Debug:

Code: [Select]

;; Found Tasi TA612C on USB-Based Serial Port (ttyACM1)
;; 4228.94ms ttyACM1: Tx: AA 55 01 03 03
;; 4252.12ms ttyACM1: Rx: 55 AA 01 0B D5 00 D4 00 D4 00 D6 00 5E
;; 4302.34ms ttyACM1: Tx: AA 55 01 03 03
;; 4325.49ms ttyACM1: Rx: 55 AA 01 0B D5 00 D4 00 D4 00 D6 00 5E
;; 4375.71ms ttyACM1: Tx: AA 55 01 03 03
;; 4399.14ms ttyACM1: Rx: 55 AA 01 0B D5 00 D4 00 D4 00 D6 00 5E


[HKJ]

I can see that you figured out your problems.

#rxStart do support multiple bytes, the Mastech would not work if it didn't.

A feature request - "Adjustable pool interval for Block driver".

Well, I'm using Block driver with poll mode. Request: 5 bytes, reply: 13 bytes.
TC does ~14 pools in a seconds: 20-25ms delay of device reply, 50 ms delay before next pool.

My Tasi device updates state with 2Hz frequency, so polling it with ~75ms interval is basically ~7 times more redundant that it makes sense. Also, TC is more busy by doing unnecessary work.

I might add a adjustable delay with a default of 50ms (as it is now), but I do not see it as very important and slower poll has one minor disadvantage: The logged data may be slightly older. The 50ms delay was selected as a compromise, allowing devices with slow processor to do other work than serving the data to TC, but still keep TC fairly up to date with measurements.
The TC driver works by storing the last read values and will return that value to any function (Log, readout, statistic, etc.) asking for the current value.

[Oleksii]

#rxStart do support multiple bytes, the Mastech would not work if it didn't.

I don't know how value "\x65\x14" for rxStart works for Mastech.
I've described cleanly that I've tried value as "\x55\xAA" or "\x55 \xAA" or "\x55\xaa" - any of these does NOT work in my case.
I've tried that carefully and twice, so I'm sure than 2 (or more) bytes does not work for me, while I'm sure what second byte is - 0xAA.

Maybe Mastech is sending those bytes with delay, so they being read and processes separately or so.

Also, rxStart accepts the byte only in format \x55, and does not work if specify it as 0x55.

"poll" is opposite - it accepts bytes only if format 0xAA 0x55, which is confusing why bytes in HEX have different format requirements for different params.

[Oleksii]

I might add a adjustable delay with a default of 50ms (as it is now), but I do not see it as very important and slower poll has one minor disadvantage: The logged data may be slightly older.

I'd appreciate if you would implement that. I have more devices where I need to use the Block driver and where I really need to slow down the polling frequency.
I fully understand that increasing the delay might be considered as the disadvantage, but that's a decision for TC users

[HKJ]

I don't know how value "\x65\x14" for rxStart works for Mastech.
I've described cleanly that I've tried value as "\x55\xAA" or "\x55 \xAA" or "\x55\xaa" - any of these does NOT work in my case.
I've tried that carefully and twice, so I'm sure than 2 (or more) bytes does not work for me, while I'm sure what second byte is - 0xAA.

Maybe Mastech is sending those bytes with delay, so they being read and processes separately or so.

I have no idea why it do not work for you. Or maybe I do, it may be a charset problem, if this is the case it will be fixed.

Also, rxStart accepts the byte only in format \x55, and does not work if specify it as 0x55.

"poll" is opposite - it accepts bytes only if format 0xAA 0x55, which is confusing why bytes in HEX have different format requirements for different params.

Generally I use string or numeric format, rxStart uses string format, this means that any character will be used, but you can use the \ to escape into numeric character specifications. Other tags may use numeric format.
I agree it would have been better if I had use the same format for both, but I will not change it now.

[Humulus]

Hi Is there any chance that the ET5420+ Will be added in this software? (the New model, the ET5420, does not seem to be aviable any more :-(

[HKJ]

Hi Is there any chance that the ET5420+ Will be added in this software? (the New model, the ET5420, does not seem to be aviable any more :-(

If somebody makes a definition it will be included.
Many of the included devices are done by readers, not by me. I help with it, by explaining stuff and by adding needed functions to TestController.

[Humulus]

How hard is it to do it by myself? What skills are needed?

[Oleksii]

How hard is it to do it by myself? What skills are needed?

I see myself 3 months ago on your current state.
No one know what skills are needed. You have to just push yourself hard and try.
p.s. I've got a success at the end, but it was not easy and not fast.

[HKJ]

How hard is it to do it by myself? What skills are needed?

This depends very much on the protocol, at it simplest (SCPI without modes) you basically list the values you want displayed and the commands you want to send. Binary protocols are harder, first you have to find documentation of the protocol or figure it out yourself, next you have to find the best matching protocol in TestController (Or ask me for help writing a new protocol driver), then you have to extract the values and make the commands using the specifications for that protocol.
A device with modes can be fairly easy or very hard, this depends on number of modes and how they work. As an example of devices with modes see DMM's. Electronic loads also has modes, but they are usually easier, because most of the settings and return values are the same for all modes.


You can find documentation here:
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html
https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html

And the Devices directory is full of examples.

[jmurray]

Hi HKJ,

I'm hoping to use the Block driver to write a definition for an appliance that uses RS485. However I'm looking to use an RS485 to ethernet adaptor.

From what I can see in the debug window, it looks as though SocketInterface can't be used with the Block driver - is this the case?

Code: [Select]

Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.SocketInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.SocketInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
        at dk.hkj.devices.DeviceBlock.getCommInterface(DeviceBlock.java:619)
        at dk.hkj.main.InterfaceThreads$DeviceThread.<init>(InterfaceThreads.java:1391)
        at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesSocket(InterfaceThreads.java:630)
        at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:765)

[HKJ]

Hi HKJ,

I'm hoping to use the Block driver to write a definition for an appliance that uses RS485. However I'm looking to use an RS485 to ethernet adaptor.

From what I can see in the debug window, it looks as though SocketInterface can't be used with the Block driver - is this the case?

For now, it will be fixed in next version.

[Humulus]

Hmm...I must say that did not encourage me 
I think I skip the ET-4520.
Dont believe I have the skills, nor the time 
But thanks for your (and others) reply!

[HKJ]

Hmm...I must say that did not encourage me 
I think I skip the ET-4520.
Dont believe I have the skills, nor the time 
But thanks for your (and others) reply!

New models will often use same protocol as old models, maybe with a few additions. This will often make it possible to use the old definition (After copying it and changing the identifier) for initial connection and most of the functions.

[gby]

Hi HKJ,

For a SCPI LXI device I need to send the ascii text
    C1:SWWV DIR,UP_DOWN
Note the underscore in the above is needed.  Sent as shown the "_" is replaced by a space as expected.

So, I added an escape "\" before it.  Unfortunately that did not work.  Working in debug mode I got the following:
   C1:SWWV DIR,UP\_DOWN
   ;; SDG2122X: Tx <C1:SWWV DIR,UPDOWN>
Note that in the actual transmitted message the sequence "\_" was reduced to no character instead of keeping the underscore.

Based on Test Controller documentation I was pretty sure \_ should work.  That sequence is used in the SiglentSDGxxxxX.txt driver for the Siglent SDG2042X device I am talking to in the line
   :write: C1:SWWV MARK\_STATE,#

So, what escape syntax do I need to use to get the underscore to actually be sent?

I am using Test Controller V2.34 taling to Siglent SDG2042X.

[HKJ]

For a SCPI LXI device I need to send the ascii text
    C1:SWWV DIR,UP_DOWN
Note the underscore in the above is needed.  Sent as shown the "_" is replaced by a space as expected.

So, I added an escape "\" before it.  Unfortunately that did not work.  Working in debug mode I got the following:
   C1:SWWV DIR,UP\_DOWN
   ;; SDG2122X: Tx <C1:SWWV DIR,UPDOWN>
Note that in the actual transmitted message the sequence "\_" was reduced to no character instead of keeping the underscore.

Based on Test Controller documentation I was pretty sure \_ should work.  That sequence is used in the SiglentSDGxxxxX.txt driver for the Siglent SDG2042X device I am talking to in the line
   :write: C1:SWWV MARK\_STATE,#

So, what escape syntax do I need to use to get the underscore to actually be sent?

Use hex code: \x5f