Program that can log from many multimeters.

[HKJ]

V1.48 is up.
This version adds a few GridPanels, a single device and the latest version of the serial library.
   Added: More Grid panels: Dual readout, auto hold readout
   Added: More Grid panels: PS & Load readout, Multi PS & Load readout
   Added: More Grid panels: Shortcut for mode popup and setup popup
   Changed: Updated to latest version of the serial library
   Changed: Waveform names for FY6900 generators (Thanks microplayer)
   Added: RND-320-KA3005P in KORAD supplies (Thanks microplayer)

Dual readout will show two values, either from same device or from two devices:


Auto hold readout is very similar to the separate popup, but slightly simpler:


The PS & Load readout shows five parameters and only needs the device to supply voltage and current. The multi device will som same 5 values, but use a sum/average from the connected devices (That is supposed to be in parallel). When mixing power supplies with loads it will show the difference!



The mode & setup is a shortcut for the device popups:



There will be more GridPanels, but probably not this year. And if somebody has an idea for a GridPanel please say.

[gby]

Happy Almost New Year HKJ,

I found some time to continue working on the low level binary serial interface.  I (think) I found a couple of TC 2.48 issues:
1.  On http://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html in Non-SCPI ascii Devices section the documentation lists
           txrx1Bin? cmd
           txrxnBin? cnt cmd
     Neither command sends anything over the serial port.  But, txrx1? cmd and txrxn? cnt cmd do send over serial port.
     I assume having "Bin" in the name is a typo in the Web page documentation.....or I am very confused?

2.  In testing sending a command and expecting 2 bytes back I get the following from the debug DOS box:

Code: [Select]

txrxn? 2 0x8a 0x00 0x88 0x00
;; S200: Tx <txrxn? 2 0x8a 0x00 0x88 0x00>
;; COM1: Tx: 8A 00 88 00
;; COM1: Rx: FF
;; S200: Rx <255>
;; 255   Using an oscilloscope on serial transmit and receive I can see the 4 transmit bytes and see 0xFF returns after Tx 0x8a and then 0x08 returns after Tx 0x88. 
   I would not expect Rx value to be 255, I was hoping for 0x255*0x80 + 0x08 = 0xFF08.
   For your reference I have included the scope trace of this serial transaction.
   Testing txrxn 2 with other data seems to always set Rx returned value to just the first returned byte.

   I also tried txrxn? with 3 and 4 and got the same result.  Rx value is always just the first byte.
   Since the device only returns 2 bytes I would have thought asking for 3 or 4 bytes would cause a Rx timeout but it doesn't.
   
Lastly, a question.  The 2 byte number coming back is sometimes signed and sometimes unsigned depending on which parameter it is.  I could write :readmath: to convert to proper data type using conditionals but I wonder if there is a conversion command/option built into TC?  What do you suggest?

[HKJ]

I found some time to continue working on the low level binary serial interface.  I (think) I found a couple of TC 2.48 issues:

I will look at this next year, but a few comments:

1) In my tests they work, here I define a command to either require a 1 or 2 byte answer:
#scpiCmd i? txrx1bin? \x45
#scpiCmd i? txrxnbin? 2 \x45
The \x45 is a string override to send the char with hex code 45, in this case I could have written E (The override is mostly for sending control characters). It is possible to do stuff like: E\x0d\x0a any space in the string will be send as a space.
The bin format do not include any automatic CR/LF, it must be specified with string overrides when required.
Both bin and Bin works.

2) I do not understand this, the txrxn? command is supposed to receive multi line text and the argument is text only. With the ascii driver I get:
;; 4187.01ms Test: Tx <txrxn? 2 0x8a 0x00 0x88 0x00>
;; 4188.05ms COM19: Tx: <0x8a 0x00 0x88 0x00.> 30 78 38 61 20 30 78 30 30 20 30 78 38 38 20 30 78 30 30 0A

3) The bin functions is supposed to always return unsigned values with first returned byte as lsb. I will add something to handle both sign and swapping bytes for more general usage, some sort of function is probably the best way (i.e. readmath).

[gby]

HKJ thanks for the hints.  I can now explain most of my issues.

I was using #driver Block in my device file.  With that driver the txrx1Bin? and txrxnBin? commands send nothing over the serial port and the txrx1? and txrxn? commands do send characters over the serial port.  I changed to #driver ascii and now the txrx1Bin? and txrxnBin? commands do send.  Sorry for my confusion.

Unfortunately, using #driver ascii with txrx1Bin? does not always send the correct character.  From 0x00 up to 0x7f and from 0xa0 to 0xff all seems to work.  But any value from 0x80 to 0x9f seems to always incorrectly send value 0x3F or character "?".  See below from the DOS debug window showing selected values working and values 0x8a and 0x90 not working with 0x3F incorrectly sent.

Code: [Select]

txrx1Bin? \x4c
;; S200: Tx <txrx1Bin? \x4c>
;; COM1: TxBin: <L> 4C
;; COM1: RxBin: 34
;; S200: Rx <52>
;; 52
txrx1Bin? \x4c\x00
;; S200: Tx <txrx1Bin? \x4c\x00>
;; COM1: TxBin: <L.> 4C 00
;; COM1: RxBin: 34
;; S200: Rx <52>
;; 52
txrx1Bin? \x8a
;; S200: Tx <txrx1Bin? \x8a>
;; COM1: TxBin: <?> 3F
;; COM1: RxBin: 00
;; S200: Rx <0>
;; 0
txrx1Bin? \x90
;; S200: Tx <txrx1Bin? \x90>
;; COM1: TxBin: <?> 3F
;; COM1: RxBin: 00
;; S200: Rx <0>
;; 0
txrx1Bin? \xa0
;; S200: Tx <txrx1Bin? \xa0>
;; COM1: TxBin: < > A0
;; COM1: RxBin: 88
;; S200: Rx <136>
;; 136
txrx1Bin? \xd8
;; S200: Tx <txrx1Bin? \xd8>
;; COM1: TxBin: <?> D8
;; COM1: RxBin: ED
;; S200: Rx <237>
;; 237
So, how to get TC to correctly send binary values between 0x80 and 0x9f??

On the question for signed versus un-signed and on byte order this device does have signed integers and will receive ms byte first and ls byte second.  So, commands to help with that natively would be convenient.  For now using "readmath" will do.

[Pukker]

Hi everyone,

Can someone hint me the settings for the RD6012?
Tried al sort of settings on Riden en on the Port settings on the PC,
but always ended up with RX-timeout.
Searched a lot in this topic, but didn't find a solution.

Thanks.

[Dwaine]

Man this program is fantastic!!!!   Thanks to everyone helping on the project.

[gby]

So, how to get TC to correctly send binary values between 0x80 and 0x9f with txrx1Bin? ??

Another question.  If a device had a register in counts that needs to be scaled and offset to convert to real units, then for the read #scpiCmd it is a simple matter of :readmath:.  But, if this register is read/write how to do a #scpiCmd for the write that takes the user/real units in and coverts to a single byte in counts before sending? 

An example read could be:
   #scpiCmd Temp txrx1Bin? \x20\x00
   :readmath: (value*22.3 - 0.6)
and the corresponding write could be:
   #scpiCmd Temp txrx1Bin? \x21\x(int(round(value + 0.6)/22.3))

The above does send a single byte but the calculation yields a decimal number and the \x sends it as a Hex number.  For example, using 1114 for the argument value should send decimal 50 or 0x32 Hex.  But, TC sends hex 50.  See below from DOS debug window:

Code: [Select]

temp 1114
;; S200: Tx <temp 1114>
;; S200: Tx <txrx1Bin? \x20\x50>
;; COM1: TxBin: <!P> 20 50
;; COM1: RxBin: 95
;;149
Perhaps adding a byte(value) typecasting function could be a step to help solve both the above issues?

[HKJ]

I was using #driver Block in my device file.  With that driver the txrx1Bin? and txrxnBin? commands send nothing over the serial port and the txrx1? and txrxn? commands do send characters over the serial port.  I changed to #driver ascii and now the txrx1Bin? and txrxnBin? commands do send.  Sorry for my confusion.

The bin suffix are not supported on the block device, because all commands are binary.
For each driver (block/ascii/etc.) the commands are coded separately, the names may be similar, but the parameters and functions may not be.

Unfortunately, using #driver ascii with txrx1Bin? does not always send the correct character.  From 0x00 up to 0x7f and from 0xa0 to 0xff all seems to work.  But any value from 0x80 to 0x9f seems to always incorrectly send value 0x3F or character "?".  See below from the DOS debug window showing selected values working and values 0x8a and 0x90 not working with 0x3F incorrectly sent.
So, how to get TC to correctly send binary values between 0x80 and 0x9f??

Oops, it is fixed in the interim release below.

On the question for signed versus un-signed and on byte order this device does have signed integers and will receive ms byte first and ls byte second.  So, commands to help with that natively would be convenient.  For now using "readmath" will do.

New function:
binConv(value,offset,count{,signed{,swap}})

;I use hex() function to show actual byte swapping
hex(binConv(0x12345678,0,4))  -> 12345678
hex(binConv(0x12345678,0,2))  -> 5678
hex(binConv(0x12345678,1,2))  -> 3456
hex(binConv(0x8012,0,2,1))    -> FFFF8012 this is a negative number
hex(binConv(0x12345678,0,4,0,1)) -> 78563412
hex(binConv(0x12345678,0,4,0,"3120")) -> 12563478
hex(binConv("\x12\x34\x56\x78",0,4))  -> 78563412

Another question.  If a device had a register in counts that needs to be scaled and offset to convert to real units, then for the read #scpiCmd it is a simple matter of :readmath:.  But, if this register is read/write how to do a #scpiCmd for the write that takes the user/real units in and coverts to a single byte in counts before sending? 

The result when using () in a line is a string result, i.e. you must convert the result to hex with the hex() function to use it as a hex argument. From the interim version it is possible to specific digits in the hex function (You need two for the above):
hex(value)
hex(value,digits)

#scpiCmd Temp txrx1Bin? \x21\x(hex(round((value + 0.6)/22.3),2))


Interim release: http://lygte-info.dk/pic/Projects/TestController/TestController.jar

[HKJ]

Can someone hint me the settings for the RD6012?
Tried al sort of settings on Riden en on the Port settings on the PC,
but always ended up with RX-timeout.
Searched a lot in this topic, but didn't find a solution.

As far as I know the only setting is baudrate on the RD6012, it must be 9600.
In TestController you must add the RD6012 to the loaded devices and specify correct serial port.

[HKJ]

Man this program is fantastic!!!!

Thanks.

Thanks to everyone helping on the project.

I hope that more people will make definitions for test equipment this year.

[Pukker]

Can someone hint me the settings for the RD6012?
Tried al sort of settings on Riden en on the Port settings on the PC,
but always ended up with RX-timeout.
Searched a lot in this topic, but didn't find a solution.

As far as I know the only setting is baudrate on the RD6012, it must be 9600.
In TestController you must add the RD6012 to the loaded devices and specify correct serial port.

Thanks HKJ for reply, I tried all the options, but not working for me.
Have to tell that I use the modified software by Unisoft, which is great.
The Ruideng original software works OK with this modified version.
But that software is a little bit ......
Installed latest Oracle Java.
I will try another laptop later.

[Hydron]

I hope that more people will make definitions for test equipment this year.

I've got one outstanding for an electronic load that I promised to write last year, got a bit busy but will do it once I'm back on plague island.

On another topic, it appears from your website that you have both a Keysight 34461A and a Keithley DMM6500 - do you have any comments on which is better for
a) day to day interactive use as a bench meter or
b) use for logging etc (I see the Keithley has a driver, I assume the Keysight would need to be used in 34401A compatibility mode or with a newly  written driver).
Am looking at investing in one of those two and the DMM6500 appears to be somewhat better value.

[HKJ]

Thanks HKJ for reply, I tried all the options, but not working for me.
Have to tell that I use the modified software by Unisoft, which is great.
The Ruideng original software works OK with this modified version.
But that software is a little bit ......
Installed latest Oracle Java.
I will try another laptop later.

Sorry, but I cannot help more. I do not have the power supply, the definition was made by somebody else. If you look back in the thread you will see it.

[HKJ]

I've got one outstanding for an electronic load that I promised to write last year, got a bit busy but will do it once I'm back on plague island.

I look forward to it.

On another topic, it appears from your website that you have both a Keysight 34461A and a Keithley DMM6500 - do you have any comments on which is better for
a) day to day interactive use as a bench meter or
b) use for logging etc (I see the Keithley has a driver, I assume the Keysight would need to be used in 34401A compatibility mode or with a newly  written driver).
Am looking at investing in one of those two and the DMM6500 appears to be somewhat better value.

For interactive use I prefer the DMM6500, for logging I use the 34461A. The 34461A have a better AC to DC converter.
I love the way I can plot data on the DMM6500, it is easy to use and I can use very fast sample rates when needed.

On my workbench I have: 34465A 34470A DMM6500 DMM7510, all within easy reach. I nearly always use DMM6500 for interactive use and the two Keysights when logging, I seldom use DMM7510 due to noise from the fan.

I always uses TC for logging, it can handle both meters directly on a network connection, no drivers required.
In TC the 34461A definition is way superior to DMM6500. I (or somebody else) may improve the DMM6500 definition in the future.

[Hydron]

Thanks, very useful to have that viewpoint from someone with both available for handy bench use.
My primary use would be interactive, and I'm not so worried about the AC ranges so it sounds like the DMM6500 is the way to go, especially as it's a little cheaper. Has certainly escalated from the original plan to get a 34401A though!

If I do go get a DMM6500 I'll see if I can contribute to a better driver. Will also have a look at scanner card option - someone has made an open source clone for the 2000-SCAN card.

[HKJ]

Thanks, very useful to have that viewpoint from someone with both available for handy bench use.
My primary use would be interactive, and I'm not so worried about the AC ranges so it sounds like the DMM6500 is the way to go, especially as it's a little cheaper. Has certainly escalated from the original plan to get a 34401A though!

If I do go get a DMM6500 I'll see if I can contribute to a better driver. Will also have a look at scanner card option - someone has made an open source clone for the 2000-SCAN card.

You may also want to read my reviews:
https://lygte-info.dk/review/DMMKeithley%20DMM6500%20UK.html
https://lygte-info.dk/review/DMMKeysight34461A%20UK.html

They are not based on long time use, only on a short term evaluation. They also contains tear downs if you want to see whats inside the meter.

[Hydron]

Thanks, have already read those - didn't have a comparison of real bench-use between the two though, which your post has provided.

[gby]

Unfortunately, using #driver ascii with txrx1Bin? does not always send the correct character.  From 0x00 up to 0x7f and from 0xa0 to 0xff all seems to work.  But any value from 0x80 to 0x9f seems to always incorrectly send value 0x3F or character "?".  9f??

Oops, it is fixed in the interim release below.

Thank you for the interim release.  \x for values from 0x80 to 0x9Ff works correctly now 

New function:
binConv(value,offset,count{,signed{,swap}})

Thanks for this new function.  In scripts with the examples I tried it works fine.  Much less tedious than shifting, masking, etc.
However, I can't seem to get it to work for serial returned data.  For example, running the below script gives the expected result:

Code: [Select]

=var foo=0xEFFF
=foo=binConv(foo,0,2,1,1)
=foo
;; -17But, the exact same EF FF data from the serial port using the same binConv in the device file scpi command does not work. 
    #scpiCmd IdFB? txrxnBin? 2 \x8E\x00\x8C\x00
    :readmath: binConv(value,0,2,1,1)
From the DOS debug Window:

Code: [Select]

idfb?
;; S200: Tx <idfb?>
;; S200: Tx <txrxnBin? 2 \x8E\x00\x8C\x00>
;; COM1: TxBin: <?.?.> 8E 00 8C 00
;; COM1: RxBin: FF EF
;; S200: Rx <13873>
;; 13873I have no idea how 13873 decimal could come from the received FF EF two hex bytes and just don't see it.  Suggestions on how to get device file :readmath: to get the same results as running a script?  Some sort of conversion function on the value inside the binConv?

Lastly, thanks for the hex(value) capability, suggestion.  Works fine for calculating the values to be transmitted to the device.

[HKJ]

    #scpiCmd IdFB? txrxnBin? 2 \x8E\x00\x8C\x00
    :readmath: binConv(value,0,2,1,1)
I have no idea how 13873 decimal could come from the received FF EF two hex bytes and just don't see it.  Suggestions on how to get device file :readmath: to get the same results as running a script?  Some sort of conversion function on the value inside the binConv?

The problem is missing documentation, the value is a string type and because the function accept a string it will not automatic be converted to a integer.
The solution is adding a typecast:
:readmath: binConv(int(value),0,2,1,1)

Note: Documentation will be released together with the official update at a later date.

[gby]

HKJ,

Thanks for the binConv(int(value),02,1,1) suggestion.  It works fine.

I am trying to make the logging faster.  In the past, with real SCPI devices/a socket connection, using a command that retrieves multiple values in one command speeds up logging.  For example, retrieving all the currents in a multiple channel supply in one command.  I tried doing that with the serial device I am working on and can't get TC to log any values.  I suspect some formatting issue.

The working SCPI device returns three numbers separated by comma and a space.  TC socket connection #askValues handles the three number comma separated reply with no #askValuesReadFormat.  For the ascii serial device I am working on I defined a #scpiCmd that reads three values and using :readmath: converted into a string with three numbers separated by command and a space.  But, logging just gets ";; S200: Rx as numbers <>" and all the logged values are 0.

The device file command I created is:
   #scpiCmd samplePVI? txrxnBin? 7 \x5E\x00\x5C\x00\x5A\x00\x3A\x00\x38\x00\x8A\x00\x88\x00
   :readmath: " "+binConv(int(value),0,3,0,1)/256.0+", "+binConv(int(value),3,2,1,1)*0.5587935448+", "+binConv(int(0xF0FFFFFFFFFFFF&value),5,2,1,1)*18/19336

This command run directly gives three correct numbers comma separated as shown below.

Code: [Select]

samplepvi?
;; S200: Tx <samplepvi?>
;; S200: Tx <txrxnBin? 7 \x5E\x00\x5C\x00\x5A\x00\x3A\x00\x38\x00\x8A\x00\x88\x00>
;; COM1: TxBin: <^.\.Z.:.8.Š.ˆ.> 5E 00 5C 00 5A 00 3A 00 38 00 8A 00 88 00
;; COM1: RxBin: A4 A6 47 00 00 FF 98
;; S200: Rx < 42150.27734375, 0.0, -0.10426148117501034>
;; 42150.27734375, 0.0, -0.10426148117501034But, using #askValues samplePVI? ends up with ";; S200: Rx as number <>" in the DOS debug log.

Is there a way to format the three numbers so that serial ascii #askValues can get the three numbers from the single combined command?

[HKJ]

Is there a way to format the three numbers so that serial ascii #askValues can get the three numbers from the single combined command?

I found a bug in the evaluation sequence (I have been doing some modification to that including adding a bug), a new interim version is up.

Also try without a leading space.

[gby]

Is there a way to format the three numbers so that serial ascii #askValues can get the three numbers from the single combined command?

I found a bug in the evaluation sequence (I have been doing some modification to that including adding a bug), a new interim version is up.

Also try without a leading space.

Thanks for looking at this quickly.  I tried the new interim release and same ;; S200: Rx as numbers <> result.  I then removed the leading space but still no logged numbers.  By the way, on the first interim release without the leading space TC returned 1 number and not a comma separated list for the individual command.  The new interim release fixes that problem and without the leading space it returns three numbers as expected.

For your reference, I am switching between:
    #askValues PosFB?;VelFB?;IFB?
which logs values properly and
    #askvalues samplePVI?
which does not log anything.  Everything else in the device file stays the same.

So, the new interim release still can't seem to parse/understand the comma separated number list but the individual command returns correctly as shown below.

Code: [Select]

samplePVI?
;; S200: Tx <samplePVI?>
;; S200: Tx <txrxnBin? 7 \x5E\x00\x5C\x00\x5A\x00\x3A\x00\x38\x00\x8A\x00\x88\x00>
;; COM1: TxBin: <^.\.Z.:.8.Š.ˆ.> 5E 00 5C 00 5A 00 3A 00 38 00 8A 00 88 00
;; COM1: RxBin: A4 A6 6A 00 08 FF D8
;; S200: Rx <42150.4140625, 4.4703483584, -0.04468349193214729>
;; 42150.4140625, 4.4703483584, -0.04468349193214729
In case it helps I have attached the working copy of the device file.

[HKJ]

Code: [Select]

[quote author=gby link=topic=234726.msg3398954#msg3398954 date=1609697631]
;; S200: Tx <samplePVI?>
;; S200: Tx <txrxnBin? 7 \x5E\x00\x5C\x00\x5A\x00\x3A\x00\x38\x00\x8A\x00\x88\x00>
;; COM1: TxBin: <^.\.Z.:.8.Š.ˆ.> 5E 00 5C 00 5A 00 3A 00 38 00 8A 00 88 00
;; COM1: RxBin: A4 A6 6A 00 08 FF D8
;; S200: Rx <42150.4140625, 4.4703483584, -0.04468349193214729>
;; 42150.4140625, 4.4703483584, -0.04468349193214729[/quote]

I cannot see what goes wrong.
Returning the string directly from a :readmath: I get:

;; 7557.14ms Test: Rx <42150.4140625, 4.4703483584, -0.04468349193214729>
;; 7557.20ms Test: Rx as numbers <42150.4140625 4.4703483584 -0.04468349193214729>

Notice I have the line "Rx as numbers" and it is missing in you dump. It is the next step after making a text line with numbers, it will convert all number into a float format (This may look similar in the log, but it is not).
One reason for it missing can be that the data returns after timeout and is read by the log window instead, but that do match with how the data is processed.

[HKJ]

For test I tried to put the string into a Arduino with your :readmath:, it worked fine:

;; 64951.04ms Test: Tx <txrxnbin? 7 \x8a>
;; 64953.04ms COM19: TxBin: <Š> 8A
;; 64953.07ms COM19: RxBin: A4 A6 6A 00 08 FF D8
;; 64953.24ms Test: Rx <42150.4140625, 4.4703483584, -0.022341745966073644>
;; 64953.27ms Test: Rx as numbers <42150.4140625 4.4703483584 -0.022341745966073644>

I only use one character to trigger the transmission.

[gby]

Based on your not seeing any issue I put the oscilloscope back on the serial transmit and receive lines.  When I do the individual command
    #samplePVI?
the expected result comes back.  With
    $askvalues samplePVI?
in the device file when I start logging I see NO serial activity.  Nothing is ever transmitted.  After trying many things and staring at the files for a while I finally realized what was going on.

The working logging line with 4 individual commands had capital "V" in #askValues and the non-working line using the multiple read command had a lower case "v" in #askvalues.  TC is case sensitive for the #askValues line and even though I had stared and tested, and tested it took a while for me to finally notice it.  You can see the lines in my previous post where I had listed the two lines I was switching between; one with "V" and one with "v".

Sorry you had to dig into testing with an Arduino to catch my incorrect lower case "v".  At least it is resolved and we can both move on.  Someday in the future it might be nice to have an error message when there is no #askValues defined and you try logging or click the Current values tab.