Program that can log from many multimeters.

[HKJ]

I tested several batteries, now I'm thinking how to superimpose the comparison results on each other like here. Can this be done with TC?

To some degree, you can show up to 6 curves at a time.
To merge the data use the import function, there you can select what parameter to synchronize, that will probably be capacity. You may also want to play with the command #CHARTSCALESYNC and maybe #CHARTSCALENAME

[PaWill68]

Does not work. The abscissa axis contains the time parameter.
Can you make a short video on how to do this?

[HKJ]

Does not work. The abscissa axis contains the time parameter.
Can you make a short video on how to do this?

Right click on the hh:mm:ss field and select the axis you want.
Note: Some axis will disable the cursor function while they are used as x-axis.

[gby]

HKJ,

I am working to try and connect a Yokogawa WT3000 Power Analyzer into Test Controller.  The WT3000 is a SCPI interfaced device but it uses what Yokogawa calls a Legacy Protocol.  Working with a Yokogawa app engineer I received the attached description and Python coding example for that protocol.  (I was told no interface spec document could be shared with me.)

Using Ethernet, the connection is a socket with a header on each message.  The header has ms bit of the leading byte set with the rest of the 4 byte header being is a count of characters in the message.  So, the standard query *IDN? is 5 characters and becomes the following hex sequence:
     80 00 00 05 2a 49 44 4e 3f

I have used Test Controller set up with
     #port LXI 10001
     #driver ascii
     #eol \_
and can send raw hex messages and get an answer with txrxnBin 8....but only get 8 characters at a time.

There is also a complication.  Yokogawa implemented their interface in a server like manner in that you must log in before you can use the interface.  The instruments is set for user anonymous with no password but you have to do the log in before Test Controller can do an *idn? or #verifyDevice.  For my initial testing I have used

Code: [Select]

; Login in command
#scpiCmd loginy? txrxnBin? 8 \x80\x00\x00\x09\x61\x6e\x6f\x6e\x79\x6d\x6f\x75\x73
; Empty password
#scpiCmd pwdy? txrxnBin? 8 \x80\x00\x00\x00But, this method only gives 8 char of the reply at a time and you have to wait between sending the user name and then password.  See the attached file which includes Python code for logging in if that helps with details.

To move forward I need some advice and/or some help:
1.  How would you suggest handling doing the login at connection time but before doing any *idn? or #verifyDevice command?
2.  How to handle this protocol?  ascii driver with raw txrxBin? commands are close but not really working.  Is there a better driver/command pair for this device or does it really need a new protocol coded into Test Controller?

Any help would be appreciated.

[HKJ]

I am working to try and connect a Yokogawa WT3000 Power Analyzer into Test Controller.  The WT3000 is a SCPI interfaced device but it uses what Yokogawa calls a Legacy Protocol.  Working with a Yokogawa app engineer I received the attached description and Python coding example for that protocol.  (I was told no interface spec document could be shared with me.)

I cannot help you at the moment, my main computer has crashed and it will be some time before I am up and running fully again (I need to buy and install some new harddisks and do a lot of configuration).

[gby]

HKJ,

Sorry to hear about your computer HW issues.  Hopefully it won't be too time consuming or expensive to get back up and running.  My son's desktop motherboard stopped booting over the weekend so I feel you pain.

No problem waiting until your computer is back to normal for some assistance.  In the meantime I am working on some ideas within existing TC functionality to talk to the Yokogawa.

[HKJ]

Sorry to hear about your computer HW issues.  Hopefully it won't be too time consuming or expensive to get back up and running.  My son's desktop motherboard stopped booting over the weekend so I feel you pain.

I do not expect any serious troubles, only some work. I have a up-to-date backup of all my data for development and website on a RAID 6 server (It can loose two disks before I have to worry).

No problem waiting until your computer is back to normal for some assistance.  In the meantime I am working on some ideas within existing TC functionality to talk to the Yokogawa.

One note: txrxnBin? can handle more than 8 bytes in the V1.65, it will return the new bytes datatype when doing that.

[gby]

Hi HKJ,

A little more info on the Yokogawa WT3000 for when you are ready.  No hurry.

I tried creating a send message function to create the required header for the message automatically from the ascii text in the instrument driver file.  In the instrument driver file I did:

   #scpiCmd sendy? txrx? (hex(2147483648 + strlen(value)) + value)

Unfortunately when I connect to the instrument and run the sendy? command TC errors out by saying the following in the DOS Debug window:

Code: [Select]

sendy? "*IDN?"
;; WT3000: Tx <sendy? "*IDN?">
dk.hkj.script.ProgramExceptions$UnknownException: Variable not found strlen
hex(2147483648 + strlen"*IDN?"____<----____) + value
        at dk.hkj.script.Script.getVar(Script.java:73)
   + many more Java error lines.
Running the same code in a text script (not in a drive #scpiCmd) works fine:

Code: [Select]

=var temp = "*IDN?"
=temp = (hex(2147483648 + strlen(temp)) + temp)
= temp
;; 80000005*IDN?
It is as if the interpreter/evaluator used by the driver file for #scpiCmd's does not allow the string operator strlen and it thinks it is a variable name rather than a function.  Does the syntax need to change to use the strlen function in a #scpiCmd inside an instrument driver file?
   

[HKJ]

It is as if the interpreter/evaluator used by the driver file for #scpiCmd's does not allow the string operator strlen and it thinks it is a variable name rather than a function.  Does the syntax need to change to use the strlen function in a #scpiCmd inside an instrument driver file?

That sounds correct. When doing a reconnect I first remove all the functions (To remove the interface function), add a few functions, run the *idn? commands and when they are done add all functions, including a new set of interface functions.
It sound like some of the general purpose functions are not added before the *idn? command. I cannot fix this before I have my system back (A new harddisk is supposed to arrive around the weekend).
I may consider adding functions or rather commands to handle your (Yokogawa) requirements directly. Something like txYG and txrxYG? to the ascii driver.

[voltsandjolts]

I have a meter which returns this format for read? resistance:

Code: [Select]

0260.60e03 Ohms\r\n

So to extract the numeric value I use

Code: [Select]

#askValues read?
; Format of answer: f=float, u=remove trailing letters, x=skip, *=Zero upper case values if this value is 0
#askValuesReadFormat fx

If the probes are open circuit (inifinite resistance) it returns:

Code: [Select]

OVLOAD\r\n

But askValuesReadFormat converts this to decimal 0.0

Test Controller has Configuration option for Overload Handling (return 0, 1e99, infinite). How can I handle OVLOAD such that this config setting is used?

Thanks

[HKJ]

Test Controller has Configuration option for Overload Handling (return 0, 1e99, infinite). How can I handle OVLOAD such that this config setting is used?

For now overflow handling only works for devices with one return value and will kick in when the value is above 1e99.

This means using a #askValuesMathFormat  can be used to convert the answer into a numeric overflow value:
#askValuesMathFormat value=="OVLOAD"?1e100:value

Note: You may need to use some of the functions from: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#String_functions to isolate the OVLOAD text. Could be: countMatch(value,"OVLOAD")>0?1e100:value

If it is a handheld multimeter you can probably get away with a simpler driver, like the SingleValue driver: https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html#Single_value

[voltsandjolts]

Thank you, sir, works perfect:

Code: [Select]

#askValues read?
#askValuesReadFormat fxx
#askValuesMathFormat value=="OVLOAD"?1e100:value

I am working on a driver for the TTi 1908 which is mains or battery powered bench DMM.
Driver seems functional now, I'll test a little more and submit here in next few days.
There is a data logging feature (only 500 data points) and I might try to get that data downloading in TC if I have time.
https://www.aimtti.com/product-category/multimeters/aim-1908

[HKJ]

V1.66 is up
My computer is working again and I have fixed a couple of bugs and added a bit.
   Added: Hioki DT4281 multimeter.
   Added: Driver AsciiBin, same as Ascii driver, but support a binary envelope around the ascii.
   Fixed: Standard functions are now available during a reconnect
   Fixed: DL24 dropouts (I hope)
   Added: Sanwa PC7000, it is mostly a Brymen BM869s and works with Brymen interface.
   Fixed: Param sweeper did not stop after a "Primary only" sweep.

The driver AsciiBin is for gpy and his Yokogawa, but can be used if other devices packs ascii commands into a binary envelope. This driver has not been tested with LXI interface, only with serial and socket. The login will have to be included in a redefined *idn? command.

I hope the dropouts on the DL24 is gone now and would also like a confirmation that it works with the new DL24M version. Some definitions for the different DL24M models are also needed.

[gby]

HKJ,

Good to hear your computer is back up.  Also, thanks for the new version.

I will be able to try the AsciiBin driver with the Yokogawa tomorrow.  Fully booked today.  Will let you know how it goes.

[HKJ]

I will be able to try the AsciiBin driver with the Yokogawa tomorrow.  Fully booked today.  Will let you know how it goes.

You may need to check the documentation for the driver: https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html#Non-SCPI_ascii_devices_with_binary_envelope_(AsciiBin)

I have added a chapter listing the differences between the 3 main SCPI/Ascii drivers, this can be useful to check before starting to implement a new device: https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html#Difference_between_the_3_SCPI/ascii_drivers_(SCPI,_SCPIx,_Ascii)

[gby]

HKJ,

Thank you very much for adding asciiBin and thanks for the documentation reference.  After setting #packetFormat Length31 I am able to sort of talk to the Yokogawa.  Below is from debug mode using simple txrx? queries showing eventual answers with the proper string.

Code: [Select]

txrx? *idn?
;; WT3000: Tx <txrx? *idn?>
;; 10.8.37.94: Tx: 80 00 00 05 2A 69 64 6E 3F
;; 10.8.37.94: Rx: 80 00 00 00
;; WT3000: Rx Timeout
txrx?
;; WT3000: Tx <txrx?>
;; 10.8.37.94: Tx: 80 00 00 00
;; 10.8.37.94: Rx: 80 00 00 00
;; WT3000: Rx Timeout
txrx?
;; WT3000: Tx <txrx?>
;; 10.8.37.94: Tx: 80 00 00 00
;; 10.8.37.94: Rx: 80 00 00 00
;; WT3000: Rx Timeout
txrx?
;; WT3000: Tx <txrx?>
;; 10.8.37.94: Tx: 80 00 00 00
;; 10.8.37.94: Rx: 80 00 00 00
;; WT3000: Rx Timeout
txrx?
;; WT3000: Tx <txrx?>
;; 10.8.37.94: Tx: 80 00 00 00
;; 10.8.37.94: Rx: 80 00 00 20 59 4F 4B 4F 47 41 57 41 2C 37 36 30 33 30 34 2D 30 34 2D 4D 56 2C 30 2C 46 36 2E 33 31 41 44 0A
;; WT3000: Rx <YOKOGAWA,760304-04-MV,0,F6.31AD>
;; YOKOGAWA,760304-04-MV,0,F6.31AD
But, it seems like there is a buffer issue of some kind.  The first txrx? *idn? command times out and you have to send multiple empty commands of just txrx? in a row to get an answer.  I also tried multiple txrx? *idn? commands in a row and it still took multiple before the answer appeared.  Once it appeared follow on txrx? empty commands got the string multiple times.  It acts like the RX buffer is 4 transactions behind the tx.

Thoughts in where in the protocol/the Yokogawa/Test Controller this "buffer problem" might be or ideas to try to debug it?  In the WireShark recording of the Yokogawa terminal utility talking to the unit there is just one message sent to get one message with content back so I am at a loss??

For the moment I have been hand typing through the login sequence which is also made difficult by the "buffer issue".  I will be trying your suggestion of "...redefined *idn? command" which I assume means using the #verifyDevice command.  My question is how to make the #verifyDevice command be multiple txrx? command in a row?  For example how to:
   txrx? anonymous
   txrx?
   txrx?
where the first supplies the user name, the second enters the blank password, and the last gets past the "Ctl server is ready" final login message.

[HKJ]

Thank you very much for adding asciiBin and thanks for the documentation reference.

You may try adjusting the timeout value (#readingDelay)
My testing has been with a serial and a socket connection returning a answer when receiving a ? char.
If you can get me some better ideas of the problem I will look at it tomorrow (It is a bit late around here now).

For multiple commands try using multiple lines, the Ascii driver do not support ; as a command delimeter in the #scpiCmd, but is supposed to support multi lines with a command on each line (I have never gotten around to test it).

Adding debugtime=2 on the command line of TestController will add a precise timestamp to each command in the log.

[gby]

HKJ,

Thanks for the hint on adding debugTime to the debug startup.

I am not sure this is an issue of #readingDelay.  When sending just txrx? an empty message of 80 00 00 00 is sent and an empty message of 80 00 00 00 is received.  I am guessing that TC interprets a received empty message as no message and lists a timeout even though it got a reply.  Perhaps something to fix?  Also, I am manually typing the queries so there is plenty of time between queries.

See below more complete debug trace.  You can see me log in and once the instrument says "Ctl server is ready." I do two separate commands:
   txrx? *idn?
   txrx? :MEAS:AVER?
Each of the above yields an 80 00 00 00 empty reply.  I then do 3 more txrx? empty queries and eventually get the *idn and :MEAS:AVER answers.  Further txrx? queries yield empty replies.  See below sequence:

Code: [Select]

;; 15:45:02.536 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; Found Yokogawa WT3000 on 10.8.37.94
txrx? anonymous
;; 15:45:21.181 WT3000: Tx <txrx? anonymous>
;; 15:45:21.181 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 15:45:21.181 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 15:45:21.181 WT3000: Rx <username:>
;; username:
txrx?
;; 15:45:31.245 WT3000: Tx <txrx?>
;; 15:45:31.245 10.8.37.94: Tx: 80 00 00 00
;; 15:45:31.245 10.8.37.94: Rx: 80 00 00 00
;; 15:45:33.495 WT3000: Rx Timeout
txrx?
;; 15:45:40.802 WT3000: Tx <txrx?>
;; 15:45:40.802 10.8.37.94: Tx: 80 00 00 00
;; 15:45:40.802 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 15:45:40.802 WT3000: Rx <password:>
;; password:
txrx?
;; 15:45:44.316 WT3000: Tx <txrx?>
;; 15:45:44.316 10.8.37.94: Tx: 80 00 00 00
;; 15:45:44.316 10.8.37.94: Rx: 80 00 00 00
;; 15:45:46.522 WT3000: Rx Timeout
txrx?
;; 15:45:49.382 WT3000: Tx <txrx?>
;; 15:45:49.382 10.8.37.94: Tx: 80 00 00 00
;; 15:45:49.382 10.8.37.94: Rx: 80 00 00 14 43 74 6C 20 73 65 72 76 65 72 20 69 73 20 72 65 61 64 79 2E
;; 15:45:49.382 WT3000: Rx <Ctl server is ready.>
;; Ctl server is ready.
txrx? *idn?
;; 15:46:03.435 WT3000: Tx <txrx? *idn?>
;; 15:46:03.435 10.8.37.94: Tx: 80 00 00 05 2A 69 64 6E 3F
;; 15:46:03.435 10.8.37.94: Rx: 80 00 00 00
;; 15:46:05.652 WT3000: Rx Timeout
txrx? :MEAS:AVER?
;; 15:46:22.802 WT3000: Tx <txrx? :MEAS:AVER?>
;; 15:46:22.802 10.8.37.94: Tx: 80 00 00 0B 3A 4D 45 41 53 3A 41 56 45 52 3F
;; 15:46:22.803 10.8.37.94: Rx: 80 00 00 00
;; 15:46:24.996 WT3000: Rx Timeout
txrx?
;; 15:46:33.523 WT3000: Tx <txrx?>
;; 15:46:33.523 10.8.37.94: Tx: 80 00 00 00
;; 15:46:33.523 10.8.37.94: Rx: 80 00 00 00
;; 15:46:35.747 WT3000: Rx Timeout
txrx?
;; 15:46:37.289 WT3000: Tx <txrx?>
;; 15:46:37.289 10.8.37.94: Tx: 80 00 00 00
;; 15:46:37.289 10.8.37.94: Rx: 80 00 00 20 59 4F 4B 4F 47 41 57 41 2C 37 36 30 33 30 34 2D 30 34 2D 4D 56 2C 30 2C 46 36 2E 33 31 41 44 0A
;; 15:46:37.289 WT3000: Rx <YOKOGAWA,760304-04-MV,0,F6.31AD>
;; YOKOGAWA,760304-04-MV,0,F6.31AD
txrx?
;; 15:46:41.925 WT3000: Tx <txrx?>
;; 15:46:41.940 10.8.37.94: Tx: 80 00 00 00
;; 15:46:41.940 10.8.37.94: Rx: 80 00 00 31 3A 4D 45 41 53 55 52 45 3A 41 56 45 52 41 47 49 4E 47 3A 53 54 41 54 45 20 30 3B 54 59 50 45 20 45 58 50 4F 4E 45 4E 54 3B 43 4F 55 4E 54 20 32 0A
;; 15:46:41.940 WT3000: Rx <:MEASURE:AVERAGING:STATE 0;TYPE EXPONENT;COUNT 2>
;; :MEASURE:AVERAGING:STATE 0;TYPE EXPONENT;COUNT 2
txrx?
;; 15:46:46.523 WT3000: Tx <txrx?>
;; 15:46:46.523 10.8.37.94: Tx: 80 00 00 00
;; 15:46:46.523 10.8.37.94: Rx: 80 00 00 00
;; 15:46:48.726 WT3000: Rx Timeout

It acts like replies are in a 4 deep first in, first out buffer so that the answer to a query comes 3 queries later in the order the queries were asked.  I have also tried longer sequences of asking many different queries in a row and the proper answer appears after three more queries.

As for doing a multi-line command I tried automating the login sequence by putting the below in the driver file:
   #scpiCmd loginy? txrx? anonymous
   txrx?
   txrx?
   txrx?

   #scpiCmd <next command>
Running loginy? did the "txrx? anonymous" command but did not send anything else.  Did I try multi-line/multi-command incorrectly?

[Pukker]

@HKJ,

Sorry to mention, but with version 1.66 I have still dropouts with DL24.
Maybe less, but can't say for sure, because dropouts never an stable behaviour.

[HKJ]

I have uploaded a test version:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar
This is a jar file, i.e. it is used to replace the jar file in a already working TC installation.

It fixes the multiline issue in the Ascii/AsciiBin driver.
For messages with an empty answer use: txrx, i.e. without the ? at the end. The ? means there must be a answer for TestController.

For DL24 I have added some debug code that will log into the log window, please run until a dropout is seen and then post the log lines that covers that.

[Pukker]

HKJ thanks for your quick reply. I've downloaded your file and test this weekend.

Edit 1:
Made an quick start run.
When starting batterytest, (with powersupply as source) I get the following message
in the log window:

;; COM4: Zero answer for 12: CA CB 00 00 00 CE

The DL24 is on COM4.


Edit 2:
In debug window when dropout:

java.lang.NullPointerException
        at dk.hkj.devices.DeviceATorchPX100$TranslatingCommInterface.getValue(DeviceATorchPX100.java:63)
        at dk.hkj.devices.DeviceATorchPX100$TranslatingCommInterface.write(DeviceATorchPX100.java:149)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:141)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:162)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:211)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:256)
        at dk.hkj.main.SCPICommand.readNumbers(SCPICommand.java:361)
        at dk.hkj.main.DeviceInterface.getValuesFromDevices(DeviceInterface.java:396)
        at dk.hkj.devices.DeviceSCPI.getValuesFromDevices(DeviceSCPI.java:44)
        at dk.hkj.main.InterfaceThreads$DeviceThread.run(InterfaceThreads.java:1460)
;; ATDL24: Rx Timeout

[HKJ]

Edit 1:
Made an quick start run.
When starting batterytest, (with powersupply as source) I get the following message
in the log window:

;; COM4: Zero answer for 12: CA CB 00 00 00 CE

Yes, I have add logging of zero answers for current and voltage, they will be removed when the dropouts are fixed.

Edit 2:
In debug window when dropout:

java.lang.NullPointerException
        at dk.hkj.devices.DeviceATorchPX100$TranslatingCommInterface.getValue(DeviceATorchPX100.java:63)

I have modified the code a bit to avoid any problems with null pointer, you can download the modified version from the same link as before.
It may be up to an hour before the caches are updated, please verify that you get V1.68 before testing.

[Pukker]

@HKJ,

Tested with version 1.68, looks good.
No dropouts seen in first tests.
Some spikes in Current value, but that can be generated by Dl24.
I always had more dropouts when I had connected DL24 and RD6012 at the same time.

See pictures.

1. Only DL24 connected.
2. DL24 and RD6012 connected. Dropouts are RD6012 values, when stressing de RD with the rotary Encoder.
3. The same as 2, but for 45 minutes, no dropouts.
4. More than 3 hours logging, not touching anything, no dropouts DL24, some spikes on current values, probably generated by DL24. Some dropouts in voltage reading RD6012.

Looks good for the moment, thanks.

[gby]

HKJ,

Using latest test version 1.68 the multi-line sequence does send the multiple lines.  However, in some way something is not sequencing correctly or something is not waiting at the right time.  Below is debug window from manually typing the below sequence in one at a time and successfully logging in.
   txrx? anonymous
   txrx
   txrx
   txrx
   txrx?

Code: [Select]

Starting
;; 12:37:03.608 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; Found Yokogawa WT3000 on 10.8.37.94
txrx? anonymous
;; 12:37:19.457 WT3000: Tx <txrx? anonymous>
;; 12:37:19.457 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 12:37:19.457 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 12:37:19.457 WT3000: Rx <username:>
;; username:
txrx
;; 12:37:35.151 WT3000: Tx <txrx>
;; 12:37:35.151 10.8.37.94: Tx: 80 00 00 00
;; 12:37:35.151 10.8.37.94: Rx: 80 00 00 00
txrx
;; 12:37:37.671 WT3000: Tx <txrx>
;; 12:37:37.671 10.8.37.94: Tx: 80 00 00 00
;; 12:37:37.671 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
txrx
;; 12:37:40.995 WT3000: Tx <txrx>
;; 12:37:40.995 10.8.37.94: Tx: 80 00 00 00
;; 12:37:40.995 10.8.37.94: Rx: 80 00 00 00
txrx?
;; 12:37:49.193 WT3000: Tx <txrx?>
;; 12:37:49.193 10.8.37.94: Tx: 80 00 00 00
;; 12:37:49.193 10.8.37.94: Rx: 80 00 00 14 43 74 6C 20 73 65 72 76 65 72 20 69 73 20 72 65 61 64 79 2E
;; 12:37:49.193 WT3000: Rx <Ctl server is ready.>
;; Ctl server is ready.

Using the below #scpiCmd I had hoped to get the same result.

   #scpiCmd loginy? txrx? anonymous
   txrx
   txrx
   txrx
   txrx?

   #scpiCmd  <next command>
But the result is very different including some Java errors.

Code: [Select]

Starting
;; 12:39:16.759 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; Found Yokogawa WT3000 on 10.8.37.94
loginy?
;; 12:39:28.096 WT3000: Tx <loginy?>
;; 12:39:28.096 WT3000: Tx <txrx? anonymous
txrx
txrx
txrx
txrx?>
;; 12:39:28.096 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 12:39:28.096 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 12:39:28.096 10.8.37.94: Tx: 80 00 00 00
java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at dk.hkj.comm.SocketPacketInterface.readData(SocketPacketInterface.java:92)
        at dk.hkj.comm.SocketPacketInterface.writeReadData(SocketPacketInterface.java:233)
        at dk.hkj.comm.SocketPacketInterface.writeReadData(SocketPacketInterface.java:227)
        at dk.hkj.devices.DeviceAsciiBin$TranslatingCommDataInterface.oWriteRead(DeviceAsciiBin.java:61)
        at dk.hkj.devices.DeviceAscii$TranslatingCommInterface.write(DeviceAscii.java:247)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:141)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:162)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:211)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:256)
        at dk.hkj.main.DeviceInterface.doCommand(DeviceInterface.java:81)
        at dk.hkj.main.CommandProcessor.processCommands(CommandProcessor.java:2834)
        at dk.hkj.main.PaneCommand.processCommand(PaneCommand.java:1463)
        at dk.hkj.main.PaneCommand.access$20(PaneCommand.java:1461)
        at dk.hkj.main.PaneCommand$31.keyTyped(PaneCommand.java:897)
        at java.awt.AWTEventMulticaster.keyTyped(Unknown Source)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$500(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
       at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
;; 12:39:28.150 10.8.37.94: Rx timeout 1000ms   In buffer:
java.lang.NullPointerException
        at dk.hkj.devices.DeviceAsciiBin$TranslatingCommDataInterface.decode(DeviceAsciiBin.java:76)
        at dk.hkj.devices.DeviceAsciiBin$TranslatingCommDataInterface.oWriteRead(DeviceAsciiBin.java:61)
        at dk.hkj.devices.DeviceAscii$TranslatingCommInterface.write(DeviceAscii.java:247)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:141)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:162)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:211)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:256)
        at dk.hkj.main.DeviceInterface.doCommand(DeviceInterface.java:81)
        at dk.hkj.main.CommandProcessor.processCommands(CommandProcessor.java:2834)
        at dk.hkj.main.PaneCommand.processCommand(PaneCommand.java:1463)
        at dk.hkj.main.PaneCommand.access$20(PaneCommand.java:1461)
        at dk.hkj.main.PaneCommand$31.keyTyped(PaneCommand.java:897)
        at java.awt.AWTEventMulticaster.keyTyped(Unknown Source)
        at java.awt.Component.processKeyEvent(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
        at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.awt.EventQueue.access$500(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.awt.EventQueue$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.awt.EventQueue$4.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
;; 12:39:28.197 WT3000: Rx Timeout

I thought maybe there needed to be a delay between commands during the log in sequence but adding
   #delay 1
between the first line and the second line ended up with no errors but just the first command was done.  No delay and then doing the other command lines.

Thoughts on why the multi-line #scpiCmd yields such different results?

Also, after logging in still see a 3 transaction delay before the reply shows up.  I thought maybe it needed a line feed at the end of the message.  I put
   #eol \_
in the driver file but no line feed characters were added.  I then tried manually typing
   txrx? *idn?\r
and
   txrx? *idn?0x0A
hoping this would add the single line feed character but that just sent the characters and not an actual single character line feed.

I am out of ideas on why the reply arrives three message later...I wonder who is buffering this communications??

[HKJ]

Using the below #scpiCmd I had hoped to get the same result.

   #scpiCmd loginy? txrx? anonymous
   txrx
   txrx
   txrx
   txrx?

   #scpiCmd  <next command>
But the result is very different including some Java errors.
...
Thoughts on why the multi-line #scpiCmd yields such different results?

Use #cmdDelayTime, this will secure a minimum delay between commands.

Also, after logging in still see a 3 transaction delay before the reply shows up.  I thought maybe it needed a line feed at the end of the message.  I put
   #eol \_

Use #eol \n or maybe #eol \r\n