|LabVIEW 2015 Real-Time Module Help|
|LabVIEW 2016 Real-Time Module Help|
|LabVIEW 2017 Real-Time Module Help|
|LabVIEW 2018 Real-Time Module Help|
|LabVIEW 2019 Real-Time Module Help|
Separate deterministic tasks from non-deterministic tasks and place deterministic tasks in different VIs to ensure they receive enough processor resources. You can prioritize the VIs and then categorize them into one of the available execution systems to control the amount of processor resources each VI receives.
LabVIEW assigns each VI to an execution system thread according to the VI priority and execution system you specify. The threads execute on the processor accordingly.
You can change the priority of a VI by right-clicking the VI in the Project Explorer window and selecting Properties from the shortcut menu to open the VI Properties dialog box. Select Execution from the Category pull-down menu in the VI Properties dialog box to open the Execution page where you can set the priority of a VI. You can select from the following VI priorities, listed in order from lowest to highest, to assign VIs a priority level:
|Caution LabVIEW uses two separate but related priority schemes: VI priorities and timed structure priorities. Timed structure priorities are numeric, and a higher value represents a higher priority relative to other timed structures executing on the target. However, all timed structure priorities fall between the high and time-critical VI priority levels. To prevent undesired behavior, NI recommends using only one priority scheme in your application. If the application uses timed structures, keep all VIs at normal priority.|
Normal priority is the default priority for all VIs you create in LabVIEW. However, subVIs inherit the priority of the caller VI. For example, a subVI called in a deterministic VI runs at time-critical priority. The time-critical priority preempts all other priorities. A time-critical priority VI does not relinquish processor resources until it completes all tasks. However, a deterministic VI can explicitly relinquish control of processor resources to ensure that the VI does not monopolize the processor resources.
|Note Because time-critical priority VIs cannot preempt each other, create only one deterministic VI per CPU to guarantee deterministic behavior.|
In addition to the five priority levels listed above, you can set VIs to subroutine priority. VIs set for subroutine priority do not share execution time with other VIs. When a VI runs at the subroutine priority level, it effectively takes control of the thread in which it is running, and it runs in the same thread as its caller. No other VI can run in that thread until the subroutine VI finishes running, even if the other VI is at the subroutine priority level.
You can change the execution system of a VI by right-clicking the VI in the Project Explorer window and selecting Properties from the shortcut menu to open the VI Properties dialog box. Select Execution from the Category pull-down menu in the VI Properties dialog box to open the Execution page where you can set the execution system of a VI. LabVIEW has the following six execution systems to help you categorize VIs:
By default, all VIs run in the standard execution system, but you can assign VIs to other execution systems. In addition to the six execution systems, you also can assign subVIs to the same as caller execution system. The same as caller execution system runs subVIs in the same execution system as the top-level VI that called the subVI.
Every execution system except user interface has a thread queue to execute VIs at the priority you specify. For example, if you have three VIs assigned to an execution system, at any time, one VI might run as the other two wait in the queue. Assuming all VIs have the same priority, one thread runs for a certain amount of time. The thread then moves to the end of the queue, and the next thread runs. When a thread completes, the execution system removes the thread from the queue.
The user interface execution system handles all user interface tasks. The other execution systems are not responsible for managing the user interface. If a VI needs to update the user interface, the execution system passes the task responsibility to the user interface execution system, which updates the user interface.
Because of the preemptive nature of deterministic VIs, they can monopolize processor resources. A deterministic VI might use all of the processor resources, not allowing lower priority tasks, such as lower priority VIs and the FTP server of an RT target, to execute.
You must build deterministic VIs that periodically yield to allow lower priority tasks to execute without affecting the determinism of the deterministic code. By timing a deterministic VI, you can ensure the VI will cooperatively relinquish processor resources.
|Note In applications running on multiple CPU systems, you can manually assign deterministic Timed Loops to dedicated processors. If you use a Timed Loop to target a VI to a dedicated CPU, the VI can safely monopolize processor resources without adversely affecting other tasks.|