Trigger Blocks

From NewEagleWiki
Jump to navigation Jump to search

MotoHawk:Blocks:Critical Region

This MotoHawk® block is used to perform actions within a critical region, with interrupts disabled. This is necessary when passing signals between tasks, or when specific actions must not be interrupted by a higher priority task. First triggers Before Critical, then disables interrupts. Then triggers Critical. Then re-enables interrupts and triggers After Critical.

MotoHawk:Blocks:Event Call

This MotoHawk® block raises a built-in framework task event. Sending an event triggers an action which completes before the current event finishes. The sent event has the same priority as the caller. Posting an event triggers an action with the lowest priority, and it will not run until all other higher-priority tasks have completed.

MotoHawk:Blocks:Function Trigger Block

This MotoHawk® block triggers a Simulink Function-Call subsystem, with the built-in framework task event. This block is the root of each MotoHawk task. More than one trigger may be placed in a model hooking off of the same event. In this case, the 'Priority Order' can be used to order these independent triggers. If the priorities are the same, then the order is implementation dependent.

Checking 'This trigger is inside another triggered subsystem' will attempt to simulate the block inside of another triggered rate, when the rate is periodic. The most common reason to check this is to place a background periodic task inside of a foreground periodic task, or vice versa. The trigger from this block may occur in bursts, synchronized to the outer rate, while simulating, but will perform as expected on the target.

Note that 'This trigger is inside another triggered subsystem' should not be checked on top-level triggers, otherwise the block will not simulate at all.

If this trigger is used inside of a containing subsystem, normally the triggered subsystem will pause and resume based on the enable/disable status of the containing subsystem. Checking 'Trigger even when containing subsystem is disabled' will cause triggers to occur even while the parent is disabled. Note that this feature will not simulate, but will execute correctly on the target. The limitation of this block on modules can be found here Minimum RTI.

MotoHawk:Blocks:Subsystem Trigger

This MotoHawk® block outputs a function-call when the subsystem in which it is contained is initialized, enabled, or disabled. Standard subsystems are Initialized once at model startup, and never again. An enabled, triggered, action, or function-call subsystem, however, can be re-initialized and/or re-enabled several times during the course of execution. The behavior of states in such a subsystem is selected using the 'States when enabling' popup in the action, trigger, or enable block at the top of a conditionally executed subsystem.

The 'Initialize (First Time)' trigger is performed when the states are reset at startup. This hook is available even in non-Enabled Subsystems.

The 'Initialize (Every Time)' trigger is performed when the states are reset at startup and after re-enabling, according to the settings of the subsystem. This hook is available even in non-Enabled Subsystems, but would then only trigger once.

The 'Enable' trigger is performed when a subsystem is enabled, and is only available in Enabled Subsystems.

The 'Disable' trigger is performed when a subsystem is disabled, and is only available in Enabled Subsystems.

MotoHawk:Blocks:Trigger Definition

This MotoHawk® block sets up the base rates for ControlCore OS events, and settings for software queue sizes.

This block is the root of each MotoHawk task. More than one trigger may be placed in a model associated with the same event. In this case, use the 'Priority Order' to order these independent triggers. If the priorities are the same, then the order is implementation dependent.