Reentrant VIs versus VI Templates

Introduction

Up to version 3.20, CS was heavily using VI templates for instanciating new objects and "threads". With version 3.21, it is recommended to use reentrant VIs with the option "Preallocate clone for each instance". This is in line with the recommendations by National Instruments and favorable in many cases.

VI Templates

VI templates have a few disadvantages.

• For technical reasons, they can't be member of libraries (lvlib).
• Their instances are also not a member of a library.
• In many cases, a clean selection of the access scope of subVIs that are used in the VI template is not possible.
• Instantiation of VIs from VI templates takes quite some time compared to running a reentrant VI.

As a main advantage, a VI instantiated from a VI template has a unique VI reference: One can put those references in an array and use the "Search 1D Array" function. This is a must for the object management within CS, since VI references are used as object references.

Reentrant VIs

In older LabVIEW versions, multiple instances of reentrant VIs always shared the same front panel and debugging was not possible. This was changed with LabVIEW 8.5, where the option of sharing and preallocating clones as well as debugging was introduced. When using sharing clones, the code of a reentrant VIs is shared amongst its instances reducing the memory footprint. Be aware, that this has implications when relying on features like "First Call?" or uninitiliazed shift-registers! When using preallocated clones, reentrant VIs almost work the same as with older LabVIEW versions but, when using this option, you may have an individual front panel for each instance.

When opening a reference to a reentrant VI (with preallocated clones) using the option "0x08", a reentrant VI behaves pretty much the same as an instance of a VI template. But such a reentrant VI has some advantages over the use of VI templates.

• It can be member of a library (lvlib) - and its instances are members too.
• As a consequence, the access scope of subVIs can be well choosen
• The instantiation is faster compared to instantiating a VI template.

However, there is one drawback compared to VI templates. References of instances of a reentrant VIs look different - their U32 typecasts are different. However, when two of such references are compared, the fundamental LabVIEW comparisons for equality always yield TRUE. This is probably due to the fact, that references of instances of a reentrant VI are (when comparing) treated as references to the same "mother"-VI. Don't use references of reentrant VIs with fundamental LabVIEW functions like "Equal?" or "Search 1D Array".

Consequences for CS

The object management of CS relies on unique VI references. Hence, the CSObj class must use instances of VI templates. All other classes may use reentrant VIs with preallocating clones instead. This was introduced with CS version 3.21. This version is fully backward compatible which means, that code using VI templates will continue to run. However, a migration of classes from VI templates to reentrant VIs is recommended.

Migration of Classes to Reentrant VIs

The following should be done.

1. Rename all *.vit to *.vi.
2. Change the VI properties in the category Execution.
   • uncheck Allow debugging
   • check Reentrant execution
   • select Preallocate clone for each instance ...
3. Add the VI to the library (lvlib) of the class - the access scope of the reentrant VI should be "public".
4. Adjust the "access scope" of subVIs to what it should be (forFriendsOnly, Private,...).
5. Constructor: When using an explicit VI name for creating a thread or panel, this must be adjusted from *.vit to *.vi.
6. In case the (GUI)class had a method "about me", you can remove that method and use the routine of the UtilityLib directly.
7. Test the class.

-- DietrichBeck - 25 Nov 2010