Labview Reentrant and Non-reentrant vis
The native ability of labview programming language to execute parallel code could be restricted if a vi called more than once on the block diagram is not set appropriately – reentrant/non-reentrant execution. By default, all vis are configured as non-reentrant execution.
Reentrant vis are like multiplication or addition functions. we want to place as many functions as possible on block diagrams and expect them to execute without restrictions, Khurram Waris said
Difference between reentrant and non-reentrant vi
Non-reentrant vi means vi when placed in code block diagram more than once, the duplicate copies will not execute until call to the first copy is completed. Based on data flow status, vi that received data on input nodes first will execute. Reentrant vis mean duplicate copies do not wait for execution completion of their clone copies on code diagram.
When to use reentrant vis
Reentrant vis could dramatically increase application execution time. Whenever possible, one should opt to change vi execution to reentrant if similar vi is used on code diagram more than once. A particular example is a calculation algorithm that only manipulates result variable Z based on input variables. Such applications where vi task is only to carry out certain calculations, it is worth indeed to let these execute and prevent non-reentrant nature of subvis. To change execution type, select ‘Execution Options’ in vi properties dialog box.
Further, when a reentrant vi is placed on code diagram, a ‘copy’ of reentrant vi is placed on code diagram. When another reentrant vi is placed on code diagram, a clone copy is placed. Both copies run independently and are mutually exclusive copies. If we open up the first copy of reentrant vi, say Function.vi – then its front panel opens with title Function.vi:1 (clone). Second copy will open with title Function.vi:2(clone) and so on. In order to make changes to reentrant vi, original vi Function.vi needs to be opened from file through File menu. Changes will be reflected in clone copies. Each clone copy could also be individually and independently debugged.
Non-reentrant vis
When we do not want clone vi to be called on block diagram at same time, we must leave these as non-reentrant. A typical example is data acquisition where we want to make sure data is first read and logged/analysed prior replacing old data with new data. However, careful programming could be used to ensure data is not over written or race condition is not created.
Function Global Variables FGVs are typical example of non-reentrant vi. FGV could be created for states ‘Acquire’, ‘Display’ and being called various times on code diagram. We can rest assured race condition will not occur and program will execute without issues i.e run time errors. FGV are always non-reentrant and even if we try to change execution to reentrant, labview will return broken arrow. The inherent nature of FGV to fully block access to its duplicate clone copy on code diagram means it is a good programming choice and could be safely called number of times on a code diagram.
Programming for optimum performance and reliability requires careful consideration. Ability to be able to run vi in parallel yet being able to restrict access by choosing options in drop-down menus give programmer great flexibility and efficient environment to be productive. I hope, this article provides another way to improve vi execution.
