ADCS "Diagnostic Service.vi": Use a custom response service ID to listen for?

[flowschi]

Hello,

I am working with an ECU which uses reserved ISO-TP service IDs:

The request uses service ID 0xC8 and the repsonse from the ECU has ID 0xC9.

So the response's service ID is not request ID + 0x40 like usual.

That's why "Diagnostic Service.vi" seems to ignore the response from the ECU, because it does not expect response SID 0xC9.

Is there any way to make things work? Any option in "diag ref"? If not, what would be the suggested way to create my own implementation?

Thank you!

[Gucky]

Hello,

the Automotive Diagnostic Command Set has no option for this.

You can make a copy of the Diagnostic Protocols.llb and modify these VIs. They are not password protected.

The llb is in:

C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\Automotive Diagnostic Command Set

Regards

[CGfromG]

Are you sure that you mean the diagnostic protocol's Service IDs or are the Transmit and Receive IDs from ISO TP not properly set?
ISO TP does not make any use of Service IDs itself, using fixed IDs for the transmission and reception of ISO TP messages is a common behavior.

From your description of the problem, in ADCS 0xC8 should be set as Transmit ID and 0xC9 as Receive ID.

[flowschi]

Yes, I am sure. I am not talking about the arbitration ID. If I use for example Service ID 22 (by using "Diagnostic Service" manually or by using "RequestDataByIdentifier"), things are working with my specified transmit ID and receive ID.

@ Gucky: I will try that, thanks!

[flowschi]

Unfortunately I don't see how I could implement the necessary changes there.

The VI "Diagnostic Service" is beeing called internally, which is password protected.

Is the handling of the service IDs (request/response) done somewhere else?

Thanks!

[Gucky]

Take a look at the "data out" of the "Diagnostic Service.vi". You should see the repsonse frame from your ECU.

Hope this helps.

[flowschi]

The problem is, that ADCS does not respond to the first frame coming from the ECU.

The communication should look like that, but the red colored lines are not beeing sent:

+27,732 Tx 0x16F773F0 05 C8 00 14 07 02 AA AA 
+27,740 Rx 0x16F7F073 10 46 C9 03 14 07 00 02  
+27,746 Tx 0x16F773F0 30 0F 05 AA AA AA AA AA  
+27,755 Rx 0x16F7F073 21 07 81 07 66 03 FA FB  
+27,765 Rx 0x16F7F073 22 32 14 FF FF FF FF FF  
+27,775 Rx 0x16F7F073 23 FF FF FF FF FF FF FF  

.....

Line 1 is my request with service ID 0xC8 (sent with Diagnostic Service.vi).

Line 2 is the first frame from the ECU, containing the service ID 0xC9. But ADCS just stops here, it does not send the flow control frame (line 3) to request the consecutive frames.

And as far as I understand, "data out" from Diagnostic Service does not help, because the data just has not been requested/transmitted.

[flowschi]

Sorry, there is a mistake in the CAN Trace from the above post.

It looks like that:

+27,732 Tx 0x16F773F0 05 C8 00 14 07 02 AA AA 
+27,740 Rx 0x16F7F073 10 46 C9 03 14 07 00 02  
+27,746 Tx 0x16FA73F0 30 0F 05 AA AA AA AA AA  
+27,755 Rx 0x16F7F073 21 07 81 07 66 03 FA FB  
+27,765 Rx 0x16F7F073 22 32 14 FF FF FF FF FF  
+27,775 Rx 0x16F7F073 23 FF FF FF FF FF FF FF  

.....

The flow control frame (3rd line) has another arbitration ID.

I guess this is the problem or even another one. The ECU requires the flow control frames on other arbitration IDs. I am afraid that I can't meet these requirements with ADCS?

[Gucky]

I'm sorry but ADCS can't send the flow control frame on other ID.

[CGfromG]

Your CAN ID does not seem to follow the format defined in the ISO Norm for ISO TP.

There the 29 bit CAN ID consists of more than just source and target address. The source address and target address are located in the last 2 bytes of the ID, these look fine in the working request as well as in the expected flow control frame. However, the rest of the IDs look strange:

This is what the ID according to ISO TP consists of:

Priority (3 bits) | Reserved Bit (1 bit) | Data Page (1 bit) | PDU format (1 byte) | PDU specific (1 byte) | Source address (1 byte) | Target address (1 byte)

The reserved bit has to be 0 according to ISO TP, in your ID it is set to 1. It is vice versa with Data Page. PDU format in your ID is F7/FA, which both are not allowed for ISO TP. It should be e.g. DA for physical addressing.

Is this the only CAN ID that you can use to communicate with the ECU? Maybe if you use a ISO TP compliant ID, it might communicate in an ISO TP compliant manner.