Program that can log from many multimeters.

[gby]

HKJ,

It turns out that #cmdDelayTime 1 allowed the automated login sequence to run.  Seems odd that only 1 mSec of additional delay makes it work but 1 mSec between commands is not going to limit performance enough to matter.

As for the issue of getting replies to queries three communications transactions later I am still at a loss.  I did try #eol \r, #eol \n but with those settings I could not log in to the instrument and thus could not try sending queries with new line or carriage return as end of line.

Any thoughts on next steps to debug what is going on?  Is there another debug option in Test Controller that might help get more information?  Do I really need to fire up WireShark and get complete traces of raw messages going back and forth?

[HKJ]

It turns out that #cmdDelayTime 1 allowed the automated login sequence to run.  Seems odd that only 1 mSec of additional delay makes it work but 1 mSec between commands is not going to limit performance enough to matter.

I may be the time the meter need to switch between sending and receiving.

As for the issue of getting replies to queries three communications transactions later I am still at a loss.  I did try #eol \r, #eol \n but with those settings I could not log in to the instrument and thus could not try sending queries with new line or carriage return as end of line.

If you need to build a special string, you can always switch into calculator mode with (), i.e. ("cmd\r\n") would be converter to the command followed by CR LF, but I doubt it will work.

Any thoughts on next steps to debug what is going on?  Is there another debug option in Test Controller that might help get more information?  Do I really need to fire up WireShark and get complete traces of raw messages going back and forth?

I do not have any good ideas and TC cannot do more debug than show transmitted and received data with a time stamp.

[gby]

HKJ,

OK, I will keep poking at the seeming 3 transaction deep buffer in the replies.  Thanks for the help so far.

I tried using the #verifyDevice command to automate logging into the instrument and can't seem to get it to match and succeed.  Using a device file without any #verifyDevice command and then manually typing loginy? yields the following debug window result.

Code: [Select]

Starting
;; 13:52:52.539 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; Found Yokogawa WT3000 on 10.8.37.94
loginy?
;; 13:52:58.838 WT3000: Tx <loginy?>
;; 13:52:58.838 WT3000: Tx <txrx anonymous
txrx
txrx
txrx
txrx?>
;; 13:52:58.838 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 13:52:58.838 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 13:52:58.854 10.8.37.94: Tx: 80 00 00 00
;; 13:52:58.876 10.8.37.94: Rx: 80 00 00 00
;; 13:52:58.881 10.8.37.94: Tx: 80 00 00 00
;; 13:52:58.897 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 13:52:58.913 10.8.37.94: Tx: 80 00 00 00
;; 13:52:58.928 10.8.37.94: Rx: 80 00 00 00
;; 13:52:58.943 10.8.37.94: Tx: 80 00 00 00
;; 13:52:58.948 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
;; 13:52:58.954 WT3000: Rx <Ctl server is ready.>
;; Ctl server is ready.
From the above the returned value for this loginy? command is "Ctl server is ready.".  I added the following to the device file:
   #verifyDevice "Ctl server is ready." loginy?
   #idString Ctl server is ready.
With the above in the device file it complains that  the "Device do not match" and closes the connection.

Code: [Select]

Starting
;; 14:08:05.739 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; 14:08:05.993 : Tx <txrx anonymous
txrx
txrx
txrx
txrx?>
;; 14:08:05.993 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 14:08:05.993 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 14:08:06.008 10.8.37.94: Tx: 80 00 00 00
;; 14:08:06.023 10.8.37.94: Rx: 80 00 00 00
;; 14:08:06.032 10.8.37.94: Tx: 80 00 00 00
;; 14:08:06.048 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 14:08:06.061 10.8.37.94: Tx: 80 00 00 00
;; 14:08:06.078 10.8.37.94: Rx: 80 00 00 00
;; 14:08:06.095 10.8.37.94: Tx: 80 00 00 00
;; 14:08:06.100 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
;; 14:08:06.105 10.8.37.94: **Device do not match** <Ctl_server_is_ready.>
;; 10.8.37.94 Device Ctl server is ready. do not match: **Device do not match** <Ctl_server_is_ready.>
;; 14:08:06.147 Stopping thread for: 10.8.37.94 - Yokogawa WT3000
What do I need to put on the #verifyDevice first argument and for the #idString to get them to match given what the multi-line log in command loginy? will return the ascii text "Ctl server is ready.".

[HKJ]

What do I need to put on the #verifyDevice first argument and for the #idString to get them to match given what the multi-line log in command loginy? will return the ascii text "Ctl server is ready.".

When using multiple commands the answer is a combination of all answers, you can use :readmath: to check it and maybe return "wt3000" if the answer contains  "Ctl server is ready."
The displayVar() function can be used in the :readmath: to see what you get.
Also note that only txrx? will return a answer, with txrx a answer will not be return.

[gby]

Thanks for the hint about displayVar().  But, for this driver, command and the latest beta V1.68 I can't get either :readmath: or displayVar() to work.  I tried the following command:
   #scpiCmd loginy? txrx anonymous
   txrx
   txrx
   txrx
   txrx?
   :readmath: "Yes"
to force the returned value to just be the string "Yes".  Unfortunately the combination of latest beta Ver 1.68, using asciiBin driver does not seem to ever execute the :readmath:.  See below debug window. 

Code: [Select]

loginy?
;; 16:17:33.794 WT3000: Tx <loginy?>
;; 16:17:33.794 WT3000: Tx <txrx anonymous
txrx
txrx
txrx
txrx?
:readmath: "Yes">
;; 16:17:33.794 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 16:17:33.794 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 16:17:33.803 10.8.37.94: Tx: 80 00 00 00
;; 16:17:33.822 10.8.37.94: Rx: 80 00 00 00
;; 16:17:33.828 10.8.37.94: Tx: 80 00 00 00
;; 16:17:33.847 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 16:17:33.856 10.8.37.94: Tx: 80 00 00 00
;; 16:17:33.871 10.8.37.94: Rx: 80 00 00 00
;; 16:17:33.884 10.8.37.94: Tx: 80 00 00 00
;; 16:17:33.890 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
;; 16:17:33.898 WT3000: Rx <Ctl server is ready.>
;; Ctl server is ready.
On another computer running Ver 1.66 I added
   :readmath: "Yes"
to the end of a command for a device using the ascii driver as a test.  In this case it returns "Yes" as expected.

[HKJ]

Unfortunately the combination of latest beta Ver 1.68, using asciiBin driver does not seem to ever execute the :readmath:.  See below debug window. 

Oops, I made a error while fixed the multiline handling. A new version is up on the same link.

Pukker: I have removed the debug messages and also tinkered a bit with the RD60xx protocol, to hopefully reduce dropouts on it.

[Pukker]

Pukker: I have removed the debug messages and also tinkered a bit with the RD60xx protocol, to hopefully reduce dropouts on it.

Great, more than an hour testing (Version 1.69) without any dropout. Compliments to HKJ

[gby]

HKJ,

Thanks for beta V1.69.  :readmath: in multi-line commands with asciiBin driver works now.

But, I still am having problems connecting when the string returned by #verifyDevice has spaces.

For a test, I added
   :readmath: "Yes"
to the end of the loginy? multi-line command and using:
   #verifyDevice "Yes" loginy?
   #idString Yes
TC logs into the Yokogawa successfully and things are working.

If I change the :readmath: at the end of the loginy? to
   :readmath: "Yes works"
and change the #verifyDevice, #idString correspondingly to:
   #verifyDevice "Yes works" loginy?
   #idString Yes works
TC fails to connect and reports:

Code: [Select]

;; 09:43:15.710 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; 09:43:15.964 : Tx <txrx anonymous
txrx
txrx
txrx
txrx?
:readmath: "Yes works">
;; 09:43:15.964 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 09:43:15.964 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 09:43:15.979 10.8.37.94: Tx: 80 00 00 00
;; 09:43:15.979 10.8.37.94: Rx: 80 00 00 00
;; 09:43:15.995 10.8.37.94: Tx: 80 00 00 00
;; 09:43:16.010 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 09:43:16.026 10.8.37.94: Tx: 80 00 00 00
;; 09:43:16.042 10.8.37.94: Rx: 80 00 00 00
;; 09:43:16.064 10.8.37.94: Tx: 80 00 00 00
;; 09:43:16.069 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
;; 09:43:16.091 10.8.37.94: **Device do not match** <Yes_works>
;; 10.8.37.94 Device Yes works do not match: **Device do not match** <Yes_works>
;; 09:43:16.133 Stopping thread for: 10.8.37.94 - Yokogawa WT3000
I note in the debug log that some of the strings are "Yes_works" with under score replacing the space and some are "Yes works" with the space.  I tried various things like #idString Yes_works and various other combinations and I could not find the right syntax to get #verifyDevice to succeed.

So, how to set the argument string in #verifyDevice and the value for #idString so that returned strings like "Ctl server is ready." with spaces in it will be properly recognized as a match?

[HKJ]

So, how to set the argument string in #verifyDevice and the value for #idString so that returned strings like "Ctl server is ready." with spaces in it will be properly recognized as a match?

Any spaces in the answer is replace with _, this means you can do the matching without using "" around the compare string.
From next version I will also replace spaces with _ in the value you type. For now use: #verifyDevice Yes_works loginy?

[gby]

HKJ,

Thanks for clearing up the space versus under score.  The #verifyDevice now logs in sucessfully most of the time.  There is still some form of communications issue sometimes where sending an empty message without expecting a reply
   txrx
generates an RX time out error.  Does txrx (no question mark) with asciiBin driver expect a reply?  I thought it would just send and not expect a reply and if not expecting a reply that would mean you should not be able to get an RX receive timeout error like shown in the below DOS debug record.

Code: [Select]

Starting
;; 12:13:07.786 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; 12:13:08.033 : Tx <txrx anonymous
txrx
txrx
txrx
txrx?
:readmath: "Ctl server is ready.">
;; 12:13:08.033 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 12:13:08.033 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 12:13:08.049 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)

[HKJ]

Does txrx (no question mark) with asciiBin driver expect a reply?  I thought it would just send and not expect a reply and if not expecting a reply that would mean you should not be able to get an RX receive timeout error like shown in the below DOS debug record.

txrx? expect a reply and passes it on to the driver
txrx expect a reply and do not pass it on.
tx do not expect a reply.

[HKJ]

A new documentation page with a list of supported equipment by function:

http://lygte-info.dk/project/TestControllerSupportedEquipment%20UK.html

[voltsandjolts]

Attached driver adds support for the TTi 1908 over USB (using CDC comport).

This DMM has a 500 datapoint memory (not a typo, only 500 datapoints unfortunately!) but I haven't had time to add support for that in the driver.

[HKJ]

Attached driver adds support for the TTi 1908 over USB (using CDC comport).

This DMM has a 500 datapoint memory (not a typo, only 500 datapoints unfortunately!) but I haven't had time to add support for that in the driver.

Thanks, it will be included in the next release.
I changed port to: #port comNoBaud

[bateau020]

Attached a driver for Rigol DG800/DG900 series.
Only tested through ethernet connection and on 2 channel enabled hardware.
Most of the on-device Main screen UI is duplicated.
TODO (one day...):
* Arb waveform upload
* many small functions like output invert, align, sweep, trigger, ....
* counter reading

(edit 09:13 CET: new version of the file)

[HKJ]

Attached a driver for Rigol DG800/DG900 series.
Only tested through ethernet connection and on 2 channel enabled hardware.
Most of the on-device Main screen UI is duplicated.
TODO (one day...):
* Arb waveform upload
* many small functions like output invert, align, sweep, trigger, ....
* counter reading

(edit 09:13 CET: new version of the file)

Thanks, I will include it in next release. I have added a #author tag with you handle, please say if you want it changed.

Waveform upload must be done with the "other" menu and use data (a selected column) from the table. Selection of a column can be done easily with the functions in TC,

[duckduck]

Hello. I just got a RD6006P (the "P" version has more precise V & I settings and lower noise). I noticed that the V & I settings were off so I made the following changes (in red):

#metadef
#author MikeLud
#idString Riden,Riden RD6006
#name Riden RD6006
#handle RD6006

#replacetext RD60xx 60062
#removeline 12A
#replaceText MaxCurrent 6.000
#replaceText MaxOCP 6.200
#replaceText CurrentScaleFactor 100
#replaceText VoltageScaleFactor 100

#metadef
#author DuckDuck
#idString Riden,Riden RD6006P
#name Riden RD6006P
#handle RD6006P

#replacetext RD60xx 60065
#removeline 12A
#replaceText MaxCurrent 6.000
#replaceText MaxOCP 6.200
#replaceText CurrentScaleFactor 10000
#replaceText VoltageScaleFactor 1000



#metadef
#author MikeLud
#idString Riden,Riden RD6012
#name Riden RD6012
#handle RD6012

#replacetext RD60xx 60121
#replaceText MaxCurrent 12.000
#replaceText MaxOCP 12.100
#replaceText CurrentScaleFactor 1000
#replaceText VoltageScaleFactor 100

#meta
#author MikeLud
#idString Riden,Riden RD60xx
#name Riden RD60xx
#handle RD60xx
#port comfixedbaud
#baudrate 115200
#driver Modbus

#verifyDevice RD60xx Model?

#notes RD6006/12 baud rate must be changed from 115200 to 9600 for this to work. RD6006P will not work at 9600. Consult User Manual for directions.

#scpiCmd SysTC? holding? 0x05
#scpiCmd VSet holding 0x08 (value) *VoltageScaleFactor
#scpiCmd VSet? holding? 0x08 /VoltageScaleFactor
#scpiCmd ISet holding 0x09 (value) *CurrentScaleFactor
#scpiCmd ISet? holding? 0x09 /CurrentScaleFactor
#scpiCmd VOut? holding? 0x0a /VoltageScaleFactor

That all seems to work OK, but the OCP and OVP reading and setting are off by a factor of 10. OVP on the supply of 0.7 shows up as OVP of 7 on TestController. Can someone point me in the right direction?

Also, none of my damn business since I didn't write this app, and I'm probably not the first to say this, but it sure would be nice to open source it and put it up on github. That being said, thanks to the authors and contributors for their hard work on this app. It is appreciated.

EDIT: I assume that memory settings won't work right either but I haven't tested those yet.

EDIT EDIT: I have played with these lines, but they didn't seem to do anything. Maybe I'm doing something wrong.

#scpiCmd OVP? holding? (MNS+2) /100
#scpiCmd OVP holding (MNS+2) (value) *100
#scpiCmd OCP? holding? (MNS+3) /1000
#scpiCmd OCP holding (MNS+3) (value) *1000

[HKJ]

Hello. I just got a RD6006P (the "P" version has more precise V & I settings and lower noise). I noticed that the V & I settings were off so I made the following changes (in red):

I would prefer you did it directly in definition file and posted a updated file, of course you would have to define the supply as a RD6006P.
The *100 and /100 etc. is the scaling and will change the values, but you may have to check the definition for where to change it.
It would be nice if you could do a perfect working implementation for the P version. You are welcome to post questions here or mail me directly with questions.

I am the only programmer on TestController (thanks to all the contributors with definitions) and I am not very good at open source. I have been publishing programs for many years, but always without source. You can see some of my older works here: https://www.miscel.dk/
I may at some date decide to do open source on TestController, but I will have to do a lot of clean up in the code.

[duckduck]

Hello. I just got a RD6006P (the "P" version has more precise V & I settings and lower noise). I noticed that the V & I settings were off so I made the following changes (in red):

I would prefer you did it directly in definition file and posted a updated file, of course you would have to define the supply as a RD6006P.
The *100 and /100 etc. is the scaling and will change the values, but you may have to check the definition for where to change it.
It would be nice if you could do a perfect working implementation for the P version. You are welcome to post questions here or mail me directly with questions.
<SNIP>

It is my intention to do a perfectly working implementation of the Riden RD6006P and also the East Tester ET5411.

So these lines (below) control reading and setting of OCP and OVP (see attached image)?

#scpiCmd OVP? holding? (MNS+2) /100
#scpiCmd OVP holding (MNS+2) (value) *100
#scpiCmd OCP? holding? (MNS+3) /1000
#scpiCmd OCP holding (MNS+3) (value) *1000

[gby]

txrx? expect a reply and passes it on to the driver
txrx expect a reply and do not pass it on.
tx do not expect a reply.

HKJ,

Still struggling to make the interface to the Yokogawa behave.  Based on the above I would expect using TX would not give an Rx Timeout error but it does.  See below DOS debug window showing the connection/log in sequence and just typing
   tx *idn?
from the command line.  At the end of the DOS debug window record after the TX only command there is an Rx Timeout.

Code: [Select]

Starting
;; 14:13:40.029 Start thread for: 10.8.37.94 - Yokogawa WT3000
;; 14:13:40.283 : Tx <txrx anonymous
txrx
txrx
txrx
txrx?
:readmath: "Ctl server is ready.">
;; 14:13:40.283 10.8.37.94: Tx: 80 00 00 09 61 6E 6F 6E 79 6D 6F 75 73
;; 14:13:40.283 10.8.37.94: Rx: 80 00 00 09 75 73 65 72 6E 61 6D 65 3A
;; 14:13:40.346 10.8.37.94: Tx: 80 00 00 00
;; 14:13:40.346 10.8.37.94: Rx: 80 00 00 00
;; 14:13:40.398 10.8.37.94: Tx: 80 00 00 00
;; 14:13:40.398 10.8.37.94: Rx: 80 00 00 09 70 61 73 73 77 6F 72 64 3A
;; 14:13:40.455 10.8.37.94: Tx: 80 00 00 00
;; 14:13:40.456 10.8.37.94: Rx: 80 00 00 00
;; 14:13:40.517 10.8.37.94: Tx: 80 00 00 00
;; 14:13:40.529 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
;; Found Yokogawa WT3000 on 10.8.37.94
tx *idn?
;; 14:13:55.465 WT3000: Tx <tx *idn?>
;; 14:13:55.465 10.8.37.94: Tx: 80 00 00 05 2A 69 64 6E 3F
;; 14:13:57.666 WT3000: Rx Timeout


Is this how it should work?

Also, the time lapse between starting a query and getting an Rx timeout error confuses me.  In the device file I have the command:
   #readingDelay 2
which I think means accept up to 2 seconds delay when reading values.  When I query and really get no reply it takes just over 2000 mSec per DOS Debug times stamps before the Rx timeout is reported.  But, when I query something with a long/large character count answer thre is always an Rx Timeout error.  The DOS Debug window has a line reporting "Rx timeout in 1000 mSec" and even more confusing the DOS Debug window time stamps say the Rx time out is happening after only 100's of mSec after the query start.

The DOS debug record at the end of the post shows properly getting one ascii float number via the Yokogawa command
   :num:norm:val? 30
Then, the record shows the Yokogawa command
   :num:norm:val?
with no index listed which should return all 255 values in one comma separated list.  Using the Yokogawa DLTerm software utility it reports taking from 50 to 184 mSec to receive this long message.  Test Controller just times out and lists the beginning of the buffer as 80 00 08 D2 which means it got the start of a 0x8D2 = 2258 decimal character reply.  Below is a summary of this sequence:
14:46:02.350  The :num:norm:val? query starts
14:46:02.518  SocketTimeoutException happens
14:46:02.618 Reports Rx timeout 1000ms   In buffer: 80 00 08 D2 80 80 80
14:46:02.663 WT3000: Rx Timeout

With #readingDelay 2 in the device file:
  1. Why does it report overall Rx Timeout after only 313 mSec?
  2. Why does it list "Rx timeout 1000ms" after only 268 mSec?
  3. Lastly, can Test Controller txrx? receive an ascii reply with 2000+ characters or does that over run the buffer?

Sorry for all this detail, but when testing logging two values every sec the communications gets an error anywhere from almost right away to maybe 100 sec into logging.  Once this communications error happens communications is permanently messed up with the replies coming out of order.  Sometimes after a com error Test Controller even freezes and stops responding/has to be force closed.  Unfortunately I haven't been able to reliably repeat Test Controller freezing.

For your reference I have attached the device file I have at the moment.

Code: [Select]

query? num:norm:val? 30
;; 14:45:37.770 WT3000: Tx <query? num:norm:val? 30>
;; 14:45:37.770 WT3000: Tx <txrx (value)
txrx
txrx
txrx?>
;; 14:45:37.770 10.8.37.94: Tx: 80 00 00 10 6E 75 6D 3A 6E 6F 72 6D 3A 76 61 6C 3F 20 33 30
;; 14:45:37.770 10.8.37.94: Rx: 80 00 00 00
;; 14:45:37.838 10.8.37.94: Tx: 80 00 00 00
;; 14:45:37.838 10.8.37.94: Rx: 80 00 00 00
;; 14:45:37.907 10.8.37.94: Tx: 80 00 00 00
;; 14:45:37.907 10.8.37.94: Rx: 80 00 00 00
;; 14:45:37.969 10.8.37.94: Tx: 80 00 00 00
;; 14:45:37.969 10.8.37.94: Rx: 80 00 00 04 49 4E 46 0A
;; 14:45:37.978 WT3000: Rx <INF>
;; INF
query? num:norm:val?
;; 14:46:02.350 WT3000: Tx <query? num:norm:val?>
;; 14:46:02.350 WT3000: Tx <txrx (value)
txrx
txrx
txrx?>
;; 14:46:02.350 10.8.37.94: Tx: 80 00 00 0D 6E 75 6D 3A 6E 6F 72 6D 3A 76 61 6C 3F
;; 14:46:02.350 10.8.37.94: Rx: 80 00 00 00
;; 14:46:02.403 10.8.37.94: Tx: 80 00 00 00
;; 14:46:02.403 10.8.37.94: Rx: 80 00 00 00
;; 14:46:02.465 10.8.37.94: Tx: 80 00 00 00
;; 14:46:02.465 10.8.37.94: Rx: 80 00 00 00
;; 14:46:02.518 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:286)
        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)
;; 14:46:02.618 10.8.37.94: Rx timeout 1000ms   In buffer: 80 00 08 D2 80 80 80
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:286)
        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)
;; 14:46:02.663 WT3000: Rx Timeout

[HKJ]

It is my intention to do a perfectly working implementation of the Riden RD6006P and also the East Tester ET5411.

So these lines (below) control reading and setting of OCP and OVP (see attached image)?

Yes and no, the lines define commands to read and write the values, but a #cmdSetup definition is used to show the value in a menu.

Generally you use #scpiCmd to define command, these can be tested from the command line. When they are working you can use #cmdSetup to make menus for them.

[HKJ]

Still struggling to make the interface to the Yokogawa behave.  Based on the above I would expect using TX would not give an Rx Timeout error but it does.

I do not have time to do a full answer now, but I hope a short answer will help you.
tx will only send a message, but adding a ? to the command means TC will expect a answer on the SCPI level and this will always lead to a timeout.
To understand that TC has two levels:
1) The SCPI like level.
2) The actual communication level.

A command with a ? will always expect a answer on the SCPI level, this will never happen from a tx (or txrx) command and means a timeout on the SCPI level.
A txrx may get a timeout on the actual communication level, when no answer is received, this will never happen form a tx that do not expect any answer.

[gby]

HKJ,

I think I understand the idea of com level and SCPI level.  Thanks for that explanation.

However, how is #readingDelay used?  From my testing it seems that the SCPI level uses this time and the communications level uses a different Rx time out value.  The example error printed 1000 mSec for the Rx timeout in the DOS box but the DOS debug times stamps said only 168 mSec before the "SocketTimeoutException  read timed out" error.

For the socket connection and for the communications level in general what sets the Rx timeout value?

Also, the example query that always fails is returning around 2260 characters.  Does that over flow the communications buffer?

Thanks again for your help.

[HKJ]

I think I understand the idea of com level and SCPI level.  Thanks for that explanation.

Not all drivers use multiple levels, SCPI is direct, SCPIx is direct, except when using the special commands (txrx, txrx?, tx, etc.).
All other drivers use the two levels.

On the SCPI level a timeout may often show up as a null pointer exception, instead of a timeout.

However, how is #readingDelay used?  From my testing it seems that the SCPI level uses this time and the communications level uses a different Rx time out value.  The example error printed 1000 mSec for the Rx timeout in the DOS box but the DOS debug times stamps said only 168 mSec before the "SocketTimeoutException  read timed out" error.

For the socket connection and for the communications level in general what sets the Rx timeout value?

Only the actual communication level uses timeout and that is supposed to be adjusted by #readingDelay. Default timeout is usually 1s or 1000ms. The SCPI level may inherited that timeout or get a null value return. I may have forgotten to transfer the #readingDelay setting to the communication driver for some drivers, if you suspect that please state the driver you are using and I will check.
The timeout is counter from start of the read, but this is not logged, instead you can usually assume the timestamp for the previous tx is the time the rx started (it will seldom be more than a ms off).

Also, the example query that always fails is returning around 2260 characters.  Does that over flow the communications buffer?

Generally there is not supposed to be any buffer overflows, but some messages queues are limited in length to avoid long delays. This only affects complete messages, a single message is not limited in length, but a timeout may cut it short.

[gby]

HKJ,

... if you suspect that please state the driver you are using and I will check.

The communications setup for the Yokogawa in the driver file is:
   #name Yokogawa WT3000
   #handle WT3000
   #port LXI 10001
   #driver asciiBin
   #packetFormat Length31
   #eol \_
   #cmdDelayTime 50
The "Load devices" tab is set to use Type "Socket".  Full driver file is attached for your reference.

Also, the example query that always fails is returning around 2260 characters.  Does that over flow the communications buffer?

Generally there is not supposed to be any buffer overflows, but some messages queues are limited in length to avoid long delays. This only affects complete messages, a single message is not limited in length, but a timeout may cut it short.

The query command I am having trouble with reports back all the measurements in a comma separated list and is around 2260 characters listing 255 floating point values including some "NaN" and some "INF".  This query command always times out and after it times out communications with the device always stops working; every subsequent query command errors out or comes in out of order like there is a buffer error.  Sometimes after this query command Test Controller freezes and must be force stopped (the close "X" in the upper corner does not work).

As shown in the previous detailed post in the second DOS Debug record this query command from last tx line to final line took 663-518 = 145 mSec.  Note the line in the debug where it says "timeout 1000ms " but the Debug time stamps show it is no where near 1000ms.  My eyes are not a precision clock, but the error report seems pretty much immediate after hitting return on the command line suggesting much faster than 1 sec from send start to timeout/error.
;; 14:46:02.465 10.8.37.94: Tx: 80 00 00 00
;; 14:46:02.465 10.8.37.94: Rx: 80 00 00 00
;; 14:46:02.518 10.8.37.94: Tx: 80 00 00 00
java.net.SocketTimeoutException: Read timed out
        at java.net.SocketInputStream.socketRead0(Native Method)
                        + Many more Java error lines removed to shorten.  See original post for full lines.
;; 14:46:02.618 10.8.37.94: Rx timeout 1000ms   In buffer: 80 00 08 D2 80 80 80
java.lang.NullPointerException
        at dk.hkj.devices.DeviceAsciiBin$TranslatingCommDataInterface.decode(DeviceAsciiBin.java:76)
                        + Many more Java error lines removed to shorten.  See original post for full lines.
;; 14:46:02.663 WT3000: Rx Timeout

Perhaps with this driver combination there is a short timeout at the socket level?
Can you think of any further test ideas to understand this problem?

Added a Little Later:

Further testing with this command shows that the error happens when the number of characters exceeds 127.  It turns out the Yokogawa allows retrieving 1 to a set number or by default up to the max 255 at once.
Setting the range from 1 to 16 sends 0x7F characters and works repeatedly.
Setting the range from 1 to 17 sends 0x83 characters and always errors out and communications stops working.

From the above I conclude somewhere Test Controller has a 127 character max buffer/limit of some kind.  The buffer length limit explains the long command always failing but does not explain or solve the issue of communications failing randomly/sometimes.