I'd go for read32BitAddress with the following absolute addresses.

for speed, definitely readDataByLocalIdentifier with dynamicallyDefinedLocalIdentifier, using readDataByLocalIdentifier with 1byte header each request message is only 4 bytes long.

thanks a lot for the address table, that's a good starting point for me.
Will try to find some matches in other images for these variables.
I don't know a service with 32bit address on the ME7.x, so I guess you mean the
service readMemoryByAddress(sid=0x23)?

P.S. can't see the ramcells.jpg in your post here, seems to be filtered by the firewall.

yes, this would allow the fastest reading of small ram portions.
But also processing timing in the ecu comes into place (messages handled only each 10ms)
so that the number of bytes in a request probably do not affect the number of messages
per second.
Then, only 10 dynDefLocalIdent's are available and I could associate only a single memory
location with each dynDefLocalIdent. That could limit the number of variables being logged
in parallel. But on the other side, can log up to 253 sequent bytes in one read and I could
use this service on any ecu tested so far. Many pro's and con's.

Spen,

would the use of CAN not rule out certain ECU's?

Rick

My data logging software using ReadMemoryByAddress to do the data logging. ReadDataByLocalIdentifier and ReadDataByCommonIdentifier don't appear to work on the ME7. The message handlers are hooked up, but there are no local or common identifier defined, so you can't read anything besides the ECU identification data. You can use DynamicallyDefineLocalIdentifer by memory address, but it is not as fast as using ReadMemoryByAddress. Also, you are required to be in a Development diagnostic session to use ReadMemoryByAddress, while DynamicallyDeifineLocalIdentifier only requires a Standard diagnostic session.

Requests for ReadMemoryByAddress are fulfilled synchronously in one loop, so you don't need to worry about having half the memory being read from the previous ECU update or anything. But you do need to worry about how often and how much data you are requesting be read. My ECU crashed at 5000RPM while doing a data logging test on the street. Engine shut off and wheels locked up, then the engine restarted a second later, but I nearly lost control of the car when it happened. Turns out if you ask for too much data to be read when the engine is running at a high RPM, the watch dog timer goes off and resets the ECU. I now test data logging before driving by hitting the rev limit in the driveway, and I have also reduced how much data I read with each request.

The data logger I plan to release will require a user to supply a memory layout file specifying the location, data type, offset, and scale of the different variables to log. On the ME7 as far as I can tell, the only generic way to data log is with the slow KWP1281 protocol. With the KWP2000 protocol since common and local identifiers aren't defined, you have to do everything by memory addresses, which change with each ECU. I believe this is why APR ultimately discontinued work on ECUx.

DynamicallyDeifineLocalIdentifier allows to define a LocalIdentifier made of blocks of non consecutive memory. The document don't specify what is maximun length of a LocalIdentifier, but suppose that its 100 bytes, then you can define a LocalIdentifier of 100 consecutive bytes or a LocalIdentifier of 100 bytes at non consecutive addresses. I think this is more economic in terms of message length than read 250 bytes to use only a few