Program that can log from many multimeters.

[HKJ]

From the above I conclude somewhere Test Controller has a 127 character max buffer/limit of some kind.

It may also be something with signed/unsigned handling, I will have to try it out tomorrow.

[HKJ]

V1.70 is up
It fixes some bugs and add new devices.
   Fixed: Some bugs in AsciiBin driver.
   Added: TTi 1908 bench meter. Thanks voltsandjolts
   Added: Rigol DG8xx/DG9xx, thanks bateau020
   Added: Error message for missing address on "Load devices" page when pressing Reconnect.
    Fixed: Riden dropouts with help from Pukker (Thanks)
   Fixed: DL24 dropouts with help from Pukker (Thanks)

gby I hope the AsciiBin driver works now.

I have two times helped people that forgot to fill in a address, I hope the added error messages fixes that for the future.

[gby]

HKJ,

Thanks for the new version.  It has certainly fixed the buffer length issue in the asciiBin driver.  Querying the Yokogawa power analyzer for all 255 data channel samples in one reply gets the reply with no communications error.  Thank you very much for this fix.

From home I was running the connection to the Yokogawa over a VPN connection.  Even with that extra variability/delay I was able to log 16 of the data channels every 600 mSec for just over 2 hours with no communications error forcing a re-start.  Earlier versions logging would always have a comm problem and recovering/getting communications going again required re-starting Test Controller.  In the original file I had #cmdDelay 50 to help with communications problems but with this version I can comment that line out.

So, whatever you did to fix the buffer length seems to have made communications more stable also.  I will keep testing it but so far so good and thanks a lot.

Just out of curiosity on a completely different subject, what sets the sample interval when on the "Current values" tab?

[HKJ]

So, whatever you did to fix the buffer length seems to have made communications more stable also.  I will keep testing it but so far so good and thanks a lot.

I fixed it so the driver did not restart every time bit 7 was one.

Just out of curiosity on a completely different subject, what sets the sample interval when on the "Current values" tab?

It has a fixed maximum rate of (I believe) 5, but will reduce the rate if there is slow devices. When logging it may use the values from that instead.

[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,

I am running into an error when running a script that might have something to do with the above.  The device is using ascii driver over a serial port and since it is a raw interface it uses txrx1Bin? and txrxnBin? communications commands.  But there is no corresponding txrx1Bin without the question mark.  So, for commands setting a value using txrx1Bin? with a ? a value is returned to the driver even though for a set we don't want a value returned.  For example, there is the below scpiCmd definition for device write to the DPoles register:
   #scpiCmd DPoles txrx1Bin? \x07\x(hex(limit(value/2,0,31)*8+3,2))

When I run scripts with the above type of set command in them a value is returned to the console.  Sometimes that extra value incorrectly ends up in a variable.  An example of this undesired value causing a script error is the below short script which comments out writing one value, reads one value from device S200, and prints the read value to the console.
   =var temp = 0
   ;S200:DPoles 0
   =temp = deviceRead("S200", "IuOffset?")
   #delay 1
   =temp

Running the above script the final value of temp on the last line correctly prints out the result of the "IuOffset?" query which should be a fixed value of -455.157.  Below is the console result when running it:
   =var temp = 0
   =temp = deviceRead("S200", "IuOffset?")
   #delay 1
   =temp
   ;; -455.157

Uncommenting out the value set command to a completely un-related device parameter (S200:DPoles 0) right before the read command the result of the final print of temp should not change.
   =var temp = 0
   S200:DPoles 0
   =temp = deviceRead("S200", "IuOffset?")
   #delay 1
   ;;-455.157
   =temp
   ;; 214

However the final value does change which is incorrect behavior.

I wonder if the root cause of this error is using txrx1Bin? for the parameter set?  The txrx1Bin? command does return a value to the driver and it looks like that returned value is messing with the script.

How to emulate the functionality of txrx1Bin with no question mark to have no returned value for a set command?  Using just txrx doesn't send the two hex values needed.  For example txrx \x07\x00 sends those ascii characters and not the two hex values according to the DOS debug window.
   ;; COM1: Tx: <\x07\x00> 5C 78 30 37 5C 78 30 30
Trying txrx1Bin \x07\x00 with no "?" just sends those characters.
   ;; S200: Tx <txrx1Bin \x07\x00>

I did the above with the latest Ver 1.70.  But, a couple of older versions also produce these same errors.

[HKJ]

The device is using ascii driver over a serial port and since it is a raw interface it uses txrx1Bin? and txrxnBin? communications commands.  But there is no corresponding txrx1Bin without the question mark.

I have not studied you post, but I have added txrx1Bin and txrxnBin.
http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[gby]

HKJ,

Wow, that was really fast.  Quick check shows that txrx1Bin with no question mark is there and using it does solve the script problem that was happening.

Thanks again for a great utility and your great support.

We are still working on polishing the Yokogawa power analyzer file and when polished and tested will share with you to include in the next release.

[HKJ]

Wow, that was really fast.  Quick check shows that txrx1Bin with no question mark is there and using it does solve the script problem that was happening.

It was very easy to duplicate the two other commands and strip the answering code.

We are still working on polishing the Yokogawa power analyzer file and when polished and tested will share with you to include in the next release.

With that many channels are you using the possibility to select what data and columns to request and show with check marks? It is a fairly new function and not really used yet.

[duckduck]

I have gotten the files for the Riden RD6006P DC power supply and the East Tester ET5411 high voltage DC electronic load to a 90% working state.

To get the last bit for the RD6006P I think that I need a modbus sniffer / analyzer. Are there freeware or open-source modbus sniffers? I think I'll ask UniSoft to help with the RD6006P since he is writing PC software for this device.

To get the last bit for the ET5411 I think that I need a USB or SCPI sniffer. What are people using for this (Windows or Linux)? Also is there PC software for the ET5411 (so I have something to sniff)?

EDIT:

I didn't know about debug mode. I should probably read the directions ;-)

I found a SCPI reference for the ET54xx's. I'll check that out.

see attached

Here are the files as they are. They mostly work, but some things don't. Thanks to the authors of the RD60xx and ET5410 files as I'm using those as a base to start from.

[HKJ]

I have gotten the files for the Riden RD6006P DC power supply and the East Tester ET5411 high voltage DC electronic load to a 90% working state.

To get the last bit for the RD6006P I think that I need a modbus sniffer / analyzer. Are there freeware or open-source modbus sniffers? I think I'll ask UniSoft to help with the RD6006P since he is writing PC software for this device.

To get the last bit for the ET5411 I think that I need a USB or SCPI sniffer. What are people using for this (Windows or Linux)? Also is there PC software for the ET5411 (so I have something to sniff)?

I suppose that you problems is something you cannot do with debug mode in TestController.

If you have a couple of serial ports (can be USB-serial adapters) you can use Termite to see what is going on using forward selection, it has a hex mode that allows you to see the modbus messages.
For this to work you need to link two serial ports with a cross cable and then use a third port for connection to the device (Can be the virtual port the device creates).

https://www.compuphase.com/software_termite.htm

I suppose you have the communication manual for ET load, but you problems is some missing or badly documented commands.

[Pukker]

@HKJ,

Question about the Current Values tab.
Could it be possible to have minimum, maximum, average values etc.
not only over an selected (30, 100, 300, 1000) number of values,
but over the whole logging session. Interesting when you log for
an long time and want to observe that values over the complete log.

Just an idea what I was looking for.

[HKJ]

@HKJ,

Question about the Current Values tab.
Could it be possible to have minimum, maximum, average values etc.
not only over an selected (30, 100, 300, 1000) number of values,
but over the whole logging session. Interesting when you log for
an long time and want to observe that values over the complete log.

Just an idea what I was looking for.

Try the "Range" page, it does exactly that:



You can fill in the first/last fields to limit the shown range.

Another option is the GridPanel, it can be customized to nearly show or adjust anything:



Here the advanced readout and charting, it can be used with any DMM or other device. This is not related to any logging, but will always work.

If you want to use the same GridPanel frequently, you can save it as a menu:



When specifying the menu name a semicolon can be used to create submenus.

[gby]

HKJ,

Attached is a working Yokogawa WT3000 power analyzer driver file to include in the next release.

Right now we don't have any more thoughts for updating it but as we use it I am sure we will add to it a little.  I will update if that happens.

[HKJ]

Attached is a working Yokogawa WT3000 power analyzer driver file to include in the next release.

I will include it in the next release, thanks.

[PaWill68]

HKJ,
Am I doing something wrong? Why do I have such outliers on my graph?

[HKJ]

Am I doing something wrong? Why do I have such outliers on my graph?

It looks like you have dropouts in communication, you can filter it out with a Math channel using DropOutFilter on maybe 5 to 10 samples.

What device do you have this problem with and what version of TC.

[PaWill68]

kunkin kp184, TCv1.70
Maybe there is an instruction on how to overlay several graphs. I'm doing something wrong.

[HKJ]

kunkin kp184, TCv1.70
Maybe there is an instruction on how to overlay several graphs. I'm doing something wrong.

You load the first and the import the others.

With time sync:


With capacity sync:


To get the imported capacity without dropouts it may be necessary to select this option (I will have to look a bit on that):

[gby]

Hi HKJ,

I am working on a non-SCPI device.  This device is a member of a family and I am trying to use #metadef sections to handle that but I can't seem to get it to work.

As I understand it with no *idn? command you use the #verifyDevice command which I am.  From my understanding of the documentation the #verifyDevice command has to match a fixed value on the command line.  So, how do I write the device file so that the different #idstring value needed to determine which #metadef section to use works?

I see in the web documentation #modifyIDN command.  But I could not find how to use/where to put #modifyIDN command in the device driver file?  I did define a #scpiCmd getDeviceSW? command and that works.  Is there something like #scpiCmd getDeviceModel? that I should define to get #metadef sections to work?

For reference, below is a subsection of the device file showing the #metadef, #verifyDevice, and the start of communication definition details.  The ModelQ? query is #scpiCmd defined later in the file to return the model/idstring of the device.

Code: [Select]

#metadef
#idstring S20330
#replaceText DIpeak 9.0
#replaceText VBusScale 0.25

#metadef
#idstring S20630
#replaceText DIpeak 18.0
#replaceText VBusScale 0.23

#metadef
#replaceText DIpeak 18.0
#replaceText VBusScale 1

#meta

;S200 does not reply to SCPI *IDN.  Need a #verifyDevice command that is the same for S200's.
; S200 Model read only variable replies with a code to identify the model.
#verifyDevice "S20360" ModelQ?

#idString S20660
#name Kollmorgen S200 Servo
#handle S200
#port com

[PaWill68]

Hi HKJ,
On KUNKIN KP184 there is a problem of strong voltage deviation (like a saw) if you receive data with a command to read one register. At the same time, no deviation is observed on the front panel. Such features of circuitry. I contacted the manufacturer and he said that it is recommended to get all the data in one command. Average data will be transmitted. This is how the front panel works.
How can you implement reading with one command?
The returned data should be 5, 6 and 7. These 3 bytes represent the average voltage value, which is the same as the value displayed on the front panel.

[HKJ]

As I understand it with no *idn? command you use the #verifyDevice command which I am.  From my understanding of the documentation the #verifyDevice command has to match a fixed value on the command line.  So, how do I write the device file so that the different #idstring value needed to determine which #metadef section to use works?

I see in the web documentation #modifyIDN command.  But I could not find how to use/where to put #modifyIDN command in the device driver file?  I did define a #scpiCmd getDeviceSW? command and that works.  Is there something like #scpiCmd getDeviceModel? that I should define to get #metadef sections to work?

The SCPIx driver supports the #modifyIDN command, the Asciii driver supports the #verifyDevice command.
TestController cannot automatic select the correct device for anything but SCPI devices, for all other devices you must specify the correct device. The use of #meta & #metadef simply generates more definitions (It is possible to list the generated definition).
To match different devices with #metadef you use the #replaceText to change the match string for each device.

In Ascii devices the #idString is not used with the device, but only matched to itself, i.e. the logic in TC requires a idstring that matches and the driver simply supplies the defined idstring when #verifyDevice matches (It can add version and serial number information to the idstring). For this to work correctly it is best always to define idstrings as: "brand,model," to match the SCPI format.

[HKJ]

Hi HKJ,
On KUNKIN KP184 there is a problem of strong voltage deviation (like a saw) if you receive data with a command to read one register. At the same time, no deviation is observed on the front panel. Such features of circuitry. I contacted the manufacturer and he said that it is recommended to get all the data in one command. Average data will be transmitted. This is how the front panel works.
How can you implement reading with one command?
The returned data should be 5, 6 and 7. These 3 bytes represent the average voltage value, which is the same as the value displayed on the front panel.

Try starting TC in debug mode and type this command:
holdingL? 0x0300

If you get a fairly long hex answer (compared to holdingL? 0x0122) it is working, but I need to add some special code to handle the answer.
And please post the long message if you get it.

[PaWill68]

Code: [Select]

;; Found Kunkin KP184 on USB2.0-Ser! (COM12)
holdingL? 0x0300
;; 1
holdingL? 0x0122
;; 12039

The hexadecimal code of the command to read all basic registers is: 01 03 03 00 00 20 44 56

[PaWill68]

CoolTerm

[HKJ]

Code: [Select]

;; Found Kunkin KP184 on USB2.0-Ser! (COM12)
holdingL? 0x0300
;; 1
holdingL? 0x0122
;; 12039

The hexadecimal code of the command to read all basic registers is: 01 03 03 00 00 20 44 56

I want to see if TC generated that command correctly and receives the full answer, this requires running TC in debug mode. If that is the case it is easy to add code for decoding the message.