Raptor:CAN Trigger: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[ | [[Raptor-Platform|Return to the main Raptor page]] | ||
[[Raptor | [[Raptor-Dev-CAN-Library|Return to CAN page]] | ||
[[File:RaptorCANTrigger.jpg|right|frame|Raptor™ CAN Trigger]] | [[File:RaptorCANTrigger.jpg|right|frame|Raptor™ CAN Trigger]] | ||
| Line 7: | Line 7: | ||
== Description == | == Description == | ||
<p>The CAN trigger block is used to execute code when a CAN message arrives. The mailbox field is used to link the trigger block to a particular CAN receive block and will trigger its function call output every time a message matching the receive block is received. Multiple CAN trigger blocks can use the same mailbox, but each mailbox can have only one receive block.</p> | <p>The CAN trigger block is used to execute code when a CAN message arrives. The mailbox field is used to link the trigger block to a particular CAN receive block and will trigger its function call output every time a message matching the receive block is received. Multiple CAN trigger blocks can use the same mailbox, but each mailbox can have only one receive block.</p> | ||
<p>When CAN messages are sent into the module they are placed into a global CAN queue. The messages are then dispersed to the CAN queue within each CAN RX block. This is triggered during idle tasking between foreground executions. This allows the messages in the mailbox / CAN queue to iterate through multiple times during a task period.</p> | |||
== Outputs == | == Outputs == | ||
| Line 33: | Line 34: | ||
| String | | String | ||
| When a message is received on the specified mailbox, the block executes. | | When a message is received on the specified mailbox, the block executes. | ||
|- | |||
! This trigger is inside another triggered subsystem. | |||
| Checkbox | |||
| When checked, this indicates that the block is inside another triggered subsystem. | |||
|- | |- | ||
! Always enabled even when containing system is disabled. | ! Always enabled even when containing system is disabled. | ||
| | | Checkbox | ||
| When checked the trigger block will continue to operate even if the subsystem in which it is contained is disabled. | | When checked the trigger block will continue to operate even if the subsystem in which it is contained is disabled. | ||
|- | |- | ||
| Line 41: | Line 46: | ||
| Number | | Number | ||
| Positive number which determines the order in which multiple trigger blocks for the same mailbox are called. Triggers are executed from lowest to highest priority. | | Positive number which determines the order in which multiple trigger blocks for the same mailbox are called. Triggers are executed from lowest to highest priority. | ||
|- | |||
! Use Simulink Function | |||
| checkbox | |||
| Whether to use a Simulink Function or a triggered subsystem. | |||
If a Simulink Function is used, it should be placed somewhere along the calling block's path to model root. | |||
|- | |||
! CAN Trigger Simulink Function Name | |||
| String | |||
| Name of the Simulink Function to call when this block is triggered. | |||
|- | |||
! Create | |||
| button | |||
| Create a Simulink Function to use with the CAN Trigger block. | |||
Must first provide a valid function name. | |||
|- | |||
! Update | |||
| button | |||
| Update the listed Simulink Function's signature to 0 inputs & 0 outputs. | |||
The Simulink Function listed in the box must already exist. | |||
|} | |} | ||
Latest revision as of 17:27, 12 September 2023
Return to the main Raptor page
Description
The CAN trigger block is used to execute code when a CAN message arrives. The mailbox field is used to link the trigger block to a particular CAN receive block and will trigger its function call output every time a message matching the receive block is received. Multiple CAN trigger blocks can use the same mailbox, but each mailbox can have only one receive block.
When CAN messages are sent into the module they are placed into a global CAN queue. The messages are then dispersed to the CAN queue within each CAN RX block. This is triggered during idle tasking between foreground executions. This allows the messages in the mailbox / CAN queue to iterate through multiple times during a task period.
Outputs
| Output | Type | Description |
|---|---|---|
|
Output Trigger |
Function-Call |
Performs a function-call every time a message matching the receive block is received |
Parameters
| Parameter | Type | Description |
|---|---|---|
| Mailbox | String | When a message is received on the specified mailbox, the block executes. |
| This trigger is inside another triggered subsystem. | Checkbox | When checked, this indicates that the block is inside another triggered subsystem. |
| Always enabled even when containing system is disabled. | Checkbox | When checked the trigger block will continue to operate even if the subsystem in which it is contained is disabled. |
| Priority | Number | Positive number which determines the order in which multiple trigger blocks for the same mailbox are called. Triggers are executed from lowest to highest priority. |
| Use Simulink Function | checkbox | Whether to use a Simulink Function or a triggered subsystem.
If a Simulink Function is used, it should be placed somewhere along the calling block's path to model root. |
| CAN Trigger Simulink Function Name | String | Name of the Simulink Function to call when this block is triggered. |
| Create | button | Create a Simulink Function to use with the CAN Trigger block.
Must first provide a valid function name. |
| Update | button | Update the listed Simulink Function's signature to 0 inputs & 0 outputs.
The Simulink Function listed in the box must already exist. |