Thank you. Unfortunate to need the resources of an entire OS or VM for one app, but I also completely understand.
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/
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 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.
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.
#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:
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:Quote#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).
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).
QuoteThe 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:Quote#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 helpsdoes 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?
QuoteWhen 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!
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.
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
$ 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
#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?
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.
#rxStart \x55
If I define the value as "\x55\xAA" or "\x55 \xAA" or "0x55 0xAA" - neither does work.#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?
;; 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
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.
#rxStart do support multiple bytes, the Mastech would not work if it didn't.
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 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.
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 :-(
How hard is it to do it by myself? What skills are needed?
How hard is it to do it by myself? What skills are needed?
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)
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?
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!
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?