Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Use Frame Sessions for Automotive Diagnostic Command Set (ADCS) on XNET hardware

I have an application that uses XNET hardware to communicate with my device under test (DUT). (using XNET 1.7)

Within this application, I communicate over the XNET CAN interface using a few different tools:

XNET Frame In Queued Sessions

XNET Frame Out Queued Sessions

XNET Signal In Sessions

XNET Signal Out Sessions

ECU Measurement and Calibration toolkit 2.3.0f4 (XCP read characteristics and measurements)

Automotive Diagnostic Command Set 1.1.1f2 (UDS protocol)

 

I would like to use a Frame In Stream Session to log all of the CAN traffic during a test execution, but I am unable to do so because the ECU M&C and ACDS toolkits use the XNET Frame In/Out Stream Sessions and I cannot create more than one of these sessions.

 

However, I recently discovered in the release notes for ECU M&C Toolkit 2.3, that the ECU M&C toolkit can now use Frame Queue Sessions instead, by using the "@nixnet" suffix instead of the "@ni_genie_nixnet" suffix.

 

I tried this out, and it does indeed work as intended.

 

Can this concept be extended to the Automotive Diagnostic Command Set as well?

 

On a lark, I tried out the same concept (using the "@nixnet" suffix instead of the "@ni_genie_nixnet" suffix) with the ADCS toolkit and it seems to sort of work, but with some bugginess.

For example, if I start the UDS session using "CAN1@nixnet" and then start my Frame In Stream sessions, everything seems to work normally.  However, if I were to close the UDS session, the XNET Frame In Stream Session stops receiving any new frames, even though the DUT on the bus is still transmitting.

 

Perhaps this is why this feature is not supported by ADCS (at least I can't find it in the documentation).  I'd love to hear if NI is working on this sort of improvement for the ADCS toolkit and publicly voice my desire for it.

0 Kudos
Message 1 of 3
(7,268 Views)

I just realized that the behavior that I described in my second-to-last paragraph resembles the behavior of ":subordinate:" mode for Frame In Stream Sessions (see page 122 of the XNET HW/SW Manual).

 

Put another way, it seem as if closing the UDS session is actually stopping the whole interface, which prevents any other running sessions from receiving new CAN frames.

0 Kudos
Message 2 of 3
(7,265 Views)

Cross posted this to the Idea Exchange as a suggestion for product improvement here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Use-Frame-Sessions-for-Automotive-Diagnostic-Command-S...

0 Kudos
Message 3 of 3
(7,251 Views)