Block Execution Order
Once the Simulink engine compiles the block diagram, it
creates a model.rtw file
(analogous to an object file generated from a C or C++ file). The model.rtw file
contains all the connection information of the model, as well as the
necessary signal attributes. Thus, the timing engine in can determine
when blocks with different rates should be executed.
You cannot override this execution order by directly calling
a block (in hand-written code) in a model. For example, in the next
figure the disconnected_trigger model on the left
has its trigger port connected to ground, which can lead to all blocks
inheriting a constant sample time. Calling the trigger function, f(),
directly from user code does not work correctly and should never be
done. Instead, you should use a function-call generator to properly
specify the rate at which f() should be executed,
as shown in the connected_trigger model on the
right.
Instead of the function-call generator, you could use any other
block that can drive the trigger port. Then, you should call the model's
main entry point to execute the trigger function.
For multirate models, a common use of the Real-Time Workshop product
is to build individual models separately and then hand-code the I/O
between the models. This approach places the burden of data consistency
between models on the developer of the models. Another approach is
to let the Simulink and Real-Time Workshop products ensure
data consistency between rates and generate multirate code for use
in a multitasking environment. The Simulink Rate Transition block
is able to interface both periodic and asynchronous signals. For a
description of the Real-Time Workshop libraries, see Handling Asynchronous Events.
For more information on multirate code generation, see Scheduling Considerations.
 | Latches for Subsystem Blocks | | Algebraic Loops |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
Get this Simulink Kit
Store 
