AIDA CAN Component

The CAN component is a hardware driver component.

CAN FD is supported since Stack version 7.00.005 in the Windows Vector XL API library version only. Configurations supporting CAN FD have several additional parameters, the parameter FDEnable should be set first.

The Windows version of the CAN component exists in several versions using either the Vector CanLib library (vcand), versions of the Vector XL driver API libraries (vxlapi), the PEAK PCAN-Basic API library, or CanEasy Vector hardware abstraction layer library to access the CAN hardware, so you will need to install appropriate drivers before the CAN component is functional.
The CAN component supports all hardware accessible through the Vector CanLib library (vcand) (currently this includes the CANcardX, CANcardXL, CANcardY, CANpari (only driver version 2.x), CAN-AC2 ISA and CAN-AC2 PCI), the Vector XL API libraries, the PEAK PCAN-Basic API library, or the CanEasy Vector hardware abstraction layer library. Stack versions up to 7.00.004 used the PEAK PCAN-Light API library (support of just the SJA1000 Parallel Port Dongle and the PEAK USB Dongle).

Most of the parameters are named in accordance to the Vector CanLib documentation. For any unknown/undescribed terms please refer to the Vector CanLib documentation.

The Windows CE version is currently only available with support for the Vector CanLib library (vcand).

The Linux version of the CAN component is currently available for the Janz megaBOX and for hardware supported by the OCAN driver.

Remarks

Version for Vector hardware (vcand)

Through the different versions of the CanLib library the order of the channels (virtual/physical) has changed from time to time and may depend on the operating system (for 2.x the bits 0 and 1 normally represented virtual channels while physical channels started at bit 2). To avoid confusion the actual order is remapped by the CAN component internally so that the virtual channels are always located on bit 0 and 1 of the ChannelMask. All physical channels are on bit 2 and above. If more than one piece of CAN hardware is installed (e. g. a CANcardX and a CANcardY) you can find out which bit corresponds to which hardware by loading the CAN component and opening one single channel at a time (ChannelMask 1, 2, 4 etc.), then check the Vector CAN control panel which channel had actually been connected to the CAN component (the application name is "AIDA").

If you did not install the component with the AIDA setup utility take care that the appropriate programming library (VCanD32.DLL) is installed before trying to use the component. The CanLib setup does not install the CanLib library in the system or any application folder. After successful installation you will find the VCanD32.DLL needed by the CAN component in the folder <Installpath>\CanLib\DLL (where <Installpath> is the path you selected during the installation procedure). You may either copy it to the system folder or to the folder where the CAN component is stored. In the latter case you may need to set a path to that folder.

Drivers and programming libraries below version 3.2 are known to have stability problems. Early v3.x programming libraries may crash the operating system when selecting non existing ports or opening a port on a busy CAN bus, drivers below v3.0 may disturb the communication on the CAN bus. Programming libraries of v3.0 and above shall be downward compatible with v2.x drivers but mixing v2.x and v3.x drivers is not supported.

The Vector drivers support two independent sets of acceptance filters. The CAN driver now unifies the two filters within one setting, so bit 31 of the AcceptanceCode and AcceptanceMask parameters is simply treated like any regular identifier bit. To receive only extended id messages AcceptanceCode must be set to 0x8??????? or 0x9???????, to receive standard id messages AcceptanceCode must be set to 0x00000??? while bit 31 of the AcceptanceCode parameter must be set to 1. To receive both types of messages bit 31 of AcceptanceCode must be set to 0.

The Vector Windows CE programming library currently does not support sharing of a CAN port between applications like the Windows version does. So a given CAN port should not be opened by more than one application or AIDA stack at a time.

The drivers for some CAN hardware (CAN-AC2 PCI, CANcard XL) behaves somewhat strange in case of CAN errors. When errors happen the CAN messages delivered by the driver are not fully initialized which caused the CAN component to generate events with sometimes hundreds of bytes of data. When no other CAN equipment is online so that the CAN cell will not receive acknowledges the CAN cell will do endless retries. With the above mentioned hardware these retries are detected as error frames by the driver and will flood the AIDA stack up to approx. 10000 events/s. As of version 1.3.13.3 (prerelease) the CAN component corrects badly initialized CAN message members and will deliver empty receive data events with no data embedded. The source ID will also be invalidated in these cases. Nevertheless, there's not much the CAN component can do against the wrongly generated error frames in case that no other CAN cell acknowledges a transmission.

Except for remapping the virtual channels the CAN component does not check for specific hardware. So the CAN component for Vector hardware will automatically support new hardware without further modifications of the component and will also support certain non-Vector hardware for which drivers or programming libraries are available. Note that when an alternative programming library is used it may impossible to use Vector hardware and non-Vector hardware at the same time. The potentially supported hardware is:

KVASER products
KVASER delivers a Vector compatible programming library. If it is installed the CAN component should work. At the time of writing no tests have been done so that the functionality cannot be guaranteed.
Softing products
Early Vector developments are based on Softing products or were developed together with Softing. Known products are:
- CAN-AC2 PCI
  In case of the CAN-AC2 PCI board there are two installation options: Either the original Softing driver is installed. In this case Vector uses a wrapper so that Softing and Vector applications both are supported. If no Softing driver is installed the Vector driver downloads its own firmware and the card is supported natively.
- CANcard2/EDICcard2
  The EDICcard2 from Softing seems to have a common hardware base with the CANcard2. To use the EDICcard2 together with the CAN component first install the Vector driver package. It may be necessary to manually install the Softing driver after installing the Vector driver.

Version for Vector hardware (vxlapi)

In order to support newer CAN hardware and to be compatible with Windows 7 and higher, there exists also CAN components based on the Vector XL API libraries (introduced with Stack version 7.00.001). This is the recommend component version to use with Vector hardware. As support for some older CAN hardware was discontinued in newer versions of this API, there is a CAN component (using the 7.5.10 version of the vxlapi.dll) which you might try (e.g. for use with CanCardX).

Version for PEAK hardware

PEAK delivers a somewhat limited version of their development environment. The restrictions are as follows:

Only one piece of a given type of hardware (LPT/USB) may be installed at a time, so you may not install more than one LPT or USB dongle at once.
There cannot be created/loaded more than one AIDA stack accessing the given hardware at the same time.
The base address and interrupt of the LPT dongle cannot automatically be detected. For this reason the base address and interrupt are hardcoded to 0x378/7.
The PEAK drivers and libraries do not support the concept of virtual channels, so the only valid values for the ChannelMask parameter are 0 (port closed) and 4 (port open).
Applicable when using versions based on the PCAN-Light API libray: When an AIDA application crashes the CAN hardware will be locked by the PEAK libraries until the next reboot. The PEAK application "PCAN Light Smasher" can be used to free the CAN hardware locked by such a crash.

Due to the licensing policy of PEAK BSK does not offer a version using the fully functional libraries by now.

Linux version for Janz megaBOX

The Janz megaBOX differs in some ways from other Janz hardware. So the following limitations apply:

Janz uses a special programming interface for the megaBOX. So the megaBOX version of the CAN component is not compatible with other Janz hardware.
The CAN port may be opened only by one application at a time. Trying to open the CAN port twice may crash the driver.
Trying to open non existing CAN ports may crash the driver.

Linux version for the OCAN driver

The OCAN driver maintained by Alessandro Rubini supports various hardware based on the Intel 82527 CAN controller. Due to architectural limitations of the 82527 controller and of the OCAN driver the following restrictions apply:

The acceptance filter can be set to either standard or extended messages. It is not possible to receive both types. The decision for either extended or standard identifiers is based on bit 31 of the parameter AcceptanceCode.
Access to a CAN port is exclusive, every port may be opened only by one application at a time. Port sharing is not possible at this time.
In the ChannelMask parameter only one bit may be set. If setting more than one bit the lowest one is used.
Remote frames are not supported by the OCAN driver, so the CAN component for OCAN responds with a send error when trying to send remote frames.

Parameters

ChannelMask

Specifies the channel(s) to be used. Please note that bit 0 and 1 represent virtual channels (see section remarks above) if these are supported. Physical channels are always located on bit 2 and above. For portable AIDA stack configurations you should use an environment variable for this parameter. The value list of this parameter is generated upon component initialisation and represents actually available channels.

FDEnable

Parameter to switch on CAN FD functionality. A value of 0 represents CAN Mode, a value of 1 represents CAN FD Mode.
Note: This parameter is only available in variants able to handle CAN FD. In order to not disturb non CAN FD configurations, it is only saved in the stack configurations, if it is different from 0.
As the handling of some parameters is different for CAN 2.0 and CAN FD this parameter setting should be done before setting other parameters. For CAN FD enabled configurations, all Bitrate parameters and bit timing parameters Bitrate, sjw, tseg1, tseg2, sam, BitrateData, sjwDbr, tseg1Dbr, tseg2Dbr need to be set before switching the stack online.
CAN FD enabled configurations are able to receive messages in CAN 2.0 and CAN FD format. The format to be used to send a message is determined by the parameter MessageFlags.

Bitrate

The bitrate to be used for the selected channels in [bits/s]. This only affects channels the component has initialization access for (as shown by the PermissionMask parameter). For some CAN hardware there are limitations concerning the selectable bitrates. Please consult the manual of your CAN hardware for further details about limitations.
Note: For CAN FD this parameter relates to the arbitration phase. Sometimes it is referred as nominal bit rate.

AcceptanceCode, AcceptanceMask

Settings of the acceptance filter (bit 31==1: use 29 bit identifier). Messages are accepted when (<Source ID> XOR AcceptanceCode) AND AcceptanceMask == 0 (see Vector CanLib documentation for details).

SendID

The message identifier to be used in transmit data events (bit 31==1: use 29 bit identifier). SendID can be overridden by setting bFlags in the event structure to AIDA_nSrcIDValid and setting up stSrcID .

MessageFlags

Contains a default value for special CAN flags to be set in transmit data events (see header file bsk_aida_can.h or Vector CanLib documentation for details). A valid AIDA_bDataFlags member in a transmit data event takes precedence over the value of this parameter.
For a quick reference, the meaning of the flags used in the component are listed here:

`0x01`	`CAN_nMSGFLAG_ERROR_FRAME`	Msg is a bus error
`0x02`	`CAN_nMSGFLAG_OVERRUN`	Msgs following this has been lost
`0x04`	`CAN_nMSGFLAG_NERR`	NERR active during this msg
`0x08`	`CAN_nMSGFLAG_WAKEUP`	Msg rcv'd in wakeup mode
`0x10`	`CAN_nMSGFLAG_REMOTE_FRAME`	Msg is a remote frame
`0x20`	`CAN_nMSGFLAG_RESERVED_1`	Reserved for future usage
`0x40`	`CAN_nMSGFLAG_TX`	TX acknowledge
`0x80`	`CAN_nMSGFLAG_TXRQ`	TX request

additionally for CAN FD following further definitions are used:

`0x20`	`CAN_nMSGFLAG_FDF`	FDF, FD Format Indicator, also referred as EDL in Bosch spec
`0x08`	`CAN_nMSGFLAG_BRS`	BRS, Bit Rate Switch
`0x04`	`CAN_nMSGFLAG_ESI`	ESI, Error State Indicator received

(BRS, ESI occur only together with FDF flag)
Examples with FDEnable set to 1:

`0x00`	`no bit set`	A message flag 0x00 stands for a message in CAN 2.0 format.
`0x20`	`CAN_nMSGFLAG_FDF`	A message flag 0x20 stands for a message in CAN FD format with no bitrate switch.
`0x28`	`CAN_nMSGFLAG_FDF` `CAN_nMSGFLAG_BRS`	A message flag 0x28 stands for a message in CAN FD format with bitrate switch.
`0x2C`	`CAN_nMSGFLAG_FDF` `CAN_nMSGFLAG_BRS` `CAN_nMSGFLAG_ESI`	A message flag 0x2C stands for a message in CAN FD format with bitrate switch and ESI bit set. Only in received messages.

With these different flag settings it is possible to test the reaction of CAN FD enabled counterparts on CAN 2.0 messages (up to 8 byte data) and on CANFD messages with or without bit rate switch.
Note: For practical reasons if FDEnable is set to 1, messages to be sent longer than 8 bytes and without the CAN_nMSGFLAG_FDF flag set, will automatically get the CAN_nMSGFLAG_FDF and CAN_nMSGFLAG_BRS flags set.

sjw, tseg1, tseg2, sam

These parameters specify the CAN bit timing. For more information about the bit timing of the CAN controller please refer to some of the CAN literature or CAN controller data sheets. When all these parameters are set to 0 the default values of the CAN hardware driver are used.
Note: For CAN FD these parameters relate to the arbitration phase. For CAN FD configurations sam has to be set to 1.

PermissionMask

This parameter shows which of the channels selected by ChannelMask the CAN component has initialization access to.

Transceiver, LineMode, ResNet

These parameters are specific for CAN boards from Vector Informatik and are directly passed to the Vector library call ncdSetTransceiver when being changed. The value 0 has a special meaning: It stands for "no change". The value "no change" also sets the dynamic flags of these parameters so that they are not being saved in a stack configuration. So to be compatible with other CAN hardware these parameters must not be changed from their default values if not necessary.

SilentMode

This parameter is specific for CAN boards from Vector Informatik and controls the generation of acknowledges on the CAN bus. Normally every node connected to the bus will slightly influence the CAN activities by the generation of ACK signals. For diagnostic purposes Vector has added hardware to optionally suppress these ACK signals. When SilentMode is set to 1 no ACK signals will be generated. In standard mode when this parameter is set to 0 it will not be saved in stack configurations. So to be compatible with other CAN hardware this parameter must not be changed from its default value if not necessary.
This parameter is new in V1.2.0 of the Vector CAN component.

BitrateData

For CAN FD the bitrate to be used for the selected channels in [bits/s] during the dataphase. This only affects channels the component has initialization access for (as shown by the PermissionMask parameter). For some CAN hardware there are limitations concerning the selectable bitrates. Please consult the manual of your CAN hardware for further details about limitations.
Note: This parameter is only available in variants able to handle CAN FD. In order to not disturb non CAN FD configurations, it is only saved in the stack configurations, if it is different from 0.

sjwDbr, tseg1Dbr, tseg2Dbr

For CAN FD these parameters specify the bit timing during the data phase. For more information about the bit timing of the CAN controller please refer to some of the CAN literature or CAN controller data sheets.
Note: These parameters are only available in variants able to handle CAN FD. In order to not disturb non CAN FD configurations, they are only saved in the stack configurations, if they are different from 0.

BusState, TxErrors, RxErrors

These parameters currently are only available for the Vector CAN component. They represent the CAN controller state as delivered by the Vector programming library (see _VchipState structure in VCanD.h). When the stack is online these parameters are updated every 50ms.