| Contents | Index |
| On this page… |
|---|
The xPC Target block library offers support to connect a target computer to a CAN network using the CAN driver blocks provided by the xPC Target I/O CAN block library. This support is for I/O device drivers for the CAN-AC2-ISA and CAN-AC2-PCI boards from Softing® GmbH (Germany). The CAN driver library allows xPC Target applications to connect to any CAN field bus network for I/O communication or real-time target-to-target communication.
These drivers support CAN specifications 2.0A and 2.0B and use the dynamic object mode of the CAN-AC2 firmware to achieve maximum real-time performance.
The xPC Target CAN library intentionally restricts its support to Softing boards with two CAN ports. To test the PCI and PC/104 boards, see the xpcdemos folder for simple loopback test models. Type the following commands to open the corresponding models. Some models use CAN_MESSAGE data types, some use double data types. Models that use double data types are considered legacy demos.
| CAN-AC2-PCI Demo | CAN-AC2-104 Demo | Description |
|---|---|---|
CAN I/O - Simple Use Case — CAN_MESSAGE data type CAN I/O - Simple Use Case — Double data type | CAN I/O - Simple Use Case — CAN_MESSAGE data type CAN I/O - Simple Use Case — Double data type | Demonstrates simple CAN I/O communication. |
CAN I/O - Message-Based Interrupts — CAN_MESSAGE data type CAN I/O - Message-Based Interrupts — Double data type | CAN I/O - Message-Based Interrupts — CAN_MESSAGE data type CAN I/O - Message-Based Interrupts — Double data type | Demonstrates asynchronous message-based event support using interrupt driven CAN I/O communication. |
The size of the driver code of the CAN boards supported by the xPC Target block library is significant, and because not all xPC Target applications will use CAN, the CAN library code is not linked by default when building a target application. This non-linking makes target applications smaller if no CAN communication functionality is needed. If the model to be built contains CAN driver blocks, xPC Target links in the appropriate CAN library code when necessary.
For each CAN board three driver blocks are provided:
A setup block, which defines the type of physical connection (baud rate and so forth). Exactly one instance of the setup block must be defined in a model for each physically installed CAN board.
A send block, which transmits (sends) the data entering the block's input ports to the connected CAN network. One or more instances of the Send block can be used in a model.
A receive block, which retrieves (reads) CAN messages received by the board and outputs the data at the corresponding output ports. One or more instances of the Receive block can be used in a model.
All drivers for the supported CAN boards program the boards for the so-called dynamic object mode. This is one of three modes the CAN board firmware from Softing can operate in. For a more detailed discussion of the three modes see the board's user manual. Dynamic object mode is best suited for real-time environments where each component of the application must have deterministic time behavior. This is the case for the xPC Target product, and that is the main reason why this mode has been chosen over the other two modes, which are FIFO and static object mode. In this mode, you use a separate port for each ID that you are sending or receiving. The blocks for these boards send messages in priority order, from the lowest ID to the highest.
The xPC Target CAN blocks support the following message data types. If you have Softing ISA CAN boards, you can use only the double data type for messages. If you have Softing PCI and PC/104 CAN boards, you can use either CAN_MESSAGE or double data types data types for new messages.
CAN_MESSAGE — Structure that contains an array of eight unsigned 8-bit integers that contains the data. This array also contains the ID, and the standard and extended ID range. CAN blocks can pass data of this type without having to manipulate it, enabling you to create simpler models. Use messages of this data type for new CAN application models. Consider updating existing CAN application models to use CAN_MESSAGE data types.
CAN_MESSAGE — Use CAN Pack blocks to pack individual signals into a CAN message for sending. Use CAN Unpack blocks to unpack individual signals from CAN messages,
You can construct a CAN_MESSAGE by using the CAN Pack. You can use this block to pass raw data packed elsewhere, by packing a data pattern manually. You can also use a CANDB file and select a predefined data pattern.
Double — Double that represents 8 bytes of message in a signal. CAN blocks manipulate data of this type before passing it. Do not use this data type to create new CAN application models. The maximum size of the data frame of a CAN message is 8 bytes. This size is the same as the C data type double uses on PC-compatible systems. At the same time, the double data type is the default data type for Simulink signals. Represent the CAN data frame within a Simulink model with a scalar Simulink signal. You can represent the data frame even if the data frame has nothing in common with a double floating-point value. The xPC Target CAN library provides a Utility sublibrary that offers bit-packing and bit-unpacking blocks. Use these blocks to pack data types other than doubles into 64 bits (8 bytes or a double) as well as for the opposite operation. Simulink signals of data type double represent CAN data frames.
If you have Softing PCI and PC/104 CAN boards, you can update existing models to use CAN_MESSAGE data types. As a rule:
If your existing models contain CAN Bit-Packing and CAN Bit-Unpacking blocks, replace them with the CAN Pack and CAN Unpack blocks.
Open and reconfigure the CAN Send and Receive blocks to use CAN_MESSAGE data types.
Remove Object Mode CAN Message and CANDBC Translator blocks. Updated models no longer require the conversions that these blocks perform.
See the CAN Blocks Transition document for more information.
Ordinarily a subsystem sends its value over the CAN bus according to its own schedule, and another subsystem stores that value for use whenever downstream processing requires it. Under some circumstances, a subsystem explicitly requests the current value from another subsystem. This is called sending a remote frame.
To prepare a remote frame, use the CAN Pack block with the Remote frame check box selected. To request the current value, send the remote frame to the responding subsystem.
To process a remote frame, use the CAN Unpack block with the Output remote check box selected to enable the Remote port. When the Remote port becomes True, send the current value to the requesting subsystem.
The library supports the following CAN boards from Softing GmbH, Germany.
Board Name | Form Factor | Identifier Range | Multiple Board Support |
|---|---|---|---|
CAN-AC2 | ISA | Standard & Extended with piggyback module | No |
CAN-AC2-PCI | PCI | Standard & Extended | Yes (up to 3) |
CAN-AC2-104 | PC/104 | Standard & Extended | Yes (up to 3) |
For more information on the board specifications, visit http://www.softing.com.
CAN-AC2
CAN board for the ISA bus offering two high-speed CAN ports. In its standard hardware configuration, it uses the Philips PCA 82C200 CAN controller, which supports standard identifiers only. Piggyback modules are available (one for each port) that replace the Philips CAN controllers with Intel® 82527 CAN controllers. The Intel controllers support both standard and extended identifiers. The board is a memory-mapped device and uses a 16 KB address range between 640 KB and 1 MB. MathWorks does not recommend this board for new projects; use the CAN-AC2-PCI instead. Softing plans no new firmware versions for this board.
CAN-AC2-PCI
CAN board for the PCI bus offering two CAN ports. The CAN controllers on the board are the SJA1000 from Philips. In its standard hardware configuration, the board is designed for both standard and extended identifiers for high-speed CAN. Piggyback modules are available (one for each port) that add low-speed CAN support to switch between high-speed and low-speed CAN. The board is a memory-mapped PCI device that uses 64 KB of address space. The address space is assigned automatically by the PCI BIOS of the target computer and lies usually in the range between 2 GB and 4 GB. Any new projects using a desktop PC as the target system should use this board and not the ISA board.
CAN-AC2-104
CAN board for the PC/104 bus offering two CAN ports. The CAN controllers on the board are the SJA1000 from Philips. The board offers both standard and extended identifiers for high-speed CAN. A low-speed CAN hardware extension is not available. The board is both I/O mapped and memory mapped. The I/O-mapped area uses a 3 KB address range and the memory-mapped area uses a 4 KB address range between 640 KB and 1 MB.
![]() | CAN I/O Support | Model Execution Driven by CAN Messages (Interrupt Capability of CAN Receive Blocks) | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |