MotoHawk:Blocks:CAN Send Message Block
Contents
Send CAN Messages
This MotoHawk™ block will pack and transmit one or more CAN messages on the selected CAN channel.
Block ID
Send CAN Messages
Library
MotoHawk_lib/CAN Blocks
Description
Can Message block content and input stypes are determined by the Message definition file.
Block Parameters
| Parameter Field | Values | Comments/Description |
| Name | Alpha-numeric text, single-quote enclosed | Specify physical channel on which to send, matching "Name" entry in CAN Definition block. No special characters, such as spaces, dashes, commas (underscore allowed) |
| Message Definition | Identify message definition file. See motohawk_can_example.m | A structure or a cell array of structures describing all of the details of 1 or more CAN messages. |
| Pacing Interval [ms] | Numeric | Insert time to delay between transmitting messages for a multiple message group. The pacing interval will insert the selected amount of time between each message if an array of messages has been specified. The group of messages will be transmitted at the interval defined in the message structure but will have an inter-message delay of the Pacing Interval. If the number of messages multiplied by the pacing interval is longer than the message interval, the latter messages will be dropped, the cycle restarted with the first message in the group. |
| Label Wires with Field Names | Check Box (enable) | Select this checkbox to cause the field names to be applied to the wires leading into the block. |
Interval
The interval in the .m file can be set to -1 to inherit the rate of the subsystem which contains the CAN Send block. The interval can also be set to a fixed value which sets the minimum time to be waited before a message is sent.
On the Classic Modules, 48, 80, and 128 pin, there is a 'fuzz' time that is hardcoded to be 500us subtracted from this time. This means a task will send the message if the time since the last message was sent is greater than the interval minus the “fuzz”. So a 100ms interval will result in a message being sent if 99.5 or more milliseconds have elapsed since the last time the message was sent.
The interval is evaluated at the rate defined by the subystem that houses the MotoHawk CAN Send block.
Scheduling is affected by both the granularity of the trigger that houses the CAN Send block and also by the other execution that is occuring within the system. CPU load can have an impact on the observed interval and a delay of up to one trigger rate is possible. Below is an example of an extreme case:
Consider a system with a 20ms trigger. Normally there is 5ms of work executed and then the expiry check occurs. Every now and then there is some variable work that executes too. In my example this is also 5ms of work. The additional delay of 5ms means that when I next check for expiry under normal loading I fail the expiry test because 100ms has not yet expired. Thus the message is delayed by the execution interval, which in my case is 20ms. The variable work would be of no consequence if it executed in the earlier trigger. It is because it executes before the test that will expire that we have the problem.
The work in the example is shown as being one after the other, the more typical case is a combination of the two. There is the work being executed in higher priority threads in combination with any work that executes in the same thread as the MotoHawk Send CAN Message block that is variable in its execution. Execution of higher priority work looks the same as executing a 1ms algorithm only some of the time before the MotoHawk Send CAN Message block executes.
Things that can be tried to minimize the chance of the delay without changing the interval 1. Execute in the highest priority time thread available. 2. Uses the smallest interval available. The small interval will minimize how late a message can be. 3. Placing execution of the MotoHawk Send CAN Message blocks early in the rate group can help to offset variability introduced by variable work executed at the same priority, but before the transmit. However this can impact what data is being rendered too. For, example there might be a desire to execute calculations and then send the message.
The interval can also be changed given knowledge of how the system executes. For example, if we are executing the MotoHawk Send CAN Message block in a 20ms trigger period(like in the example) then by altering the interval to be 90ms then would pretty much guarantee that the message will be sent every 5th trigger execution. Four trigger periods will not be long enough, 5 will always be too long.
Using the smallest time domain interval available in combination with a modified interval will give the best results while also protecting against changes in the future.
