The following is an example second timer…

int(tot(1:lookup(Val{SIM Counter}::0~1=0:2~65535=1)))

Note 1 used for seconds. If the process variable is in minutes
(e.g., ml/min) then 60 would be needed. 3600 for hours
(e.g., MPH); etc.

The tot() function has a catchup feature based upon its
saved (delta) timestamp. It has been suggested that totalizers
should remain active for most accurate results. This can be
accomplished by leaving the dashboard containing totalizer
active, adding to data logging and/or by floating widget.

My timer is a stored value between sessions so note
how I use a SIM Counter which increments when
Torque starts. This causes a zero value to totalize
until the conditional value is achieved, then the timer
resumes totalizing from the saved value by 1. This step
allows the timestamp to become current avoiding the
catchup between sessions.

SIM Counter equation…

Min(Val{SIM Counter}+1:15)

Ian if you are reading this… it would be nice
to add two more parameters to tot() function:

Enable/Disable totalizer.
Initial value.

If a specific initial value could be set when
a reset occurs then count down timers could
be created by totalizing negative values.

MPG example…

tot(3600:[0d]*0.62137)/tot(3600:[5e]*0.264172052)

Edited.

Try totalizing your speed…

tot(3600:[0d]*0.62137)

to yield totalized miles travelled.

I believe [0d] reports in km/h. [5e]
reports in L/h. Note corrections above.
Foggy memory strikes again.

It should totalize your speed into miles.
If your speed was a constant 60 MPH the
totalizer should show exactly 60 miles after an
hour of travel. (Similar to the timer example
given above… a constant value totalized
over time period).

In most cases your “value” for totalizing won’t
be constant. The tot() function looks at the
delta time between readings and adjusts/prorates
its result based upon the base period used every
active cycle.

Clear as mud right?