Program that can log from many multimeters.

[HKJ]

No one seems to have answered my question. Does TestController have any logging of the establishment of the connection with the serial port and GPIB controller? I can only see logging of commands/data sent by the user after the connection has already been attempted.

Generally tcrundebug, but be aware the output from this command is redirected to a file.

I tried running from tcrundebug and got this output:

Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.DummyInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.DummyInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
   at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesShared(InterfaceThreads.java:653)
   at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:803)
Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.DummyInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.DummyInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
   at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesShared(InterfaceThreads.java:653)
   at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:803)

But what does this mean?

The name "Scan ports" suggest it is because you have checkmarked "Scan serial ports" and it sort of find a device that it cannot really connect to (That makes sense because it do not support a GPIB interface).

[jmurray]

New question: I'm playing with a modbus device, but I seem to be having a lot of trouble with the syntax for a modbus definition file.

For whatever reason, the device doesn't respond to specific relay queries as per the modbus standard. Probably a poor implementation.
I can query the state of all coils successfully, with:

Code: [Select]

Tx <coil? 0x0000 0x0020>
Tx: 01 01 00 00 00 20 3D D2
Rx: 01 01 04 80 00 00 00 D2 11
Rx <2147483648>

But I can't work out how to mask the returned coil information (80 00 00 00) to provide me with a result. I tried using the &mask specification from the modbus documentation, and various other ideas, but can't quite seem to work it out. I also haven't quite worked out how Test Controller is turning the returned packet in to a decimal value of 2147483648 either.

[jmurray]

New question: I'm playing with a modbus device, but I seem to be having a lot of trouble with the syntax for a modbus definition file.

For whatever reason, the device doesn't respond to specific relay queries as per the modbus standard. Probably a poor implementation.
I can query the state of all coils successfully, with:

Code: [Select]

Tx <coil? 0x0000 0x0020>
Tx: 01 01 00 00 00 20 3D D2
Rx: 01 01 04 80 00 00 00 D2 11
Rx <2147483648>

But I can't work out how to mask the returned coil information (80 00 00 00) to provide me with a result. I tried using the &mask specification from the modbus documentation, and various other ideas, but can't quite seem to work it out. I also haven't quite worked out how Test Controller is turning the returned packet in to a decimal value of 2147483648 either.

Okay, update:
I managed to get it working with matchBits() in :readmath:

Code: [Select]

#scpiCmd RLY32? coil? 0x0000 0x0020
:readmath: matchBits(0x8000, value)

Is this the recommended method?
Thanks

[jmurray]

New question: I'm playing with a modbus device, but I seem to be having a lot of trouble with the syntax for a modbus definition file.

For whatever reason, the device doesn't respond to specific relay queries as per the modbus standard. Probably a poor implementation.
I can query the state of all coils successfully, with:

Code: [Select]

Tx <coil? 0x0000 0x0020>
Tx: 01 01 00 00 00 20 3D D2
Rx: 01 01 04 80 00 00 00 D2 11
Rx <2147483648>

But I can't work out how to mask the returned coil information (80 00 00 00) to provide me with a result. I tried using the &mask specification from the modbus documentation, and various other ideas, but can't quite seem to work it out. I also haven't quite worked out how Test Controller is turning the returned packet in to a decimal value of 2147483648 either.

Okay, update:
I managed to get it working with matchBits() in :readmath:

Code: [Select]

#scpiCmd RLY32? coil? 0x0000 0x0020
:readmath: matchBits(0x8000, value)

Is this the recommended method?
Thanks

Nope, spoke too soon. Not sure what's being evaluated but it's not returning the states of the relays. Just some other result.
I'll keep trying in vain.

[WaveyDipole]

Thank you for your reply.

No one seems to have answered my question. Does TestController have any logging of the establishment of the connection with the serial port and GPIB controller? I can only see logging of commands/data sent by the user after the connection has already been attempted.

Generally tcrundebug, but be aware the output from this command is redirected to a file.

Yes, I am aware and its where O got the below from - a file called tc.log.

I tried running from tcrundebug and got this output:

Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.DummyInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.DummyInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
   at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesShared(InterfaceThreads.java:653)
   at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:803)
Exception in thread "Scan ports" java.lang.ClassCastException: class dk.hkj.comm.DummyInterface cannot be cast to class dk.hkj.comm.SerialInterface (dk.hkj.comm.DummyInterface and dk.hkj.comm.SerialInterface are in unnamed module of loader 'app')
   at dk.hkj.main.InterfaceThreads$ScanPorts.addDevicesShared(InterfaceThreads.java:653)
   at dk.hkj.main.InterfaceThreads$ScanPorts.run(InterfaceThreads.java:803)

But what does this mean?

The name "Scan ports" suggest it is because you have checkmarked "Scan serial ports" and it sort of find a device that it cannot really connect to (That makes sense because it do not support a GPIB interface).
[/quote]

That would maybe explain it, except that 'Scan serial ports' is NOT checked, so yes, I was wondering why the log suggests that the software is trying to scan serial ports when I had already explicitly specified one?

[HKJ]

Nope, spoke too soon. Not sure what's being evaluated but it's not returning the states of the relays. Just some other result.
I'll keep trying in vain.

The matchbits can be used for it, but the specification is a string:
matchBits("1xxx",value)

The value must match all 1 & 0 in the match value and all x is ignored.

There are other ways to mask bits, like & for and, >> for shift, in many cases I prefer them, but that is probably because I am very used to programming. The advantage of matchBits it that it can do a combined match on multiple bit positions in one function and it is easy to see what is going on (Multiple and and shift can also do it, but it can be a bit harder to read).

[HKJ]

But what does this mean?

I looked at the code, it looks like TC do not get a serial port when it initializes the GPIB interface, but instead a dummy interface. The dummy interface is returned when no name matches the special serial port name.

That is the reason I say to right click in the address field (On load device page for a serial device) to get the correct serial port name.

[tdv]

Hi HKJ,
I'm using Atorch PX100 with Test Contrioller. It works well in most cases, but sometimes I see some strange things, e.g. when the logging ON and pressing the screen button ON in setup, the load turns on and immediately turns off again. The physical button ON under the same conditions works right. When stop logging, everything becomes fine. Perhaps these are the disadvantages of the exchange protocol used. I have small prog from original producer of the load. It works right but has lack features. In the "Help" menu of prog there is a description of the exchange protocol. Perhaps you can add it to the Test Contrioller and this will help solve problems and add some new features, such as temperature measurement. In the attachment, I added a description of the protocol.
Thanks in advance!

[HKJ]

Hi HKJ,
I'm using Atorch PX100 with Test Contrioller. It works well in most cases, but sometimes I see some strange things, e.g. when the logging ON and pressing the screen button ON in setup, the load turns on and immediately turns off again. The physical button ON under the same conditions works right. When stop logging, everything becomes fine. Perhaps these are the disadvantages of the exchange protocol used. I have small prog from original producer of the load. It works right but has lack features. In the "Help" menu of prog there is a description of the exchange protocol. Perhaps you can add it to the Test Contrioller and this will help solve problems and add some new features, such as temperature measurement. In the attachment, I added a description of the protocol.
Thanks in advance!

When discussing protocol issue it is much easier for me if you include a communication log (Run TC in debug mode).

TC support 3 different protocols for the load, that match different version of the load. ATorch do not specify which version are supported on different versions, it is trial and error.

[tdv]

When discussing protocol issue it is much easier for me if you include a communication log (Run TC in debug mode).

Sorry, I'm far from programming.
Maybe I'll do something wrong.
Here is a part of the log with described problem (when the button ON from SETUP is pressed, it turns on the load and immediately turns it off)
It happens only when button LOG is on. When stop logging, everything is fine.

[HKJ]

When discussing protocol issue it is much easier for me if you include a communication log (Run TC in debug mode).

Sorry, I'm far from programming.
Maybe I'll do something wrong.
Here is a part of the log with described problem (when the button ON from SETUP is pressed, it turns on the load and immediately turns it off)
It happens only when button LOG is on. When stop logging, everything is fine.

I got around to log at the log.
TC only sends one on command and no off command, i.e. the auto-off must be something the load do by itself. This might be because the communication is fairly busy when logging and the load misunderstands something.


;; PX100: Tx <on 1>  Load is requested on
;; COM3: Rx: CA CB 00 0F FF CE CF   Answer for last voltage read is received
;; PX100: Rx <4.095>                      Answer for last voltage read is returned to display module.
;; PX100: Tx <current?>                   Read for load current
;; PX100: Tx <tx 1 1 *dd>                The on request is processed
;; COM3: Tx: B1 B2 01 01 00 B6        The on request is transmitted
;; COM3: Rx: 6F                                Load answers
;; PX100: Tx <rx? 0x12 /1000>          The request for read current is processed
;; COM3: Tx: B1 B2 12 00 00 B6         The request is transmitted


TC is multitasking, that is the reason commands are queued and first processes a blt later.

[Gertjan]

I found that the Fluke 8845A / 8846A  device configuration file is not working with meters with older firmware.

This definition is using the FETCh3? command for retrieving the measurement data. But this command is only available in later firmware versions (post 2008)
It is a known problem, described here: FLUKE 8846A does not respond to FETCH3? command


IMG 2991  Fluke 8845A-8846A firmware versions-2000pix

The upper meter, the 8845A has the older 2008 firmware, and there is no measurement read-out in TestController.
The lower meter, the 8846A, has the newer 2010 firmware and is perfectly usable in TestController.

For now, this is just a heads-up for 8845A / 8846A owners.

I am in the process of writing a new device configuration file for 8845A / 8846A, using commands available in all firmware versions.
(The existing definition is just a skeleton. Apart from the FETCh3 problem, it has only a Mode Menu and no advanced configuration (Setup Menu) at all)

regards, Gertjan.

[HKJ]

I am in the process of writing a new device configuration file for 8845A / 8846A, using commands available in all firmware versions.
(The existing definition is just a skeleton. Apart from the FETCh3 problem, it has only a Mode Menu and no advanced configuration (Setup Menu) at all)

Sounds interesting.

You can adjust commands and menus in a definition depending on something.
And if you read the version number it can be that something.

If you need any help with that kind of functionality, I can give your some hints on how to do it.

[Furna]

I am trying to use TestController with my BM869s firmware ver 'b' (bought March 2024).
Debug:

Code: [Select]

;; jSerialComm version: 2.10.3
;; Start thread for: HIDv0820p0001 - Brymen BM869s
;; HIDv0820p0001: Found HID: 0DB0 0B30 
[...]
;; HIDv0820p0001: Found HID: 0820 0001  11 3F 02
;; HIDv0820p0001-147217: Found usb device: \\?\hid#vid_0820&pid_0001#7&3a345e71&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
;; HIDv0820p0001-147217: Comm failed
;; HIDv0820p0001-147217: RxHID:
;; Stopping thread for: HIDv0820p0001-147217 - Brymen BM869s

The address is definitely correct since it is working with Sigrok/SmuView.
The device is NOT in use by other software.
Is there a way in TC to see/dump the comunication?
Any idea?

Thank you.

EDIT:
My adapter has been modified following instructions provided by Brymen ...
https://www.eevblog.com/forum/projects/brymen-bc-86p-usb-adapter-firmware-with-usbtmc-scpi/msg5404913/#msg5404913
Could timing be an issue?
Anyway it is working both with origianl software and SmuView

[HKJ]

I am trying to use TestController with my BM869s firmware ver 'b' (bought March 2024).

I have no idea why it fails, but the HID implementation is not great, it uses some special windows file handles to read HID data.

[Furna]

I am trying to use TestController with my BM869s firmware ver 'b' (bought March 2024).

I have no idea why it fails, but the HID implementation is not great, it uses some special windows file handles to read HID data.

I have the same behaviour on Linux Ubuntu 24.04
Log attached below.

Any idea how to debug? I am not familiar with Java.
Thank you.

[MASCH]

Hi,

I am trying to get my Keysight E3632A working, but so far no success....so some help would be highly appreciated

My configuration:

- AR488 USB to GPIB adapter
- MAC Mini computer
- E3632A set to GPIB address 2

From the Arduino IDE I can get a response to *IDN? and meat? commands.

But so far I have had no success getting the Power Supply to work with testcontroller.

I am not sure what to put in the address fields in the testcontroller software for the AR488 GPIB adapter and the Power supply?

- do I need to enter the same address for both?

Here is a screenshot of what I have so far:



Since there is no definition file for this instrument included with the testcontroller sw which is already configured for GPIB, I have tried to edit it to use GPIB instead.....but also no success.

Does anyone already have such a definition file?
My version is also attached here.

BR
Markus

[HKJ]

I have the same behaviour on Linux Ubuntu 24.04
Log attached below.

HID interface only works on Windows with TC.
A virtual Windows on Linux may work.

[HKJ]

Hi,

I am trying to get my Keysight E3632A working, but so far no success....so some help would be highly appreciated

My configuration:

- AR488 USB to GPIB adapter
- MAC Mini computer
- E3632A set to GPIB address 2

From the Arduino IDE I can get a response to *IDN? and meat? commands.

But so far I have had no success getting the Power Supply to work with testcontroller.

I am not sure what to put in the address fields in the testcontroller software for the AR488 GPIB adapter and the Power supply?

- do I need to enter the same address for both?

Here is a screenshot of what I have so far:

(Attachment Link)

Since there is no definition file for this instrument included with the testcontroller sw which is already configured for GPIB, I have tried to edit it to use GPIB instead.....but also no success.

Does anyone already have such a definition file?
My version is also attached here.

In the address field for E3632A you use the id and GPIB address, i.e. A:2

And you must select GPIB in the Type column.

[jmurray]

Hi HKJ,

What are the chances of eventually getting more functionality in the Mode popup, similar to the Setup popup? Things like #comboboxhot, pages, etc.

Currently working on a definition file (ASCII driver) for a 32 channel instrument that has 11 different modes per channel (12 including off), and am struggling to find a way get Test Controller to update the number of columns as necessary, because I can't feasibly use the Mode popup to configure, without creating a popup with 32 sets of 12 buttons 
(And to make that worse, the unit can be connected to multiple expansion chassis for up to 992 channels!)

[HKJ]

Hi HKJ,

What are the chances of eventually getting more functionality in the Mode popup, similar to the Setup popup? Things like #comboboxhot, pages, etc.

Currently working on a definition file (ASCII driver) for a 32 channel instrument that has 11 different modes per channel (12 including off), and am struggling to find a way get Test Controller to update the number of columns as necessary, because I can't feasibly use the Mode popup to configure, without creating a popup with 32 sets of 12 buttons 
(And to make that worse, the unit can be connected to multiple expansion chassis for up to 992 channels!)

I have been thinking about a numeric field to select channel (or whatever), that can then be combined with the buttons.
But I have not done anything about it.

You might be able to do something similar with a numeric mode button for each channel and then use a #scpiCmd to store the number and other #scpiCmds to send commands combined with the number. There are a couple of drivers that uses this for "Setup".

[Gertjan]

Hi HKJ,

I am working on a new definition for Fluke 8845A / 8846A. I also want to support the GPIB connector.

I found something odd (maybe a bug?) using [LOC] to terminate the GPIB connection, and set the meter back to local control.
[LOC] does not seem to work. However, sending ++llo and ++loc from a terminal program to the 8846A works as expected, setting the meter to remote and back to local.

The relevant part of the definition:

Code: [Select]

#port GPIB
#driver SCPIx

#finalCmd [1000];[LOC];[2000]

The resulting log:

Code: [Select]

;; FL8846A: Delay: 1000ms
;; FL8846A: Delay: 2000ms
;; COM9: Close
The delays are executed, but between the delays nothing is happening.... The meter stays in remote.

But when I change the definition code to this:

Code: [Select]

#scpiCmd gpibExit
[LOC]

#finalCmd [1000];gpibExit;[2000]

The [LOC] command is executed:

Code: [Select]

;; FL8846A: Delay: 1000ms
;; FL8846A: Tx <gpibExit>
;; FL8846A: Tx <[LOC]>
;; COM9: Tx: <++LOC.> 2B 2B 4C 4F 43 0A
;; FL8846A: Delay: 2000ms
;; COM9: Close
Now the [LOC] is sent to the meter, and indeed the meter goes back to local as expected.

What is going on here, and why does the first approach not work?
I am using the latest version of TC (v2.53) and AR488.

regards, Gertjan.

[Gertjan]

Hi HKJ,

Some additional info:
I found that [LLO] also does not work in the standard usage: #initCmd [LLO]. I did not notice before, as when the meter receives commands, it goes into remote anyway.

I need an exit #pgm# anyway, for some LAN and COM exclusive exit commands. So a workaround could be to send [LOC]  from there. Something like this:

Code: [Select]

#scpiCmd LanSerialExit #pgm#
if (portType!="GPIB")
  deviceWrite(handle,"SYST:LOC");
else
---line of code to send [LOC]---
endif;
Do you have a suggestion for the line of code to send the [LOC] command?

For your info the complete definition, (it is still a work in progress): Fluke8845A-8846A_v0.30.zip

regards, Gertjan.

[Odd]

(Solved)  The Wh measurement worked fine for me in the past, but on this run, it does not work, and got red.


When the logging is done, can I somehow fix and see the chart WITH the logged data?  / can the logged data be saved, then loaded back into the program?  - and re-visualized with additional/fixed math lines?

Solution:  after the logging was stopped, even the old math lines worked and could be applied.

[WaveyDipole]

But what does this mean?

I looked at the code, it looks like TC do not get a serial port when it initializes the GPIB interface, but instead a dummy interface. The dummy interface is returned when no name matches the special serial port name.

That is the reason I say to right click in the address field (On load device page for a serial device) to get the correct serial port name.

I have not been able to get this working on Linux, so I did some further experiments with TestController tonight.

I generally work on Linux, but I tried running TestController using a Windows 10 virtual machine. After re-directing the serial port to the virtual machine, installing Java on Windows, I then set up TestController in exactly the same way as I did on Linux, except for the port name. On Windows I did get a drop-down listing the serial ports on the devices tab and from this I was able to identify COM3 as the port being used by the AR488. After sertting up I clicked on Reconnect and got taken to the Commands tab as usually and saw an "Invalid Device" error telling me that the response from the AR488 was 'null'. This was at least a different response to what I had been getting on Linux. I then remembered that when connecting to the serial port on some Arduino boards, it takes a couple of seconds for the board to restart, so I used the 10uF capacitor trick to prevent the reset pulse and that worked. The HP34401A was now correctly identified, could be controlled and TestController received readings from it. So far so good. Incidentally, I like the ability to turn the display on and off!

I then went back to Linux an tried exactly the same thing. As previously, there was no drop-down listing the serial ports and I was not able to connect to the 34401A at all.

I then went back to Windows a second time and everything still worked as it had done previously.

The experiment was useful. It shows that I was using the correct procedure for setting up and that TestController works fine with an AR488 and the Agilent 34401A on Windows. However, evidently, for some reason, it does not recognise serial ports on Linux. I wonder, does it work on a Mac? On Linux I get no drop down list of serial port, and as noted earlier, the program seems to be defaulting to a dummy port.

I wonder whether it might be useful to add a configuration option to add a delay after connecting to the serial port and attempting to get a response from *idn? command via the AR488 controller. That might avoid the need to the capacitor workaround. Perhaps this is already possible by putting something in the Settings field in the GPIB interfaces dialogue?

I would be happy to contribute and have a look at what the problem on Linux is, but I don't see the sources published anywhere?

I would also like to add a short TestController setup section to the AR488 manual. I have already captured some screenshots while testing this evening, but it would be useful to be able to show it working on Linux as well if possible.

In any case, thank you for making this program available and I appreciate your adding support for the AR488.