ndOpenDiagnosticOnCANFD

Automotive Diagnostic Command Set Toolkit Help

Edition Date: November 2018

Part Number: 372140J-01

»View Product Info
Download Help (Windows Only)

Purpose

Opens a diagnostic session on a CAN or CAN FD port. Communication to the ECU is not yet started.

Format

long ndOpenDiagnosticOnCANFD(
       char CANInterface[],
       unsigned long long baudrate,
       unsigned long long FDbaudrate,
       unsigned short ioMode,
       unsigned short transportProtocol,
       unsigned short maxDLC,
       unsigned long transmitID,
       unsigned long receiveID,
       TD1 *diagRefOut);

Input

CANInterface

Specifies the CAN interface on which the diagnostic communication should take place.

NI-CAN

The CAN interface is the name of the NI-CAN Network Interface Object to configure. This name uses the syntax CANx, where x is a decimal number starting at 0 that indicates the CAN network interface (CAN0, CAN1, up to CAN63). CAN network interface names are associated with physical CAN ports using Measurement and Automation Explorer (MAX).

NI-XNET

By default, the Automotive Diagnostic Command Set uses NI-CAN for CAN communication. This means you must define an NI-CAN interface for your NI-XNET hardware (NI-CAN compatibility mode) to use your XNET hardware for CAN communication. However, to use your NI-XNET interface in the native NI-XNET mode (meaning it does not use the NI-XNET Compatibility Layer), you must define your interface under NI-XNET Devices in MAX and pass the NI-XNET interface name that the Automotive Diagnostic Command Set will use. To do this, add @nixnet to the protocol string (for example, CAN1@nixnet). The interface name is related to the NI-XNET hardware naming under Devices and Interfaces in MAX.

Note Note  By selecting nixnet as the interface string, the Automotive Diagnostic Command Set uses the Frame Input and Output Queued sessions. To force the use of Frame Input and Output Stream sessions instead, select ni_genie_nixnet as the interface string (for example, CAN1@ni_genie_nixnet). An application instance can use only one Frame Input Stream Session and one Frame Output Stream Session at a time, so use the default name nixnet as the interface string, so that multiple NI-XNET Frame Queued Sessions can coexist on a single interface, and the Frame Input and Output Stream Sessions may be used, for example, for a Frame logging/replay use case.

CompactRIO or R Series

If using CompactRIO or R Series hardware, you must provide a bitfile that handles the CAN communication between the host system and FPGA. To access the CAN module on the FPGA, you must specify the bitfile name after the @ (for example, CAN1@MyBitfile.lvbitx). To specify a special RIO target, you can specify that target by its name followed by the bitfile name (for example, CAN1@RIO1,MyBitfile.lvbitx). RIO1 defines the RIO target name as defined in your LabVIEW Project definition. The lvbitx filename represents the filename and location of the bitfile on the host if using RIO or on a CompactRIO target. This implies that you must download the bitfile to the CompactRIO target before you can run your application. You may specify an absolute path or a path relative to the root of your target for the bitfile.

baudrate

The diagnostic communication baud rate. You can wire standard baud rates as well as custom 64-bit baud rates to this control. For more information on 64-bit nonstandard baud rates, refer to the NI-XNET Hardware and Software Help. You can use the NI-XNET Bus Monitor and NI-XNET Database Editor utilities to create a custom baud rate. Refer to NI-XNET Tools and Utilities Help and NI-XNET Hardware and Software Help for more information about creating a custom baud rate.

FDbaudrate

The diagnostic communication CAN FD baud rate for use with the CAN FD+BRS ioMode. You can wire standard FD baud rates as well as custom 64-bit baud rates to this control. For more information on 64-bit nonstandard FD baud rates, refer to the NI-XNET Hardware and Software Help. You can use the NI-XNET Bus Monitor and NI-XNET Database Editor utilities to create a custom FD baud rate. Refer to NI-XNET Tools and Utilities Help and NI-XNET Hardware and Software Help for more information about creating a custom FD baud rate.

ioMode

The CAN I/O mode used for diagnostic communication. Choices are:

0CAN 2.0The classical CAN 2.0 8-byte frames will be used.
1CAN FDCAN FD frames with up to 64 bytes will be used.
2CAN FD+BRSCAN FD frames with up to 64 bytes will be used; in addition, the data and checksum bytes will be transferred at a higher baud rate to improve performance.
3ECU DeterminedThe IO Mode that is actually used is determined from the first response of the ECU. The first request to the ECU is sent in CAN 2.0 mode; if the ECU responds in any mode, this mode is selected for further communication. If the ECU does not respond (timeout), ADCS retries the request in the other modes. If none succeeds, the timeout error is returned to the user.

After the communication has started, the IO Mode that is actually used can be determined from reading the Actual CAN IO Mode property.

Note Note  The CAN FD features are only supported with NI-XNET version 17.0.1 or later.

transportProtocol

Specifies the transport protocol for transferring the diagnostic service messages over the CAN network. The following values are valid:

0 ISO TP—Normal Mode. The ISO TP as specified in ISO 15765-2 is used; all eight data bytes of the CAN messages are used for data transfer.
1 ISO TP—Mixed Mode. The ISO TP as specified in ISO 15765-2 is used; the first data byte is used as address extension.
2 VW TP 2.0.

maxDLC

The maximum CAN frame length to be used in CAN FD diagnostic communication. Allowed values are 8, 12, 16, 20, 24, 32, 48, and 64. For an ioMode of CAN 2.0, this setting is ignored and a value of 8 is used. For the CAN FD settings of the ioMode, this limits the frame size for transmission of diagnostic requests. The receive data length is determined from the incoming messages and not limited by this value.

transmitID

The CAN identifier for sending diagnostic request messages from the host to the ECU.

receiveID

The CAN identifier for sending diagnostic response messages from the ECU to the host.

Output

diagRefOut

A struct containing all necessary information about the diagnostic session. This is passed as a handle to all subsequent diagnostic functions, and you must close it using ndCloseDiagnostic.

Return Value

The return value indicates the function call status as a signed 32-bit integer. Zero means the function executed successfully. A negative value specifies an error, which means the function did not perform the expected behavior. A positive value specifies a warning, which means the function performed as expected, but a condition arose that may require attention.

Use the ndStatusToString function to obtain a descriptive string for the return value.

Description

ndOpenDiagnosticOnCANFD opens a diagnostic communication channel to an ECU. This function initializes the CAN port specified as input and stores a handle to it (among other internal data) into diagRefOut, which serves as reference for further diagnostic functions.

No communication to the ECU takes place at this point. To open a diagnostic session on the ECU, call ndStartDiagnosticSession or ndUDSDiagnosticSessionControl.

In general, you do not need to manipulate the diagRefOut struct contents, except if you use the ISO TP—Mixed Mode transport protocol, in which case you must store the address extensions for transmit and receive in the appropriate members of that struct.

Possible examples of selections for the interface parameter for the various hardware targets are as follows.

Using NI-CAN hardware:

  • CAN0—uses CAN interface 0.
  • CAN1—uses CAN interface 1 and so on with the form CANx.
  • CAN256—uses virtual NI-CAN interface 256.

Using NI-XNET hardware with NI-XNET Frame Input/Output-based sessions:

  • CAN1@nixnet—uses CAN interface 1 of an NI-XNET device.
  • CAN2@nixnet—uses CAN interface 2 of an NI-XNET device and so on with the form CANx.

Using NI-XNET hardware with NI-XNET Stream Input/Output-based sessions:

  • CAN1@ni_genie_nixnet—uses CAN interface 1 of an NI-XNET device.
  • CAN2@ni_genie_nixnet—uses CAN interface 2 of an NI-XNET device and so on with the form CANx.

Using R Series:

  • CAN1@RIO1, c:\temp\MyFpgaBitfile.lvbitx—uses a named target RIO1 as compiled into the bitfile at location c:\temp\MyFpgaBitfile.lvbitx.

Using CompactRIO

  • CAN1@/MyFpgaBitfile.lvbitx—uses compiled bitfile MyFpgaBitfile.lvbitx, which must be FTP copied to the root of the CompactRIO target.

WAS THIS ARTICLE HELPFUL?

Not Helpful