PEAK-System Forum

Hi to all,

I trigger a service request via UDSApi.SvcReadDataByIdentifier(). The PID/LEV is 0xFD 0x54.
The reception of the response (33Bytes) workes fine with UDSApi.WaitForService().

However I want the reception to be event driven.
The event fires ok, in the eventhandler I try to pick out the right message by

a) multiple calls of UDSApi.Read() until the result is TPUDSStatus.PUDS_ERROR_NO_MESSAGE
b) checking each received message, for the appropriate type to hold my data

I think TPUDSMessageType.PUDS_MESSAGE_TYPE_INDICATION is an indicator for coming data...

However I get 4 messages with the following content:
Message 1:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 3
DATA = 0x22 0xFD 0x54

Message 2:
MSGTYPE = PUDS_MESSAGE_TYPE_INDICATION
LEN = 33
DATA = 0x62 0xFD 0x54 0xFF 0x4E 0x01 ---> the next bytes ARE NOT INITIALIZED !!!

Message 3:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 33
DATA = 0x62 0xFD 0x54 0xFF 0x4E 0x01 ---> the data is correct until the end

Message 4:
MSGTYPE = PUDS_MESSAGE_TYPE_CONFIRM
LEN = 0
DATA = not initialized

So effectivly I get 3! messages with type PUDS_MESSAGE_TYPE_CONFIRM.
What is the best way to filter out the correct message containing the data?

Thanks again for your help
Andy

Hello,

awild wrote:I think TPUDSMessageType.PUDS_MESSAGE_TYPE_INDICATION is an indicator for coming data...

yes, this is a message indicating that data is pending

awild wrote:However I get 4 messages with the following content:

The Message 1 is the confirmation of your request.
The Message 2 is the beginning of the response; it is normal that not all data bytes are valid since not all the data is retrieved yet.
The Message 3 is the confirmation of the response; the requested data was completely received.
The Message 4 is very strange, especially with a length of 0. We cannot understand this message.

awild wrote: So effectivly I get 3! messages with type PUDS_MESSAGE_TYPE_CONFIRM.
What is the best way to filter out the correct message containing the data?

the filtering you mean is actually what the UDS_WaitFor... functions do. If you keep using UDS_Read, you need to check the NETADDRINFO.SA/TA to distinguish request from responses, check that the RESULT field of those is OK (0), that the message type is PUDS_MESSAGE_TYPE_CONFIRM, etc. until you get all your data. Note that you also have to take care about errors like "PUDS_NRC_EXTENDED_TIMING" that can arise when the ECU needs more time to process a request.

Instead of using the UDS_Read, you could use the function UDS_WaitForSingleMessage(). This function waits for a response to a given UDS request. You can still use your even driven approach, but instead of call UDS_Read several times on signal, you call WaitForSingleMessage once.

Hi Keneth,

thank you for the hint, this is indeed much easier and works ok !

However there is something curious in defining the request message for the WaitForSingleMessage() function: As you can see I set DATA[1]=0 and DATA[2]=0 on purpose in order to check whether WaitForSingleMessage() is able to filter the message correct.
I expected no message reception, because the PID/LEV of the UDS Service is wrong.
But I received the response fine!
Why has DATA[1] and DATA[2] no meaning in terms of selecting the right response?
Thereafter I set DATA[0] = 0x21.
Then there was no reception, as to be expected.
It seems that only the SID is verified to detect the UDS message to receive?

Thank you very much
Andy

Hello,

here an extract of the help that may explain what is happening:

PCAN-UDS API Documentation - Page 117 - wrote: Note: the criteria to identify if a response matches the message request is based only on the network
addressing information and the UDS service identifier: if a same service is requested multiple times with
different parameters (like service ReadDataByIdentifier with different Data IDs), the user will have to
ensure that the extra content matches the original request.