Raptor:CAN Trigger: Difference between revisions

From NewEagleWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[RaptorWiki|Return to the main Raptor page]]
[[Raptor-Platform|Return to the main Raptor page]]


[[Raptor:CAN|Return to CAN page]]
[[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.
|}
|}
== Supported Versions ==
* [[Raptor:Versions#2013a_0.0.1|Raptor 2013a_0.0.1]] and newer

Latest revision as of 17:27, 12 September 2023

Return to the main Raptor page

Return to CAN page

Raptor™ CAN Trigger

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.