Woodward Custom CANopen Instance Definition

Woodward Custom CANopen Instance Definition

CANopen definition block defines a CANopen communication instance.

Block ID

CANopen Instance Definition

Library

Woodward Custom CANopen Library

Description

In order for the Woodward Custom CANopen library to be used, the user's MotoHawk security token will need to have the proper license added to it. For instructions on how to accomplish this, please see the instructions for adding the MotoHawk CANopen Library license.

A user can check whether their MotoHawk security token has the needed product license at the Matlab command line by executing the woodward_custom_canopen_check_license command. A returned value of 1 means the MotoHawk CANopen library is licensed, while a returned value of 0 means it is not.

Node ID of the instance is supplied by input port. It must be within the range of 1 - 127.

Number of possible CANopen instance definitions is not limited. There could be more than one CANopen instance definitions referencing a single CAN resource. It is not advised to use the same node ID on more than one instance reference the same CAN resource.

Referenced heartbeat period entry OD 0x1017 is a name of an object dictionary entry. It is required that it's data type is UNSIGNED16 and access type allow reading. It describes how often the CANopen instance sends heartbeat messages. Period is defined in milliseconds.

Referenced SYNC COB-ID entry OD 0x1005 is a name of an object dictionary entry. It is required that it's data type is UNSIGNED32 and access type allow reading. It defines CAN ID of SYNC messages that the CANopen instance will respond to. Note that in order to support the range of CAN ID's for a SYNC message, the range of possible values, 0 to the maximum defined engineered value defined in the object dictionary definition for the SYNC COB-ID is integrated into the CAN mask. As this field is optional, the uint32 max value is used when not defined and will force the CAN mask to be unrestricted (mask of 0). It is recommended to set the maximum value as low as possible to keep as many relevant bits in the CAN mask as possible to have the most efficient CANopen receive queue.

Referenced SYNC Period Entry OD 0x1006 is a name of an object dictionary entry. It is required that it's data type is UNSIGNED32 and access type allow reading. Edit field is only visible when enable sync producer checkbox is checked. It defines how often the CANopen instance sends SYNC messages. Period is defined in milliseconds.

The CANopen software stack processes all CANopen messages on the "CAN Channel" every 3 ms. It is necessary to specify a software message queue (receive queue size) that is appropriate for the baud rate and bus loading. At 100% loading the following table can be used to estimate a good value for the slot queue:

Baud Rate Maximum Messages per second Recommended Queue Size

250kbps 5700 18

500kbps 11400 35

1000kbps 22800 70

It is necessary to define CANopen definition blocks in subsystem located in the main MotoHawk application window, where target definition and CAN definitions are. Node ID could be changed during runtime, however is is recommended to update it in an NMT event trigger block that is configured to execute on NMT reset on command. Following design could be used :

CANopen definition block is inside CANopen definition subsystem. STARTUP_EVENT trigger must be used to ensure that block is called during model initialization. Additionally it's priority must be lower than 255.

CANopen definition shouldn't be defined in different location, as it could result in incorrect behavior on start-up (boot-up message sent with incorrect Node ID).

Block Parameters

Parameter Field Values Comments/Description

Instance Name String Unique name for this instance of the protocol.

Channel Name String CAN resource name that will receive requests and transmit responses.

Receive Queue Size Numeric Specifies the number of messages buffered in the CANopen slot queue. Must be within the range of 1-200.

Use Extended CAN IDs Checkbox If selected 29 bit extended CAN ID will be used, otherwise standard 11 bit will be used

Referenced Heartbeat Period Entry OD 0x1017

Numeric Name of object dictionary entry where "heartbeat period" parameter is stored. Defines how often Heartbeat is sent.

Referenced SYNC COB-ID Entry OD 0x1005

String Name of object dictionary entry where "SYNC COB-ID" is stored. Only SYNC messages with given COB-ID are processed.

Referenced SYNC Period Entry OD 0x1006

String Name of object dictionary entry where SYNC period is stored. It defines how often SYNC message is generated. Visible only when "enable sync producer" is checked.

Copyright 2018 Woodward Corporation. All Rights Reserved. Visit Us: mcs.woodward.com

Woodward Custom CANopen Heartbeat Consumer Instance

CANopen heartbeat consumer instance allows the receiving of heartbeat messages.

Block ID

CANopen Heartbeat Consumer Instance

Library


Description

This block allows CANopen heartbeat messages to be received from the CANopen instance with a matching node ID from the input port. It is not recommended to change the node ID input port value during runtime. Doing so will cause erroneous information to be returned from a

CANopen heartbeat consumer status block that references this heartbeat consumer instance. Reading received messages is accomplished by CANopen heartbeat consumer status block.

Block Parameters


CANopen Instance String Name of referenced CANopen instance.

Heartbeat Instance Name String Unique name of heartbeat consumer instance.


Woodward Custom CANopen Heartbeat Consumer Status

CANopen heartbeat consumer status reads NMT status of the referenced heartbeat consumer instance.

Block ID

CANopen Heartbeat Consumer Status

Library

Woodward Custom CANopen

Description

This block retreives the selected heartbeat information from the referenced heartbeat consumer instance. The last known NMT state or the time that has elapsed since the last heartbeat message has been received. The measurement is valid once a heartbeat message from the node ID of the heartbeat consumer instance has been received.

It is possible to read one of following parameter :

• Last Known NMT state:◦ 0 - Transmitting CANopen instance is in Boot-Up state

◦ 4 - Transmitting CANopen instance is in Stopped state◦ 5 - Transmitting CANopen instance is in Operational state◦ 127 - Transmitting CANopen instance is in Pre-Operational state

• Time Elapsed Since Heartbeat Received

Block Parameters


Referenced Heartbeat Consumer

String Name of associated CANopen heartbeat consumer Instance

Status Drop Down • Last Known NMT State• Time Elapsed Since Heartbeat Received


Woodward Custom CANopen LSS Configuration Request Trigger

This block creates a trigger that is called when the referenced LSS slave instance recives the selected LSS Configuration request.

Block ID

CANopen LSS Configuration Request Trigger

Library


Description

This block creates a trigger that is called when the referenced LSS slave receives the drop down selected LSS configuration request message. For all requests except LSS activate bit timing parameters, an LSS response on configuration request response block can be used to provide application derived error code values.

Possible LSS Configuration Requests:

• LSS Configure Node-ID

• LSS Configure CAN Baud Rate• LSS Activate Bit Timing Parameters• LSS Store Configuration Parameters

This trigger is called when selected LSS configuration request is received. All requests except 'LSS Activate Bit Timing Parameters' requires response. To set appropriate response please use CANopen LSS response on configuration request. When no response is specified by the user, a positive response will be sent.

When the trigger is configured to execute when configuring the LSS node ID, a node ID port will provide the new node ID to use upon transition to LSS operation mode. When the trigger is configured to execute when configuring the CAN baud rate, a table selector and table index port will provide these values to the application for use. Table index value meanings are provided below:

Baud Rate Table Index

1000 kBit 0

800 kBit 1

500 kBit 2

250 kBit 3

125 kBit 4

reserved 5

50 kBit 6

20 kBit 7

10 kBit 8

Example usage of this block together with response:

When a trigger associated with any of the selectable LSS configuration requests is not present, that functionality is disabled and the CANopen software will respond with an error message upon the request.

Block Parameters


LSS Instance Reference String Name of associated CANopen LSS slave instance.

Trigger Name String Name of created trigger. Parameter is optional, if no name is provided in the edit field the trigger name is generated automatically.

LSS Configuration Drop down LSS configuration request on which trigger is called :

• LSS Configure Node-ID• LSS Configure CAN Baud Rate• LSS Activate Bit Timing Parameters• LSS Store Configuration Parameters

Execution Order within Task Numeric (Integer) More than one trigger may be placed in a model that is driven by the same event. Use the execution order within task attribute to define the execution order of these triggers relative to one another. The triggers will execute from the lowest execution order within task value to the highest.

This trigger is inside another triggered subsystem

Checkbox If the trigger is inside another triggered subsystem, this must be checked.

Trigger even when containing subsystem is disabled

Checkbox If the trigger is inside another enabled subsystem, then execute this subsystem if that subsystem is enabled.


Woodward Custom CANopen LSS Mode Read

This blocks reads internal LSS mode of the referenced LSS slave instance.

Block ID

CANopen LSS Mode Read

Library


Description

This blocks provides the current LSS mode of the referenced CANopen LSS slave instance.

Possible status values are:

• 0 - Transmitting CANopen instance is in operation mode• 1 - Transmitting CANopen instance is in configuration mode

Block Parameters




Woodward Custom CANopen LSS Mode Trigger

This block creates Trigger that is called when the selected LSS Mode is entered.

Block ID

CANopen LSS Mode Trigger

Library


Description

This block creates a trigger that is called when the referenced LSS slave instance enters the LSS mode selected from the LSS event drop down.

Possible LSS Mode Events :

• LSS Enter Operation Mode• LSS Enter Configuration Mode

Block Parameters




LSS Event Drop down NMT event on which trigger is called :

• LSS Enter Operation Mode• LSS Enter Configuration Mode


This Trigger is inside another triggered subsystem





Woodward Custom CANopen LSS Response on Configuration Request

This block allows to send a response on received LSS configuration request.

Block ID

CANopen LSS Response on Configuration Request

Library


Description

This block allows an application to set the error code and specific error portions of a response to a LSS configuration request message. If this block is not used for LSS Configuration requests, then a positive response will be used for the error code and specific error code portions of the response message.

It is recommended that this block be connected to an LSS configuration request trigger as per the below example.

To have application control over the response to an LSS configuration request it is necessary to connect this blocks trigger input to a CANopen LSS configuration request trigger. If this block is not used, then a positive response will be sent to the requesting CANopen LSS master. Possible error codes and their meaning are as follows:

Error Code Description

0 protocol successfully completed

1 Node ID out of range, bit timing not supported or store configuration not supported.

2 Storage media access error. Supported for store configuration parameters only (for others reserved).

3-254 reserved

255 Implementation specific error occured. Set the specific error code port accordingly.


Woodward Custom CANopen LSS Slave Instance

Adding this block to model configures the referenced CANopen instance to work as a LSS slave.

Block ID

CANopen LSS Slave Instance

Library


Description

This block configures the referenced CANopen instance definition to be an LSS slave. As an LSS slave, the referenced CANopen instance'snode ID and CAN baud rate can be configured via Layer Setting Services. The input port will allow for LSS messages to be ignored (0) or accepted and processed (1) by the referenced CANopen instance.

It is necessary to define CANopen LSS Slave Instance block in subsystem triggered by a STARTUP_EVENT. This is to ensure the correct node ID is sent in the CANopen boot up message. An example of this follows:

The CANopen LSS slave instance block is inside the CANopen definition subsystem.

Block Parameters


CANopen Instance Reference String Name of referenced CANopen instance definition.

LSS Slave Instance Name String Unique name of LSS slave instance.

Referenced Vendor-ID Entry OD 0x1018sub1

String Name of object dictionary entry where identity vendor-ID parameter is stored.

Referenced Product Code Entry OD 0x1018sub2

String Name of object dictionary entry where identity product code parameter is stored.

Referenced Revision Number Entry OD 0x1018sub3

String Name of Object Dictionary entry where identity revision number parameter is stored.

Referenced Serial Number Entry OD 0x1018sub4

String Name of Object Dictionary entry where identity serial number parameter is stored.


Woodward Custom CANopen NMT Block Reset Node Command

This block allows an application to ignore NMT reset node commands.

Block ID

CANopen NMT Block Reset Node Command

Library


Description

This block allows the application to decide whether to ignore NMT reset node commands for the referenced CANopen instance. The boolean (1 ignore NMT reset node commands, 0 do not ignore NMT reset node commands) input port value is read each time the block executes and stores the application intent and checked when an NMT reset node command is received.

Block Parameters




Woodward Custom CANopen NMT Event Trigger

This block creates a trigger that is called when selected NMT event message is received by the referenced CANopen instance.

Block ID

CANopen NMT Event Trigger

Library


Description

This block creates a trigger that is called when selected NMT event message is received by the referenced CANopen instance.

Possible NMT Events :

• NMT Reset Application on Command• NMT Reset Application on Power up• NMT Reset Communication on Command• NMT Reset Communication on Power up• NMT Enter Pre-operational• NMT Enter Operational• NMT Enter Stopped

Reset application/communication on power up triggers are called during power up. Reset application/communication on command triggers are called during run-time after receiving an NMT command message. Upon receiving an NMT command, the corresponding action is performed automatically (with exception of reset application event). In that case, the trigger execution informs the application that a reset application message has been received and resets the CANopen communication. In order to actually reset the module it is necessary to add reset logic. It should be enclosed in a function call subsystem connected to the reset application NMT trigger. The trigger can be used when the referenced CANopen application is an NMT master or an NMT slave.

Block Parameters



Trigger Name String Name of created trigger function. Parameter is optional, if no trigger name is provided a trigger name is generated automatically.

NMT Event Drop down NMT event on which trigger is called :

• NMT Reset Application on Command• NMT Reset Application on Power up• NMT Reset Communication on Command• NMT Reset Communication on Power up• NMT Enter Pre-operational• NMT Enter Operational• NMT Enter Stopped







Woodward Custom CANopen NMT Master Command

This block transmits an NMT command to another node.

Block ID

CANopen NMT Master Command

Library


Description

This block will transmit an NMT command message to the input port determined slave node ID when executed. This port accepts a specific node ID (1-127) or all nodes (0). The command input port will be the NMT command value that is to be transmitted in the NMT command message.

Transmitting NMT commands is only possible when NMT master instance is defined and enabled. When the referenced NMT master instance is disabled (which means that the CANopen instance is an NMT Slave) transmitting NMT commands is disabled as well.

Which command is transmitted is defined by a value supplied to the command input. Possible values :

• 1 - Start• 2 - Stop• 128 - Enter Pre-Operational• 129 - Reset Node• 130 - Reset Communication

This block also allows changing internal NMT state. In this case the slave node ID value must be the same as node ID value supplied to the referenced CANopen instance.

Block Parameters


NMT Master Reference String Name of referenced NMT master instance.


Woodward Custom CANopen NMT Master Instance

This block configures the referenced CANopen instance as an NMT master.

Block ID

CANopen NMT Master Instance

Library


Description

This block configures the referenced CANopen instance as an NMT master. When exeucting this block, the input port value will enable (1) or disable (0) the transmission of NMT command messages transmitted from the referenced CANopen instance. If disabled, the referenced CANopen instance becomes an NMT slave and NMT master commands are disabled.

There cannot be more than one NMT master instance referencing the same CANopen instance definition.

Block Parameters



NMT Master Instance Name String Unique name of NMT master instance block.


Woodward Custom CANopen NMT State Read

This blocks reads internal NMT state of the referenced CANopen instance.

Block ID

CANopen NMT State Read

Library


Description

This blocks reads the internal NMT state of the referenced CANopen instance.

Possible output values:

• 0 - Transmitting CANopen instance is in Boot-up state• 4 - Transmitting CANopen instance is in Stopped state• 5 - Transmitting CANopen instance is in Operational state• 127 - Transmitting CANopen instance is in Pre-Operational state

Block Parameters


CANopen Instance Reference String Name of associated CANopen instance definition.


Woodward Custom CANopen Object Dictionary Entry Definition

This block creates an object dictionary entry.

Block ID

CANopen OD Entry definition

Library


Description

This block creates an object dictionary entry with unique index and subindex. It provides an interface to write or read a value, which could be used in blocks that send or receive CANopen messages.

Internal / External Object DictionaryObject dictionary entry could be defined as internal or external.

• Internal entries represent object dictionary data of the referenced CANopen instance. They could be used by SDO server upload and download, PDO Tx and Rx protocol, LSS Slave or CANopen instance definition object dictionary references.

• External entries represent object dictionary data of an external node. When it is required to receive object dictionary data from another CANopen instance, it will be writen to the corresponding external object dictionary entry. When it is required to send object dictionary data to another CANopen instance, it will be read from the external object dictionary entry and transmitted to the other CANopen instance. External object dictionary entries are used with SDO client upload and download blocks.

Which ports are available differ depending on selected internal/external option.

Port configurations :Ports are available only when data source in definition script is set to a value of 2. When data source is set to a constant (1) or a data store (3) there are no inputs or outputs.

• There is one input when :◦ entry is internal and access type is read only◦ entry is external and access type is write only

• There are two outputs when :◦ entry is internal and access type is write only◦ entry is external and access type is read only

• There are one input and two outputs when :◦ entry is internal or external and access type is read-write

The input supplies the object dictionary entry with a value that would be sent to another CANopen instance. Output ports supply values that have been received from another CANopen instance and Data Available parameter indicates that new data has been received.

Object dictionary definition scriptObject dictionary script must be defined by following structure format :

objdb.name = 'EXT_OD_6000_00';

objdb.is_external_od_entry = true;

objdb.index = hex2dec('6000');

objdb.sub_index = 0;

objdb.description = 'Battery Status';

objdb.units = '';

objdb.data_type = 'UNSIGNED8';

objdb.data_source = 2;

objdb.entry_access_type = 'RO';

objdb.data_default = 1;

objdb.data_datastore_name = '';

objdb.transform.numerator = 1;

objdb.transform.denominator = 1;

objdb.transform.offset = 0;

objdb.transform.minimum = 0;

objdb.transform.maximum = 1;

objdb.transform.saturate = true;

Object dictionary definition script examples are included with the CANopen block set. Suggested arrangement is to have all object dictionary entries associated with the same CANopen instance in a single file. However it is possible to organize it differently as long as resulting structure, which is used as a OD definition parameter, has the same format as the above example.

Description of script parameters (if not marked as optional, parameter is mandatory):

• name - unique name of object dictionary entry• is_external_od_entry - defines if object dictionary entry is internal (module parameters) or external (external node parameters)

◦ Internal object dictionary entry is an internal parameter of this CANopen instance◦ External object dictionary entry is a duplicate of an entry from an external node

• index - object dictionary numerical index value• sub_index - sub index of object dictionary entry• description - brief description, optional parameter• units - value units, optional parameter• data_type - data type of value, naming should comply to CANopen specification• data_source - source of value

◦ 1 - constant value defined in data_default field◦ 2 - port◦ 3 - data store

• entry_access_type - access type of value ◦ 'RO' - read only◦ 'WO' - write only◦ 'RW' - read and write

• data_default - default value of parameter. For strings it is important to provide data_default with maximum length of possible string. If desired default data is shorter than maximum length of accepted string, fill it with '0'. Length of data_default determines maximum length of accepted string

• data_datastore_name - name of data store, ignored if data_source is different than 3• transform fields - fields that determines what operations are performed on received value before storing it to object dictionary entry.

These fields are optional.◦ Numerator - if not defined defaults to 1◦ Denominator - if not defined defaults to 1◦ Offset - if not defined defaults to 0◦ Minimum - must be higher than this value, if if not defined defaults to minimum possible value that could be stored in provided

data type◦ Maximum - must be lower than this value, if not defined defaults to maximum possible value that could be stored in provided data

type◦ Saturate - used only in SDO protocol, if not defined defaults to false

◾ when true, a value that exceeds minimum or maximum value is saturated

◾ when false, a value that exceeds minimum or maximum value is rejected and abort code is sent in response

Block Parameters



OD Definition String Evaluates to OD entry definition specified in the example script.


Woodward Custom CANopen Protocol Instance Enable

CANopen protocol instance enable activates a CANopen instance to allow transmission and receiving of messages.

Block ID

CANopen Protocol Instance Enable

Library


Description

This block provides application control over the activation of a CANopen instance. Using this block will cause the referenced CANopen instance to not start its initialization procedure and no CANopen communication relating to the referenced CANopen instance will occur. CANopen

instances that don't utilize this block will initialize as part of application start up. Once enabled by providing a boolean TRUE to the input port, it is not possible to disable that CANopen instance.

Block Parameters


CANopen Reference String Reference to the CANopen instance to be application enabled.


Woodward Custom CANopen RX PDO

This block defines PDO mapping for received PDO messages.

Block ID

CANopen RX PDO

Library


Description

This block defines PDO mapping for received messages.

COB ID Base value shall comply with CANopen specification :

• First 7 bits must always be set to '0'.• If CAN id type in the CANopen instance is set to standard only 0x180, 0x200, 0x280, 0x300, 0x380, 0x400, 0x480 and 0x500 are allowed

• If CAN id type in the CANopen instance is set to extended 0x180, 0x200, 0x280, 0x300, 0x380, 0x400, 0x480, 0x500 and any value equal or greater than 0x800 are allowed

RX PDO script definitionRX PDO must be defined by following structure format :

pdodb.name = 'RPDO_0';

pdodb.description = 'RPDO example';

pdodb.parameters.enable_pdo.data_source = 2;

pdodb.parameters.enable_pdo.data_default = true;

pdodb.parameters.enable_pdo.data_datastore_name = 'enable_DS';

pdodb.parameters.node_id.data_source = 2;

pdodb.parameters.node_id.data_default = uint8(3);

pdodb.parameters.node_id.data_datastore_name = 'nodeid_ds';

pdodb.fields{1}.data_od_entry_name = 'OD_1023_00';

pdodb.fields{1}.start_bit = 0;







Receive PDO definition script examples are included with CANopen block set. The suggested arrangement is to have all RX PDO entries associated with the same CANopen instance in a single file. However it is possible to organize it differently as long as resulting structure, which is used as a RX PDO Data Script definition, has the same format as the above example.

Description of script parameters (if not marked as optional parameter is mandatory):

• name - unique name of RX PDO entry• description - brief description, optional parameter• parameters - mandatory configuration parameters

◦ enable_pdo - enable PDO parameter

◾ data_source - source of enable PDO value

◾ 1 - constant value defined in data_default field

◾ 2 - port

◾ 3 - data store

◾ data_default - default value of enable PDO

◾ data_datastore_name - name of data store where enable PDO is stored, only used when selected data_source is data store◦ node_id - node id of PDO message, value must be within the range of 1 - 127

◾ data_source - source of node id value


◾ 2 - port

◾ 3 - data store

◾ data_default - default value of node id

◾ data_datastore_name - name of data store where node id is stored, only used when selected data_source is data store• fields - describes PDO mapping

◦ data_od_entry_name - name of object dictionary entry◦ start_bit - indicates where object dictionary entry value is placed in PDO frame

Block Parameters



COB-ID Base Numeric COB-ID Base value.

Transmission Type Drop down • SYNC - Received data is processed after SYNC message is received

• EVENT-DRIVEN - Received data is processed immediately

Data Script definition String Evaluates to RX PDO definition specified in the example script.


Woodward Custom CANopen RX PDO Status

This block allows monitoring status of receive PDO block.

Block ID

CANopen RX PDO Status

Library


Description

This block provides one of the two statuses described below for a referenced receive PDO block. The time is only valid when a CANopen instance is in NMT state operational. When NMT stat is not operational, the measurement is valid port will return false on block execution.

One of two statuses could be monitored :

• Average Data Rate - average elapsed time between received messages defined in a receive PDO block.• Time Elapsed Since PDO Received - elapsed time since last message defined in a receive PDO block was received

Result is only valid when the CANopen instance referenced by the receive PDO block is in NMT state operational. Do not use status information when Measurement is Valid is false.

Block Parameters


RX PDO Reference String Name of associated receive PDO block.

Select Status Drop down Selected receive PDO status to be monitored.

• Average Data Rate• Time Elapsed Since PDO Received


Woodward Custom CANopen SDO Client Channel Instance

This block defines a CANopen SDO client channel.

Block ID

CANopen SDO Client Channel Instance

Library


Description

This block creates a FIFO CANopen client transmit queue. The number of entries in the queue is defined in the SDO requested queue size parameter. SDO client upload and download requests will be placed in this queue for transmission to servers with the Node ID defined by this block's input port.

The node ID is updated when the client channel block executes. The node ID is not saved when the client request is queued, it is retrieved when the queued request is transmitted. It is therefore not recommended that an application make runtime changes to the node ID unless it is sure that there are no SDO client messages pending transmission and the CAN open instance is not waiting on a response from a server.

There can be up to 127 SDO client channel blocks associated with a single SDO client instance. It is not recommended to use the same Node ID value in multiple SDO client channel blocks.

COB ID base values shall comply with CANopen specification :

• First 7 bits must always be set to '0'.• If CAN id type in the CANopen instance is set to standard the following value is allowed :

◦ COB-ID base client->server : 0x600◦ COB-ID base server->client : 0x580

• If CAN id type in the CANopen instance is set to extended the following values are allowed :◦ COB-ID base client->server : 0x600 and any value equal or greater than 0x800◦ COB-ID base server->client : 0x580 and any value equal or greater than 0x800

SDO requested queue size defines how many SDO requests sent by SDO download and SDO upload blocks can be queued before rejecting additional requests to queue SDO client communication requests. A request is kept in the queue until a response from another node is received or the timeout is met (timeout parameter is set in SDO client block).

It is recommended that client channel be used for peer-to-peer communication. Only one server and one client should communicate over single channel.

Block Parameters


SDO Client Reference String Name of associated SDO client.

Channel Name String Unique name of SDO client channel.

COB-ID Base Client->Server Numeric COB-ID base of this SDO client's client to server ID.

COB-ID Base Server->Client Numeric COB-ID base of this SDO client's server to client ID.

SDO Requested Queue Size Numeric Requested size of SDO client channel queue.


Woodward Custom CANopen SDO Client Instance

This block enables SDO client capabilities.

Block ID

CANopen SDO Client Instance

Library


Description

This block enables SDO client capabilities for the referenced CANopen instance. In order to use SDO client channel instance blocks, SDO client upload and download request blocks, this block is neccessary.

There can be only one SDO client associated with a single CANopen instance definition block.

The SDO timeout defines how long the referenced CANopen instance will wait for a response from a server before discarding a client request.

Block Parameters



Instance Name String Unique name of SDO client instance.

SDO Timeout [ms] Numeric Selected timeout of SDO client messages in milliseconds. It must be within the range of 1-100000ms.


Woodward Custom CANopen SDO Client Segmented Buffer Instance

This block defines a buffer for SDO client messages.

Block ID

CANopen SDO Client Segmented Buffer Instance

Library


Description

This block defines a buffer for SDO client messages. It references an SDO client instance and is shared among every SDO client channelreferencing the same SDO client instance.

The segmented buffer is used to transmit data that is larger than 4 bytes. The number of defined buffers should allow uninterrupted communication between CANopen clients and servers. When a response to an SDO client request is received from a server, or when an SDO client request is scheduled to be transmitted when no buffer is available, it will be ignored.

The buffer size should be equal to the longest visible string that might be sent/received by an SDO client.

Block Parameters


SDO Client Reference String Name of associated CANopen SDO client instance.

Buffer Size Numeric Size of segmented buffer in bytes.


Woodward Custom CANopen SDO Download

This block defines SDO client download transmission.

Block ID

CANopen SDO Download

Library


Description

The execution of this block will initiate the transmission of an SDO client download request message. If at the time of execution, the referenced SDO client channel is not empty, the download request will be queued and transmitted in the order it was received. The SDO client download

request messsage sends the data of the external object dictionary entry referenced in the external OD entry reference block mask field. The message is sent to a CANopen server with the node ID provided on the referenced SDO client channel instance.

Object dictionary entry should :

• be external• have access type is one of following: write-only or read-write• be associated with the same CANopen instance definition as the SDO client.

Protocol TypeSegmented SDO protocol sends visible string longer than 4 characters, otherwise SDO expedited protocol is used.

SDO download request message is sent with the rate inherited from the containing subsystem.

Block Parameters


SDO Client Channel Reference String Name of associated SDO client channel.

External OD Entry Reference String Name of associated object dictionary.

SDO Download Name String Unique name of SDO download block.


Woodward Custom CANopen SDO Request Processed Trigger

This block creates a trigger that is called when SDO upload or SDO download message is processed.

Block ID

CANopen SDO Request Processed Trigger

Library


Description

This block creates a trigger that will execute a connected subsystem when the referenced SDO client upload or download block has completed its specified action of uploading from a server or downloading to a server. The trigger condition drop down selects whether the trigger will execute when an upload or download request has successfully completed, or if the request has not completed successfully.

There are two possible conditions:

• SDO Processed without Error - triggers when a message is successfully processed.• SDO Processed with Error - triggers when a message is not processed successfully.

Possible values of abort code include CANopen SDO abort codes and following manufacturer specific codes :

Manufacturer Specific Abort Code Description

0x00000000 No error while processing the request

0x00000001CANopen SDO client queue is full, request couldn't be processed

0x00000002Unable to send the SDO client request - CAN buffer queue request failed or LSS not enabling transmission

0x00000003 Segmented buffer is too small to handle the message

0x00000004 Segmented buffer busy - message not send

0x00000005 Unable to send request - not appropriate NMT state

Block Parameterss


SDO Upload/Download Reference

String Name of associated CANopen download or CANopen upload block.

Trigger Name String Name of created trigger function. Parameter is optional, if no trigger name is provided in the function name will be generated automatically.

Trigger Condition Drop down Condition on which trigger is called :

• SDO processed without error• SDO processed with error

Execution Order within Task Numeric (Integer) More than one trigger may be placed in a model that is driven by the same event. Use the execution order within task attribute to define the execution order of these triggers relative to one another. The triggers will execute from the lowest execution order within Task value to the highest.






Woodward Custom CANopen SDO Server Channel Instance

This block defines a CANopen SDO server channel.

Block ID

CANopen SDO Server Channel Instance

Library


Description

This block defines CANopen SDO server channel.

This block creates an interface for CANopen clients with a node ID that matches the node ID value on this block's input port to make SDO upload and download requests of the referenced SDO server. Should a client request be received while the server is processing a previous request, that request will be discarded and the new request will be processed.

There could be up to 127 SDO Server channel blocks. It is not recommended to use the same node ID value in multiple SDO server channel blocks.

COB ID Base values shall comply with CANopen specification :

• First 7 bits must always be set to '0'.• If CAN id type in the CANopen instance is set to standard only the following value is allowed :

◦ COB-ID base client->server : 0x600◦ COB-ID base server->client : 0x580

• If CAN id type in the CANopen instance is set to extended the following values are allowed :◦ COB-ID base client->server : 0x600 and any value equal or greater than 0x800◦ COB-ID base server->client : 0x580 and any value equal or greater than 0x800

SDO client requests can request the value of, or change value of any internal object dictionary entry.

It is recommended that server channel be used for peer-to-peer communication. Only one server and one client should communicate over single channel

Block Parameters


SDO Server Reference String Name of associated SDO server.

Channel Name String Unique name of SDO server channel.

COB-ID Base Client->Server Numeric COB-ID base of this SDO servers's client to server ID.

COB-ID Base Server->Client Numeric COB-ID base of this SDO servers's server to client ID.


Woodward Custom CANopen SDO Server Download Request Trigger

This trigger is called when SDO server has received data as a result of SDO download transaction.

Block ID

CANopen SDO Server Download Request Trigger

Library


Description

This trigger is called when SDO server has received data as a result of an SDO download transaction. It allows previewing the data before storing it and customization of SDO server response. It is required to have a configured CANopen SDO server instance and CANopen SDO server channel in order for the trigger to execute. It is only allowed to reference internal CANopen object dictionary entries with a writable access type.

The trigger could be used either as an indication of a received request or as an initiator of CANopen SDO server response on request block. Details on how to initiate a response are in CANopen SDO server response on request help documentation. Processing received data is only possible inside function call subsystem as in the below example.

Block Parameters


OD Entry Reference String Name of associated internal CANopen object dictionary entry.








Woodward Custom CANopen SDO Server Instance

This block enables SDO server capabilities.

Block ID

CANopen SDO Server Instance

Library


Description

This block enables SDO server capabilites for the referenced CANopen instance. It is necessary to use this block if SDO server channels are used. There can be only one SDO server associated with a single CANopen instance definition. This block is neccessary in an application for that application to receive SDO upload and download requests from CANopen clients.

Block Parameters



Instance Name String Unique name of SDO server instance.


Woodward Custom CANopen SDO Server Response on Request

This block allows to send a response on received SDO upload/download request.

Block ID

CANopen SDO Server Response on Request

Library


Description

This block creates a CANopen SDO server response on either download or upload request. If a value other than 0 is provided to the response input port, the SDO upload or download request is rejected and the non zero value is used as the abort code in the subsequent abort response message.

The intended application configuration is to connect this block to an SDO server download request trigger or an CANopen SDO server upload request trigger.

Response to upload request:

Response to Download request:


Woodward Custom CANopen SDO Server Upload Request Trigger

This trigger is called when an SDO Server receives an SDO upload request.

Block ID

CANopen SDO Server Upload Request Trigger

Library


Description

This trigger is called when SDO server receives an SDO upload request. It allows customization of a SDO server response. It is required to have a configured CANopen SDO server instance and CANopen SDO server channel in order for the trigger to exeucte. It is only allowed to reference readable internal CANopen object dictionary entries.

The trigger could be used either as an indication of a received request or as an initiator of CANopen SDO server response on request block. Details on how to initiate a response are in CANopen SDO server response on request help documentation. Processing received data is only possible inside function call subsystem as in the below example.

Block Parameters


OD Entry Reference String Name of associated internal CANopen object dictionary entry.

Trigger Name String Name of created trigger name. Parameter is optional, if no name is provided in the edit field the trigger name is generated automatically.







Woodward Custom CANopen SDO Upload

This block defines SDO client upload transmission.

Block ID

CANopen SDO Upload

Library


Description

The execution of this block will initiate the transmission of an SDO client upload request message. If at the time of execution, the referenced SDO client channel is not empty, the upload request will be queued and transmitted in the order it was received. The SDO client upload request

messsage requests the external object dictionary entry referenced in the external OD entry reference block mask field. The message is sent to a CANopen server with the node ID provided on the referenced SDO client channel instance.

Object dictionary entry should :

• be external• have access type is one of following: read-only or read-write• be associated with the same CANopen instance definition as the SDO client.

Protocol TypeSegmented SDO protocol sends visible string longer than 4 characters, otherwise SDO expedited protocol is used.

SDO upload request message is sent or queued with the rate inherited from the containing subsystem.

Block Parameters


SDO Client Channel Reference String Name of associated SDO client channel.

External OD entry reference String Name of associated object dictionary.

SDO Upload Name String Unique name of SDO upload block.


Woodward Custom CANopen SYNC Rx Trigger

This block creates a trigger that is called when a SYNC message is received.

Block ID

CANopen SYNC Rx Trigger

Library


Description

This block creates a trigger that will execute when a SYNC message is received with a node ID that matches the node ID defined in the SYNC COB-ID object dictionary entry defined in the referenced CANopen instance definition. If the referenced CANopen instance is configured as SYNC producer, the trigger executes on SYNC message transmission.

Block Parameters


CANopen Instance String Name of referenced CANopen instance definition.

Trigger Name String Name of created trigger. Parameter is optional, if no name is provided in the edit field the trigger name will be generated automatically.







Woodward Custom CANopen TX PDO

This block defines PDO mapping for transmitted messages.

Block ID

CANopen TX PDO

Library


Description

This block defines PDO mapping for transmitted messages.

COB ID Base value shall comply with CANopen specification :

• First 7 bits must always be set to '0'.• If CAN ID type in the CANopen instance is set to standard only 0x180, 0x200, 0x280, 0x300, 0x380, 0x400, 0x480 and 0x500 are allowed• If CAN ID type in the CANopen instance is set to extended 0x180, 0x200, 0x280, 0x300, 0x380, 0x400, 0x480, 0x500 and any value

equal or greater than 0x800 are allowed

TX PDO script definitionTX PDO must be defined by following structure format :

pdodb.name = 'TPDO_0';

pdodb.description = 'TPDO example';

pdodb.parameters.enable_pdo.data_source = 2;

pdodb.parameters.enable_pdo.data_default = true;

pdodb.parameters.enable_pdo.data_datastore_name = 'enable_ds';

pdodb.parameters.node_id.data_source = 2;

pdodb.parameters.node_id.data_default = uint8(3);

pdodb.parameters.node_id.data_datastore_name = 'nodeid_ds';

pdodb.parameters.sync_events_before_tx.data_source = 2;

pdodb.parameters.sync_events_before_tx.data_default = uint8(3);

pdodb.parameters.sync_events_before_tx.data_datastore_name = 'nodeid_ds';

pdodb.parameters.transmission_rate.data_source = 2;

pdodb.parameters.transmission_rate.data_default = int16(100);

pdodb.parameters.transmission_rate.data_datastore_name = 'Transmission_Rate_For_PDO_0';









Transmit PDO definition script examples are included with CANopen block set. The suggested arrangement is to have all TX PDO entries associated with the same CANopen instance in a single file. However it is possible to organize it differently as long as the resulting structure, which is used as a TX PDO Data Script definition, has the same format as the above example.

Description of script parameters (if not marked as optional the parameter is mandatory):

• name - unique name of TX PDO entry• description - brief description, optional parameter• parameters - necessary configuration parameters

◦ enable_pdo - enable PDO parameter

◾ data_source - source of enable PDO value


◾ 2 - port

◾ 3 - data store

◾ data_default - default value of enable PDO

◾ data_datastore_name - name of the data store where enable PDO is stored, only used when selected data_source is data store

◦ node_id - node ID of PDO message, value must be within the range of 1 - 127

◾ data_source - source of node ID value


◾ 2 - port

◾ 3 - data store

◾ data_default - default value of node ID

◾ data_datastore_name - name of data store where node ID is stored, only used when selected data_source is data store◦ sync_events_before_tx - SYNC events before TX parameter. It is used only when selected transmission type is synchronous

cyclical. It defines how many SYNC events must occur before PDO is transmitted.

◾ data_source - source of SYNC events before TX


◾ 2 - port

◾ 3 - data store

◾ data_default - default value of SYNC events before TX, must be within the range of 1 - 240

◾ data_datastore_name - name of data store where SYNC events before TX is stored, only used when selected data_source is data store

◦ transmission_rate - Transmission rate parameter, value in milliseconds. It is only used when selected transmission type is asynchronous manufacturer specific. It defines how often PDO message is transmitted. When 0 it is disabled. When -1 it is sent periodically with rate inherited from containing subsystem.

◾ data_source - source of transmission rate


◾ 2 - port

◾ 3 - data store

◾ data_default - default value of node ID

◾ data_datastore_name - name of data store where node ID is stored, only used when selected data_source is data store• fields - describes PDO mapping

◦ data_od_entry_name - name of object dictionary entry◦ start_bit - indicates where object dictionary entry value is placed in PDO frame

Block Parameters



COB-ID Base Numeric COB-ID Base value.

Transmission Type Drop down • SYNC_ACYCLIC - data is sent on every SYNC message received

• SYNC_CYCLIC - data is sent after defined number of SYNC messages are received

• ASYNC_MFC_SPEC - data is sent with defined rate

Data Script definition String Evaluates to TX PDO definition specified in the example script.


Documents

Woodward Custom CANopen Instance Definition