|Download Help (Windows Only)|
The Primary Control Loop (PCL) controls the timing of the VeriStand Engine by performing several execution steps. The PCL can run in one of two modes, where the only difference between the modes is the timing of steps that affect latency between the Model Execution Loop(s) and the PCL. You can select the PCL execution mode on the Controller configuration page in the System Explorer window.
|Parallel mode||Low Latency mode|
|Model-related steps during first PCL iteration||
|Model-related steps during second-nth PCL iteration||
||(Same steps as first iteration.)|
The following illustration shows the timing of execution steps the PCL takes in Parallel mode as it transfers data to and from a model. Notice the one-cycle delay between when a model executes and when the data it produces is available to the system.
As mentioned previously, in Parallel mode the PCL does not wait for models to finish executing before it executes other steps. As a result, models can continue executing even after the PCL has moved on to its next iteration. However, during the next iteration, the model must finish executing before the PCL is scheduled to read data from models. The following illustration shows how the VeriStand Engine imposes this deadline in Parallel mode.
If a model does not finish executing by the deadline, the VeriStand Engine does not schedule any models to start executing during that iteration. Also, the Model Count system channel increments.
|Tip To identify which model was late, monitor the Time Step Duration execution channel for each model. This is useful when a system contains multiple models, and you need to determine which one was late.|
If you configure a model to run at a decimation of the PCL rate, the VeriStand Engine enforces a deadline only when the decimation specifies it should finish executing. For example, if the target rate for the PCL is 100 Hz and the decimation for a model is 2 (therefore, it runs at 50 Hz), the VeriStand Engine does not impose a deadline after the first 100 Hz PCL iteration because, according to the decimation, the model is not scheduled to finish executing. However, after the second 100 Hz PCL iteration, when the model should be finished executing, the VeriStand Engine does impose a deadline. This happens on a per-model basis, so a different model in the system with a decimation of 1 would have a deadline imposed during every 100 Hz PCL iteration.
The following illustration shows the timing of execution steps the PCL takes in Low Latency mode as it transfers data to and from a model. Notice the PCL waits for the model to finish executing before it continues to execute, so other loops have access to data from models during the same iteration it was generated.
|Note National Instruments recommends you select this mode only if you need to minimize the latency between your inputs, model execution, and outputs. Waiting for Model Execution Loops to read, execute, and write on each iteration can significantly slow the execution speed of the system.|
For models that are decimated, the timing of execution steps the PCL takes in Low Latency mode differs slightly. A model that is decimated returns values on every Nth iteration of the PCL, when N represents the decimation factor, rather than every iteration as shown in the previous illustration. Additionally, passing data between decimated models causes an expected N tick delay where N represents the decimation factor.
|Note Since decimated models run in parallel, they ignore the execution order you set in the system definition file. However, you can add handshaking code to decimated models for which you want to implement an execution order.|
In Low Latency mode, model deadlines are not enforced because the PCL waits for models to finish executing before moving to the next iteration. In other words, other components of the VeriStand Engine, such as inlined hardware and custom devices, are delayed by late models, but data from models is guaranteed to be available when needed. Note that the Model Count and HP Count system channels increment when models cause the PCL to be late.
|Tip To identify which model caused the PCL to be late, monitor the Time Step Duration execution channel for each model. This is useful when a system contains multiple models, and you need to determine which one was late.|