Pages: [1] 2 3 ... 9
Author Topic: Logging with KWP-2000 protocol  (Read 122368 times)
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« on: November 05, 2010, 04:40:15 AM »

I was wondering which method should be used for data logging using a KWP2000-protocol connection.
Can't have a look how VCDS (turbo-button) or ECUx are doing it, but maybe somebody knows more details?

Increasing the measurement rate by setting up higher communication speed is clear.
But which service is best used to read out measurement values?
You can read data using the service readDataByLocalIdentifier or read RAM contents
using readMemoryByAddress (if allowed by the ECU) or use whatever method to retrieve
memory contents.

I know that some ECUs support the readDataByLocalIdentifier with *localIdentifiers*,
which reports measurement groups in a similar form as done with KW1281. This would be relatively
easy to use but seems to be not working for most ECU's if I'm not wrong.
Most ECUs support dynamically defined identifiers by memoryAddress, allowing to read also
RAM cells, but this could be slow since it's reading only a limited number of bytes
per service.

Also could read RAM in blocks and then filter out the measurement values. This
could make sense, if a lot of measurement values are lying at adjacent addresses.
It's clear you need a mapping table to show which addresses hold the values you want
to measure, and this table will be specific for each ecu sw-version.
Here it is unclear to me how to generate such a table, where to start gathering
information about the addresses?

And finally, could it cause problems when reading without being somehow synchronized to
the engine control process?  I mean, is it possible to get wrong results when retrieving
values that are currently under update?
Logged
spen
Full Member
***

Karma: +43/-0
Offline Offline

Posts: 112


« Reply #1 on: November 09, 2010, 01:51:14 PM »

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



Logged
iznogoud
Full Member
***

Karma: +13/-0
Offline Offline

Posts: 104

Learning junkie


« Reply #2 on: November 09, 2010, 02:58:09 PM »

The question about "race conditions" is an interesting one. I think there must be a 'trigger" somewhere in the algorithm.

Can you please state OS and hardware? Thanks.
« Last Edit: November 09, 2010, 10:49:12 PM by iznogoud » Logged

Audi S4 B5 2000 6sp Cactus Green
Audi A4 B6 Avant 1.8T 2001.5 5sp Santorin Blue
ArgDub
Full Member
***

Karma: +60/-1
Offline Offline

Posts: 202


« Reply #3 on: November 09, 2010, 10:13:29 PM »

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

Karma: +43/-0
Offline Offline

Posts: 112


« Reply #4 on: November 10, 2010, 01:48:28 AM »


For speed, the can bus has to be the way to go?
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #5 on: November 10, 2010, 03:03:25 AM »

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




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.
Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #6 on: November 10, 2010, 03:07:44 AM »

The question about "race conditions" is an interesting one. I think there must be a 'trigger" somewhere in the algorithm.

Can you please state OS and hardware? Thanks.
not shure about your question for OS and HW. In general I'm looking at ME7.x ECUs with
ERCOS on it. The logging application could run on any platform.
If "regular" mechanisms to read values are used like the official measurementGroup reading,
I believe the ECU will take care to eliminate race conditions.
But how is the situation when using inofficial mechanisms for reading engine process variables?
It could come out that this in fact is no problem, since the KWP2000 messages are handled
by the ecu in a task that's scheduled on a regular basis and thereby somehow synchronized
to the rest of the engine process. At least that's what I hope ...

Logged
setzi62
Full Member
***

Karma: +142/-0
Offline Offline

Posts: 249


« Reply #7 on: November 10, 2010, 03:11:43 AM »

for speed, definitely readDataByLocalIdentifier with dynamicallyDefinedLocalIdentifier, using readDataByLocalIdentifier with 1byte header each request message is only 4 bytes long.
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.
Logged
spen
Full Member
***

Karma: +43/-0
Offline Offline

Posts: 112


« Reply #8 on: November 10, 2010, 03:53:10 AM »

I don't know the service names which bosch use.  I know there is a routine to read an address though.

Just a crazy idea,  we could upload a function, and add it as a process ID for the ecu to complete and then end comms.  Our new function would then broadcast a set frame of preamble + addresss data we define (n addresses) + crc check when the k line is empty.    Then we switch our datalogger to 'sniff' mode and reap the frames?  Very low overhead, as long as we don't saturate the K line and / or drive the other controllers too hard with interrupts.

Still not as fast as the can bus though!
Logged
Rick
Hero Member
*****

Karma: +62/-4
Offline Offline

Posts: 704


« Reply #9 on: November 10, 2010, 05:58:47 AM »

Spen,

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

Rick
Logged
spen
Full Member
***

Karma: +43/-0
Offline Offline

Posts: 112


« Reply #10 on: November 10, 2010, 11:51:47 AM »

I think even cars without esp still have canbus coming out of the ecu.  Have a look at your wiring diagram for the c ecu, it should be labelled can hi, can lo, or maybe Chi Clo.

CAN is better than KWP2000 for us (c and d ecu users).  Our cars won't take KWP2000 over the k line.  My ecu will talk KWP2000 on a bench Sad  but not in the car.  I think you verified this with your hybrid ecu?

I dount our cars have CAN at the OBD socket.  Mine has the infotainment CANBUS but not the management can bus.  Infotainment bus!  It links the TV tuner to the RNS-D, nothing more!  My DIS is clk/data lines!



Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #11 on: November 10, 2010, 12:19:29 PM »

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.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Rick
Hero Member
*****

Karma: +62/-4
Offline Offline

Posts: 704


« Reply #12 on: November 10, 2010, 02:10:55 PM »

I think even cars without esp still have canbus coming out of the ecu.  Have a look at your wiring diagram for the c ecu, it should be labelled can hi, can lo, or maybe Chi Clo.

CAN is better than KWP2000 for us (c and d ecu users).  Our cars won't take KWP2000 over the k line.  My ecu will talk KWP2000 on a bench Sad  but not in the car.  I think you verified this with your hybrid ecu?

I dount our cars have CAN at the OBD socket.  Mine has the infotainment CANBUS but not the management can bus.  Infotainment bus!  It links the TV tuner to the RNS-D, nothing more!  My DIS is clk/data lines!


Spen,
very interesting that you can't use KWP over  OBD.  Have you tried Tony's software in your car?  Do you know why it doesn't work in car?  I've not looked at the wiring diagram yet, but is it due to the other modules on the Kline not liking KWP2000?

If so, I will run a cable straight from the ECU plug to the OBD socket, and have an isolation switch which disconnects everything from the Kline apart from the ECU and OBD socket.  That should work as that's how it is on the bench.  Pain in the arse having to bench flash each time.

Rick
Logged
ArgDub
Full Member
***

Karma: +60/-1
Offline Offline

Posts: 202


« Reply #13 on: November 10, 2010, 05:39:50 PM »

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
Logged
Tony@NefMoto
Administrator
Hero Member
*****

Karma: +130/-4
Offline Offline

Posts: 1389


2001.5 Audi S4 Stage 3


« Reply #14 on: November 10, 2010, 10:31:59 PM »

There are 10 dynamically defined local identifiers.

Each dynamically defined local identifier can have a max of three entries from what I could determine from the assembly code. Each entry can be used to read a maximum of 255 bytes of memory it seems. But a KWP2000 message has a maximum of 253 data bytes after the service ID and local identifier in the response. So each local identifier read using a dynamically defined local identifier can essentially read a maximum of 253 bytes spread over three different memory ranges.

Read data by local identifier requests take the service ID and the local identifier as data for a total of two bytes of data in addition to the header. The response includes one byte local identifier and then the read data.

Reading memory by address, you can read a maximum of 254 bytes from one memory range.

Read memory by address requests takes a three byte memory address and a one byte memory size as data for a total of four bytes of data in addition to the message header. The response just includes the read data.

Ultimately if you have 30 different memory regions you want to read, then it may better to use dynamically defined local identifiers. If you want to read many many different memory regions, then you may be better off using read memory by address. This is because you have to reset and redine dynamic identifiers if you want to change them.

And like I said, ReadMemoryByAddress requires a Development session, and ReadDataByLocalIdentifier requires a Standard session.
Logged

Remember you have to log in if you want to see the file attachments!
Info or questions, please add to the wiki: http://www.nefariousmotorsports.com/wiki
Follow NefMoto developments on Twitter: http://twitter.com/nefmoto
Pages: [1] 2 3 ... 9
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.024 seconds with 16 queries. (Pretty URLs adds 0s, 0q)