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

[HKJ]

But with a dark background the text will be hard to read.

#cmdSetup separator also supports :color:

I am looking for a way to have a text in a different color dynamically.

Separator is a bit of a special case.

There is a trick that may work, prefix the string with <html>, then you can use some old html codes to control the text (Java never updated its html handling to newer standards). Be a bit careful with it, it may break the formatting (it is used native in some TC stuff).

[flash2b]

So :color: is for buttons (exception is separator).

Why is there not a :fontcolor: option?

Java supports it: button.setForeground(Color.RED);

[HKJ]

So :color: is for buttons (exception is separator).

Documentation says:
:color: Color for an indicator, can be a name or (r,g,b) values. It Is is used on buttonson indicator, "Set" buttons and separator.

Why is there not a :fontcolor: option?

Java supports it: button.setForeground(Color.RED);

From start I wanted a simple to define style for the controls. For that reason I kept settings at a minimum.
Over time some more settings has been added and helped improve the look, usually they are optional, i.e. it is still possible to define they layout in a fairly simple way.

A tag to control font color would not change that, but I do not see much reason for it, most control do not really have a good way to use a fontcolor, info and infoAsk is about the only ones where it could be used.

[flash2b]

So a button with black font and :color: blue is a style decision? If I was able to set the font color to white than a def developer could use it, now all darker colors cannot be used.

Do not get me wrong, I do not want to have fancy styling but an indicator Error: with a Red light next to it could also be a text "Error" in a red color without a text.

I like to have a infoAsk that supports a colored text, better from a condition if a variable is not durable.

[HKJ]

So a button with black font and :color: blue is a style decision? If I was able to set the font color to white than a def developer could use it, now all darker colors cannot be used.

I want a certain uniformity to the look.

Do not get me wrong, I do not want to have fancy styling but an indicator Error: with a Red light next to it could also be a text "Error" in a red color without a text.

I like to have a infoAsk that supports a colored text, better from a condition if a variable is not durable.

Looking at the list of controls, info and infoAsk are the only controls with only text, it is probably no big issues to support the :color: tag for that.

Please try the latest beta and see how :color: and :bgcolor: works on them and report back, I have not tested anything.

[scopeguy27]

This is exactly the kind of glue software that deserves more credit — getting a bench of mixed-brand DMMs, loads and supplies into one CSV timeline is half the work in most long-term tests. Nice touch that the column names behave like variables for the math channel, that saves the usual export-to-spreadsheet dance. Bookmarked for the next bench reshuffle; the shared-timeline-with-math part is what vendor tools never get right.

[flash2b]

:color: works in info and infoAsk, thx.

:bgcolor: has no effect at all.

[scopeguy27]

This is exactly the kind of glue software that deserves more credit — getting a bench of mixed-brand DMMs, loads and supplies into one CSV timeline is half the work in most long-term tests. Nice touch that the column names behave like variables for the math channel, that saves the usual export-to-spreadsheet dance. Bookmarked for the next bench reshuffle; the shared-timeline-with-math part is what vendor tools never get right.

[HKJ]

:color: works in info and infoAsk, thx.

:bgcolor: has no effect at all.

I will take a look more at :bgcolor: but not today.

[scopeguy27]

This is exactly the kind of glue software that deserves more credit — getting a bench of mixed-brand DMMs, loads and supplies into one CSV timeline is half the work in most long-term tests. Nice touch that the column names behave like variables for the math channel, that saves the usual export-to-spreadsheet dance. Bookmarked for the next bench reshuffle; the shared-timeline-with-math part is what vendor tools never get right.

[HKJ]

This is exactly the kind of glue software that deserves more credit — getting a bench of mixed-brand DMMs, loads and supplies into one CSV timeline is half the work in most long-term tests. Nice touch that the column names behave like variables for the math channel, that saves the usual export-to-spreadsheet dance. Bookmarked for the next bench reshuffle; the shared-timeline-with-math part is what vendor tools never get right.

That is only one aspect of TC, it can also automate tests, it has 5 test function in addition to scripting.
The 5 are: a specialized battery test, a power supply/dc-dc converter test, a simple logging until a specific condition is fulfilled, a sweep of 1 to 3 parameters and a table that can change setting at specific times and run multiple loops.

There is also some other useful tools in the popups menu.

Also note that F1 is a help key and will open a webpage with help for the page you are on.

[flash2b]

:color: works in info and infoAsk, thx.

:bgcolor: has no effect at all.

I will take a look more at :bgcolor: but not today.

with infoAsk, it colors the button and the text in the same color. It is ok when :bgcolor: is also settable and almost what I wanted... so I look forward to that fix in due time. Thx

[Benleentje]

My definition for the ZERA VCS320 is working.
According to the SMM 3000 software wish stil works for my model i think this definition should work for other Zera type's and or  3 phase calibrators. That why i take i lot of effort to put manual setting into it.
I was not able to test other devices and didn't put any of them in the definition.

The device has no readback for any setting so ik needed a lot of variables.

[Cyclotron]

I don't know if anyone else uses it or has noticed the change log for multiple instruments on a ProLogix interface, but I wanted to say a big, big thank you to @HKJ for the work on multiple devices on a ProLogix-style controller. Basically, I have two buses and two ProLogix-type controllers.  Everything is available on them, and then I have the third "bus," which is VMSG, that emulates the ProliX interface for my VISA and USB devices on my lab computer.  This now means I can log and graph from any instrument at any time, and all of them on that bus are available.

 

[HKJ]

In next version :bgcolor: will work, I had to set a opaque flag for it to work.

Thinking more about it, I have also moved bgcolor to the :labelformat:, a second color will go to the background

[HKJ]

My definition for the ZERA VCS320 is working.
According to the SMM 3000 software wish stil works for my model i think this definition should work for other Zera type's and or  3 phase calibrators. That why i take i lot of effort to put manual setting into it.
I was not able to test other devices and didn't put any of them in the definition.

The device has no readback for any setting so ik needed a lot of variables.

Added, thanks.

I added a "#interfaceType Calibrator" to the definition.

[Gertjan]

I want a certain uniformity to the look.

Hi HKJ,

I Think this is an important point.
Definitions by third party authors become a part of the parent program, TestController.
It is good to have all setup and mode menu's the same look and feel, as much as possible.

Giving not too many layout options is helpful to obtain this.
Otherwise we will get all kind of wild and colourful menu's to the taste of the definition author, but not matching the TestController style.
A uniform style makes it easier for users to find their way.

I am also not too happy with the different themes (light, dark). It makes it difficult to choose colours that will work with all themes. (The solution for my own definitions is that I simply ignore the existence of the colour themes....)

After all, TestController is a technical tool. Not consumer software, that has to follow trends.

Regards, Gertjan.

[flash2b]

The colors were designed to wotk on both light and dark background unlike the default colors. I used a color calculator to determine the reading visibility for all 16 colors against a light and dark background.

The colors were chosen based on analysis and not on a trend.

[HKJ]

I Think this is an important point.
Definitions by third party authors become a part of the parent program, TestController.
It is good to have all setup and mode menu's the same look and feel, as much as possible.

Giving not too many layout options is helpful to obtain this.
Otherwise we will get all kind of wild and colourful menu's to the taste of the definition author, but not matching the TestController style.
A uniform style makes it easier for users to find their way.

I am not against color, but it has to be used the right way and generally that is the case.

I am also not too happy with the different themes (light, dark). It makes it difficult to choose colours that will work with all themes. (The solution for my own definitions is that I simply ignore the existence of the colour themes....)

After all, TestController is a technical tool. Not consumer software, that has to follow trends.

The chart can be used in presentations, that means it needs more flexibility in design. That is also the reason I already had overrides for colors and annotations, the schemes just makes color overrides easier.

[Gertjan]

Hi HKJ,

Here is a definition file for the Marconi 2018 and 2019 Signal Generators
Another classic, but still relevant piece of test equipment added to TestController. 😊
This is an easy to use generator, with excellent performance.



Marconi_2018_-_front-2000pix.jpg

These Marconi’s are using old style GPIB commands: a command for each pressed front panel button. And all answers consist of the same long answer string that contains all values and settings info.
So reading from the generator is not very fast. I worked around this by reading the answer string only when really necessary, and then split out all values to variables.
Most reads are now from the cache. Logging, Current Values tab and readout popup are now very fast, as is buildup of the setup menu.
All tabs of the setup menu:


Mi2018-All-tabs-screenshot-v1,0-1000pix.png


This time I tried to make #scpiCmd’s as close as possible to the real SCPI commands of comparable generators. (instead of making up my own)
I think that was your original intention with #scpiCmd’s. (Although nowhere stated)

There are also Marconi 2018A and 2019A Signal Generators. These next generation generators are having different GPIB commands. (a more modern system) So they can't be used with this device configuration file.

Please find the Marconi 2018 and 2019 device file here: Marconi2018-2019.zip

Regards, Gertjan.

[HKJ]

Here is a definition file for the Marconi 2018 and 2019 Signal Generators
Another classic, but still relevant piece of test equipment added to TestController. 😊
This is an easy to use generator, with excellent performance.

Added, thanks.

[KungFuJosh]

I am also not too happy with the different themes (light, dark). It makes it difficult to choose colours that will work with all themes. (The solution for my own definitions is that I simply ignore the existence of the colour themes....)

Indeed. The benefit of something being optional is that you can ignore it. The people who like that option can utilize it...and life goes on.

[flash2b]

While writing the Owon OWH9811 definition (SCPIx driver) I found a timing issue when a multi-query #scpiCmd is used inside #askValues.

Setup:
#scpiCmd readHarmList :HARM:LIST:VAL? VOLT;:HARM:LIST:VAL? CURR
#askValues [mode:Harmonic_List]readHarmList;[mode:Harmonic,Harmonic_List]:MEAS:VOLT:THD?;[mode:Harmonic,Harmonic_List]:MEAS:CURR:THD?

Expected: 32 values (2 x 15 list values + 2 THD).
Actual: the result of each item is handed over one step late. The log shows:
- after the VOLT:THD? query: Rx <list values> (result of readHarmList)
- after the CURR:THD? query: Rx <2.897> (the VOLT:THD result)
- then "Rx as numbers" with only 31 values
- the CURR:THD reply (2.529) appears after the read is finished and is lost.

When the #scpiCmd is the last item in #askValues, the result is "Rx as numbers <No data (timeout?)>", although the replies are complete in the log.

Workaround: putting the queries directly in #askValues instead of a #scpiCmd works correctly, all 32 values in the right columns.

TC version: 3.56

Code: [Select]

29404.67ms OWH9811: Tx <readHarmList>
29405.20ms OWH9811: Tx <:HARM:LIST:VAL? VOLT;:HARM:LIST:VAL? CURR>
29406.79ms COM8: Tx: <:HARM:LIST:VAL? VOLT.>
29447.45ms COM8: Rx: <13.011, 0.001, 0.177, 0.004, 0.104, 0.001, 0.260, 0.001, 0.126, 0.003, 0.046, 0.004, 0.081, 0.004, 0.035, >
29451.71ms COM8: Tx: <:HARM:LIST:VAL? CURR.>
29476.42ms COM8: Rx: <0.086, 0.000, 0.001, 0.000, 0.001, 0.000, 0.002, 0.000, 0.001, 0.000, 0.000, 0.000, 0.001, 0.000, 0.000, >
29477.42ms OWH9811: Tx <:MEAS:VOLT:THD?>
29479.62ms COM8: Tx: <:MEAS:VOLT:THD?.>
29508.22ms COM8: Rx: <2.897>
29508.62ms OWH9811: Rx <13.011 0.001 0.177 0.004 0.104 0.001 0.260 0.001 0.126 0.003 0.046 0.004 0.081 0.004 0.035 0.086 0.000 0.001 0.000 0.001 0.000 0.002 0.000 0.001 0.000 0.000 0.000 0.001 0.000 0.000 >
29509.13ms OWH9811: Tx <:MEAS:CURR:THD?>
29512.25ms COM8: Tx: <:MEAS:CURR:THD?.>
29524.17ms COM8: Rx: <2.529>
29524.65ms OWH9811: Rx <2.897>
29525.46ms OWH9811: Rx as numbers <13.011 0.001 0.177 0.004 0.104 0.001 0.26 0.001 0.126 0.003 0.046 0.004 0.081 0.004 0.035 0.086 0.0 0.001 0.0 0.001 0.0 0.002 0.0 0.001 0.0 0.0 0.0 0.001 0.0 0.0 2.897>
2.529

[HKJ]

While writing the Owon OWH9811 definition (SCPIx driver) I found a timing issue when a multi-query #scpiCmd is used inside #askValues.

I know TC sometimes fail to decode all values, but I have not looked for the issue.

You can get around it by using #askValuesReadFormat
It accept the same conditions as #askValues

[flash2b]

My workaround make a long #askValues statement worked. But >2h wasted to find it out.