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

[WaveyDipole]

That's odd since jSerialComm.jar does not appear to be supplied with the application. However, TestController does come with some serial library in the node_modules folder?

On both of my Linux machines I have openjava and node installed. java --version reports version 17.0.14. My user is a member of the dialout group.

jSerialComm is compiled into TestController to make deployment as simple as possible on all platforms and secure that the version used is supported by TC (jSerialComm is mostly very compatible between version, but not always).

You will have to forgive me as I am still very much learning about Java. I have now confirmed that JSerialComm is indeed wrapped up inside the TestController program file. Since JSerialCom is a 'universal' platform independent library that works on Windows, Android, Linux and other operating systems, it does seem rather odd that its not finding any "real" serial ports om my two Linux machines. I have tried TestController in two different Linux distros as well. It certainly does find serial ports on Windows, so it ought to work on Linux. Its difficult to know why that is at this point, but I presume that is why the program ends up trying to use a dummy port instead?

I should perhaps mention that other programs such as the Arduino IDE and Vscode work just fine with serial ports on those computers, so this doesn't appear to be a user permissions issue.

In order to try and understand this further, I am going to try and construct a small java program using that library to see whether it will let me work with serial ports on my two distros.

UPDATE:
So it turns out that the jSerialComm library comes with a test program called SerialPortTest.java. After a bit of fiddling I was able to compile and run this program and it did enumerate the available serial ports on both of my Linux computers. This at least demonstrates that the current version of JSerialComm is compatible with and works on my Linux installations. I am not sure, but it does look like the TestController package may use a different version of jSerialComm and it would be useful to test that specific version. Any idea which one it is?

[HKJ]

Here is a test version with the newest jSerialComm:

http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[Gertjan]

I tried to get the [LOC] functionality into the #pgm#, to make the code more compact and elegant. But could not find a solution....
Is there a way to send [LOC] functionality from a #pgm#?

You can send the [LOC] the same way you send other SCPI commands or at least it is supposed to work that way.
I will check it out when I get a GPIB adapter connected again.

Hi HKJ,

Thanks for looking into this [LOC] Issue.

In the #pgm# I tried this command: deviceWrite(handle,"[LOC]"). This results in nothing written in the log file, and nothing is sent to the device. (I checked with other commands in place of [LOC], those were sent to the device as expected.)

I did some tests with [LOC] in other device drivers:
- Definitions with the ASCII driver:
These work all as expected. But in my ASCII driver definitions the [LOC] is always sent from a #scpiCmd. Just as in my 8846A workaround

- More interesting is the result from testing with  SCPI driver (NOT SCPIx). I tested with my Philips PM2811 definition:

Code: [Select]

#name Philips PM2811
#handle PM2811
#port GPIB

#finalCmd ABOR;*CLS;*RST;[1000];[LOC];[500];

The resulting log file:

Code: [Select]

;; PM2811: Tx <ABOR>
;; COM9: Tx: <ABOR.> 41 42 4F 52 0A
;; PM2811: Tx <*CLS>
;; COM9: Tx: <*CLS.> 2A 43 4C 53 0A
;; PM2811: Tx <*RST>
;; COM9: Tx: <*RST.> 2A 52 53 54 0A
;; PM2811: Delay: 1000ms
;; COM9: Tx: <++LOC.> 2B 2B 4C 4F 43 0A
;; PM2811: Delay: 500ms
;; COM9: Close

So in the SCPI driver the [LOC] command is executed, and ++LOC sent to the device. Although the documentation states that for this functionality one needs the SCPIx driver.....

I hope this helps....

regards, Gertjan.

[WaveyDipole]

Here is a test version with the newest jSerialComm:

http://lygte-info.dk/pic/Projects/TestController/TestController.jar

Thank you for this.

As an update to the my previous post, I discovered a version string for jSerialComm in the original TestController.jar file of 2.10.3, so I downloaded this version fro the GitHub and tested it and it also enumerates devices like this:

Code: [Select]

Available Ports:

   [0] ttyS0 (/dev/ttyS0): Physical Port S0 - Physical Port S0 @ 0-0.0 (VID = -1, PID = -1, Serial = Unknown)
   [1] ttyUSB0 (/dev/ttyUSB0): USB2.0-Serial - USB2.0-Serial @ 2-3 (VID = 6790, PID = 29987, Serial = Unknown)
I had focussed in on the port name within the (brackets) as this is the standard format of Linux port names. However, I then remembered a comment you made in an earlier post about using the exact port name that was returned by the port scan. Since the port scan is not returning a list of ports, I was something at a loss, but what if, as shown above after the initial [1], the field in TestController required just the port name without the preceding '/dev/'? I had found that when using the SerialPortTest program when one opts to manually type in the port, it is possible to enter either /dev/ttyUSB0 or just ttyUSB0.

So in TestController (still using the current release) I entered just 'ttyUSB0' instead of '/dev/ttyUSB0' in the Address field and it worked!
I thought I had done this before, but maybe I still had the config wrong in some other respect at the time. The current config had already been tested and shown working on Windows so once the port name was changed, it just worked.

Unfortunately, for some reason, the same does not work for your updated test version. Neither '/dev/ttyUSB0' nor 'ttyUSB0' works.
(It does now. I don't know why it didn't work earlier, but I suspect the serial port was being held open by another process.)

Its a little unusual to specify a tty port on Linux in this way, but the good is, that I can now use the original release version.

[HKJ]

As an update to the my previous post, I discovered a version string for jSerialComm in the original TestController.jar file of 2.10.3,

TC uses the SerialPort.getCommPorts() to scan for serial ports and the portname in the address field must match the getSystemPortName() return by these elements. One reason for this is to avoid connecting to the same port multiple times if you have it listed on multiple devices, TC will only try the first enabled device.

Maybe I ought to match on getSystemPortPath() also.

The list read by SerialPort.getCommPorts() is also used to display the found serial port when you right-click in the address field, i.e. if no ports are listed, TC have not found any serial ports and cannot connect serially.

 so I downloaded this version fro the GitHub and tested it and it also enumerates devices like this:

Code: [Select]

Available Ports:

   [0] ttyS0 (/dev/ttyS0): Physical Port S0 - Physical Port S0 @ 0-0.0 (VID = -1, PID = -1, Serial = Unknown)
   [1] ttyUSB0 (/dev/ttyUSB0): USB2.0-Serial - USB2.0-Serial @ 2-3 (VID = 6790, PID = 29987, Serial = Unknown)
I had focussed in on the port name within the (brackets) as this is the standard format of Linux port names. However, I then remembered a comment you made in an earlier post about using the exact port name that was returned by the port scan. Since the port scan is not returning a list of ports, I was something at a loss, but what if, as shown above after the initial [1], the field in TestController required just the port name without the preceding '/dev/'? I had found that when using the SerialPortTest program when one opts to manually type in the port, it is possible to enter either /dev/ttyUSB0 or just ttyUSB0.

So in TestController (still using the current release) I entered just 'ttyUSB0' instead of '/dev/ttyUSB0' in the Address field and it worked!
I thought I had done this before, but maybe I still had the config wrong in some other respect at the time. The current config had already been tested and shown working on Windows so once the port name was changed, it just worked.

Unfortunately, for some reason, the same does not work for your updated test version. Neither '/dev/ttyUSB0' nor 'ttyUSB0' works.

Its a little unusual to specify a tty port on Linux in this way, but the good is, that I can now use the original release version.

I have updated my build to use the new version now, i.e. the next release will probably use it.

[WaveyDipole]

TC uses the SerialPort.getCommPorts() to scan for serial ports and the portname in the address field must match the getSystemPortName() return by these elements. One reason for this is to avoid connecting to the same port multiple times if you have it listed on multiple devices, TC will only try the first enabled device.

Maybe I ought to match on getSystemPortPath() also.

It makes sense that the port names must match and perhaps one doesn't usually think of serial ports as having a name and a path element, but, they actually do. Even on Windows, there is a path (e.g something like \\.\COM3) although typically one just uses a short name like e.g. COM3. I guess there is some logic to jSerialComm having both getCommPorts() and getSystemPortPath() methods to on the one hand get the path element, and on the other a list of port names.

The list read by SerialPort.getCommPorts() is also used to display the found serial port when you right-click in the address field, i.e. if no ports are listed, TC have not found any serial ports and cannot connect serially.

I agree that this is probably what should be the case, but for some reason on Linux (on MX Linux and MINT at least) a list of ports is not getting generated and not having it available was part of the problem. Nevertheless, the ports are present and available for connection provided that the port name is specified in the appropriate way, without the path element (e.g. ttyUSB0).

On Windows, a list is usually displayed so one can readily see what ports are available and their actual names which is helpful..

I have updated my build to use the new version now, i.e. the next release will probably use it.

I look forward to the next release. I think it would perhaps be helpful for the address field to accept serial port names in the form '/dev/ttyUSB0' as well as just 'ttyUSB0'. I appreciate that may mean a little more code to split the '/dev/' bit from the name where present but it might avoid some head scratching.

If at any time you need me to test on my Linux computers, then I am happy to help. Otherwise, thank you for your helpful responses to my issue.

[gby]

HKJ,

I am working on a driver file for a new servo drive.  This time I have gotten the product to add simple SCPI language support.  This way I should be able to use the #driver SCPIx instead of #driver ascii like I have before.  Since these products support many 100's of keywords not having to create read and write #scpiCmd's for each keywords with the #driver SCPIx makes things much simpler.

Unfortunately logging with #driver SCPIx randomly loses about 10% of the data points.  However, the same #askvalues command using the #driver ascii works every time.  Here is detailed background:

Logging works:
   #port com
   #eol \r\n
   #driver ascii

Logging loses points:
   #port com
   #eol \r\n
   #driver SCPIx

In both cases the logging command is the same
#askValues REC.TRIG; REC.DATA?

Below is debug from #driver SCPIx where the logging point worked where the last received item is properly 6 csv numbers.

Code: [Select]

;; 10:56:31.921 KED: Tx <REC.TRIG>
;; 10:56:31.923 COM6: Tx: <REC.TRIG..> 52 45 43 2E 54 52 49 47 0D 0A
;; 10:56:31.923 KED: Tx <REC.DATA?>
;; 10:56:31.923 KED: Tx <txrxn? 2 REC.RETRIEVEDATA 0>
;; 10:56:31.925 COM6: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 10:56:31.925 COM6: Rx: <1> 31
;; 10:56:31.925 COM6: Rx: <0.045,0.071,3249506180,7.387,0.091,0.000> 30 2E 30 34 35 2C 30 2E 30 37 31 2C 33 32 34 39 35 30 36 31 38 30 2C 37 2E 33 38 37 2C 30 2E 30 39 31 2C 30 2E 30 30 30
;; 10:56:31.925 KED: Rx <0.045,0.071,3249506180,7.387,0.091,0.000>
;; 10:56:31.925 KED: Rx as numbers <0.045 0.071 3.24950618E9 7.387 0.091 0.0>
Below is debug from the #driver SCPIx where the data point is lost/the last received item is just 1 value of 0.0.

Code: [Select]

;; 10:56:32.022 KED: Tx <REC.TRIG>
;; 10:56:32.023 COM6: Tx: <REC.TRIG..> 52 45 43 2E 54 52 49 47 0D 0A
;; 10:56:32.023 KED: Tx <REC.DATA?>
;; 10:56:32.023 KED: Tx <txrxn? 2 REC.RETRIEVEDATA 0>
;; 10:56:32.025 COM6: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 10:56:32.025 COM6: Rx: <>
;; 10:56:32.025 COM6: Rx: <-->1> 2D 2D 3E 31
;; 10:56:32.025 KED: Rx <-->1>
;; 10:56:32.025 KED: Rx as numbers <0.0>Notice in the above that TestController says
   COM6: Rx: <-->1> 2D 2D 3E 31
But the device never sent "-->1".  So, it is as if the receive buffer is getting confused.

In support of the thought that TestController #driver SCPIx is getting confused is the fact that #driver ascii with the exact same device responding in the exact same way always gets every returned log point correctly.

The device itself answers the REC.RETRIEVEDATA 0 from TestController with:
   1<CR LF>
   0.045,0.071,3249506180,7.387,0.091,0.000 <CR LF>
   -->
where "<CR LF>" means just the two ascii character 0D 0A or \r\n.  Note that the last line is a prompt and does not have "<CR LF>" after it.  Also note that the two previous lines have no initial prompt characters.

Any thoughts on the same communications sequence works with #driver ascii but with #driver SCPIx regularly get confused?  Any thoughts on how the get #driver SCPIx to work with this device?  Is it possible there is a bug in the #SCPIx driver?

[HKJ]

Any thoughts on the same communications sequence works with #driver ascii but with #driver SCPIx regularly get confused?  Any thoughts on how the get #driver SCPIx to work with this device?  Is it possible there is a bug in the #SCPIx driver?

I have no good answer.
The two txrxn? commands are coded separately, but the code is basically the same and they both call the same reading routine in the driver (It is called writeReadLines(cmd, n)
Both definitions support a optional minimum delay between commands and SCPIx also support optional removal of a prompt after the communication.

In your log this part:

;; 10:56:31.925 COM6: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 10:56:31.925 COM6: Rx: <1> 31
;; 10:56:31.925 COM6: Rx: <0.045,0.071,3249506180,7.387,0.091,0.000> 30 2E 30 34 35 2C 30 2E 30 37 31 2C 33 32 34 39 35 30 36 31 38 30 2C 37 2E 33 38 37 2C 30 2E 30 39 31 2C 30 2E 30 30 30
;;

Is from the driver (i.e. the com driver) and is generated by the same code in both cases (A general rule: when log line list a comport it is generated from the com driver, when it list a device it is generated from the definition).

This makes it very hard for me to have a good guess why it fails.

[gby]

HKJ,

Thanks for the reply.  Would Wireshark recording the actual USB COM traffic help debug this issue?  Is there any experiment you can think to run to get more data on the issue?

I would really like to get SCPIx working since that method only needs a 300 line driver file while using the ascii driver requires a 3000 line file and regular updates as the product adds new functionality.

[HKJ]

HKJ,

Thanks for the reply.  Would Wireshark recording the actual USB COM traffic help debug this issue?  Is there any experiment you can think to run to get more data on the issue?

I would really like to get SCPIx working since that method only needs a 300 line driver file while using the ascii driver requires a 3000 line file and regular updates as the product adds new functionality.

The only idea is that I might be able to simulate your device with a Arduino.
For this I need your definition and the *idn string and I hope I do not need to implement much more that that to simulate the logging.

Looking at you log I would guess:
REC.TRIG
REC.RETRIEVEDATA 0

Is needed and then some fixed answer strings.



One thing: Do the device echo the  commands, that can give issues with TC.
When looking at this:

Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 10:56:32.025 COM6: Rx: <>
;; 10:56:32.025 COM6: Rx: <-->1> 2D 2D 3E 31

I wonder if there is a CR LF received (It do not explain why the two definitions works different, but timing can affect stuff, especially when logging. TC is designed to minimize delays in the communication thread when logging, but it is not zero).

[gby]

The device does not echo the tx strings from TestController.

The device does send CR LF for the first two lines but I do not believe it does for the last line which is a prompt.  Below is the sequence

TC sends: REC.TRIG CR LF
Device replies: CR LF
TC sends: REC.RETRIEVEDATA 0 CR LF
Device replies:  1 CR LF 0.045,0.071,3249506180,7.387,0.091,0.000 CR LF -->

Note there is no CR LF after the --> prompt.  Hopefully this is enough detail to get you going.

[HKJ]

The device does not echo the tx strings from TestController.

The device does send CR LF for the first two lines but I do not believe it does for the last line which is a prompt.  Below is the sequence

TC sends: REC.TRIG CR LF
Device replies: CR LF
TC sends: REC.RETRIEVEDATA 0 CR LF
Device replies:  1 CR LF 0.045,0.071,3249506180,7.387,0.091,0.000 CR LF -->

Note there is no CR LF after the --> prompt.  Hopefully this is enough detail to get you going.

That explains it.
TC sends: REC.TRIG CR LF
Device replies: CR LF  <----------------- Here is the extra line

You need to read these character or maybe you can get away with adding a short delay after the command (Like ;[50]), either method will most likely work.
Note: TC do support adding a delay after each command as a general setting in these drivers, but it will reduce the speed for all commands.

TC will flush the input buffer at the start of the command, but it may send the second command before the last answer is received, i.e. TC will believe it is part of the answer to the second command.

And if you disable logging both SCPIx and Ascii may fail.

[gby]

HKJ,

Thanks for the suggestion around the relative timing of TC sends and TC receives.  If this is the issue I am not sure why driver ascii works and driver SCPIx drops some samples.  There still seems to be some kind of difference between the #driver ascii and #driver SCPIx.

I changed the driver file to
   #port com
   #eol \r\n
   #driver SCPIx
   #cmdDelayTime 50
but nothing seems to have changed.  In looking at the debug file I am not seeing the 50 mSec of delay between commands that I was expecting.  Below is a debugTime capture while running with the #cmdDelayTime 50 line in the driver file.  It shows a good logged point followed by a lost/bad logged point.

Code: [Select]

;; 17:05:09.497 COM6: Tx: <REC.TRIG..> 52 45 43 2E 54 52 49 47 0D 0A
;; 17:05:09.497 KED: Tx <REC.DATA?>
;; 17:05:09.497 KED: Tx <txrxn? 2 REC.RETRIEVEDATA 0>
;; 17:05:09.498 COM6: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 17:05:09.498 COM6: Rx: <1> 31
;; 17:05:09.498 COM6: Rx: <0.050,0.071,3249513593,6.726,0.060,0.029> 30 2E 30 35 30 2C 30 2E 30 37 31 2C 33 32 34 39 35 31 33 35 39 33 2C 36 2E 37 32 36 2C 30 2E 30 36 30 2C 30 2E 30 32 39
;; 17:05:09.499 KED: Rx <0.050,0.071,3249513593,6.726,0.060,0.029>
;; 17:05:09.499 KED: Rx as numbers <0.05 0.071 3.249513593E9 6.726 0.06 0.029>
;; 17:05:09.597 KED: Tx <REC.TRIG>
;; 17:05:09.598 COM6: Tx: <REC.TRIG..> 52 45 43 2E 54 52 49 47 0D 0A
;; 17:05:09.598 KED: Tx <REC.DATA?>
;; 17:05:09.598 KED: Tx <txrxn? 2 REC.RETRIEVEDATA 0>
;; 17:05:09.600 COM6: Tx: <REC.RETRIEVEDATA 0..> 52 45 43 2E 52 45 54 52 49 45 56 45 44 41 54 41 20 30 0D 0A
;; 17:05:09.600 COM6: Rx: <>
;; 17:05:09.600 COM6: Rx: <-->1> 2D 2D 3E 31
;; 17:05:09.600 KED: Rx <-->1>
;; 17:05:09.601 KED: Rx as numbers <0.0>
Per the debug time stamps the first/working log point takes 2 mSec for send, receive of two commands and the second/not working one took 3 mSec.  The pause between data points is 98 mSec or approximately the the 100 mSec logging time interval.

Am I using #cmdDelayTime incorrectly or is it not working properly with #driver SCPIx?

PS  I can say that the problem happens much less often in Debug mode.  Say 1% of the time in debug mode and 10% of the time in regular mode.

[dmenezes]

Hi @HKJ,

First of all, thanks again for writing TC and sharing it with us all -- it's a wonderful program and I keep finding new uses for it.

Secondly, I would like to make a humble suggestion: could you please change TC to ignore lines beginning with "#" when importing CSV fles?

This is a common extension of the CSV standard, and is frequently used to insert comments (ie, non-data lines that should be ignored). Excel and Libreoffice do ignore those lines, but TC instead seems to stop at the first such line.

I have quite a few of these files around (not generated by TC, but TC's table and chart functions are great for analyzing them, much better than Excel or LibreOffice), and while it's not too complicated  to remove comments from them (just open a terminal, and do a `grep -v '^#' <original-file >temp-file` and then feed the latter to TC), it does disrupt the workflow -- so if TC could just ignore them like these other programs, it would really help.

TIA!

[The Soulman]

Pardon my noob question..
I'm trying to connect to to my Keithley 192 via a gpib adapter similair to the ar488 (it's this one: https://www.eevblog.com/forum/projects/poe-ethernet-gpib-adapter-open-source-project-now-public )
There is no 192 definition yet but the 199 one by Gertjan (thanks!) should work to some extend as most basic commands appear to be the same and should provide a nice starting point.

However the format in tc's address window isn't clear to me, if for instance, the gpib address number of the dmm is 8 and the IP address of the adapter is 169.254.2.77
should I enter:

Code: [Select]

8:169.254.2.77 ?

Is the port number in the definition file?
edit:
I understand that I also must configure a gpib adapter, it is the same ip address, is this correct? (see attachment)
I did read the manual a few times but this isn't mentioned?

[flash2b]

The main should be Keithley 199 GPIB B:8
The GPIB interfaces screen should be: AR488Lan B Socket 169.254.2.77

[Gertjan]

There is no 192 definition yet but the 199 one by Gertjan (thanks!) should work to some extend as most basic commands appear to be the same and should provide a nice starting point.

You will have to adapt the 199 configuration file. Your 192 will not identify as a 199, so TestController will respond with "Keithley,199 not found", and abort connecting.
Change the line #idString Keithley,199 to #idString Keithley,192.
Also modify #name and #handle to 1992.

Most important: remark out the line #verifyDevice "199" model? (place a semicolon in front of the line)

Now TestController will not verify the meter ID, and connect to any meter on the specified GPIB address.
Unfortunately, I did not find any GPIB command in the 192 manual for instrument  identification....

It is a good idea to use the 199 definition as a starting point for a 192 configuration file. There will be differences between the Model 192 and the 199. The 192 was about 10 years earlier then the Model 199. The GPIB standard was still in its infancy in 1979. Start with getting the communication & handshake right. (Using the W, Q, M, K and Y commands)
Carefully studying  the 192 manual and the TC ascii driver documentation will get you a long way.


I do not know if your Kofen diy PoE Ethernet GPIB Adapter is compatible with Prologic-LAN or AR488-LAN.
So first make sure that your GPIB adapter is working correctly in TestController before complicating matters further with an untested configuration file...

regards, Gertjan.

[TicoRussell]

Is it possible to use the TestController program and the Brymen BM869s multimeter to log two temperatures at the same time?
The multimeter has the ability to have two thermocouples connected simultaneously to take two measurements at the same time.

[The Soulman]

To not further clutter this topic I've created a new topic specifically to the gpib control of the Keithley 192.
https://www.eevblog.com/forum/testgear/keithley-192-gpib-control/ 

[Furna]

Is it possible to use the TestController program and the Brymen BM869s multimeter to log two temperatures at the same time?
The multimeter has the ability to have two thermocouples connected simultaneously to take two measurements at the same time.

Currently I am not able to have TestController to bound to my Brymen BM869s; anyway my adapter has been modified see
https://www.eevblog.com/forum/testgear/program-that-can-log-from-many-multimeters/msg5864597/#msg5864597
I would apreciate, if you own a BM869s, you try to bound and report the result.
Thank you

[Fenstergucker]

I would apreciate, if you own a BM869s, you try to bound and report the result.
Thank you

I used the 'TestController' program for the first time out of interest because I also have two Brymen BM869s with BC-86X and BC-86P adapters. I am using Windows 7 64-bit and have tested OpenJDK JDK v24.0.1 and v14.

I was only able to establish a connection with JDK v14 and the old BC-86X adapter.

With JDK v14 and JDK v24.0.1, no connection was possible with the new BC-86P adapter.
I have changed the firmware on the BC-86P adapter so that the adapter works with the BM869s from March 2024, see BC-86P patch

The old BC-86X adapter works with the BM869s from 2014 and 2024 with 'TestController'.

Peter

EDIT: The connection with the old BC-86X adapter works with JDK equal to or less than v21.0.2 (build 21.0.2+13).
EDIT2: One difference between the adapters is that the BC-86X is USB Low-Speed, the BC-86P is Full-Speed. I have recorded the USB protocol, maybe I can find a hint why the new BC-86P adapter does not work.

Code: [Select]

;; jSerialComm version: 2.10.3
;; Start thread for: HIDv0820p0001 - Brymen BM869s
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 046D C534  3F
;; HIDv0820p0001: Found HID: 0820 0001  A4 3F 01
;; HIDv0820p0001-81828: Found usb device: \\?\hid#vid_0820&pid_0001#8&18a0fb0&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
;; HIDv0820p0001-81828: TxHID: 00 00 86 66
;; HIDv0820p0001-81828: RxHID: 00 00 00 02 BE BE DA E4 A9 00 1E 40 40 40 40 40 00 00 00 86 86 86 86 00 00 00 00
;; Found Brymen BM869s on HIDv0820p0001-81828
;; HIDv0820p0001-81828: TxHID: 00 00 86 66
;; HIDv0820p0001-81828: RxHID: 00 00 00 02 BE BE DA E4 A9 00 1E 40 40 40 40 40 00 00 00 86 86 86 86 00 00 00 00
;; BM869: Tx <VALUE?>
;; HIDv0820p0001-81828: TxHID: 00 00 86 66
;; HIDv0820p0001-81828: RxHID: 00 00 00 02 BE BE DA E4 DB 00 1E 40 40 40 40 40 00 00 00 86 86 86 86 00 00 00 00
;; BM869: Rx <24.2>
;; BM869: Rx as numbers <24.2>
;; BM869: Tx <VALUE?>
;; HIDv0820p0001-81828: TxHID: 00 00 86 66
;; HIDv0820p0001-81828: RxHID: 00 00 00 02 BE BE DA E4 DB 00 1E 40 40 40 40 40 00 00 00 86 86 86 86 00 00 00 00
;; BM869: Rx <24.2>
;; BM869: Rx as numbers <24.2>


[HKJ]

Am I using #cmdDelayTime incorrectly or is it not working properly with #driver SCPIx?

I will have to check it, but you can use the [delay] syntax in the command.

[HKJ]

Hi @HKJ,

First of all, thanks again for writing TC and sharing it with us all -- it's a wonderful program and I keep finding new uses for it.

Secondly, I would like to make a humble suggestion: could you please change TC to ignore lines beginning with "#" when importing CSV fles?

This is a common extension of the CSV standard, and is frequently used to insert comments (ie, non-data lines that should be ignored). Excel and Libreoffice do ignore those lines, but TC instead seems to stop at the first such line.

I have quite a few of these files around (not generated by TC, but TC's table and chart functions are great for analyzing them, much better than Excel or LibreOffice), and while it's not too complicated  to remove comments from them (just open a terminal, and do a `grep -v '^#' <original-file >temp-file` and then feed the latter to TC), it does disrupt the workflow -- so if TC could just ignore them like these other programs, it would really help.

Good idea, I will look at it.

[HKJ]

EDIT: The connection with the old BC-86X adapter works with JDK equal to or less than v21.0.2 (build 21.0.2+13).
EDIT2: One difference between the adapters is that the BC-86X is USB Low-Speed, the BC-86P is Full-Speed. I have recorded the USB protocol, maybe I can find a hint why the new BC-86P adapter does not work.

I uses a hack for the HID access and it has some serious limitations.

[Fenstergucker]

I uses a hack for the HID access and it has some serious limitations.

Ok, then that's the way it is.
However, the BC-86P adapter still behaves strangely. This concerns the connection to the USB port and the reconnect in the TestController. String descriptors are read in, then the HID report descriptor. And then an 'endless' attempt is made to read in string descriptors. But the length specification has changed from 255 to 1026, and this does not seem to work properly.

Peter