Starting an own process/task on the ecu would be a hard job. Need to setup
a task table and code in ram and then find a way to start the task periodically.
Probably an alarm is free for this use. But conflicts with the running tasks that already
use the serial port could not be avoided.
What can be done is: you can load own code and table into the external ram and then
link it in by redirecting a pointer. So your code gets called whenever a message comes
in and works as an additional message handler for your own logging message.
The code can work on a table and collect all memory locations in one go.

Tony, seems that developer of ecux found a way to bypass the three entries restriction. I've just checked that it can pull at least 67 values (8-16bit mix at non consecutive address) with a single readDataByLocalIdentifier. Also, noted it doesn't use DynamicallyDeifineLocalIdentifier, it defines LocalIdentifier writing directly to ram.

It's funny that whatever baud rate you choose, it never change timing nor baud rate, so reading 67 values it achives 12 samples per second at default 10400 bauds, and 14 sps if you read one value.

Guillermo

Thanks for looking into that. The dynamically defined local identifier entries are stored in RAM, so it is possible you could use WriteMemoryByAddress and manually write them into RAM without using DynamicallyDefineLocalIdentifier. Writing the entires straight into RAM would allow you to bypass the three entry limit per local identifier. The three entry limit is only enfored when defining identifiers.

But this trick is even less portable across ECUs, because you need to find where the local identifier entries are stored and make sure to not to use RAM used by anything else. You could find the location of the local identifier entries by reading RAM, defining local identifiers, and reading RAM again. I am not sure how you can confirm how much RAM is free to use if you want to use more than the standard three entries per identifier. Also, by doing it this way you lose the ability to run in a Standard diagnostic session.

I am planning on releasing my data logger based on ReadMemoryByAddress before I work on trying any new techniques. But it's pretty cool to be hearing some new ideas on the subject.

setzi, I would like to hear about those experiments

Attached are two logs, first RPM and IAT were logged, in second 68 variables were logged. I wrote an explanatory note next to messages but there are many question marks for you guys.

Edit:
ECU 06A906032HS

It's like Tony said, the data table of the local identifier (describing ram address +
number of bytes for each variable to be read) is written into unused ram and
the data pointer in the local identifier table is redirected to the new data table.
For the 68 variables log the communication speed should have been 57600 baud.
I did some small updates in the excel file comments about this.

At all, the used logging method is a nice trick to get over some limits of the ecu functionality.

Just for curiosity: when playing with dynDefLI's, I saw two things:
- could use 3 memory regions per ddli only if the first two regions each just contain one byte.
- with a Cbox image for the definition of a ddli the memory address had to be
  given in swapped order (low byte first, the middle and finally last high byte), strange??

I think I missed the accessTimingParameters service...
Will try it, and probably increase the sample rate

I am definitely interested. In particular, i'd also like to try to reproduce ME7L functionality (even if it isn't general!) so it can be built as some sort of portable library for use in other platforms, as well as being able to redirect the output somewhere useful (like a domain socket to a local process, or tcp socket to a remote host).

Do you have sample code anywhere in your repo?

I might try to rewrite it in C

i goddamn hate vb with a passion.

I'm pretty sure setzi isn't going to give me the source code