Authoring MotoHawk Scripts for use with CAN Send and CAN Read
CAN Definition Script Parameters and Description
Message Name and Descriptions
| Parameter Field | Values | Comments/Description |
|---|---|---|
| name | Alpha-numeric text, single-quote enclosed. | Block display name. |
| description | Alpha-numeric text, single-quote enclosed. | Brief text used to document the CAN message. |
| protocol | Alpha-numeric text, single-quote enclosed. | Name of the protocol the CAN message uses. |
| module | Alpha-numeric text, single-quote enclosed. | Name of the source module. |
| bus_name | Alpha-numeric text, single-quote enclosed. | Reference to a CAN Definition block. The CAN resource selected by that CAN definition block is the bus to transmit on, or monitor for reception of the message. |
CAN ID Setup
| Parameter Field | Values | Comments/Description |
|---|---|---|
| id | Numeric | CAN message ID, either 11 or 29 bit. If not defined and not the first message defined in the definition script, this message will use the same ID as the previous CAN message defined in this file. |
| idext | Alpha-numeric text, single-quote enclosed. | Can either be 'STANDARD' if using 11 bit CAN message ID or 'EXTENDED' if using 29 bit CAN message ID. |
| idmask | Numeric | Indicates the relevant bits of a CAN ID to be checked before providing a received message to the application. A bit having a value of 1 in the mask will require the corresponding bit in the ID to be exactly that value (0 or 1) in order for the CAN message to be received and content provided to the CAN read block. Bits in the mask set to 0 means don't care and the corresponding bit in the CAN ID can be either 0 or 1 for the message to be received and provided to the CAN read block. |
| idinherit | boolean | Set the idinherit field to 1 to have a frame use the same CAN ID as the previous message in the definition script. Doing so will cause an update error if that same message also defines an idcontent field. This setting is ignored if the definition script is used for a CAN read block.. |
| idcontent | structure, see this section for descriptions of the available fields. | Each idcontent node defined in the CAN definition script will create one input port on CAN send blocks. This field allows the application to have runtime configuration of the portion of the CAN message ID defined by the idcontent.start_bit and idcontent.bit_length fields. This can be used to vary the CAN message ID for each of the messages defined in the CAN definition script. Please see motohawk_can_multisend_example.m for an example of how to do this. Each idcontent node defined for receive message definition scripts will create an output port on CAN read blocks. This will allow the application access to portions of the CAN message ID via that output port. |
Transmit Interval and Payload Configuration
| Parameter Field | Values | Comments/Description |
|---|---|---|
| interval | Numeric | Transmit period in milliseconds. Can be set to -1 to send when the CAN send block is executed. Defaults to -1 if not defined. |
| payload_size | Numeric | The number of bytes to send for a CAN send block. The minimum number of bytes required to accept a received CAN frame and provide it to the application through a CAN read block. Default value is 8 if not defined. |
| payload_value | Numeric | For CAN send blocks, any bits set in the payload mask will be hard-coded to be the corresponding bits of the payload value, regardless of any payload fields that may overlap it. For receives, this will result in a software filter requiring the bits set in the payload mask to be equal to those in the payload value. For an example of how to configure a payload value and mask in a CAN read block, please see motohawk_can_multiread_example.m. |
| payload_mask | Numeric | Indicates which bits of the payload_value are relevant for the payload_value of CAN read blocks, or which bits of the payload_value will be hard coded for CAN send block message. For an example of how to configure a payload value and mask in a CAN read block, please see motohawk_can_multiread_example.m. |
| fields | structure, see this section for descriptions of the available fields. | Describes individual fields in the payload for application control. Creates input ports for CAN send blocks, and output ports for CAN read blocks. See motohawk_can_example.m for examples of message fields. |
| use_fd | boolean | Indicates that the message is to be transmitted using CAN FD. Doing so will also require the start bit for message fields to be updated based on the CAN FD numbering (511-0 vs 63-0). All CAN Send messages used for a CAN Send block must be all CAN FD or all non CAN FD. There cannot be a mix of FD and non FD messages associated with the same CAN Send block. |
| use_brs | boolean | Indicates that the CAN FD message is to be sent using CAN FD baud rate switch. If this is enabled, use_fd must also be enabled as baud rate switch only works with CAN FD messages. |
Structure Parameters Used by idcontent and fields Sections
| Parameter Field | Values | Comments/Description |
|---|---|---|
| name | Alpha-numeric text, single-quote enclosed. | Name of the field or idcontent section. |
| units | Alpha-numeric text, single-quote enclosed. | Units used in the mask display table. |
| start_bit | Numeric | Indicates the least significant bit of the field, regardless of endian-ness. |
| bit_length | Numeric | Number of bits in the field, may spill across bytes. Fields with data_type UNSIGNED or SIGNED cannot exceed 32 bits. |
| byte_order | Alpha-numeric text, single-quote enclosed. | May be 'BIG_ENDIAN' or 'LITTLE_ENDIAN'. Defaults to 'BIG_ENDIAN' if not defined. Only 'BIG_ENDIAN' is valid for .idcontent{} fields. |
| data_type | Alpha-numeric text, single-quote enclosed. | May be one of 'UNSIGNED', 'SIGNED', 'FLOAT32', or 'FLOAT64'. Defaults to 'UNSIGNED' if not defined. |
| scale | Numeric | The scale factor. Since the same message description struct is used for both CAN send and CAN read blocks, the scale factor should not be thought of as a gain. Instead, think of it as the units of the signal in the payload on the CAN communication wire, such as 1/100 of a degree, for a signed integer representing degrees Kelvin, where 1245 (in the payload on the CAN communication wire) represents 12.45 degK (in Simulink-model units). Defaults to 1.0 if not defined. |
| offset | Numeric | Offset applied to the field or idcontent in engineering units. Defaults to 0.0 if not defined. |
| minimum | Numeric | Minimum signal value. If the signal value on transmit is less than this value, the minimum value is sent instead. Defaults to -inf if not defined. |
| maximum | Numeric | Maximum signal value. If the signal value on transmit is greater than this value, the maximum value is sent instead. Defaults to inf if not defined. |
CAN Single Frame Send and Receive
An example of sending or receiving a single CAN frame is provided in motohawk_can_example.m. This script can be used for both CAN send and CAN read blocks. The mandatory and optional fields are listed with descriptions beginning here. An example of sending a CAN FD message is provided in motohawk_can_fd_example.m. It also provides a path for authoring CAN definition scripts that can be used for both CAN FD and non CAN FD messages by taking a parameter and editing the fields based on that parameter to support CAN FD.
CAN Multi Frame Send
MotoHawk CAN send blocks allow for users to define multiple CAN frames to be sent from a single CAN send block. This can be accomplished by creating a cell array of message data in the CAN definition script. Multiple messages will be transmitted at the rate of the CAN send block Pacing Interval after the first defined frame is sent. The example script, motohawk_can_multisend_example.m provides an example of how to configure a CAN definition script to transmit multiple frames from one CAN send block.
Image of CAN send block with multiple idcontent nodes defined
In this example image, the least significant 4 bits of the CAN message ID are taken from the input ports, Node ID 1 and Node ID 2, for their respective CAN frames.
CAN Multi Frame Read
The MotoHawk CAN read blocks don't allow for the definition of multiple message by using a cell array the same way CAN send blocks do. Receiving multiple messages on the same CAN read block can be achieved by controlling the CAN ID and CAN mask parameters to allow a range of CAN message IDs to be received. In order to accomplish this, the idmask must identify a portion of the CAN ID that can be either 0 or 1. For example, when using standard CAN ID's (11 bit), a mask of 0x1F0 will allow any received frame with a CAN ID between 0x1F0 to 0x1FF inclusive to be received by the CAN read block referencing that definition script. Note that it is up to the user to define the data fields such that any message received by that block provides data to the application that makes sense to the application. If the data fields vary and parsing the received content in the application is not desired, then it will be necessary to use multiple CAN read blocks.
Image of CAN read block with payload mask in use to route received messages with the same CAN ID
This example has defined a payload mask and payload ID so that a received frame with CAN ID 0x1FF and a first byte of 0xAA would be routed to the first CAN read block pictured. A frame with CAN ID of 0x1FF and first payload byte of 0x55 would be routed to the second CAN read block. The example script, motohawk_can_multiread_example.m provides the content of the two CAN read blocks shown below.
