Suppressing Computations By Filtering Out Events

On this page…
When to Suppress Computations How to Set Up Event Filter Blocks Behavior of Event Filter Blocks Evaluating the Behavior Examples That Use Event Filter Blocks

When to Suppress Computations

This section describes situations in which you should consider selectively preventing execution of an Atomic Subsystem block that has event-based input signals.

Note   If the computations that you want to suppress are in a Function-Call Subsystem block instead of an Atomic Subsystem block, see Conditionalizing Events.

States and Persistent Variables in Computation

When the computation uses persistent variables of a MATLAB function, Memory blocks, or other blocks with state, consider whether performing the computation at inappropriate points in the simulation causes it to store the wrong data for future use or corrupt the state of a block. If that issue affects your computation, try one of these solutions:

• Introduce additional logic in your model to prevent the subsystem from executing or prevent it from corrupting a variable or state.

• Use the techniques in How to Set Up Event Filter Blocks. The techniques are applicable when you can characterize the appropriate points at which to perform the computation, in terms of a type of signal-based event of an input to an Atomic Subsystem block. For example, suppose increases in a signal value are appropriate points at which to perform the computation, while other sample time hits are not.

For an example that uses the solution involving the Event Filter block, see the model in Example: Observing Service Completions. The model uses a MATLAB function that compares the current and previous values of the input arguments. At the end, the function stores the current values in persistent variables, to use (as previous values) in the next invocation of the function. If the example invoked the function upon irrelevant sample time hits in the second input argument, the function inappropriately overwrites the stored values and causes the next invocation of the function to produce incorrect results. To avoid this issue, the example uses the Event Filter block to avoid invoking the function when the second input argument has sample time hits that are not increases in value.

Logic Corresponding to Changes or Triggers

Execute an Atomic Subsystem block when a particular input signal has a particular type of signal-based event, and not when the signal has other types of events, as in the following cases:

• When your implementation of the subsystem implicitly assumes that the signal has had a particular type of event.

• When your model requires the result of the computation only when the signal has had a particular type of event.

For example, if you want the simulation to respond to worsening backlogs in a queue by recomputing a routing path, the relevant signal-based events of the queue length signal are the increases, not decreases or repeated values. When the queue length increases, perform the computation, thereby avoiding disrupting the routing when the queue length does not increase.

Back to Top

How to Set Up Event Filter Blocks

The Event Filter block enables you to adjust the behavior of an Atomic Subsystem block by restricting the type of signal-based events that cause the subsystem to execute. The restriction applies to the signal that connects to a particular input port of the Atomic Subsystem block. To apply restrictions to multiple input ports, use multiple Event Filter blocks.

To set up such a restriction:

1. Locate the Atomic Subsystem input port whose behavior you want to adjust. Also, locate the signal that provides data for this input port.

2. Insert the Event Filter block into your model. Connect the data signal to the Event Filter input port. Connect the Event Filter output port to the Atomic Subsystem input port.

3. Configure the Event Filter block by setting parameters in its dialog box.

   If You Want the Subsystem to...	Set These Parameters
   Execute when the data signal exhibits a qualifying signal-based event, and the signal is real-valued	Set Execute atomic subsystem to one of these values: Upon sample time hit Upon trigger Upon change in signal In the case of triggers and changes, an additional parameter lets you specify the direction of the trigger or change: rising, falling, or either.
   Execute when the data signal exhibits a qualifying signal-based event, and the signal is complex-valued	Set Execute atomic subsystem to Upon sample time hit.
   Use the most recent value of the data signal, but the signal must not cause the subsystem to execute	Set Execute atomic subsystem to Never.

Back to Top

Behavior of Event Filter Blocks

When the input signal of an Event Filter block has a sample time hit, it does the following:

1. Updates its output signal with the value of the input signal. This value is available to the Atomic Subsystem block to which the Event Filter block connects.

2. Determines whether to execute the Atomic Subsystem block, based on the settings in the block dialog box of the Event Filter block. If the Event Filter block is not supposed to execute the Atomic Subsystem block, the Event Filter does nothing further, until the next sample time hit of the input signal. Otherwise, processing continues to the next step.

3. Determines when to execute the Atomic Subsystem block.

   • If you did not select the Resolve simultaneous signal updates according to event priority option, the Event Filter block executes the Atomic Subsystem block immediately.

   • If you select the Resolve simultaneous signal updates according to event priority option, the Event Filter block schedules an event on the event calendar. The event time is the current simulation time. The event priority is the value of the Event priority parameter in the Event Filter block. When the event calendar executes this event, the Atomic Subsystem block performs its computation.

   • If you select both the Resolve simultaneous signal updates according to event priority option, and the configuration parameter Prevent duplicate events on multiport blocks and branched signals, the software uses the Event priority parameter to help Simulink to sort blocks in the model. In this case, the software no longer schedules an event on the event calendar.

Back to Top

Evaluating the Behavior

Use the SimEvents debugger to examine any of these occurrences:

• A signal-based event causes an Atomic Subsystem block to execute immediately.

• An Event Filter block suppresses execution of the subsystem because a signal-based event is not a qualifying event.

You can also use the Instantaneous Event Counting Scope to view signal-based events of these signals:

• Input signal to an Event Filter block

• Input signal to an Atomic Subsystem block, when the signal is not the output of a Event Filter block

Back to Top

Examples That Use Event Filter Blocks

• Example: Resetting an Average Periodically

• Example: Observing Service Completions

• Example: Effects of Specifying Event Priorities

Back to Top

Performing Computations in Atomic Subsystems

Performing Computations in Function-Call Subsystems

© 1984-2012- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS