we wait

Capp777, your formula is incorrect
if the time is 1 second, then the result increases in 1 second,
if time is 2 seconds, then the result is increased in 0.5 seconds
and so on, the rate of increase in the result increases with time

Since I was testing offline I used…

tot(1:lookup([1F]+1::0=0:1~65535=1))

since [1F] was not available. but it
totalized in seconds, saved results and
resumed when I restarted Torque.

tot(1:lookup([1F]::0~10=0:11~65535=1))

would allow the delta time catchup to
update before resuming timing.

Sorry it didn’t work for you.

Quote from cintakc on November 10, 2019
Capp777, your formula is incorrect
if the time is 1 second, then the result increases in 1 second,
if time is 2 seconds, then the result is increased in 0.5 seconds
and so on, the rate of increase in the result increases with time

End Quote.

Cintakc,

My suggested equation uses a one second time base period
and totalizes only a 0 or 1 value. The time base should never
be 2. Typically the base period would be…

1 for seconds
60 for minutes
3600 for hours
etc.

It’s basically a timer maintained in Torque since the ECU
will always reset [1F] based upon standard. Not sure if
[7F] would be better.

Torque’s totalizer function does have a catchup
feature that will have an impact if Torque starts
totalizing value other than zero right away on
startup. That’s where the range limits should
help.

Edited.

Hello Ian.
I rummaged the entire Internet, all forums, but so and not found formula, which is used you Have in program Torque, for parameter:
Run time since ancient times = PID [1F]
I understand that You are busy, but could you tell me the formula for conversion of units of time to that mean?
https://drive.google.com/open?id=1ROseHe5mIzT_fzHTysU38emvYnmSjSvd
Thanks in advance!

Cintakc,

The lookup delimiter needs to be a : not ;

My equation with the +1 offline worked
because the value never exceeds 1 but when
I simulated values greater than one I found
the semi colon issue…needs to be a colon.

Incorrect delimiter…

tot(1:lookup([1F]::0=0;1~65535=1))

Correct delimiter…

tot(1:lookup([1F]::0=0:1~65535=1))

Typo.

Quote from Capp777 on November 11, 2019
The lookup delimiter needs to be a : not ;

My equation with the +1 offline worked
because the value never exceeds 1 but when
I simulated values greater than one I found
the semi colon issue…needs to be a colon.

Incorrect delimiter…

tot(1:lookup([1F]::0=0;1~65535=1))

Correct delimiter…

tot(1:lookup([1F]::0=0:1~65535=1))

Typo.

Capp777, today I filmed the work Of your formula, in the running program TORQUE in the car.
In the video, there is a conversation in Russian.
https://drive.google.com/open?id=18yII_ta41iVqH6JVLcxzk_bbM0gvJICP
Your formula does not work in reality!!!
Does not work saving parameters, in the TORQUE:
1. Store the value in the vehicle profile
2. To preserve the value of the global”
Not in 1 not in 2 option.
About than I previously and wrote already.

Again I say I’m sorry it doesn’t work for you.

tot(1:lookup([1F]::0~29=0:30~65535=1))

When I test offline using a simulated counter
it …

Let timer count to 75 seconds.
Exited Torque.
Waited several minutes then restarted Torque.
Timer resumed counting at 75, not 0.

Saving pid results works for me. [1F] is just a
timer just like my simulated counter. [7F] might
be worth testing if your vehicle supports it.

Ian has stated that he will look into adding a
new function when he can.

int(tot(1:lookup([0c]::0~299=0:300~65535=1)))

Edited.

Hi!

The USB update is mostly done now (including a small speedup for FTDI based devices, further than what was already quick on the OBDLink scantool) – I have just to test on the only other non-ftdi based adapter here to sure things are ok and the next beta will be sent out. You’ll see an increase of about 20PIDs/sec for the OBDLink adapter on CANBUS (taking it to about 180PIDs/sec max)

One significant change with the USB stuff is that the app will default to using the USB adapter if one is plugged in and the user chooses to start the app (so if bluetooth is selected, this will be overridden). There were a bunch of issues fixed with USB in this update

After that, it’s a couple of map activity fixes and also looking at this new function request in a bit more detail (plus anything else that people have mentioned) – as always betas will appear first on this so expect frequent updates when I implement stuff.

Hi!

Finally released 1.10.110 which has the USB updates in – I also managed to fit in time to update the Trip View activity to fix an issue in there

USB should be a lot easier to use now once you have the update (it’s just waiting on google to review and approve the beta). Unfortunately I could not find my prolific based adapter but it should still work for non-ftdi based devices as well