|Download Help (Windows Only)|
A model is set to run at a certain rate, or step size, as defined in the build options when the model is compiled. However, the rate at which the Model Interface API actually steps the model is determined by how often the Take Model Time Step VI executes in your application. As mentioned previously, you can use a Timed Loop to step the model at a specific rate to ensure this VI runs reliably and repeatedly.
In the following block diagram, each iteration of the Timed Loop must complete execution within the period specified. To calculate the period, the Get Model Period VI reads the compiled rate of the model in seconds. However, the Period input of the Timed Loop expects values in the same units as the 1 kHz clock timing source, so this application converts seconds to milliseconds.
|Note If the subdiagram of the Timed Loop completes execution within the period of the loop, the Timed Loop sleeps and allows any other code or structures to execute on the block diagram.|
The previous block diagram shows Timed Loop and Model Interface API features that allow you to control and monitor the timing of models in your application.
|Set the period of Timed Loop iterations/rate of model time steps.||Period input on Timed Loop|
|View how long the current time step of the model has been running.||Iteration Duration output on Timed Loop|
|View whether the previous iteration of the Timed Loop ran longer than the specified period.||Finished Late? [i-1] output on Timed Loop|
|View the time in the model.||Get Simulation Time VI|
Refer to the MIT Simple Load and Run Model VI in the labview\examples\Control and Simulation\Model Interface directory for example code that demonstrates these concepts.
Depending on the rate at which you call the Take Model Time Step VI, the rate at which the model actually executes might differ from the compiled rate. For example, even if the model was compiled to run at 100 Hz, you can set the Timed Loop period so that it runs at 1 kHz, or 10 times faster than real time. This means the model does not run in real time and is potentially unstable.
If both the controller and plant are simulated, such as in model-in-the-loop testing, running your model at a faster rate than the rate for which it was compiled can be desirable. Running faster than real time allows you to accomplish more simulation in a shorter amount of time. However, when you test with real hardware, as in hardware-in-the-loop testing, run your model at the rate for which it was compiled to accurately simulate the system.