Program that can log from many multimeters.

[TheDefpom]

OK, I am obviously doing this wrong LOL, like I said I am still trying to learn how to do this myself.

[C.J.S.]

FYI, I made few EDITs to my previous post. The decimal point issue was there before I think. I am now really off to bed!

[TheDefpom]

OK try this version, it probably won't work but its worth a shot LOL.

I have a couple of "fallback" values, Primary and 2nd, if those show up then it isn't working properly.

[HKJ]

OK try this version, it probably won't work but its worth a shot LOL.

I have a couple of "fallback" values, Primary and 2nd, if those show up then it isn't working properly.

I did a few modifications to you try that will improve the possibility it works.
I have not tried doing any simulation with a Arduino, i.e. I can just hope it works.

[C.J.S.]

I tried the last device file posted by HKJ. It is definitely an improvement, since now the correct mode names (Capacitance and ESR) and units (F and Ohm) are shown, and also the readout values are correct ( 214n  and around 110m ). Only the readout values for Capacitance and ESR are now fast blinking. To illustrate this I made a short recording of the TestController window. The recording can be found in attached zip file. This fast blinking was actually introduced in the last version posted by Scott. The versions before that one did not show this fast blinking behavior.

[HKJ]

Only the readout values for Capacitance and ESR are now fast blinking. To illustrate this I made a short recording of the TestController window. The recording can be found in attached zip file. This fast blinking was actually introduced in the last version posted by Scott. The versions before that one did not show this fast blinking behavior.

Can you do a debug mode and post some logging from it.

[C.J.S.]

Hi HKJ and Scott,
I talked about "fast blinking" of the readout values, but a better description would be "fast switching of measurement values on the "Current values" tab between the actual measured value and zero". Anyway, for the moment I will still call this issue "fast blinking".

I figured out that this fast blinking was introduced after Scott modified and uncommented the line that starts with #modeFromValue.

After I figured this out I took the last device file that you posted, and commented out line #173:
;#modeFromValue getElement(value,2)+";"+getElement(value,3);

After this modification the fast blinking was gone, and the presentation of the measurement values on the Current values tab looks OK.
Btw, I noticed that you modified this line in the file that you posted, but the function of this line is not clear to. As said, commenting out this line fixes the fast blinking issue, but other than that I did not notice any change in the way that the measurement values are presented. FYI, also commenting out line #172 that starts with #askModeMathFormat does not seem to have any effect, but since this line does not influence the blinking issue I left this line untouched.

I have attached the updated config file that works OK for me. Detailed description of changes that I made
1) Commented out line #173 that starts with #modeFromValue to avoid the fast blinking
2) Fixed a typo in comment line #209 (:FUNC:IMP:C changed to :FUNC:IMP:B)
3) Updated handle names "4090x" to "RS4090x" (with handle 4090C my meter was called "90C" which I don't like)
4) Commented out lines 146 and 147 (#value Primary and #value 2nd) to get rid of the two superfluous rows in the "Current Values" tab

Again thank you Scott and HKJ for your time, and let me know if you have remarks.

Attachments: Updated config file and screenshot of Current values tab with grid panel popup.

[HKJ]

I talked about "fast blinking" of the readout values, but a better description would be "fast switching of measurement values on the "Current values" tab between the actual measured value and zero". Anyway, for the moment I will still call this issue "fast blinking".

I figured out that this fast blinking was introduced after Scott modified and uncommented the line that starts with #modeFromValue.

After I figured this out I took the last device file that you posted, and commented out line #173:
;#modeFromValue getElement(value,2)+";"+getElement(value,3);

This line is important when you are in auto mode. TC will not issue a mode check automatically, but this line is used to extract mode information from the #askValues command. This is also the reason for the flashing, the string returned by #modeFromValue and #askMode must match or you get flashing.

After this modification the fast blinking was gone, and the presentation of the measurement values on the Current values tab looks OK.
Btw, I noticed that you modified this line in the file that you posted, but the function of this line is not clear to. As said, commenting out this line fixes the fast blinking issue, but other than that I did not notice any change in the way that the measurement values are presented. FYI, also commenting out line #172 that starts with #askModeMathFormat does not seem to have any effect, but since this line does not influence the blinking issue I left this line untouched.

#askModeMathFormat is used to modify the answer from #askMode, sometimes it is needed, sometimes not. Here you only have the two mode values and nothing else and TC can figure it out without the use of #askModeMathFormat


And try using the "Device (tracking readout, Dual device readout"

[C.J.S.]

This line is important when you are in auto mode. TC will not issue a mode check automatically, but this line is used to extract mode information from the #askValues command. This is also the reason for the flashing, the string returned by #modeFromValue and #askMode must match or you get flashing.

OK, I am trying to understand this, but need some help. We have now the following 3 lines in the config file:

Code: [Select]

#askMode :FUNC:IMP:A?; :FUNC:IMP:B?
#askModeMathFormat getElement(value,0)+";"+getElement(value,1);
;#modeFromValue getElement(value,2)+";"+getElement(value,3);

The 3rd line was commented out by me to avoid the flashing. You say the string returned by #modeFromValue and #askMode must match or you get flashing.
Is there a way to see the strings returned by system commands #modeFromValue and #askMode ?

I have looked at help page https://lygte-info.dk/project/TestControllerCommands%20UK.html, but could not find the answer. So far, for every command starting with # that I enter on the command line of the selected device, I get an "Invalid command" error message in the "Log and program editor window". Also it is stated that "The help window will show help for the command line, it has help for all commands that starts with # and for most non-SCPI devices". How do I for example get help for commands #askMode and #modeFromValue ?

And try using the "Device (tracking readout, Dual device readout"

Sorry, I don't understand. How do I do this?

[HKJ]

The 3rd line was commented out by me to avoid the flashing. You say the string returned by #modeFromValue and #askMode must match or you get flashing.
Is there a way to see the strings returned by system commands #modeFromValue and #askMode ?

I have looked at help page https://lygte-info.dk/project/TestControllerCommands%20UK.html, but could not find the answer. So far, for every command starting with # that I enter on the command line of the selected device, I get an "Invalid command" error message in the "Log and program editor window". Also it is stated that "The help window will show help for the command line, it has help for all commands that starts with # and for most non-SCPI devices". How do I for example get help for commands #askMode and #modeFromValue ?

Debug do not display the #modeFromValue string, but it shows the #askMode string (I may add the other later on). You can see the currently used modes by using the command line: =deviceMode("RS4090C"), but when the readouts are flashing it may be a bit difficult to see both.

The # lines in the definitions are not commands as such, they cannot be used from the command line and do not have entries in the help file.
You can find documentation here: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html
And here: https://lygte-info.dk/project/TestControllerConfigDevice2%20UK.html

And try using the "Device (tracking readout, Dual device readout"

Sorry, I don't understand. How do I do this?

When you right click in the "Grid panel" window you can select a dual device readout. It is present in the two first menu entries, the first one is for a specific channels, the second one "Device (tracking) readout" will change if the device changes it channels names.

[TheDefpom]

I have updated the file a little from the last one supplied by CJS.

I did a quick search and found that there are other models in the range (basically the same as the ET versions), so I have added those to the definition, and tidied up a few bits here and there.

So base any further changes on this one.

I have also renamed the file to reflect the official model numbers.

[HKJ]

I have updated the file a little from the last one supplied by CJS.

I did a quick search and found that there are other models in the range (basically the same as the ET versions), so I have added those to the definition, and tidied up a few bits here and there.

Good, now it just needs to get the #modeFromValue working, i.e. support of AUTO mode. I wonder what exactly goes wrong, one possible fix is to swap the parameters to #askValues, i.e. place mode first (This will work if the problem is due to something in the :FETC? command). This would also require adjustment in the #askValuesReadFormat and #modeFromValue commands. I hope CJS will work a bit on it when he have time.

[TheDefpom]

I think it is complicated a bit by the meter not responding with the active modes when it sends the readings with the FETC?, unlike the ET4xxx version.

It can only get the modes from :FUNC:IMP:A?; and :FUNC:IMP:B? and if it is like the ET series it may not respond to a string of commands like that, it may need seperate commands to be sent after it has responded to each.

[HKJ]

I think it is complicated a bit by the meter not responding with the active modes when it sends the readings with the FETC?, unlike the ET4xxx version.

It can only get the modes from :FUNC:IMP:A?; and :FUNC:IMP:B? and if it is like the ET series it may not respond to a string of commands like that, it may need seperate commands to be sent after it has responded to each.

You can easily list many commands on the  #askValues line and get whatever you wish. It do not matter if the meter can handle a line with multiple commands, TC will split them into single commands (This can be seen in log mode).

[Cavhat]

I've made significant progress with my little scripting project involving Test Controller, but I've run into a problem.  I intermittently receive the following error:

Code: [Select]

java.lang.NullPointerException
        at dk.hkj.main.InterfaceThreads$LoggingSample.run(InterfaceThreads.java:1192)

The effect of this error is that Test Controller fails to start logging data in the Table page (the "Log" button does not turn red and the Table page remains empty), and my script--which is supposed to loop until a certain number of entries are logged into the Table--endlessly loops.

This error doesn't happen every time I run my script, but it does appear to happen in the same location in my script, shortly after I enable logging with the #log 1 command.  It also seems to happen more often when I have more than one instrument enabled in Test Controller.  Closing and restarting Test Controller also doesn't seem to reliably resolve the error.

My script is complex, large, and spread across multiple files (I'm basically using scripts as subroutines), but aside from this issue it works well, thanks to Test Controller!  However, this error seems to be intermittent and, because of that, I'm not sure how best to troubleshoot.  Does this post give you enough information to chase down the error?

[HKJ]

I've made significant progress with my little scripting project involving Test Controller, but I've run into a problem.  I intermittently receive the following error:

Do you #RECONNECT devices in your script? If you do remember to use a #WAITREADY

The error happens when TC tries to put data into the table, the below test version will ignore the problem:
lygte-info.dk/pic/Projects/TestController/TestController.jar

TheDefpom talks a bit about TestController in his latest video:

 
The link is to the point in the video where he start talking about TestController.

The start is about the device definitions, later on he shows some remote readout and control for a couple of devices.

[HKJ]

V1.91 is up
This is mostly a bug fix.
   Fixed: Some bugs in the latest definitions that could affect TC V1.89.
   Added: GridPanel, DevicePopups support the device mode right click menu when possible.

Due to some problems in the latest definitions, TC could fail when parsing the definitions (This is not always done during program start, but often later).
If have fixed the definitions (But not tested them), including the Ruoshui that is not included in the release yet.

In the future this kind of bug will only affect the definition, not TC.

[C.J.S.]

You can easily list many commands on the  #askValues line and get whatever you wish. It do not matter if the meter can handle a line with multiple commands, TC will split them into single commands (This can be seen in log mode).

@Defpom, this is an illustration of what HKJ says. When I enter the following SCPI command on the VC4090C commandline:

Code: [Select]

FETC?;:FUNC:IMP:A?;:FUNC:IMP:B?

, I get following response in the Commands & Log window:

Code: [Select]

FETC?
;; 2.14313e-07,0.133632
:FUNC:IMP:A?
;; C
:FUNC:IMP:B?
;; ESR

Good, now it just needs to get the #modeFromValue working, i.e. support of AUTO mode. I wonder what exactly goes wrong, one possible fix is to swap the parameters to #askValues, i.e. place mode first (This will work if the problem is due to something in the :FETC? command). This would also require adjustment in the #askValuesReadFormat and #modeFromValue commands. I hope CJS will work a bit on it when he have time.

The problem that I see with AUTO mode is that the response of the VC4090C LCR meter on SCPI command :FUNC:IMP:A? is AUTO. So from this response it is not clear if the LCR meter has detected an inductor, capacitor or a resistor. Also in AUTO mode, the response on :FUNC:IMP:B? is the last secundary mode that was active before entering AUTO mode, and not the secondary mode that is active in AUTO mode.

Example:
When I first set C as primary mode and ESR as secondary mode, the response on

Code: [Select]

:FUNC:IMP:A?; :FUNC:IMP:B?

is

Code: [Select]

:FUNC:IMP:A?
;; C
:FUNC:IMP:B?
;; ESR

When I then switch the meter to AUTO mode, the following parameters are shown on the display of the LCR meter:
Cs: 214.31 nF
D:  0.0001
So the meter is measuring capacitance and dissipation factor (in AUTO mode, the secondary mode cannot be changed)

The response on 

Code: [Select]

FETC?;:FUNC:IMP:A?;:FUNC:IMP:B?

is:

Code: [Select]

;; 2.1432e-07,0.00012804
:FUNC:IMP:A?
;; AUTO
:FUNC:IMP:B?
;; ESR

So the measurement values that are returned are for C and D (dissipation factor), but the modes that are returned are AUTO and ESR.

Maybe other SCPI commands must be used to get the actual primary and secondary operating modes in AUTO mode. But in the SCPI command document that I posted earlier in this thread, I cannot find which other SCPI commands to use.

For me the AUTO mode is not really important. When I do automated measurements for characterization of a specific component, I know if the component is an L, C or R. And a limitation of the AUTO mode is that the secondary mode is not freely selectable. In AUTO mode, the secondary mode for an inductor is Q, for a capacitor it is D (dissipation factor), and for a resistor it is X (reactance). Other choices for the secondary mode are not possible.

Maybe we should just forget about the AUTO mode? We could remove AUTO mode from the Mode and Setup popups, and mention under Notes that AUTO mode is not supported.
Let me know what you think.

[C.J.S.]

Just for information, a PC application exists for remote control of the East Tester / Ruoshui / Victor LCR meters. This PC application can be downloaded from the Youtube channel of Tony Albus. It is attached to Video #083.

The picture attached below shows a screenshot of the PC application, with a 220nF capacitor connected to the LCR meter, and the meter set to AUTO mode. As can be seen on the screenshot the PC application shows values for Cs and D (dissipation factor). This suggests that SCPI commands exist to query which are the primary and secondary parameters when the meter is set to AUTO mode. As said in my previous post, I don't know which SCPI commands should be used for this.

Maybe software exists for monitoring of SCPI traffic between PC application and instrument? If we could monitor the SCPI traffic, we could probably find the SCPI commands for querying primary and secondary operating modes when the meter is in AUTO mode. As said in my previous post, for me this AUTO mode is not really important. But if other people want to use AUTO mode, we could try to find the relevant SCPI commands.

[HKJ]

It is easy enough to add a AUTO column, but it cannot show what mode is selected.

In the attached file I have done that and also swapped the command sequence in the #askValues command.

I usually use https://www.compuphase.com/software_termite.htm to monitor serial communication, but it requires 3 serial ports, two cross connected.

[Cavhat]

I've made significant progress with my little scripting project involving Test Controller, but I've run into a problem.  I intermittently receive the following error:

Do you #RECONNECT devices in your script? If you do remember to use a #WAITREADY

The error happens when TC tries to put data into the table

I finally got some free time to take another look at this.  I don't use the #RECONNECT command; instead, I connect to only those devices that I plan to run the script against prior to launching the script.  The script I'm currently developing runs generalized performance verification tests, using subroutines to define and administer tests for the various equipment I own.  Right now I'm testing it against my two SDM3055s and my SDG2122X.  At some point I'd like to get my SDS1202X-E and my GW Instek GPP-4323 involved.

The good news is that with TestController v.1.91 my script runs consistently and successfully--many thanks for the bugfix!

The bad news is that I can't run it against all three aforementioned instruments at the same time without Test Controller complaining about slow logging and ultimately throwing exceptions while becoming unresponsive.  For example, I can successfully use my script to verify the frequency accuracy of one SDM3055 using one channel of the SDG2122X, and I can separately do the same for the other SDM3055 using, e.g., the other channel of the SDG2122X, but I can't run it against both SDM3055s using both channels of the SDG2122X at the same time.  I attempted that, and here is an excerpt of the resulting death throes before I had to force-quite Java/TestController using Windows Task Manager:

Code: [Select]

************************* Logging slow *****************************
;; SDM3055_1: Rx <+5.00001406E+05   HZ
>
;; SDM3055_1: *OPC waited: 720ms
************************* Logging slow *****************************
;; SDM3055_1: Rx as numbers <500001.406>
;; SDM3055_1: Tx <DATA:LAST?>
;; SDM3055_2: Tx <DATA:LAST?>
;; SDG2122X: Tx <C1:BSWV?>
************************* Logging slow *****************************
************************* Logging slow *****************************
************************* Logging slow *****************************
;; SDM3055_1: Rx <+5.00001328E+05   HZ
>
************************* Logging slow *****************************
;; SDG2122X: Rx <C1:BSWV WVTP,SINE,FRQ,500000HZ,PERI,2e-06S,AMP,0.169731V,AMPVRMS,0.06Vrms,MAX_OUTPUT_AMP,20V,OFST,0V,HLEV,0.0848656V,LLEV,-0.0848656V,PHSE,0
>
;; SDM3055_2: Rx <+0.00000000E+00   HZ
>
************************* Logging slow *****************************
************************* Logging slow *****************************
;; SDG2122X: Tx <C2:BSWV?>
************************* Logging slow *****************************
;; SDM3055_1: *OPC waited: 1304ms
;; SDM3055_2: *OPC waited: 1289ms
************************* Logging slow *****************************
;; SDG2122X: Rx <C2:BSWV WVTP,SINE,FRQ,20HZ,PERI,0.05S,AMP,0.8487V,AMPVRMS,0.300015Vrms,MAX_OUTPUT_AMP,20V,OFST,0V,HLEV,0.42435V,LLEV,-0.42435V,PHSE,0
>
;; SDM3055_1: Rx as numbers <500001.328>
************************* Logging slow *****************************
************************* Logging slow *****************************
************************* Logging slow *****************************
;; SDM3055_2: Rx as numbers <0.0>
;; SDG2122X: Rx after internal processor <500000 0.169731 0 0 20 0.8487 0 0 >
************************* Logging slow *****************************
************************* Logging slow *****************************
;; SDG2122X: Rx as numbers <500000.0 0.169731 0.0 0.0 20.0 0.8487 0.0 0.0>
************************* Logging slow *****************************
Exception in thread "AWT-EventQueue-0" Exception in thread "AWT-EventQueue-0"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "AWT-EventQueue-0"
Exception in thread "LoggerSample" ;; SDM3055_2: Tx <:SENSE:FUNCTION?>java.lang.OutOfMemoryError: Java heap space

;; SDM3055_2: Rx <"FREQ"
>
************************* Logging slow *****************************
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Input to log mover"

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "TimerQueue"
Exception in thread "Device: SDM3055" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Device: SDM3055" Exception in thread "Device: SDG2122X" java.lang.OutOfMemoryError: Java heap space
Exception in thread "BackgroundCommands" java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

I've got plenty of RAM; all other open applications are crisp and responsive while Test Controller ignores its UI as it rolls over and dies.  I'm using many parameterized subscripts as a sort of "poor man's" subroutines and have defined variables in my top-level script as a return-value mechanism for those subroutine that need to modify variables that are used elsewhere.  (I've architected the script in this manner based on my totally untested theory and bald assumption that script parameters are passed by value and not by reference.)

Given Test Controller's debug excerpt and my descriptions of the script--and assuming that I'm probably doing something wrong on my end--do you have have suggestions for how to proceed with troubleshooting?

[HKJ]

Code: [Select]

Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

...

Given Test Controller's debug excerpt and my descriptions of the script--and assuming that I'm probably doing something wrong on my end--do you have have suggestions for how to proceed with troubleshooting?

The "Out of memory error" is probably the reason for it running slow. My best guess is that you call some scripts recursively.
Try using #runscript without parameters, this is possible as long as you run your main script in background (#RUNSCRIPTASYNC).


"Logging slow" is related to log output, not logging data.

[Cavhat]

The "Out of memory error" is probably the reason for it running slow. My best guess is that you call some scripts recursively.
Try using #runscript without parameters, this is possible as long as you run your main script in background (#RUNSCRIPTASYNC).

None of my scripts are called recursively, but your suggestion did give me the idea to investigate potential variable scoping issues.  Sure enough, a couple of my "child" scripts implicitly used a parent script's iterator variable instead of defining their own locally scoped iterator variable.  It looks something like this:

Code: [Select]

#scriptScript MyParentScript

=var i = 0;
; iterate through an array using i...
#runScript MyChildScript1
; do some other things...
#runScript MyChildScript2
#return

;-------------------------------------------------------------
#scriptScript MyChildScript1
=i = 0;
; iterate through some other array using i...

; note that I failed to actually declare "i" here using "=var i = 0;" and TC doesn't complain about it,
; so MyChildScript must be using the "i" declared in MyParentScript above and, consequently,
; this script merely redefines "i" here.
#return

;-------------------------------------------------------------
#scriptScript MyChildScript2
=i = 0;
; iterate through yet another array using i...

; note the same issue with variable scoping as in MyChildScript1
#return

Once I corrected my variable scoping mistakes in a couple scripts, everything suddenly behaves properly and the whole script runs flawlessly.  Cheers!

[HKJ]

Once I corrected my variable scoping mistakes in a couple scripts, everything suddenly behaves properly and the whole script runs flawlessly.  Cheers!

Yes, scripting understands inherited variables.

You can check variables with: =getVarList(0) or =getVarList(1)
0=global, 1=local, it will not list inherited variables.

[C.J.S.]

It is easy enough to add a AUTO column, but it cannot show what mode is selected.
In the attached file I have done that and also swapped the command sequence in the #askValues command.

I have tested the updated definition file Ruoshui VC409xx.txt that you posted. Measurement values returned in AUTO mode are now indeed displayed under "Current values".
But unfortunately with the following line active:
#modeFromValue getElement(value,0)+";"+getElement(value,1);
, the measurement values on the "Current values" tab are flashing again, as shown in the video that I posted on October 22nd. So I have commented out this line again.

Furthermore I made following improvement to the Ruoshui VC409xx.txt definition file:
* fixes to #value section for proper display of returned values in ECAP and Z mode
* renamed Dissipation to Dissipation_Factor, and changed unit from % to none
   (rationale: the value that the LCR meter returns for D is 1/Q; this is not a percentage)
* fixed a few typos

The updated definition file is attached below.