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

[HKJ]

The timeout occur after a sending action, but not consistently.

The timeouts never happen if I switch to a dedicated COM port.

I will take a look at the code, but I am not confident I can find anything.


Note: The debugTime can also use an alternate time format if you write debugTime=2

[MrPete]

@HKJ, are curly-brace blocks of code possible in either scripts or #pgm# ? Can I create a global function that makes use of code like that? Or do I need to do everything in the more typical #if / #else / #endif etc etc style? I thought I saw such code somewhere but now am not finding it.

FWIW, a suggestion: it would be great on the configuration tab to have a button that pops up a list of all configurable values, such as the names of the various folders referenced by TC, etc. Plus things like current version number etc... I'm thinking this is helpful to have in one place for diagnostics, for reporting the context, and many other purposes. (Example: I had not used autoinit before. It took quite a while to realize where it is kept )

[KungFuJosh]

@MrPete, you should search the definition folder for examples. There's already some definitions with advanced programming in them.

[HKJ]

@HKJ, are curly-brace blocks of code possible in either scripts or #pgm# ? Can I create a global function that makes use of code like that? Or do I need to do everything in the more typical #if / #else / #endif etc etc style? I thought I saw such code somewhere but now am not finding it.

Curly brackets is not used in TC's languages. The programming language is basically a full language with all required structures, only exception is functions that is outside the standard syntax, but must be created with system functions (There is a reason for that).
You can see a summary of the programming here: https://lygte-info.dk/project/Calculator%20UK.html#Programming

FWIW, a suggestion: it would be great on the configuration tab to have a button that pops up a list of all configurable values, such as the names of the various folders referenced by TC, etc. Plus things like current version number etc... I'm thinking this is helpful to have in one place for diagnostics, for reporting the context, and many other purposes. (Example: I had not used autoinit before. It took quite a while to realize where it is kept )

TC has lot of configurable and semi configurable values, I believe some standard page showing some or all configurable value may be a bit confusing. TC saves all settings in one place (Default is (documents or home)/TestController/settings, but you do not even need to know that because everything editable in that folder can be reached from menus (if you checked the link I provided, it do directly show what menu to use).

[HKJ]

The timeout occur after a sending action, but not consistently.

The timeouts never happen if I switch to a dedicated COM port.

Looking at the code I can see that modbus has automatic retry, but there is a multi thread bug in it.
I have fixed that and uploaded a new version.

[flash2b]

HKJ, TC 3.15 is better but still I manage to get timeouts. Always a few seconds after making a send (write) action.

Code: [Select]

;; 932593.29ms YK_DO23020VC: Tx <outputAll?>
;; 932594.21ms YK_DO23020VC: Tx <holding? 0x00 2 /100 /100>
;; 932594.70ms COM3: Tx: 01 03 00 00 00 02 C4 0B
;; 932618.21ms COM3: Rx: 01 03 04 02 EE 01 90 9A 42
;; 932618.63ms YK_DO23020VC: Rx <7.5 4.0>
;; 932618.95ms YK_DO23020VC: Rx as numbers <7.5 4.0>
;; 932793.78ms YK_DO23020VC: Tx <outputAll?>
;; 932794.68ms YK_DO23020VC: Tx <holding? 0x00 2 /100 /100>
;; 932795.04ms COM3: Tx: 01 03 00 00 00 02 C4 0B
;; 932818.49ms COM3: Rx: 01 03 04 02 EE 01 90 9A 42
;; 932819.01ms YK_DO23020VC: Rx <7.5 4.0>
;; 932819.49ms YK_DO23020VC: Rx as numbers <7.5 4.0>
;; 932998.36ms YK_DO23020VC: Tx <outputAll?>
;; 932998.81ms YK_DO23020VC: Tx <holding? 0x00 2 /100 /100>
;; 932999.07ms COM3: Tx: 01 03 00 00 00 02 C4 0B
;; 934008.19ms COM3: Tx: 01 03 00 00 00 02 C4 0B
java.lang.NullPointerException
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface$ModbusRTUInterface.readHoldingInput(DeviceModbus.java:276)
        at dk.hkj.devices.DeviceModbus$TranslatingCommInterface.write(DeviceModbus.java:1151)
        at dk.hkj.comm.CommInterface.writeRead(CommInterface.java:150)
        at dk.hkj.main.SCPICommand.writeReadDelay(SCPICommand.java:182)
        at dk.hkj.main.SCPICommand.writeReadInternal(SCPICommand.java:362)
        at dk.hkj.main.SCPICommand.writeRead(SCPICommand.java:408)
        at dk.hkj.main.SCPICommand.readNumbers(SCPICommand.java:524)
        at dk.hkj.main.DeviceInterface.getValuesFromDevices(DeviceInterface.java:418)
        at dk.hkj.devices.DeviceSCPI.getValuesFromDevices(DeviceSCPI.java:101)
        at dk.hkj.main.InterfaceThreads$DeviceThread.run(InterfaceThreads.java:1726)
;; 935030.19ms YK_DO23020VC: Rx Timeout
;; 935030.54ms YK_DO23020VC: Rx as numbers <No data (timeout?)>

I now also have it during direct COM port... is that even possible ?

Ok... retested on TC 3.14 direct COM port and also some timeouts.... I was afraid !

[flash2b]

The automatic retry goes off too fast or is listening to the wrong thread ?....  (this problem was not in TC3.14 !)

TC 3.15

Code: [Select]

;; 506992.40ms YK_DO23020VC: Tx <*idn?>
;; 506992.57ms YK_DO23020VC: Tx <holding? 0x10>
;; 506992.73ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 507013.58ms COM3: Rx: 01 03 02 59 EC 83 99
;; 507013.79ms YK_DO23020VC: Tx <holding? 0x0E>
;; 507013.96ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 508032.69ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 508054.84ms COM3: Rx: 01 03 02 00 02 39 85
;; 508055.56ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 508056.10ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 509079.18ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 509101.13ms COM3: Rx: 01 03 02 00 0D 79 81
TC 3.14

Code: [Select]

;; 8467.61ms YK_DO23020VC: Tx <*idn?>
;; 8468.35ms YK_DO23020VC: Tx <holding? 0x10>
;; 8469.05ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 8490.49ms COM3: Rx: 01 03 02 59 EC 83 99
;; 8491.00ms YK_DO23020VC: Tx <holding? 0x0E>
;; 8492.18ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 8514.42ms COM3: Rx: 01 03 02 00 02 39 85
;; 8515.06ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 8516.30ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 8538.07ms COM3: Rx: 01 03 02 00 0D 79 81

[MrPete]

You do a addFuncGlobal() in some init statement: https://lygte-info.dk/project/Calculator%20UK.html#Execute_scripts this is best done by using #scpiCmd
It is possible to pass arguments to the declared function, they will all be in a params[index] array.
...
A function have direct access to the variables of the calling function, i.e. all the device values when it is called from math.
It is necessary to declare it as global, because you cannot get access to the math context for declaring a function, this means you have to be careful with naming, to avoid conflict with anything else. I.e. do not use a short simple name, but a longer name with something specific to the device/task.

If it is not part of a device definition, you can declare the function in:
Autorun.txt this file will run once when TC is started.
AutoInit.txt this file will run every time TC load devices.
Use a = before a single line declaration or place a line with #calc before a multi line declaration

I have learned some additional lessons...

* Need "#calc" at the top of AutoInit.txt
* Comments in this context begin with "//" instead of ";;"
* Every reference to a Math context variable must use Math.xyz (not just xyz)
* Any global variables must be initialized in AutoRun.txt otherwise they'll be "randomly" reset at various times (since AutoInit can run many times, not under my control.)
* Various mistakes produce surprising error messages. It is MUCH easier to build up from very small portions of the desired code/patterns.

[HKJ]

I have learned some additional lessons...

* Need "#calc" at the top of AutoInit.txt

Not at the top, but before you use the programming language.
TC has two languages:
Script, that is all commands starting with #, i.e. https://lygte-info.dk/project/TestControllerScriptCommands%20UK.html
Programming language, that is the stuff described here: https://lygte-info.dk/project/TestControllerFunctions%20UK.html and here https://lygte-info.dk/project/Calculator%20UK.html

The #calc switches to programming language, but any # will switch back to script.

* Comments in this context begin with "//" instead of ";;"

Comments in programming language is // or /* ... */

* Every reference to a Math context variable must use Math.xyz (not just xyz)

That is always the case.

* Any global variables must be initialized in AutoRun.txt otherwise they'll be "randomly" reset at various times (since AutoInit can run many times, not under my control.)

autorun.ini is under your control, it is run when you do a reconnect

* Various mistakes produce surprising error messages. It is MUCH easier to build up from very small portions of the desired code/patterns.

Error messages is often rather obscure, what the parser or execution engine sees, may not be logical to you.

The programming language has two parts:
1) A tokenizer or parser that convert the text to tokens
2) The execution engine that perform the tokens, i.e. execute the program.

Depending on mode 1) feed its output either directly to 2) or to some storage, that can later be feed to 2)

[HKJ]

The automatic retry goes off too fast or is listening to the wrong thread ?....  (this problem was not in TC3.14 !)

The automatic retry will first be activated on a comm timeout.
You may want to play a bit with the #debug command, it will give more information.
Try #debug * *
It is probably too much info.

For now I cannot see what is going wrong.

Starting TC in debug mode, do not activate all debug functions!

[MrPete]

@HKJ,
I am attempting to write some Math functions usable to create multiple trend lines for data series in the table.

I am missing some information to enable me to do this (if it is possible at all!) What I don't see:

* Is there a known sequence to the calls to the Math expression when the table is processed by TC?
* Is there a way to know which row is currently being processed for the current call to the Math expression?
* Is there a way to access the time (Time, Minutes, whatever) in the current Math expression?

Thanks muchly!

[HKJ]

@HKJ,
I am attempting to write some Math functions usable to create multiple trend lines for data series in the table.

I am missing some information to enable me to do this (if it is possible at all!) What I don't see:

* Is there a known sequence to the calls to the Math expression when the table is processed by TC?

They are called in top down sequence, but it is not documented or guaranteed.
You are not supposed to use output from one math line as input to another math line.

* Is there a way to know which row is currently being processed for the current call to the Math expression?

No, the math expressions are used for other stuff, they are not exclusive for the table.
A lot of the popups and "current values" start their own calculations that are independent from the table.

* Is there a way to access the time (Time, Minutes, whatever) in the current Math expression?

You can access the system time, there is also a time variable when logging, but that will not help other places that uses the math.
Try
=getVarList(0)
from the command line.
You can also use the command in a program, if you put it into a printLog(getVarList(0)) statement.

Note: The argument to getVarList(0) is 0 for global, 1 for local, 2 for parent.

[flash2b]

The automatic retry will first be activated on a comm timeout.
You may want to play a bit with the #debug command, it will give more information.
Try #debug * *
It is probably too much info.

For now I cannot see what is going wrong.

Starting TC in debug mode, do not activate all debug functions!

I did some additional logging

TC 3.14 - Direct COM

Code: [Select]

;; 38466.16ms YK_DO23020VC: Tx <*idn?> 2A 69 64 6E 3F
;; 38467.05ms YK_DO23020VC: Tx <holding? 0x10>
;; 38467.87ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 38468.41ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 38489.93ms COM3: Rx: 01 03 02 59 EC 83 99
;; 38490.26ms COM3: Rx: 01 03 02 59 EC 83 99
;; 38491.34ms YK_DO23020VC: Tx <holding? 0x0E>
;; 38492.10ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 38492.85ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 38514.28ms COM3: Rx: 01 03 02 00 02 39 85
;; 38514.54ms COM3: Rx: 01 03 02 00 02 39 85
;; 38516.35ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 38516.79ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 38517.49ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 38539.03ms COM3: Rx: 01 03 02 00 0D 79 81
;; 38539.31ms COM3: Rx: 01 03 02 00 0D 79 81
;; 38544.64ms YK_DO23020VC: Rx <Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3> 45 6C 65 63 64 65 6D 6F 2C 59 4B 2D 44 4F 32 33 30 32 30 2C 20 48 4B 33 32 46 30 33 30 4D 46 34 50 36 2C 20 31 2E 33
;; Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3
TC 3.14 - Mobus shared

Code: [Select]

;; 97186.64ms YK_DO23020VC: Tx <*idn?> 2A 69 64 6E 3F
;; 97187.36ms YK_DO23020VC: Tx <holding? 0x10>
;; 97188.18ms Modbus Port3:1: Tx: 01 03 00 10 00 01 85 CF
;; 97188.75ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 97210.08ms COM3: Rx: 01 03 02 59 EC 83 99
;; 97210.34ms Modbus Port3:1: Rx: 01 03 02 59 EC 83 99
;; 97211.10ms YK_DO23020VC: Tx <holding? 0x0E>
;; 97211.72ms Modbus Port3:1: Tx: 01 03 00 0E 00 01 E5 C9
;; 97212.41ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 97233.99ms COM3: Rx: 01 03 02 00 02 39 85
;; 97234.25ms Modbus Port3:1: Rx: 01 03 02 00 02 39 85
;; 97235.08ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 97235.64ms Modbus Port3:1: Tx: 01 03 00 11 00 01 D4 0F
;; 97236.32ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 97257.62ms COM3: Rx: 01 03 02 00 0D 79 81
;; 97257.89ms Modbus Port3:1: Rx: 01 03 02 00 0D 79 81
;; 97258.67ms YK_DO23020VC: Rx <Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3> 45 6C 65 63 64 65 6D 6F 2C 59 4B 2D 44 4F 32 33 30 32 30 2C 20 48 4B 33 32 46 30 33 30 4D 46 34 50 36 2C 20 31 2E 33
;; Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3
TC 3.15 - Direct COM

Code: [Select]

;; 122523.54ms YK_DO23020VC: Tx <*idn?> 2A 69 64 6E 3F
;; 122524.55ms YK_DO23020VC: Tx <holding? 0x10>
;; 122525.44ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 122526.09ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 122547.61ms COM3: Rx: 01 03 02 59 EC 83 99
;; 122548.04ms COM3: Rx: 01 03 02 59 EC 83 99
;; 122549.53ms YK_DO23020VC: Tx <holding? 0x0E>
;; 122550.43ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 122551.13ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 122572.64ms COM3: Rx: 01 03 02 00 02 39 85
;; 122572.94ms COM3: Rx: 01 03 02 00 02 39 85
;; 122574.43ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 122574.76ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 122575.55ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 122597.07ms COM3: Rx: 01 03 02 00 0D 79 81
;; 122600.60ms COM3: Rx: 01 03 02 00 0D 79 81
;; 122601.84ms YK_DO23020VC: Rx <Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3> 45 6C 65 63 64 65 6D 6F 2C 59 4B 2D 44 4F 32 33 30 32 30 2C 20 48 4B 33 32 46 30 33 30 4D 46 34 50 36 2C 20 31 2E 33
;; Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3

TC 3.15 - Mobus shared

Code: [Select]

;; 21332.58ms YK_DO23020VC: Tx <*idn?> 2A 69 64 6E 3F
;; 21333.22ms YK_DO23020VC: Tx <holding? 0x10>
;; 21333.99ms Modbus Port3:1: Tx: 01 03 00 10 00 01 85 CF
;; 21334.64ms COM3: Tx: 01 03 00 10 00 01 85 CF
;; 21356.12ms COM3: Rx: 01 03 02 59 EC 83 99
;; 21356.37ms Modbus Port3:1: Rx: 01 03 02 59 EC 83 99
;; 21357.16ms YK_DO23020VC: Tx <holding? 0x0E>
;; 21357.84ms Modbus Port3:1: Tx: 01 03 00 0E 00 01 E5 C9
;; 21358.56ms COM3: Tx: 01 03 00 0E 00 01 E5 C9
;; 21379.86ms COM3: Rx: 01 03 02 00 02 39 85
;; 21380.17ms Modbus Port3:1: Rx: 01 03 02 00 02 39 85
;; 21381.45ms YK_DO23020VC: Tx <holding? 0x11 /10>
;; 21381.83ms Modbus Port3:1: Tx: 01 03 00 11 00 01 D4 0F
;; 21382.53ms COM3: Tx: 01 03 00 11 00 01 D4 0F
;; 21403.99ms COM3: Rx: 01 03 02 00 0D 79 81
;; 21404.30ms Modbus Port3:1: Rx: 01 03 02 00 0D 79 81
;; 21405.12ms YK_DO23020VC: Rx <Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3> 45 6C 65 63 64 65 6D 6F 2C 59 4B 2D 44 4F 32 33 30 32 30 2C 20 48 4B 33 32 46 30 33 30 4D 46 34 50 36 2C 20 31 2E 33
;; Elecdemo,YK-DO23020, HK32F030MF4P6, 1.3
It looks that in both TC version using direct COM, the request/answers are sent twice. That does not sound right, but I am not the expert.

If you need additional log let me know.

[HKJ]

It looks that in both TC version using direct COM, the request/answers are sent twice. That does not sound right, but I am not the expert.

If you need additional log let me know.

Nothing is send twice, but it is logged at two different levels in the code.

[flash2b]

Ok, that is great.

It does not explain the behavior I posted earlier between TC 3.14 and 3.15, it was using Direct COM port so the result should have been the same. Or was the logging changed... ?

[HKJ]

It does not explain the behavior I posted earlier between TC 3.14 and 3.15, it was using Direct COM port so the result should have been the same. Or was the logging changed... ?

I have made the #debug command more friendly (Added support for *), but not changed the actual logging.
Can you catch the behavior again with more logging?

[flash2b]

Using direct COM port and the #debug * * it is the same.

Without #debug * *, TC 3.15 logs the 2nd and 4rd TX to COM twice. TC 3.14 does not do this, strange if normal logging is not modified.

Sorry for not seeing the timeouts earlier when you released the Modbus sharing. The device I'm working with is an output device, and with temperature reading I never seen a timeouts because it is inputting. I recon that after I write a values sometime the reading stream is temporary interrupted resulting in the timeout. And that i occurs after a few seconds after a write action is that TC has already send continuously read actions from the device. The device is rather quick.

[HKJ]

Using direct COM port and the #debug * * it is the same.

Without #debug * *, TC 3.15 logs the 2nd and 4rd TX to COM twice. TC 3.14 does not do this, strange if normal logging is not modified.

Sorry for not seeing the timeouts earlier when you released the Modbus sharing. The device I'm working with is an output device, and with temperature reading I never seen a timeouts because it is inputting. I recon that after I write a values sometime the reading stream is temporary interrupted resulting in the timeout. And that i occurs after a few seconds after a write action is that TC has already send continuously read actions from the device. The device is rather quick.

Modbus do not really care if you write or read to a device, the messages are the same.
I may check some of it when I have a modbus device connected and maybe also adjust the log output slightly.

[flash2b]

From a modbus perspective you are right, but I meant that writing a value to a device (from a device perspective) might take a little more time since it is actually setting things. I recon setting the output to 10V is longer that just returning the set value, but this might also be a fraction difference.

[HKJ]

From a modbus perspective you are right, but I meant that writing a value to a device (from a device perspective) might take a little more time since it is actually setting things. I recon setting the output to 10V is longer that just returning the set value, but this might also be a fraction difference.

TC always sends the message and waits for an answer, if no answer is received within timeout (Usually 1 sec), it returns with a timeout. The modbus driver will then retry the operation once and if that also fails return a timeout and post a error message.

[MrPete]

* Is there a way to access the time (Time, Minutes, whatever) in the current Math expression?

You can access the system time, there is also a time variable when logging, but that will not help other places that uses the math.

Sorry, I should have been more clear:

In the table, each row has both measured/calculated values such as Voltage etc... AND a time stamp in various formats.

Is there a way to access the time stamp of a given row, in a way similar to how we access measured/calculated values?

[HKJ]

* Is there a way to access the time (Time, Minutes, whatever) in the current Math expression?

You can access the system time, there is also a time variable when logging, but that will not help other places that uses the math.

Sorry, I should have been more clear:

In the table, each row has both measured/calculated values such as Voltage etc... AND a time stamp in various formats.

Is there a way to access the time stamp of a given row, in a way similar to how we access measured/calculated values?

I did say that there is a time variable when logging.
Play a bit with getVarList(0), I do not document all variables.

[HKJ]

A bit more info:
TC has functions to access any value in a table, but not from Math.
https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Table_related_functions

It is even possible to create a new table from the programming language.
BUT it is not possible to modify values in the table, that is by design.

[MrPete]

A bit more info:
TC has functions to access any value in a table, but not from Math.
https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Table_related_functions

It is even possible to create a new table from the programming language.
BUT it is not possible to modify values in the table, that is by design.

It appears also, if I don't want to modify values but DO want to incorporate additional columns of data, my choices are either:
a) Use expressions that work inside Math or a live script during data collection (see https://lygte-info.dk/project/TestControllerMath%20UK.html#Including_a_control_variable_in_the_data )
b) After data collection is complete, my only option is to fully replace the entire table (eg tableAddCSVText()) or redo the table from scratch one row at a time (tableInitHeader() and tableAddRow() ).

Does that sound correct?

As for referencing the time associated with each table row, it appears I have two options:
* table(N,"time") gives the (fractional seconds in this case) of a given row
* I can create a table column that CAN be referenced from Math or anywhere, by creating a Math element of type SumTimeSec, expression 1. This produces the same fractional seconds values as the time column. -- probably slower but at least it can be referenced by anything that has access to Math or Table.

BTW, here's a minor documentation typo:

* In https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Writing_a_time_stamp
  "The date function returns: hh:mm:ss" should be "The timestamp..."

I found another but at the moment do not remember where.

[HKJ]

It appears also, if I don't want to modify values but DO want to incorporate additional columns of data, my choices are either:
a) Use expressions that work inside Math or a live script during data collection (see https://lygte-info.dk/project/TestControllerMath%20UK.html#Including_a_control_variable_in_the_data )
b) After data collection is complete, my only option is to fully replace the entire table (eg tableAddCSVText()) or redo the table from scratch one row at a time (tableInitHeader() and tableAddRow() ).

Does that sound correct?

You can add math expression after the logging is done, math is only blocked while logging is running.

As for referencing the time associated with each table row, it appears I have two options:
* table(N,"time") gives the (fractional seconds in this case) of a given row
* I can create a table column that CAN be referenced from Math or anywhere, by creating a Math element of type SumTimeSec, expression 1. This produces the same fractional seconds values as the time column. -- probably slower but at least it can be referenced by anything that has access to Math or Table.

Creating your own time column will be compatible with other places where math is used.

BTW, here's a minor documentation typo:

* In https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Writing_a_time_stamp
  "The date function returns: hh:mm:ss" should be "The timestamp..."

I found another but at the moment do not remember where.

Thanks, I have fixed it, it will be published next time I upload updated documentation.