Do the maximum latency values of the Rate Transition block, as described in the Real-Time Workshop documentation, apply to non-real-time Simulink Simulations?

1 view (last 30 days)
I am using Rate Transition blocks in a non-real-time Simulink model
for simulation purposes only (no Real-Time Code Generation). In the
Real-Time-Workshop documentation for this block it says that the maximum
latency added by a deterministic fast-to-slow transition is one sample
period of the slower task. This should be equivalent to a Zero-Order-Hold
operation which adds zero latency. Also it says the maximum latency added
by a deterministic slow-to-fast transition is two sample periods of the
slower task. This should be equivalent to a Unit Delay operation which
adds one sample period of the slower task. My question is: do these
"maximum" latency values only apply to real-time-generated code or do they
also apply in my non-real-time Simulink model? i.e. do rate transition
latency values in my Simulink model, which currently behave like strict
zero-order-hold and unit-delay blocks (and zero latency in NoOp operations)
have the potential to change, especially under unknown circumstances. If
so then I need to find a different way to model them.
The exact rate transfers I care about are these:
- Deterministic Fast-to-Slow Zero-Order-Hold transfers - should be
exactly zero sample time delay of slower task.
- Deterministic Slow-to-Fast Unit Delay transfers - should be exactly
1 sample time delay of slower task.
- NoOp Slow-to-Fast transfers - should be exactly zero sample time
delay of slower task.
These need to behave exactly like this in non-real-time Simulink models.

Accepted Answer

MathWorks Support Team
MathWorks Support Team on 27 Jun 2009
The RTW documentation is applicable only to the operation of real time code. Here is the key terminology: maximum latency.
In the Real-Time-Workshop documentation for this block it says that the maximum
latency added by a deterministic fast-to-slow transition is one sample
period of the slower task. This should be equivalent to a Zero-Order-Hold operation which adds zero latency.
This is true if all the fast tasks executed before the slow task can push the execution of the slow task to right before its next scheduled execution. Here, latency is defined as how old the data is since it was sampled/computed. The block adds no latency; it is a function of the real-time execution.
Also it says the maximum latency added by a deterministic slow-to-fast transition is two sample periods of the slower task.
Again, we see a 1 sample period delay from the unit delay, and a maximum tasking latency of 1 slow sample period, thus the maximum is 2. Again, the sample could be a maximum of 2 sample periods old when it is read by the fast task.
Therefore, these maximum latency values only apply to the real-time generated code.

More Answers (0)

Categories

Find more on Multicore Processor Targets in Help Center and File Exchange

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!