Program that can log/control many multimeters and other devices.

[flash2b]

We have lift off !!



There are some problems.....

I recon the tab "Current Values"  will poll the meter to quick. Logging with 1 sec delay resulted into the log in the screenshot. Is there a way to control the speed of Current Values ?

I have now

Code: [Select]

; ----- Read measurement ------
#askValues FUNC?;FETCH:MAIN?
#askValuesReadFormat xff
#askModeMathFormat getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
#modeFromValue getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")+return0(printLog(getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")));
; ----- Read mode -----
#askMode FUNC?;FETCH:MAIN?
In your documentation your write: "It is strongly recommended to use same parameters to #askMode & #askValues, also #askModeMathFormat & #modeFromValue must use the same parameters." but this is not TRUE, since #askMode & #askValues have the same and #askModeMathFormat & #modeFromValue have the same but they are not all the same.

Regarding #cmdMode, my meter cannot set Cp independently, it must be done with Cs or D, like a set. How do I combine it into one #cmdMode ?

BTW thank you for helping me so quick...

[HKJ]

I recon the tab "Current Values"  will poll the meter to quick. Logging with 1 sec delay resulted into the log in the screenshot. Is there a way to control the speed of Current Values ?

Yes, different readout have different poll speed, you can slow it down by adding ;[400] or something like that to the #askValue command.
The fastest poll is from the "Adjust scale" popup, I believe it tries for 10 polls/second.

I have now

Code: [Select]

; ----- Read measurement ------
#askValues FUNC?;FETCH:MAIN?
#askValuesReadFormat xff
#askModeMathFormat getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
#modeFromValue getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")+return0(printLog(getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")));
; ----- Read mode -----
#askMode FUNC?;FETCH:MAIN?
In your documentation your write: "It is strongly recommended to use same parameters to #askMode & #askValues, also #askModeMathFormat & #modeFromValue must use the same parameters." but this is not TRUE, since #askMode & #askValues have the same and #askModeMathFormat & #modeFromValue have the same but they are not all the same.

The important part is that the two functions return the same string, maybe I could write the documentation a better way.

Regarding #cmdMode, my metet cannot set Cp independently, it must be done with Cs or D, like a set. How do I combine it into one #cmdMode ?

You can set anything with #cmdMode, but it can only and react to one mode. TC will do a read-back and verify that you got the mode or select whatever mode the device is in. I.e. I do not believe you will get any real problems with setting two modes with a command only defined to handle one mode.

[flash2b]

Well for today I am some essential steps further.

The reading speed is is linked to the aperture speed of the LCR meter and the number of averaging times it will perform. It is listed as 40 rdgn/sec on FAST, I am currently testing it on SLOW, then it is supposed to be 3 rdgn/sec. I do not know what the reading speed through the SCPI interface is, but most likely somewhat slower. COM speed is 115200 baud.

I believe the ;[400] delay is not dynamically possible if I remember correctly, so I cannot do a delay based on a value or a var. Is there a way to delay based on a value ?

I will give it a try with #cmdMode, a LCR meter is just much more complex than a DMM where I have all my experience with.

I will also add all other branded meter models to my definition so it will support also the Anbai and Applent models at the end. I hope to release some version this year, but it is doubtful if all of the capabilities of the LCR meter are supported then.

[HKJ]

I believe the ;[400] delay  is not dynamically possible if I remember, so I cannot do a delay based on a value or a var. Is there a way to delay based on a value ?

I have not tried it, but something like this may work:

#scpiCmd MyDelay #pgm#
sleep(sleepTime)


You must be sure sleepTime is define before MyDelay is used, it is defined with :setVar:

You generally have to defined any command that uses variable as #scpiCmd
A #scpiCmd can have the same name as a regular SCPI command, then it will take precedes and must send the command, it addition it can do other stuff like manipulating variables.

[HKJ]

Generally devices works in either of these mode when returning measurements:
1) Always return answer fast and it is the last valid measurement.
2) Start a new measurement and send the result when it is done, this usually has a significant delay, but TC handles it automatic, because it waits for the answer.

In addition there can be a limit on how fast the device can accept commands (Usually old devices), in some TC drivers you can set a fixed delay between commands to get around this, the other option is the [200] specification.
Sometimes there are commands that needs a long processing time, but do not include any answers when done, these may requires the use of [200] specification.

[Gertjan]

The reading speed is is linked to the aperture speed of the LCR meter and the number of averaging times it will perform. It is listed as 40 rdgn/sec on FAST, I am currently testing it on SLOW, then it is supposed to be 3 rdgn/sec. I do not know what the reading speed through the SCPI interface is, but most likely somewhat slower. COM speed is 115200 baud.

I believe the ;[400] delay is not dynamically possible if I remember correctly, so I cannot do a delay based on a value or a var. Is there a way to delay based on a value ?

Maybe [*OPC] is a solution. This is a dynamic delay that waits until the previous SCPI command is done.
The meter must support the *OPC and *ESR?  SCPI commands for this to work.

This (and more) from the TC documentation:

Timing issues

There are a couple of ways to handle timing issues, each has advantages and disadvantages.

Use a [*OPC] tag (Not all devices support this) after the SCPI command will delay until that command is done, this can be a good solution when doing different types of mode changes, but may block the communication if used after a trigger command. The [*OPC] tag will not wait more than 10 second. This function uses the *OPC SCPI command followed by some *ESR? commands, when logging only the actual delay will be shown.

Use a [delay] tag after a SCPI command, the maximum delay is [9999]. This will give the device a fixed time to process the command, before more communication is attempted. This is a last resort solution, it is better to use [*OPC].

Example:
Code:

:OUTP:STAT ON;[*OPC]
:OUTP:STAT ON;[500]


Another way to handle a slow device is to increase the timeout. The default timeout is 1 second, this may not always be enough, there are two settings for this:

#readingDelay is used to allow more time for reading values from the device
#modeChangeDelay give the device time to change mode, a value of 10 (seconds) will usual be fine.

regards, Gertjan.

[flash2b]

Your suggestion is good, and when I was programming some controls and wanted to avoid :updatedelayed: 0.3 statements in the Setup menu, I found out that my Owon LCR2020 does not support Operation Complete (OPC) and Event Status Request (ESR) functions.

If I need it, I will calculate based on Aperture and Averaging Times with some formula/program and do a :setvar: to a calculated delay. Then I will create a scpiCmd that will wait based on the calculated delay. I can then call this scpiCmd if needed.

#readingDelay is something I want to avoid at all cost since it will slow down all command reads, so generally making the menu's slow. The Owon LCR2020 is very fast, however TestController can be even faster .

[Gertjan]

Hi flash2b,

A pity your Owon LCR2020 does not support OPC and*ESR?... 
[*OPC] is a much better solution then a fixed delay with [delay], as it only adds as much delay as is needed.  I have used it several times.

Regarding #readingDelay
Maybe the documentation is a bit confusing. The way I read it, this is NOT a delay. It is increasing the timeout after a request.
In other words, after sending a read?, TC will wait longer, as specified with #readingDelay, for an answer before it gives an time-out error.

Same with #modeChangeDelay for Mode changes.

regards, Gertjan.

[flash2b]

And here is where we do it for. Sometimes while coding a definition I forget that the end-goal is logging with TestController and not coding for TestController 



Above you can see the measurement of Cs and Rs on a Wima MKS-4 capacitor. You can see that when I just connected it is was slightly warmer, since temperature influences the characteristics of the DUT.

Unfortunately I have not found LCR meters that also support temperature measurements while doing LCR measurements. So I need to use a TC-controlled temperature meter in conjunction to my measurement. (I have such a device !!  ).

I am in the process of adding the two Monitor mode measurements to the definition, so that I can additionally log D and Q (or any available) parameters at the same time. The maximum measurement parameters at the same time, is 4 for the Owon 2000 series.

[flash2b]

As I reflected back on what I learned from selecting the correct #askMode, I wondered myself.

It seemed over-complexifying to add the mode + values on one line, and then parsing them with #modeFromValue and #askModeMathFormat and #askValuesReadFormat. I have seen DMM that do not offer commands to retrieve "mode" and then you are stuck using it, but my LCR meter does provide "mode" as a command.

So at the beginning there this was the result:

Code: [Select]

; ----- Read measurement ------
#askValues FUNC?;FETCH:MAIN?
#askValuesReadFormat xff
#askModeMathFormat getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
#modeFromValue getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
; ----- Read mode -----
#askMode FUNC?;FETCH:MAIN
But I simplified it dramatically to this:

Code: [Select]

#scpiCmd ASKMAIN? FUNC?
:readmath: replace(value,"-"," ")
; ----- Read measurement ------
#askValues FETCH:MAIN?
; ----- Read mode -----
#askMode ASKMAIN?
No more #modeFromValue, #askModeMathFormat and #askValuesReadFormat and ultimately faster since the meter only sends the "values"  during #askValues.

I never understood from the documentation that #askMode needs a <space>-separated list of modes and that #askValues needs a comma-separated list of values, but now I do.

Just wanted to share this insight with you all.

PS.
Is there a way to avoid the ASKMAIN? so that the string replace that is needed is on the same line a #askMode ?

[HKJ]

As I reflected back on what I learned from selecting the correct #askMode, I wondered myself.

It seemed over-complexifying to add the mode + values on one line, and then parsing them with #modeFromValue and #askModeMathFormat and #askValuesReadFormat. I have seen DMM that do not offer commands to retrieve "mode" and then you are stuck using it, but my LCR meter does provide "mode" as a command.

It was mostly designed for DMM's that provide unit on the value line, but because I have not implemented a #askMode that runs at the same time as #askValue, it must be used in your case.

So at the beginning there this was the result:

Code: [Select]

; ----- Read measurement ------
#askValues FUNC?;FETCH:MAIN?
#askValuesReadFormat xff
#askModeMathFormat getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
#modeFromValue getElement(value,0,"[- ]")+" "+getElement(value,1,"[- ]")
; ----- Read mode -----
#askMode FUNC?;FETCH:MAIN
But I simplified it dramatically to this:

Code: [Select]

#scpiCmd ASKMAIN? FUNC?
:readmath: replace(value,"-"," ")
; ----- Read measurement ------
#askValues FETCH:MAIN?
; ----- Read mode -----
#askMode ASKMAIN?
No more #modeFromValue, #askModeMathFormat and #askValuesReadFormat and ultimately faster since the meter only sends the "values"  during #askValues.

:readmath: replace(value,"-"," ")
That works fine  for modes, but can be problematic for numbers.

I never understood from the documentation that #askMode needs a <space>-separated list of modes and that #askValues needs a comma-separated list of values, but now I do.

Just wanted to share this insight with you all.

I believe both works on both space and comma, but I have not checked the code, but most of the time #askValues is space separated

PS.
Is there a way to avoid the ASKMAIN? so that the string replace that is needed is on the same line a #askMode ?

#askModeMathFormat is :readmath: for #askMode.

[flash2b]

Thank you !

It is now even more simpler:

Code: [Select]

; ----- Read measurement ------
#askValues FETCH:MAIN?
; ----- Read mode -----
#askMode FUNC?
#askModeMathFormat replace(value,"-"," ")

[flash2b]

Below some random  logging with TestController and my latest definition that supports all 4 values directly from the Owon LCR2020.



Above you can see the measurement of the same  Wima MKS-4 capacitor and in real-time also the deviation in nF and percentage. These last 2 values could be any of the 14 additional values that the meter is offering on top of the 16 combinations.

[flash2b]

Just wondering:

- Is it possible to add tab's to the Mode Menu ? (like tab's from the Setup Menu)
- Is it possible to add an indicator of any sort (like colored text, colored box, icon like "toggleButton" or something else) in the Mode menu to show which selected #cmdMode is active ?
- Is it possible to trigger a #cmdMode from the setup menu, like clicking the button so invoking the #cmdMode ?

For me those will be welcome additions.

[HKJ]

Just wondering:

- Is it possible to add tab's to the Mode Menu ? (like tab's from the Setup Menu)

No, mode is usally fairly simple.

- Is it possible to add an indicator of any sort (like colored text, colored box, icon like "toggleButton" or something else) in the Mode menu to show which selected #cmdMode is active ?

No, the only item yo can use in addition to buttons is a checkbox.

- Is it possible to trigger a #cmdMode from the setup menu, like clicking the button so invoking the #cmdMode ?

No, setup is stuff that can be changed while log is running, mode is for stuff that needs a reinitialization of TC.

For me those will be welcome additions.

I do not plan on any of your wishes.

[KungFuJosh]

I've updated the Batronix Magnova definition for their latest firmware update. This version now includes an Other button to execute a QuickSave.

Thanks,
Josh

[flash2b]

A challenge with my LCR2020 is that the the #askValues sometimes are not set.

So I made a nice askMode which I checked with some TC functions:

Code: [Select]

deviceMode(handle) ---> Cs,Rs,off,d,freq
modeColumnNames(handle,"Cs") ---> Capacitance
modeColumnNames(handle,"Rs") ---> Resistance
modeColumnNames(handle,"off") ---> No_Value
modeColumnNames(handle,"d") ---> Dissipation_Factor
modeColumnNames(handle,"freq") ---> Frequency
So far so good, looks like de #values are correctly linked

An example from the values I retrieve from the meter are:

Code: [Select]

;; LCR2020: Rx as numbers <1.01469E-7 7.97137 0.0 0.00508214 1000.0>
The problem is that TC puts the 4 value into the column of the 3 value in the "current values" and the log function as shown below:


What do I do wrong?

It does not happen if the 3rd and 4th modes are swapped and the values swapped as well.

[HKJ]

I've updated the Batronix Magnova definition for their latest firmware update. This version now includes an Other button to execute a QuickSave.

I have updated the file, thanks.

[HKJ]

The problem is that TC puts the 4 value into the column of the 3 value in the "current values" and the log function as shown below:

What do I do wrong?

It does not happen if the 3rd and 4th modes are swapped and the values swapped as well.

I do not see any issues, TC will parse the value in sequence and assign them in sequence. It is up to you to present them in the correct sequence.
You can modify the #askValue line dynamically, depending on modes with [Mode:mode_list]

[flash2b]

I've read the documentation, but I think it will not be the solution for my problem.

My 2 monitor modes give different modes from the main read out, however if they are disabled, they still give "off" as an answer to #askMode.

They always return a value, regardless off their mode. If they are "off" they return "0.0".

So may be I did explain it incorrectly, the #askValues always return 5 numeric values is my example.

Code: [Select]

;; LCR2020: Rx as numbers <1.01469E-7 7.97137 0.0 0.00508214 1000.0>
On the "current values" tab they are in that exact order, however I did not expect that TC does not change the Column "Name" as it is configured by by #askMode and clearly correct.

It seams to happen when the third value in my read is 0.0, if the third and forth are swapped (and also in de #askMode), it works ok.

(Adding [Mode:mode_list] in my #askValues does not change that, furthermore main reads 2 modes with only 1 askValue, in my example Cs and Rs are read with just one SCPI command. I do not see how I can do that with [Mode:mode_list].)

[HKJ]

I've read the documentation, but I think it will not be the solution for my problem.

You might be able to do something with #askValuesReadFormat, it can define values to ignore.

#askValuesReadFormat uuuuuuxxxx[mode:Energy]uuu

https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#readFormat

You can also edit the input string with #askValuesMathFormat, this is done before #askValuesReadFormat is used.

[flash2b]

I have now defined it as:

Code: [Select]

; ----- Read measurement ------
#askValues FETCH:MAIN?;FETCH:MON1?;FETCH:MON2?;FREQ?

; ----- Read mode -----
#askMode FUNC?;FUNC:MON1?;FUNC:MON2?
#askModeReadFormat replace(replace(value,"-"," ")+" freq","off off","off off1")

I can try using #askValuesMathFormat and add a [mode:off]ffxff and [mode:off1]fffxf but still think is strange that it happens.

Note: Both off and off1 are defined as #value

[flash2b]

is this specific case #askValuesReadFormat ffxff will work, but now the last value is gone.

However #askValuesReadFormat fffff[mode:off]ffxff doees not work, can you really add [mode:xxx] in the askValuesReadFormat ??

[MrPete]

I'm feeling a bit dumb. i'm testing the Riden RD6006 -- many seem to use this. I have many aspects working fine, yet stuck on some basics:

* It has a CV mode for battery charging. Yet as soon as I enable the power output in TestController, it goes to CC instead of CV?? How to use CV?

* In many cases on the RD6006 popup menu, entering a voltage ends up storing that value / 10. (I.e I enter 8 and get 0. Likely definition bug or user error?

[HKJ]

is this specific case #askValuesReadFormat ffxff will work, but now the last value is gone.

However #askValuesReadFormat fffff[mode:off]ffxff doees not work, can you really add [mode:xxx] in the askValuesReadFormat ??

I put it in the documentation, so I am pretty sure I also put it in the code. It is performed before the #askValuesReadFormat do it parsing.