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

[flash2b]

In need some sleep, found another error... sorry !

[ Attachment Invalid Or Does Not Exist ]

Part of TestController V3.34

[KungFuJosh]

In need some sleep, found another error... sorry !

Are you copying me now?

[HKJ]

In need some sleep, found another error... sorry !

Are you copying me now?

I am, but I also need some sleep!

[MrPete]

The exception output to console is always active, i.e. running with the console open and without the debug flag would do that.
You will have to edit the debug bat file for that or create another bat file.

You can always for a exception with a calculator error, i.e. typing =1/0 on the command line will output a long exception dump to console output.

For those who don't know (I just looked this up )

In the testcontroller batch files, here's how you manage whether or not the console is visible:
"javaw ..." (eg testcontroller.bat) -- runs with no visible console
"java ..." (eg testcontroller-debug.bat) -- runs with visible console

[MrPete]

@HKJ, I assume you know the following already. I didn't and am not sure it's documented:

* Logging itself runs in a separate thread, and in general maintains performance independent of other TestController activities

HOWEVER

* Activating #chart elements while logging can GREATLY impact logging from that point on! I have examples now where 0.1 second logging became 0.2 or 0.3, with occasional much-longer delays.

[HKJ]

* Activating #chart elements while logging can GREATLY impact logging from that point on! I have examples now where 0.1 second logging became 0.2 or 0.3, with occasional much-longer delays.

That is computer and configuration depend. If you checkmark "Fast charting" on the configuration page, the chart will use less cpu power.
But even a 10 year old computer can maintain 100 samples/second (Using virtual devices) if the computer was a high performance model.
But TC do lose speed if the table is very large, I have one table with 7 million samples, each containing 10 measurements (From virtual), it starts out at 100 samples/second, but at 5 days and 7 million samples it is down to 3 samples/second. That makes the average sample rate 14 samples/second over 5 days. This speed depends on the computer used.

[KungFuJosh]

It's worth noting that enabling Fast charting will limit the amount of devices that can be charted at once.

[flash2b]

Also the number of curves (excl. digital traces) is restricted to 4 when it is set to on.

[HKJ]

It's worth noting that enabling Fast charting will limit the amount of devices that can be charted at once.

Fast charting does two things:
1) Limit the number of lines on the chart
2) Limits the resolution. TC extract a subset of the data and then passes that to the chart engine. I do  not remember the exact numbers, but it is something like 5000 datasheets for normal and 1000 datasheets for fast, i.e. it will only be visible on a high resolution screen with a fairly large chart or when generating save images in large size.

[MrPete]

* Activating #chart elements while logging can GREATLY impact logging from that point on! I have examples now where 0.1 second logging became 0.2 or 0.3, with occasional much-longer delays.

That is computer and configuration depend. If you checkmark "Fast charting" on the configuration page, the chart will use less cpu power.
But even a 10 year old computer can maintain 100 samples/second (Using virtual devices) if the computer was a high performance model.
But TC do lose speed if the table is very large, I have one table with 7 million samples...

I've had Fast Charting enabled all along. I *thought* this is a petty good computer. Specs include
* 11th gen i9-11900H @ 2.5/4.9 Ghz (cpumark ~20,000 , 8 core/16 thread, half the speed of the fastest out there, but that's still 40M+ FP Mops)
* 64GB RAM
* NVMe storage, min speed write at 2GB/sec
* And the whole thing is coasting when running TestController

What I observed when running my script:
* The working version: enables #log 0.1 at the start, does a bunch of varied tests with various load current and timing, looping until the battery is below a cutoff voltage, all without touching #chart  (although I DID notice one anomaly: when I re-set #log 0.1 at the beginning of the loop, all is well. If I only set it once at the start, eventually the log speed degrades to ~~ 0.2 or even 03. sec ... so I re-enabled #log 0.1 at the start of the loop, and all has been well.)
* After collecting the data, the script does a bunch of analysis, then sets up the #chart, and saves log, table and script. -- that also works.

* Then I thought: it would be nice to observe the proper #chart while collecting data.
* So I copied the #chart setup to the beginning, before the loop runs. This included a #waitui

RESULT:
* log pauses over 1 second right when the #chart is being set up
* log is more like 0.2-0.5 sec throughout the (~15-20 minute) capture.

NOTE: that experiment was BEFORE I restored the #log 0.1 to the start of the loop. I don't know what that might do.

When I have a bit of time, I'll do some more diagnostics for you, @HKJ...

[HKJ]

I've had Fast Charting enabled all along. I *thought* this is a petty good computer. Specs include
* 11th gen i9-11900H @ 2.5/4.9 Ghz (cpumark ~20,000 , 8 core/16 thread, half the speed of the fastest out there, but that's still 40M+ FP Mops)
* 64GB RAM
* NVMe storage, min speed write at 2GB/sec
* And the whole thing is coasting when running TestController

There is no reason for TC to slow down on that computer.

One command that may be a good idea to play with is #COMMANDTIME?
It list the response time from different devices when logging. It do not measure time when sending commands, it only measures parallel operations.

[MrPete]

There is no reason for TC to slow down on that computer.

One command that may be a good idea to play with is #COMMANDTIME?

Mostly 25+/- ms. Sometimes closer to 60ms.

I have nothing to compare with so no idea if good/bad...

[HKJ]

There is no reason for TC to slow down on that computer.

One command that may be a good idea to play with is #COMMANDTIME?

Mostly 25+/- ms. Sometimes closer to 60ms.

I have nothing to compare with so no idea if good/bad...

0.1sec is 100ms, i.e. there may not be much time to send command to the devices. That is not a problem if it only is done once in a while, but if it is done fairly frequently it may be an issue.

Note: Time is collected and the counters reset when you use the command, i.e. you can let it run for some time and then get the worst case time.

[HKJ]

V3.34 is up
It contains a lot of small updateds/changes to TC and a few new devices (Flash2b has been busy)
   Updated: Some documentation pages has been updated.
   Added: Gauselink TH30 (Thanks Flash2b)
   Changed: Output with ;; changed
   Added: Function getGlobalVar(varName) that will always return the global instance of a variable or a empty var if none exist.
   Added: Function deleteLocalVars({varName{,varName}}) that will delete local variables
   Fixed: Some minor issues with NumberDual control
   Added: #CALCSTART & #CALCEND script commands for easier handling of long programs
   Added: ComWinTop BSR-DA02B, BSR-AA02B Voltage and current source device (Thanks Flash2b)
   Added: Popup remote readout
   Changed: The INS/right-click menu for the command line will use two levels when it is large.
   Changed: Ascii driver now support expression for both parameters of #verifyDevice, second parameter must still return a command to the device.
   Changed: portType is valid earlier in the initialization
   Added: Interpolation functions, see calculator documentation.
   Fixed: Definitions for Readouts had issues with leading and trailing spaces (Thanks Flash2b)
   Added: Elecdemo YK-DO23010 C, YK-DO23010 V, YK-DO23011 C, YK-DO23011 V, YK-DO23020 VC, YK-DO23021 VC, YK-DO23020 VV, YK-DO23021 VV, YK-DO23020 CC, YK-DO23021 CC, YK-DO23031 VVV, YK-DO23031 CCC analog output (Thanks Flash2b)
   Update: #interfaceType added/changed on some definitions to match updated documentation (Thanks Flash2b)
   Added: Keithley 2001M DMM (Thanks KungFuJosh)
   Added: On "Load devices" is it possible to filter on #interfaceType (Use right click menu)
   Changed: TC will now cleanup the #interfaceType definition, this may change case on them.
   Updated: The #interfaceType definitions, more has been added and some changed.
   Added: Eletechsup UD24B01, N229E01, N228D02, UD23A08, N223B08 USB/RS232 relays (Thanks Flash2b)
   Changed: TC will not complain about a missing #askValues on devices with no #value definitions.

The INS/right-click command line menu has been change to two level (When the list is long), it makes it much better at showing all commands:


It is now possible to filter devices on type (For devices marked with a type):


For people using the programming language, this page has received a lot of updates: https://lygte-info.dk/project/Calculator UK.html

Flash2b made some remote readouts for TC, I like it so much that I have added direct support in TC for it:

[flash2b]

Pretty long list of changes/updates.

You forgot to mention the updated wrytech PDVS 2 Mini voltage source from Gertjan, but it is included in the release ZIP file I see even with the #interfaceType Calibrator added to it !

[HKJ]

Pretty long list of changes/updates.

You forgot to mention the updated wrytech PDVS 2 Mini voltage source from Gertjan, but it is included in the release ZIP file I see even with the #interfaceType Calibrator added to it !

Oops, I have added it to the update list that is shown in TC (now).

[flash2b]

I also liked this:  Changed: TC will not complain about a missing #askValues on devices with no #value definitions.

(that was annoying with readouts only....)

[flash2b]

Small question about the ;;.

It is now without ;; in the debug log, but still shown in the output log (main window). Probably deliberate since I did not read the discussion you had about it.

[HKJ]

I also liked this:  Changed: TC will not complain about a missing #askValues on devices with no #value definitions.

(that was annoying with readouts only....)

Your readouts was the reason I fixed it. 

[HKJ]

Small question about the ;;.

It is now without ;; in the debug log, but still shown in the output log (main window). Probably deliberate since I did not read the discussion you had about it.

The ;; only has a purpose in the log window. The general idea is you can give a lot of commands on the command line, then press "Clean" and you have it as a program in the log window.
This has always been possible, except output with multiple lines spoiled it and required some manual work. If hope this is fixed now.

[flash2b]

I have update 2 definitions to support #interface, they are attached

[ Attachment Invalid Or Does Not Exist ]

[HKJ]

I have update 2 definitions to support #interface, they are attached

Updated, thanks.

I looked in the files and I do not agree with you.
It is readVoltage() when the input is voltage and readCurrent() when the input is current.
For inputs that can read multiple types of values it is readValue()

The names has to be standardized for the interface to have a meaning.

PS: I changed the names.

[flash2b]

Fine. My idea was like relay where there is also no readValue but relays and relay.

I am looking for the new interpolation function, but I cannot find it. Could you provide a (general) link where it is documented so I can study it? 

[HKJ]

Fine. My idea was like relay where there is also no readValue but relays and relay.

There is set/get, but no read for relay and anyway it is not any normal quantity they have.

I am looking for the new interpolation function, but I cannot find it. Could you provide a (general) link where it is documented so I can study it? 

It is not in the main TC documentation, but the page with functions has a link to this page:

https://lygte-info.dk/project/Calculator%20UK.html#Interpolation

[flash2b]

For people wondering what to do with a remote readout.....



The readout on the photo above has 2.3 Inch (Height) displays and is encased in a aluminum housing. This can even be hung since there are (detachable) hooks.

It seems that 6 digits is the maximum you can buy commercially.

With the remote readout popup in channel mode you can just select the value you want to show, any of the ones that are available in the Current Values tab + math values. In expression mode you can use an expression what you want to see. Since many Modbus devices do not have a physical screen/display it is very handy to have. But also for test measurement equipment that has a screen/display it can be beneficial. I do not have problems reading my values while measuring now I use one