06-19-2013 02:36 PM
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.
06-19-2013 03:02 PM
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.
06-20-2013 05:53 AM
Cross posted this to the Idea Exchange as a suggestion for product improvement here: