MC ECU Select.vi

Purpose

Selects an ECU based upon the names stored in an A2L database.

Format

Input

	protocol and interface selects target communication protocol and the desired interface to use for this task. The Protocol and Interface input is required, as this parameter is not defined in the A2L database. The default baud rate for XCP or CCP on CAN, or the IP address for XCP on UDP/TCP, may be defined in the A2L database, but you can change it by setting the Interface Baud Rate or IP Address property with MC Set Property.vi. This parameter is expected to be a string with the format Protocol:Interface. Protocol supports: CCP to use the CAN Calibration Protocol XCP to use the XCP Universal Measurement and Calibration Protocol Interface selects the transport layer and hardware interface to employ: Ethernet Use UDP or TCP as Interface. Supported with XCP protocol only. NI-CAN Use CANx as Interface to select the corresponding NI-CAN interface. The special CAN interface values 256 and 257 refer to virtual interfaces. For more information about using virtual interfaces, refer to the Frame to Channel Conversion section of Chapter 6, Using The Channel API, in the NI-CAN Hardware and Software User Manual. NI-XNET Use CANx@nixnet as Interface to select the corresponding NI-XNET interface as configured under Devices and Interfaces in MAX. For using NI-XNET hardware on CompactRIO or R Series hardware, you may need to create an FPGA bit file to enable access to the modules. Refer to NI-XNET documentation for information about creating and loading a bit file; use the regular NI-XNET string format. Note  When you append @nixnet to the Protocol and Interface string, the ECU Measurement and Calibration Toolkit uses NI-XNET Queued sessions. To force the ECU Measurement and Calibration Toolkit to use Stream sessions instead, append @ni_genie_nixnet to the Protocol and Interface string (for example, CCP:CAN1@ni_genie_nixnet). NI 985x CAN modules Use CANx@BridgeBitFile.lvbitx as Interface. A bridge FPGA VI (found in the LabVIEW examples of ECU MC) must be compiled for the RIO target; BridgeBitFile.lvbitx represents the absolute file path of the resulting bit file. It will be downloaded to the FPGA automatically when opening the CAN interface. For Real-Time targets, the bit file must be transferred to the internal disk, and this local file path must be used. CANx refers to the name of the front panel controls used in the bridge FPGA VI (not to the module name in the LabVIEW project). Only a single 985x CAN interface is supported per FPGA target. Use CANx@RIOx,BridgeBitFile.lvbitx as Interface to also specify the RIO target. RIOx equals the RIO target name as defined in your LabVIEW Project definition.
	DB reference in is the task reference which links to the opened database file.
	ECU name is the ECU name to select out of a A2L Database file, with which to initialize all subsequent tasks.
	Error in is a cluster which describes error conditions occurring before the VI executes. If an error has already occurred, the VI returns the value of the error in cluster to error out. status is TRUE if an error occurred. This VI is not executed when status is TRUE. code is the error code number identifying an error. A value of 0 means success. A negative value means error: VI did not execute the intended operation. A positive value means warning: VI executed intended operation, but an informational warning is returned. For a description of the code, wire the error cluster to a LabVIEW error-handling VI, such as the Simple Error Handler. source identifies the VI where the error occurred.
	CAN interface specifies the CAN interface to use for this task. For compatibility reasons, if you are using the CCP protocol you can only specify the CAN interface to use for this CCP task. The interface input uses a ring typedef in which value 0 selects CAN0, value 1 selects CAN1, and so on. As the ECU M&C API is based on the NI-CAN Channel API, the NI-CAN Frame API cannot used on the same CAN network interface simultaneously. If the CAN network interface is already initialized in the Frame API, this function returns an error.

Output

ECU ref out is the task reference which links to the selected ECU.

Error out describes error conditions. If the Error in cluster indicated an error, the Error out cluster contains the same information. Otherwise, Error out describes the error status of this VI. status is TRUE if an error occurred. code is the error code number identifying an error. A value of 0 means success. A negative value means error: VI did not execute the intended operation. A positive value means warning: VI executed intended operation, but an informational warning is returned. For a description of the code, wire the error cluster to a LabVIEW error-handling VI, such as the Simple Error Handler. source identifies the VI where the error occurred.

Description

MC ECU Select.vi creates an ECU reference handle linked to the selected ECU name. MC ECU Select.vi does not start communication. This enables you to use MC Set Property.vi to change the properties of an ECU task. After you change properties, use MC ECU Connect.vi to start communication for the task and logically connect to the selected ECU. Prior to calling MC ECU Select.vi, an available ECU name can be queried by calling MC Get Property.vi with the parameter ECU/Name.

Possible selections for the interface and protocol parameter for the various hardware targets are as follows.

Using Ethernet:

• XCP:UDP—uses XCP on UDP
• XCP:TCP—uses XCP on TCP

Using NI-CAN hardware:

• CCP:CAN0—uses CCP on CAN interface 0
• CCP:CAN1—uses CCP on CAN interface 1, and so on with the form CANx
• CCP:CAN256—uses CCP on virtual CAN interface 256
• CCP:CAN257—uses CCP on virtual CAN interface 257
• XCP:CAN0—uses XCP on CAN interface 0
• XCP:CAN1—uses XCP on CAN interface 1, and so on with the form CANx

Using NI-XNET hardware with frame-based sessions:

• CCP:CAN1@nixnet—uses CCP on CAN interface 1
• CCP:CAN2@nixnet—uses CCP on CAN interface 2, and so on with the form CANx
• XCP:CAN1@nixnet—uses XCP on CAN interface 1
• XCP:CAN2@nixnet—uses XCP on CAN interface 2, and so on with the form CANx

Using NI-XNET hardware with stream-based sessions:

• CCP:CAN1@ni_genie_nixnet—uses CCP on CAN interface 1
• CCP:CAN2@ni_genie_nixnet—uses CCP on CAN interface 2, and so on with the form CANx
• XCP:CAN1@ni_genie_nixnet—uses XCP on CAN interface 1
• XCP:CAN2@ni_genie_nixnet—uses XCP on CAN interface 2, and so on with the form CANx

Using CompactRIO or R Series:

• CCP:CAN0@RIO1,c:\temp\MyFpgaBitfile.lvbitx—uses CCP on named target RIO1 as compiled into the bit file at c:\temp\MyFpgaBitfile.lvbitx
• XCP:CAN0@RIO1,c:\temp\MyFpgaBitfile.lvbitx—uses XCP on named target RIO1 as compiled into the bit file at c:\temp\MyFpgaBitfile.lvbitx
• CCP:CAN0@/MyFpgaBitfile.lvbitx—uses CCP on default RIO target as compiled into the bit file placed into the root directory of the RT target
• XCP:CAN0@/MyFpgaBitfile.lvbitx—uses XCP on default RIO target as compiled into the bit file placed into the root directory of the RT target