Program that can log from many multimeters.

[HKJ]

Working a bit on Kunkin, but it far from finished:

Try with this .jar file, it will get the correct transmit message:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar  (V1.15)

The definition file must contain:
#driver Modbus
#subDriver Kunkin

Using a "holdingL 0x116 2000" message matches manual with this subDriver

What I need to know now is (Logs from using debug mode):

Do TC handle the answer and what is the answer.

Do a "holding 0x10c 1" set the load in short mode.

Answering messages from:
holding? 0x10c
holdingL? 0x116
holdingL? 0x300

[HKJ]

Ver. 0.3 of the HMO1022 definition file. Now includes phase measurement. 
Useful for aligning tape heads - should anybody sill be doing this.

It will be included in the next release.

[gby]

Initial test results with Kunkin KP184 using the below in the device file:
   #port com
   #driver Modbus
   #subDriver Kunkin
   ;#disableWriteSingle 1
I then did the following sequence to test using the test TC V1.15:

1.  Started TC in debug mode with only Kunkin selected
2.  Did holdingL 0x116 2000
     Got a reply from it.
     Doc says echo full command but debug only shows first 6 Char not full 13.
     Best news is the current value was successfully set to 2000 mA (Checked via front panel)
3.  holding 0x10c 1
     No Rx from Kunkin/Rx Timeout
4.  holding? 0x10c
     Rx timeout
5.  holdingL? 0x116
     Rx timeout
6.  holdingL? 0x300
     Rx timeout
The full debug window contents of running the above is attached.

Then just to see if some incomplete operation on the instrument or in TC held up the queries I power cycled the Kunkin, restarted TC and the first thing I did was
   holdingL? 0x116
to see if that made any difference.  Unfortunately same answer Rx Timeout.  Lastly, right after this I tried:
   holdingL 0x116 1500
and again the write worked.  So, the Kunkin seems to be ready right away after an unsuccessful communication attempt.

Working a bit on Kunkin, but it far from finished:

Try with this .jar file, it will get the correct transmit message:
http://lygte-info.dk/pic/Projects/TestController/TestController.jar  (V1.15)

The definition file must contain:
#driver Modbus
#subDriver Kunkin

Using a "holdingL 0x116 2000" message matches manual with this subDriver

What I need to know now is (Logs from using debug mode):

Do TC handle the answer and what is the answer.

Do a "holding 0x10c 1" set the load in short mode.

Answering messages from:
holding? 0x10c
holdingL? 0x116
holdingL? 0x300

[HKJ]

Initial test results with Kunkin KP184 using the below in the device file:

Thanks, it helped. I have updated the .jar file (Same link as before).
The problem is that it do not use modbus, but some modified (and not very well documented) version of it. I have to experiment with the messages.

Please run the same tests as before.

[gby]

Thanks, it helped. I have updated the .jar file (Same link as before).
The problem is that it do not use modbus, but some modified (and not very well documented) version of it. I have to experiment with the messages.

Please run the same tests as before.

Results with V1.16:
1.  Started TC in debug mode with only Kunkin selected
2.  Did holdingL 0x116 2000
     No Rx reply in debug window.
     Successfully set current to 2000 mA
3.  holding 0x10c 1
     No Rx from Kunkin
     Don't think it did anything, not sure display shows short mode on.
4.  holding? 0x10c
     Rx timeout
5.  holdingL? 0x116
     Rx worked
     Received back the 2000 mA setpoint.
6.  holdingL? 0x300
     Rx gave something in debug window.  Should be actual voltage and current which are both 0, but only 2000 shows.
     Manual says send:      01 03 03 00 00 00 8E 45
     TC 1.16 actually sent: 01 03 03 00 00 04 4D 44
     I think the TC "04" needs to be "00" for this command.  last two are correct CRC's I assume.
The full debug window contents of running the above is attached.

For doing communication debug like this can TC send raw hex sequences typed manually in somehow?  If there was a mode to send raw could just try commands and see what comes back without having to change Java code.  Just a thought....

[HKJ]

Try changing all the holdingF to holdingL in the definition file, you will probably be able to set parameters on the load then.

What is missing now is reading and writing 1 byte values (0x10c) and the long message (Maybe it is 0x3000 instead of 0x300).
Do it work with a 32 bit read?
holdingL? 0x10c

There is some model and version info here:
holdingL? 0x0001

[gby]

Try changing all the holdingF to holdingL in the definition file, you will probably be able to set parameters on the load then.

What is missing now is reading and writing 1 byte values (0x10c) and the long message (Maybe it is 0x3000 instead of 0x300).
Do it work with a 32 bit read?
holdingL? 0x10c

There is some model and version info here:
holdingL? 0x0001

After changing holdingF to holdingL in the Device file most things are working now with Ver 1.16 
Nothing I tried caused any errors in the debug window.  No Java errors, no timeouts.

I fixed a couple of typos in the original device file:
   Voltage, current measurement addresses backwards.
   Mode setting CC and CV in device popup were backwards.

I did the requested queries:

1.  Start TC Ver 1.16 with just Kunkin KP184 connected.
     Connects with no errors.
2.  holdingL? 0x10c
     Returns 234881024 = 0xE000000
3.  holdingL? 0x0001
     Returns 1840 which seems to be the model number
4.  mode? to read back the present mode
     Returns number correctly.  3 for CW and 1 for CC.

Seems to log OK also.  I requested log 0.01 and it did 0.05 sec between points consistently.  I assume 0.05 sec is set by the communications/Kunkin turn around time.  Still, pretty good.

I have attached the debug window for the above and the modified device file I used.

Any suggested next steps to try?

[HKJ]

Any suggested next steps to try?

Do on/off work?

Any it needs a verifications:

#scpiCmd model? holdingL? 0x0001
#verifyDevice 1840 model?

This will basically prevent the definition from loading without a KP184 connected, i.e. the *idn? will not answer.


With this there is not much to do, maybe try if reading/writing two bytes at a time work. I have uploaded a new version where holding without the final L will read/write 2 byte entries, you can try that with 0x10c

[BobM]

HKJ, could you please explain the basics of how the IP communication between your software and the devices work?

I'm trying to get RD6006W to communicate with the software. I have a fair bit of computer and electronics experience (decades) but I can't seem to find documentation on the basics. Which side initiates the IP connection? Ports? Etc.

From what I gathered so far RD60006W uses Modbus to communicate. These is an ESP8266 chip inside the RD6006W that act's as an IP bridge for Modbus.

To get the ESP8266 chip to communicate, it needs to be joined to WiFi, which I successfully did with an Android app. But the app apparently set a "server IP", which is the IP of the Android device. Once the ESP8266 obtained a real IP, I port scanned it and found nothing open. Which suggests the RD6006W would connect to your software?

[HKJ]

HKJ, could you please explain the basics of how the IP communication between your software and the devices work?

Standard client-server with the device being server.

To get the ESP8266 chip to communicate, it needs to be joined to WiFi, which I successfully did with an Android app. But the app apparently set a "server IP", which is the IP of the Android device. Once the ESP8266 obtained a real IP, I port scanned it and found nothing open. Which suggests the RD6006W would connect to your software?

As I said above the device must be server for my software to connect.

The serial connection to RD6006 uses modbus-RTU (Modbus has 3 different formats: RTU, Ascii, TCP)

[gby]

Do on/off work?

Any it needs a verifications:

#scpiCmd model? holdingL? 0x0001
#verifyDevice 1840 model?

This will basically prevent the definition from loading without a KP184 connected, i.e. the *idn? will not answer.

With this there is not much to do, maybe try if reading/writing two bytes at a time work. I have uploaded a new version where holding without the final L will read/write 2 byte entries, you can try that with 0x10c

On/Off is working.  Indicator in device popup does not work.  Not sure why.

Added the model?, #verifyDevice to the file and that seems to work.

Code: [Select]

;; Start thread for: COM1 - Kunkin KP184
;; COM1: Set params: 9600
;; : Tx <holdingL? 0x0001>
;; COM1: Tx: 01 03 00 01 00 04 C9 15
;; COM1: Rx: 01 03 04 00 00 07 30 17 F8
;; COM1: Tx <mode?>
;; COM1: Tx <holdingL? 0x0110>
;; COM1: Tx: 01 03 01 10 00 04 30 44
;; COM1: Rx: 01 03 04 00 00 00 01 F3 3B
;; COM1: Rx <1>
;; Found Kunkin KP184 on Serial0 (COM1)
Using the new V1.17:
   holding? 0x10c
yields Java errors and Rx Timeout.  On the other hand,
   holdingL? 0x10c
yields 0 as the response when device is off and 234881024 = 0xE0000000 when the device is on.  I am guessing that holdingL would work if combined with masking to get at the bits.  My Kunkin manual has no documentation on 0x10c so I can't suggest what masking.

Attached is the latest Kunkin 184 device file.  Perhaps it is good enough to publish now?

[HKJ]

On/Off is working.  Indicator in device popup does not work.  Not sure why.

Because on must return a 1 value with the current definition. This is easily fixed.
Instead of "on 1" use "on  0xE0000000" or add a :readmath: expression to convert it on the line below #scpiCmd: :readmath: value?1:0

Using the new V1.17:
   holding? 0x10c
yields Java errors and Rx Timeout.  On the other hand,
   holdingL? 0x10c
yields 0 as the response when device is off and 234881024 = 0xE0000000 when the device is on.  I am guessing that holdingL would work if combined with masking to get at the bits.  My Kunkin manual has no documentation on 0x10c so I can't suggest what masking.

I have a Chinese/English spreadsheet with a list of address, some of them are marked with 1 and some with 4
These is some more to control if somebody wants to use the time.

Attached is the latest Kunkin 184 device file.  Perhaps it is good enough to publish now?

With exception of getting the indicator to work, yes. More stuff would be nice, but it not needed before I will include the definition.

[BobM]

Standard client-server with the device being server.

That's what I would have bet on if I were to guess how it works.

But, I'm getting a very strong impression that the RD6006W acts as the client, and the software (Riden's PC software and mobile apps) act as the server.

Here's why:

• When connecting the ESP8266 module to the WiFi is seems to set the "server" IP, which is the IP of the mobile device itself, and saves it permanently
• When booting up the RD6006W, it shows my mobile's IP as the "server", and if Riden's mobile app is closed during boot up, it says "Connecting server.... [ERROR]". If the app is open, it says connection to server was OK

Did anyone actually get RD6006W working over WiFi? 

[gby]

On/Off is working.  Indicator in device popup does not work.  Not sure why.

Because on must return a 1 value with the current definition. This is easily fixed.
Instead of "on 1" use "on  0xE0000000" or add a :readmath: expression to convert it on the line below #scpiCmd: :readmath: value?1:0

Added the :readmath and now on? returns 0 or 1 and not 0xE0000000.  But, the popup indicator seems to be permanently on.  I must admit that indicator lights are the hardest part of device files for me.

Attached is latest Kunkin KP184.  I suggest going ahead and publishing it.

[Messtechniker]

Ver. 0.4 of the HMO1022 definition file. Now includes
Position read/write,Volts/Division read and Mode buttons

[HKJ]

But, I'm getting a very strong impression that the RD6006W acts as the client, and the software (Riden's PC software and mobile apps) act as the server.

I believe that is the case and it is not support in TestController.

I suggest going ahead and publishing it.

Agree.

Ver. 0.4 of the HMO1022 definition file. Now includes
Position read/write,Volts/Division read and Mode buttons

I will include the updated version.
You can have more than one button on a line by using "buttons" instead of "button"
https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Control_buttons

I was thinking about something like this:

#cmdSetup button Quick_Viev
:write: MEAS1:#
Off AOFF
On AON

[Messtechniker]

Yep. I was also thinking about this 2 buttons in row thing, but initially did not succeed.
I'll try your valuable hint.

A few minutes later:
Quick View buttons now in a single row.
Will wait with publication until I get a response from R&S Germany about the non-functional offset command OFFS.

Just got a response from R&S. They can reproduce this behaviour! (gotcha)
And will get back to me.
Good service for a scope which has been discontinued a while ago.

[HKJ]

Yep. I was also thinking about this 2 buttons in row thing, but initially did not succeed.

The "buttons" format can handle from one button and up, the only limit is how wide you want the popup. The "button" function is mostly for one wide button to do an important function, as you can see it lacks the label at the left side that most other controls have.
If you use":write: #" then the full command for each button is after the button text.

[BobM]

But, I'm getting a very strong impression that the RD6006W acts as the client, and the software (Riden's PC software and mobile apps) act as the server.

I believe that is the case and it is not support in TestController.

Does that mean that TestController can only work through a USB connection with the RD6006W?

[Messtechniker]

Now something a bit different. Although I don't think I'll be going down that rabbit hole just now.
Maybe on a rainy winters day.

I have several home-grown networked BME 280 sensors which spit out continuously temperature, humidity and atmospheric pressure through a virtual com interface. Example of a single full sequence below. Is there in principle a way to acquire, then split the data string and finally display the data, for example only temperature and humidity in Test Controller? Of all the supported instruments is there already one doing something like this?

Output as ASCII:
Ut:527388 Up:408424 Uh:31645<\r><\n>Temperatur:        23.68?C<\r><\n>Luftdruck 64bit:   1005.564hPa<\r><\n>Luftdruck 32bit:   1005.18hPa<\r><\n>Luftfeuchtigkeit:  65.097%<\r><\n>H?he ?ber Meer:  64.18m<\r><\n><\r><\n>

Same output as HEX:
55 74 3A 35 32 37 33 38 38 20 55 70 3A 34 30 38 34 32 34 20 55 68 3A 33 31 36 34 35 0D 0A 54 65 6D 70 65 72 61 74 75 72 3A 20 20 20 20 20 20 20 20 32 33 2E 36 38 B0 43 0D 0A 4C 75 66 74 64 72 75 63 6B 20 36 34 62 69 74 3A 20 20 20 31 30 30 35 2E 35 36 34 68 50 61 0D 0A 4C 75 66 74 64 72 75 63 6B 20 33 32 62 69 74 3A 20 20 20 31 30 30 35 2E 31 38 68 50 61 0D 0A 4C 75 66 74 66 65 75 63 68 74 69 67 6B 65 69 74 3A 20 20 36 35 2E 30 39 37 25 0D 0A 48 F6 68 65 20 FC 62 65 72 20 4D 65 65 72 3A 20 20 36 34 2E 31 38 6D 0D 0A 0D 0A

Just as a matter of interest.

[HKJ]

I have several home-grown networked BME 280 sensors which spit out continuously temperature, humidity and atmospheric pressure through a virtual com interface. Example of a single full sequence below. Is there in principle a way to acquire, then split the data string and finally display the data, for example only temperature and humidity in Test Controller? Of all the supported instruments is there already one doing something like this?

Not really. There is a couple of problems with the format:
1) The device initiate the communication
2) It is a multi line message.

Notes:
1) is supported for dmm's, i.e. devices with a single value. There is one driver customizable that can handle that.
2) That is not supported on any customizable driver.

The easiest way to use a home grown sensor is to make a command interpreter that supports "*idn?" and "values?", you can find examples on my website:
https://lygte-info.dk/project/ThermoSensor%20UK.html
https://lygte-info.dk/project/LogicOutputs%20UK.html

Both devices are included in TestController, but not with a text file, because I included them before I made the customizable definitions.
In them I use a customable command interpreter, that is very easy to include in other projects.

[Messtechniker]

Thank you for the information. So I'll be looking around for something else to do in winter should I get bored. Next thing I'll be doing is to repair an old R&S UPGR Psophometer this being much more in line with my abilities. But that's

[HKJ]

You made me think!

If somebody makes a project that works with TestController and want to share it I can publish a link or even a page with the project description on my website.
Before a project qualify it must contain enough that it can be easy duplicated, i.e. at least:

• Schematic/wiring diagram in a readable format, i.e. PDF or PNG
• Parts used.
• Source code for the software
• Device definition for TestController.

[gby]

HKJ,

Since you changed the script expression evaluation process I find that for #delay and #log commands using a variable I need to put ()'s around it.  For example,
   old:  #log stepTime
 new:  #log (stepTime)
Adding the ()'s is not an issue.  But, it broke some (all?) of your built in example scripts.

if you have a generator connected to TC, right click the window and select Waveform generator | Logarithmic frequency sweep to get the built in frequency sweep example script.  If you run that script as is it no longer works.  Running that script as is finishes way too fast and logs no data.  I tested this with Ver 1.17.

If I add ()'s around the #delay (stepTime) and #log (stepTime) commands in the frequency sweep example script it works again.  You probably should update your example scripts for this expression evaluation syntax change.

[HKJ]

Since you changed the script expression evaluation process I find that for #delay and #log commands using a variable I need to put ()'s around it.  For example,

Big Oops. I hope it is fixed now (The script library is downloaded from my website, this means I can update easily).
Anybody that is online when they start TestController will get the updated version.
Note: I have not tested anything, just changed the scripts.