CANopen Blockset Eng

CANopen Master Blockset
Version 21.1
User Documentation
Project: CANopen Blockset
Version: 2.10
Status:
File: CANopen_Blockset_eng.doc
Created on: 03/31/2010
Last modified: 22/04/2021
No. of pages: 29
Copyright © 2013 dSPACE GmbH. All rights reserved.

CANopen Master Blockset - User Documentation
Contents
Contents ..................................................................................................................................................2
1 Functionality ........................................................................................................................................3
2 Preconditions .......................................................................................................................................4
2.1 Abbreviations ..................................................................................................................................4
2.2 Hardware Environment ...................................................................................................................4
2.3 Relevant Files .................................................................................................................................4
2.4 Distinction to ConfigurationDesk extension ....................................................................................5
3 Installation ............................................................................................................................................6
3.1 Folder Structure ..............................................................................................................................6
3.2 Simulink Library ..............................................................................................................................7
3.3 Demos .............................................................................................................................................7
3.3.1 Experiments ...........................................................................................................................7
4 Using the CANopen Master Blockset ................................................................................................8
5 CANopen GUI .......................................................................................................................................9

5.1 General Setup .................................................................................................................................9
5.2 Node Block ....................................................................................................................................10
5.3 Node XX ........................................................................................................................................11
5.4 Synch block ...................................................................................................................................15
6 Menu ...................................................................................................................................................16
7 Inputs and Outputs............................................................................................................................17

NMT Communication ....................................................................................................................18
7.1.2 SDO Communication ...........................................................................................................22
7.1.3 PDO Communication ...........................................................................................................26
Appendix A: Notes and Remarks ........................................................................................................29
Appendix B: List of Figures.................................................................................................................30
© dSPACE 2013 2 / 30
1 Functionality
The CANopen Master Blockset makes it possible to simulate a CANopen master according to com-
munication profile CiA DS301. It does not cover the whole communication profile. The following func-
tionalities are supported:
• Addressing up to 127 nodes

• Booting from 1 to 127 nodes according to the device profile described in the DS401 standard
• Generating the SYNC message
• Displaying the received EM (emergency) messages in the trace file
• Read and write access to the object dictionary of the CANopen slave via the assigned SDO
message. Only the standard ID is supported for this.
• Write access to the real-time data, via up to 4 PDOs each time. The standard IDs are support-
ed.
• Read access to the real-time data, via up to 512 PDOs each time. The standard IDs and cus-
tomer specific IDs are supported.
• Configuration file specifying the SDO messages to be sent after boot up.
© dSPACE 2013 3 / 30
2 Preconditions
2.1 Abbreviations
NMT Network Management

PDO Process Data Object
RxPDO Receive Process Data Object
TxPDO Transmit Process Data Object
SDO Service Data Object
CAN Controller Area Network
2.2 Hardware Environment

The CANopen Master Blockset supports exclusively dSPACE standard hardware. The platform must
match one of the following constellations:
IO-Board
DS2202 DS2210 DS2211 DS4302 DS4504/DS4342 stand-alone
Processor board
DS1006 x x x x x
DS1007 x x x x x
DS1401 (MABXII) x
DS1202 (MLBX) x
IO-Board
DS2680/DS2672 DS2671 DS6301 DS6341
Processor board
SCALEXIO RT-PC x x x x
For error-free CAN communication, the CAN bus should ideally be terminated with a 120-Ohm resistor
at each end of the communication line. The software-switchable termination resistor on the I/O board
can be activated via the "Termination resistance" parameter in the RTICANMM Setup Block on re-
quest.
2.3 Relevant Files

The CANopen Blockset mainly consists of the “CANopen General Setup” block. It can be copied into a
model from the library. After opening the GUI and configuring the desired nodes, two S-Functions and
one configuration file will be generated automatically:
• CANopen_Synch_Master_<ControllerName>.c (Simulink block Sync_Master)

• <ControllerName>_Knoten_x.c (Simulink block Node: #)
• Config_<ControllerName>_NODE_x.h
Each node has its own configuration page in the user interface.
© dSPACE 2013 4 / 30
2.4 Distinction to CANopen ConfigurationDesk extension

In addition to the CANopen Blockset described in this document, there is an extension for Configura-
tionDesk that uses custom functions to simulate CANopen master nodes. Both versions work inde-
pendently, but support different hardware to some extent. The CANopen custom functions support
SCALEXIO, and MicroAutoBox III, among others.
© dSPACE 2013 5 / 30
3 Installation
During installation of the solution the license dongle has to be inserted.
Executing the Solution Master Setup starts the installation and the install wizard guides you through
the process.
After the installation you can decrypt the demo files via the Installation Manager.
3.1 Folder Structure
After the installation a new directory for all corresponding files is created. The structure of this directo-
ry is shown in figure 1.
Figure 1: Folder structure
• CustomFunctions
o Contains ConfigurationDesk extension information and code
• InstallationSet
o Contains installation information
• Matlab/Demo
o Contains demo models, compiled code and experiments
• Matlab/Doc
o Contains the user documentation and a tutorial
• Matlab/Library
o Contains the model library of the blockset
• Matlab/local
o Contains relevant files for Matlab
• Matlab/M
o Contains all relevant m- or p-files respectively for the solution
© dSPACE 2013 6 / 30
3.2 Simulink Library

The Simulink library is shown in figure 2.
Figure 2: Simulink library
3.3 Demos
Demos shouldn’t be opened or modified inside the installation directory.
A double click on the Demo subsystem will open the following dialog box:
Clicking on the button “Install & Open” will copy all demo files to the Windows user directory and open
the Simulink demo model. The demo model can then be used directly.
3.3.1 Experiments
There is a demo experiment for ControlDeskNG for platform DS1006.
In ControlDeskNG the experiment can be opened with “File” -> “Open” -> “Project + Experiment from
Backup…”
The corresponding zip-file can be selected in the following dialog box.
© dSPACE 2013 7 / 30
4 Using the CANopen Master Blockset

To use the CANopen functionality, the following blocks have to be inserted in the model:
• RTI CANMM General Setup

• RTI CANMM Controller Setup
• CANopen Configuration
The settings for the CAN controller are performed by means of RTI CANMM blocks. These are used to
set the necessary physical layer for the CAN. They are described in the RTICANMM documentation.
To open the user interface, double-click the CANopen Configuration Block. The Simulink blocks re-
quired for CANopen communication are generated via this user interface.
General setup:
You can select 'General setup' in the user interface to make general settings such as the target di-
rectory for the generated files. In most cases, the defaults are sufficient for communication with the
CANopen slaves. For a more detailed description, see chapter 4.1.
Nodes:
You can click 'Nodes' on the left of the dialog to select a node under Select Node and add it to a list
by using “Add to model”. “Remove from model” lets you remove a node again. An entry is generat-
ed in the tree view for every node that you add. You can select a node from the tree to configure it.
The configuration file can also be selected here.
These steps have to be repeated for each additional node. For a more detailed description, see
chapters 4.2 and 4.3.
Synch block:
Select "Synch block" from the dialog to make settings for the synchronization block that has to be
generated. To send SYNC messages, the synchronization time has to be specified and ‘Synch
message active’ must be activated. By default, the model execution time is read from the model.
For a more detailed description, see chapter 4.4.
When you click “Create” to confirm the settings, the required S-functions and associated Simulink
blocks are created, the configuration file is read, and the Synch block and the desired number of node
blocks are added to the model.
© dSPACE 2013 8 / 30
5 CANopen GUI
The CANopen node blocks and the Sync Master Block are generated via the CANopen GUI. The indi-
vidual settings that can be made are described in greater detail below.
5.1 General Setup

You can make general settings on the General setup page (see Figure 3). The "Actual model root"
field displays the current path and cannot be changed.
You can enter the target directory for the generated files in the "Destination folder for generated files"
field. This directory should be changed only during the initial configuration of the user interface. If you
change it later, it may occur that files cannot be found.
Figure 3: General Setup
© dSPACE 2013 9 / 30
5.2 Node Block

Select the controller setup block used by the CANopen node in the field “Select the RTICANMM Setup
block” on the Nodes page (see figure 4).
Enter the number/ID of the node in the field “Select nodes”, and add it via the “Add to Model” button.
The nodes can have IDs ranging from 1-127. Each ID must not be used more than once in a network.
You can use the “Remove from Model” button to remove individual nodes.
Figure 4: Nodes
© dSPACE 2013 10 / 30
5.3 Node XX
On the page Node xx page (see figure 5), you can configure each node individually. There are two
tabs on this page, “General” and “Advanced”. The settings on the “General” tab are sufficient for many
use cases.
General
RXPDO: Lets you select up to four RxPDO messages. You can select the communication type in the
COM field (for example, 1 - 240 cyclically synchronous or 255 for triggered). DLC defines the length of
the messages (1 – 8 bytes).
Number of used TxPDOs: Lets you enter the number of expected TxPDO messages. A maximum
number of 512 TxPDOs can be received.
Caution: If more than 4 TxPDOs are selected, some additional settings have to be made on the
“Advanced” tab.
Use standard initialization parameters: If selected, the following objects from the object directory
are parameterized when the node is started:
- 1006 Communication Cycle Period
- 100C Guard Time
- 100D Life Time Factor
- 1800 Transmit PDO Transmission Type
In addition, any arbitrary object can be parameterized via a configuration file. This is done by selecting
the checkbox user-defined config file for initialization sequence on the “Advanced” tab and select-
ing a suitable file. For the format of the configuration file, refer to the appendix.
Use heartbeat: Normally the nodes of a network are supervised via heartbeat. Here the nodes will
send an “alive”-message cyclically. The period is entered in the field “Heartbeat period”. If this mes-
sage is not received by the master within the defined time, an error message will be sent.
Use Node guarding: If activated, the master sends a remote request message cyclically. The nodes
send a status message in reply. If no reply has been sent after 5 s, the master sends a reset mes-
sage. This behavior can be changed by using the option “Number of answers to remote request that
can be lost”, which is described below. The master will only send a reset message after a specified
number of status answers were not received. You can enter the cycle time for the remote request
message in the Guarding period field.
Use Life guarding: With life guarding, each node can monitor the functionality of the master. If the
remote request message is not received within a certain time (life time), the node sends an error mes-
sage and goes into Preoperational mode. The life time is computed from two parameters, Life Time
Factor x Guarding period, and a safety factor of 1.5 seconds.
Life guarding can be activated only if node guarding is also active.
If "Use standard initialization parameters" is activated the values entered for Life Time Factor and
Guarding period are written to the object directory when the model is started.
Number of answers to Remote Request that can be lost: This value defines how many remote
request message can be left unanswered before the node changes its state to error and a reset mes-
sage is sent. If the value 999 is entered all answers to remote request messages are ignored and the
master doesn’t send a reset message.
© dSPACE 2013 11 / 30
Figure 5: Node Block 16 General
© dSPACE 2013 12 / 30
Advanced
Use standard TxPDO IDs / Use definition from config file for TxPDO IDs: If the first option is se-
lected, the identifiers specified in the CANopen standard are used for the TxPDOs. With the second
option, you can define your own identifiers in a text file.
Caution: The Standard IDs option must not be selected if more than 4 TxPDOs are entered.
User-defined config file for TxPDO IDs: If you do not want to use the standard identifiers for TxPDO
communication, you can select a user-specific configuration file for defining the required identifiers.
For the format of the configuration file, refer to the appendix.
Prohibit reset in first model loop: If this option is activated no reset message is sent to the CANO-
pen nodes in the first model loop.
No boot-up message expected: This option can be used if the connected CANopen device doesn’t
send a bootup message. Therefore the master assumes that the node is operational after starting the
model or after a reset. The starting sequence is then continued.
Reset node after error: If this option is activated a reset message is sent in case the node sends an
error message.
Logfile configuration: With this option you can choose which messages are displayed in the Con-
trolDesk log file.
© dSPACE 2013 13 / 30
Figure 6: Node Block 16 Advanced
© dSPACE 2013 14 / 30
5.4 Synch block
The Synch block can be configured on the Synch block page (see figure 6).
Time period for synchronization message: Send period for the SYNC message, which can be used
as a synchronization signal for PDO communication.
The time entered here has no function as soon as the SYNC message is deactivated.
Synch message active: If this checkbox is not selected, no SYNC messages are placed on the CAN
bus. Deactivating the SYNC message is useful if PDO communication has to be asynchronous and
monitoring of the master is not needed.
Figure 7: Synch block
© dSPACE 2013 15 / 30
6 Menu
Via the menu you can save the current configuration of the CANopen network or load an existent con-
figuration. You can find these functions in the drop-down menu “Settings” (see figure 8).
Figure 8: Menu Settings
Via the second menu “Help” you can access the user documentation of the CANopen Master
Blockset. It is available in German and English (see figure 9).
Figure 9: Menu Help
© dSPACE 2013 16 / 30
7 Inputs and Outputs

The basic structure of the CANopen protocol is reflected in three different access processes in the
user interface. This internal structure is relevant for the user because specific services can be as-
signed to the individual communication objects.
Unless otherwise stated, the inputs and outputs described here refer to the node's block.
NMT SDO PDO

Figure 10: CANopen Blocks: Synch Block, Node Block
© dSPACE 2013 17 / 30
NMT Communication
The blue-framed elements are for controlling the state transitions. The NMT state machine determines
the state of the communication level and enables the SDO and PDO objects sequentially. In the Oper-
ational state, the protocol is completely available, and the real-time data can be exchanged.
7.1.1.1 The Inputs
Mode:
Function: You can specify whether the transitions should be performed automatically in the state ma-
chine. This applies to resets after error messages and switching to the Operational state when the
internal parameter configuration is completed.
Caution!: In rare cases, an infinite loop can occur in AUTO mode. If an error occurs, a reset is per-
formed and the system is restarted. If the error source cannot be remedied simply by resetting, there
is another error message. A second reset is performed, etc., etc. You can interrupt this loop by return-
ing to MANUAL mode.
Size: uint8
Values: [0;1]
0: AUTO
1: MANUAL
Default value: 1
Unit: -
State:
Function: Signal for controlling the state machine for CANopen communication, as described in the
DS301 profile. It controls the enabling of SDO and PDO objects. SDOs are enabled in the Preopera-
tional state, but PDOs are not available until the Operational state. Neither SDO nor PDO messages
are active in Stopped mode.
Size: uint8
Values: [1;2;3;4;5]
1: START
Change Preoperational → Operational
2: STOP
Change Operational → Stopped
3: GO_INITIAL
Change Operational/Stopped → Preoperational
4: RESET_NODE
5: RESET_COMMUNICATION
Default value: -
Unit: -
© dSPACE 2013 18 / 30
NMT_Timeout:
Function: The time permitted after a reset, in which the CANopen slave performs its internal configura-
tion.
Size: uint32
Values: Arbitrary
Default value: 5
Unit: Seconds
Reset:
Function: A manual reset of the node can be performed by applying a leading edge on this input. This
can be done in each state.
Size: uint8
Values: [0;1]
Default value: 0
Unit: -
© dSPACE 2013 19 / 30
7.1.1.2 The Outputs
Actual_State:
Function: Displays the current state of the node. Caution! This is not an actual value in the real sense,
but the current value assumed by the model.
Size: uint8
Values: [0;1;2;3;4;5;6]
0: Initial Bootup: The node performs its internal initialization after switch-on or after a reset.
1: Preoperational :The internal configuration has finished, the model's SDO interface is active.
2: Configuring: The Preoperational state is reached after boot up. The S-function then performs con-
figuration. The period for the SYNC message and the communication parameters for the PDO mes-
sages are entered in the object directory by SDO access. The model's SDO interface is inactive during
this action.
3: Operational: Corresponds to the operational state defined in the CANopen specification. The PDO
interface is active.
4: Stopped: Matches the stopped state defined in the CANopen specification. The PDO and SDP in-
terfaces are inactive.
5: Error: An emergency (EM) message was received. A reset is expected. In AUTO mode, this is per-
formed in the next model step. In MANUAL mode, the program waits for the user's command.
6: First Model Loop: Default when the model is started. A reset is performed systematically in the first
model step.
7: Hearbeat message missing: the heartbeat message could not be received during the specified time.
The node remains in this state until either a bootup message is sent or a manual reset of the node is
issued.
Unit: -
EM_Data:
Function: CANopen devices have internal diagnostics for monitoring the quality of communication. If
an error occurs, this is indicated by an emergency message. The error description is encoded in data
bytes in the message, and these are made available to the user as an output vector.
Size: uint8[8]
Unit: CAN raw data
© dSPACE 2013 20 / 30
NMT_Status:
Function: NMT_Status indicates whether a bootup message was received. Any timeout that occurred
is also displayed.
Size: uint8
Values: [0;1;2]
0: Waiting for bootup message
1: Bootup message was received

2: Time-out
Unit: -
© dSPACE 2013 21 / 30
7.1.2 SDO Communication

The red-framed elements form the diagnostics interface. They allow read and write access to the ob-
ject director1 of the addressed node via SDO messages.
SDO communication uses the client/server principle. Each client query triggers an acknowledgement
message, which the server must place on the bus within a defined time window. The implementation
described here supports the monitoring of this process.
The implementation distinguishes between internal and external SDO accesses. Internal accesses are
performed automatically and solely for the configuration of the node. When this process is completed,
external access is enabled. You can interactively read or write to specific memory cells in the object
directory. The term "diagnostics" is used for this. Configuration is performed systematically on each
restart and after each reset. The diagnostics are not activated until after that. The status message
"Ready for diagnostics" informs you of the transition.
The CANopen Blockset supports the SDO ID from the DS401 device profile.
7.1.2.1 The Inputs
SDO_Trigger:
Function: A rising edge at this input activates the raw data that is input. The appropriate SDO mes-
sage is composed and sent on the CAN bus in the same model step.
Size: uint8
Defined values: [0;1]

0 → 1: ACTIVE
Default value: 0
Unit: -
SDO_W_Command:
Function: This input field belongs to the raw data that is sent in the CANopen message. The access
direction (read/write) and the number of bytes are encoded in the data.
Size: uint8
Values: [0x22; 0x2f; 0x2b; 0x27; 0x23; 0x40]

0x22: Write
0x2f: Write 1 Byte
0x2b: Write 2 Bytes
0x27: Write 3 Bytes
0x23: Write 4 Bytes
0x40: Read
t.
Default value: -
Unit: CAN raw data
SDO_W_Index:
1
All the internal parameters for access via CANopen SDO are stored in the object directory of a CANopen de-
vice.
© dSPACE 2013 22 / 30
Function: Enter the address of the object here. It consists of 2 bytes of index and 1 byte of subindex.
Size: uint8[3]
Values: Arbitrary
Default value: -
Unit: CAN raw data
SDO_W_Value:
Function: Input field for 4 bytes of raw data.
Size: uint8[4]
Values: Arbitrary
Default value: -
Unit: CAN raw data
SDO_Timeout:
Function: This input is used for monitoring the SDO communication. The timeout period is the length
of the time window within which the device must respond to an SDO query by acknowledging it. This
value depends on the system architecture.
If this time is exceeded, this is indicated by the status output. There is no further problem handling.
The internal counter continues to be incremented, the process is in a wait loop. In the automatic con-
figuration process during initialization, the bootup process is frozen: The configuration cannot be com-
pleted, and the slave remains in the Preoperational state. You can terminate the wait loop by perform-
ing a reset.
Size: uint32
Values: Arbitrary
Default value: 0.1 (experience value)
Unit: Second
© dSPACE 2013 23 / 30
7.1.2.2 The Outputs
SDO_R_COMMAND:
Function: This output displays the first data byte of the acknowledgement message in raw format. It
contains the coded status information.
Size: uint8
Values: [0x4f; 0x4b; 0x47; 0x43; 0x60; 0x80]

0x4x: a 4 defines a positive response to a read access. Because of the 8-byte message format, SDO
messages always contain 4 data bytes. If the queried value is smaller, all the surplus bytes are set to
zero and declared invalid. The length of valid data is coded by "x".
0x4f: The response contains 1 byte.
0x4b: The response contains 2 bytes
0x47: The response contains 3 bytes
0x43: The response contains 4 bytes
0x60: Write access was performed successfully.
0x80: ERROR – The data bytes contain an error description.
The codes for remedying the errors are defined in the CANopen standard.
Unit: CAN raw data
Node_xx_SDO_R_Index:
Function: Displays the address of the data object concerned. It consists of 2 bytes of index and 1 byte
of subindex.
Size: uint8[3]
Values: Arbitrary
Unit: CAN raw data
Node_xx_SDO_R_Value:
Function: Displays the data bytes contained in the response. All 4 bytes are always represented as
raw data regardless of their validity. The data is updated in the same model step, immediately after
receipt of the message. The data that is displayed is therefore always the data last received. You can
see from the status output whether the displayed data matches the previous or the current query.
Size: uint8[4]
Values: Arbitrary
Unit: CAN raw data
© dSPACE 2013 24 / 30
SDO_Status:
Function: The status indicates the current state of the SDO process. It can also be used as a trigger
for automatic evaluation of the data.
Size: uint8
Values: [0;1;2;3;4]
0: Waiting for answer
1: Answer OK (SDO_R_Command = 0x60)
2: Answer Timeout
3: Answer ERROR (SDO_R_Command = 0x80)
4: Ready for Diagnostics (Internal configuration completed)
Unit: -
© dSPACE 2013 25 / 30
7.1.3 PDO Communication

The green-framed elements are assigned to process data communication. They are used for exchang-
ing the actual process information on the bus. Data communication is performed via PDO objects:
RxPDO for reference values, TxPDO for actual values.
In any given environment, the various process data can be subject to different requirements. CANo-
pen therefore provides a communication parameter that defines a separate transmission type for each
PDO. PDOs are transmitted or expected either asynchronously or synchronously according to the
setting.
PDO communication uses the producer/consumer principle. The producer places data on the bus, and
each node can read it if interested. Communication runs without acknowledgements and is not moni-
tored as such.
The CANopen Blockset provides 4 RxPDOs and up to 512 TxPDOs. The IDs of the RxPDOs are pre-
defined according to the DS401 standard. Either the standard IDs or IDs defined in a configuration file
can be used for the TxPDOs.
7.1.3.1 The Inputs
Enable (Sync_Block):
Function: Signal that releases the synchronous mode. If it is set, the SYNC message is sent cyclically.
It is used to synchronize the bus nodes for PDO communication. In parallel, the Sync Master Block
generates a toggle signal on the sync model output. All the node blocks in the Simulink model are
synchronized to one another by this signal.
Size: uint8
Values: [0;1]
0: SYNC message not active
1: SYNC message active
Default value: 1
Unit: -
Sync (Sync_Block):
Function: This input is used to synchronize the PDO communication. It has to be connected to the
toggle output of the Sync Master Block.
Size: uint8
Values: [0;1]
Default value: -
Unit: -
© dSPACE 2013 26 / 30
PDO_Trigger:
Function: This input is relevant if the PDO concerned was configured to be asynchronous.
PDO communication is enabled when the node is in the operational state. If this condition is met, and
communication has to be asynchronous, the trigger input is active. The reference values entered in
the input fields are sent as CAN messages on the bus on each rising edge of the trigger input.
Size: uint8[4]
Defined values: [0;1]

0 → 1: ACTIVE
Default value: 0
Unit: -
RxPDO1_Data to RxPDO4_Data:
Function: The reference values are written to these input fields. The length of an RxPDO is defined by
what is called PDO mapping during the definition of the system topology. The user specifies the ob-
jects to be accessed from the central directory on the PDO. One RxPDO contains up to 8 bytes of
data.
Only the number of bytes actually set is allowed to be sent. If the length of the sent message does not
match the value expected by the node, the node sends an EM message.
Size: uint8[1 bis 8]
Values: Arbitrary
Default value: 0
Unit: CAN raw data
© dSPACE 2013 27 / 30
7.1.3.2 The Outputs
TxPDO_Data:
Function: Displays the actual values. The output is a vector with 8 * number_TxPDO entries, because
each TxPDO contains 8 bytes of data.
Size: uint32[8*Anzahl_TxPDO]
Defined values: Arbitrary
Unit: -
TxPDO_Status:
Function: The status output describes the state of TxPDO communication. With synchronous commu-
nication, any timeout is reported. You can also see from the status information when the data arrived
and whether any data was lost.
Size: uint8[4]
Defined values: [0;1;2;3]

0: New data on the bus
1: No new data on the bus
2: Data was lost
3: Time-out
Unit: -
© dSPACE 2013 28 / 30
Appendix A: Notes and Remarks
Deletion: The individual nodes can be deleted by the Remove from Model button or manually. Note
that manual deletion does not work if the button was pressed to delete blocks but Apply was not
clicked.
Deleting the blocks will also delete the corresponding S-Function and config-file. Deleting the last
node block in the model will also delete the Synch block and its S-Function.
Copy/Paste: Node blocks can be copied into subsystems via copy and paste (Ctrl-C, Ctrl-V). The orig-
inal block has to be deleted afterwards.
Caution!: Moving the blocks via Ctrl-X doesn’t work!
Option user-defined config file
The text file contains data on SDO messages that are sent after bootup. This data must be specified in
a specific format. The name of the new configuration file contains the board type, the board, channel
and controller numbers, and the number of the generated node. From dSPACE Release 6.4, the name
contains only the controller number and the node number.
Configuration file format: The data in the text file must be provided in the following form:
601 2B 71 21 02 00 00 00 00; comment
The first number is the message's ID. After that comes the type of query (read or write). Then the
index, subindex, and 4 bytes of data. Comments are separated by a semicolon.
Option Config file for user-defined TxPDO IDs
Configuration file format: The data in the text file must be provided in the following form:
StepIndex: 0x01
BaseID: 0x180
StepID: 0x10
UseNodeID: 0x00
The entries have the following meanings:
StepIndex: Step width for generating further identifiers after each set of 4 PDOs
BaseID: Start value for forming the identifiers
StepID: Step width for extending the identifiers
UseNodeID: Specifies whether to add the node number when computing the identifiers
The calculation is based on the following formula:

Calculated ID = BaseID + ((number of TxPDO -1)mod 4)*StepID + StepIndex(after each 4 TxPDOs)
Example:
ID of TxPDO1: BaseID + 0*StepID, here: 0x180
ID of TxPDO2: BaseID + 1*StepID, here: 0x190
ID of TxPDO3: BaseID + 2*StepID, here: 0x1A0
ID of TxPDO4: BaseID + 3*StepID, here: 0x1B0
ID of TxPDO5: BaseID + 0*StepID + StepIndex, here: 0x181
ID of TxPDO6: BaseID + 1*StepID + StepIndex, here: 0x191
etc.
© dSPACE 2013 29 / 30
Appendix B: List of Figures

Figure 1: Folder structure ...............................................................................................................6
Figure 2: Simulink library ................................................................................................................7
Figure 3: General Setup .................................................................................................................9
Figure 4: Nodes ............................................................................................................................10
Figure 5: Node Block 16 General .................................................................................................12
Figure 6: Node Block 16 Advanced..............................................................................................14
Figure 7: Synch block ...................................................................................................................15
Figure 8: Menu Settings ...............................................................................................................16
Figure 9: Menu Help .....................................................................................................................16
Figure 10: CANopen Blocks: Synch Block, Node Block ..............................................................17
© dSPACE 2013 30 / 30

CANopen Blockset Eng

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CANopen Blockset Eng

Uploaded by

Copyright:

Available Formats

CANopen Master Blockset

Project: CANopen Blockset

Copyright © 2013 dSPACE GmbH. All rights reserved.

4 Using the CANopen Master Blockset ................................................................................................8

5 CANopen GUI .......................................................................................................................................9

7 Inputs and Outputs............................................................................................................................17

Appendix A: Notes and Remarks ........................................................................................................29

Appendix B: List of Figures.................................................................................................................30

• Addressing up to 127 nodes

NMT Network Management

2.2 Hardware Environment

2.3 Relevant Files

• CANopen_Synch_Master_<ControllerName>.c (Simulink block Sync_Master)

2.4 Distinction to CANopen ConfigurationDesk extension

3.1 Folder Structure

Figure 1: Folder structure

3.2 Simulink Library

Figure 2: Simulink library

4 Using the CANopen Master Blockset

• RTI CANMM General Setup

5.1 General Setup

Figure 3: General Setup

5.2 Node Block

Figure 5: Node Block 16 General

Figure 6: Node Block 16 Advanced

5.4 Synch block

Figure 7: Synch block

Figure 8: Menu Settings

Figure 9: Menu Help

7 Inputs and Outputs

NMT SDO PDO

7.1.1.1 The Inputs

7.1.1.2 The Outputs

Unit: CAN raw data

1: Bootup message was received

7.1.2 SDO Communication

7.1.2.1 The Inputs

Defined values: [0;1]

Values: [0x22; 0x2f; 0x2b; 0x27; 0x23; 0x40]

Unit: CAN raw data

Unit: CAN raw data

Function: Input field for 4 bytes of raw data.

Unit: CAN raw data

Default value: 0.1 (experience value)

7.1.2.2 The Outputs

Values: [0x4f; 0x4b; 0x47; 0x43; 0x60; 0x80]

Unit: CAN raw data

Unit: CAN raw data

Unit: CAN raw data

7.1.3 PDO Communication

7.1.3.1 The Inputs

Defined values: [0;1]

Size: uint8[1 bis 8]

Unit: CAN raw data

7.1.3.2 The Outputs

Defined values: Arbitrary

Defined values: [0;1;2;3]

Appendix A: Notes and Remarks

Option user-defined config file

Option Config file for user-defined TxPDO IDs

The entries have the following meanings:

The calculation is based on the following formula:

Appendix B: List of Figures