Diagnostic Service.vi reports timeout when CAN-FD+BRS with extended FrameID is implemented

[daveli03]

When I try to execute UDS diagnosis, Diagnostic Service.vi is applied.

The tested ECU(incl. HW & SW) has been verified correctly in the vehicle.

1) when using normal frame ID, this VI works well, diagnostic signal can be transmitted and received quickly (within ~100ms);

2) when extended frame ID (CAN FD is used) is implemented, this VI becomes quite slowly (under continuously running, it could cost more than 1 sec to finish one transmit & receive), and then timeout error will be reported. Sometimes error report will disappear.

Related configuration has been implemented under the instruction of help document. 

To verify whether signal has been sent correctly, BusMonitor (xnet service) or BusMaster is used to monitor CAN BUS, finding that the transmitted signal can be obtained, as well as the feedback signal sent from ECU.

My questions are:

1) why it could become some slowly when extended frame ID is used?

2) if it's not the correct VI, which I should choose to implement UDS diag  service for extended frame ID under CAN-FD is used?

ps. I was originally asking this  question in the "Labview Board" as URL below:

https://forums.ni.com/t5/LabVIEW/Diagnostic-Service-vi-reports-timeout-when-CAN-FD-BRS-with/m-p/3974...

[kayfh]

Hi,

a few general things first:

The ADCS help says this on extended IDs (on the page of "Open Diagnostic on CAN FD.vi"):

transmit ID is the CAN identifier for sending diagnostic request messages from the host to the ECU. To specify an extended (29-bit) ID, OR the value with 0x20000000.

receive ID is the CAN identifier or sending diagnostic response messages from the ECU to the host. To specify an extended (29-bit) ID, OR the value with 0x20000000.

Have you OR'ed the IDs with the value stated to enable extended ID?

Another point is CAN FD, are the baud rates correctly set? CAN FD is known to be quite touchy to settings like the sample point. You can generate custom hex baud rates using e.g. the assistant in the NI-XNET Bus Monitor or Database Editor and pass these values into "Open Diagnostic on CAN FD". Also, is the bus properly terminated, e.g. by enabling the termination property?

Kay

[daveli03]

Hi Kay,

Thanks for your help.

1) The extended ID (29-bit) has been OR'ed before inputting, that's why it works every circa 1 sec, i.e., the error report will be toggling every second.

2) CAN FD band rates is also set correctly, matching with what has been stated in A2L: 2MBps.

By the way, where to set "enabling bus termination in this .vi"?  the tested ECU has the completely correct functionality.

[kayfh]

Hi,

for CAN FD there are more settings than just the numeric baud rate values greatly impacting communication, mainly the sample points. It is important that these settings match for all nodes on the network like the ECU, or data transmission errors might happen. Is there a SAMPLE_POINT set in the A2L?

You could also try displaying "Bus Error Frames" (in Interface and Database Settings dialog) in the XNET Bus Monitor, if errors are reported something is wrong with the communication settings.

To enable CAN Termination, use ADCS' "Diag Set Property" VI with "property ID"=Termination and value 1, or use an external hardware termination.

Kay

[daveli03]

hi Kay,

Thanks for your help.

Now it works well. Exactly sampling points will significantly impact the communication. Using SAMPLE_POINT value(80%) defined in A2L, we transform 2MBps baudrate into a hexadecimal value in "custom baudrate", and then set this value as the input of diag.vi, then it works well.

what's more, in my case, CAN Termination is not necessary as it has already been existed in ECU (120ohm resistor)

Dave.

[kayfh · Accepted solution]

Hi,

glad to know that the problem is fixed! Please be sure to apply the sample point also for the standard baud rate.

You can find more information on CAN FD sample points with NI-XNET here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7mDSAS

By the way, proper CAN termination requires two 120 Ohms terminations, one at each end of the main bus, though one terminated side can be good enough if the bus is small and the data rate is not too high. If the ECU is terminating with 120 Ohms and no other device is on the bus, it's optimal to also turn on termination in the tester.

Kay