Example Code

LabVIEW alternative to Object Oriented Programming - Daemon Timer Example

Products and Environment

This section reflects the products and operating system used to create the example.

To download NI software, including the products shown below, visit ni.com/downloads.

    Software

  • LabVIEW

Code and Documents

Attachment

Overview: Demonstrates how to create multiple timers and manage them. 

Description

There are times when you want to define a process and then spawn multiple instances of that process. With many programmers familiar with object oriented languages, the first place people think to start is with LV Object Oriented Programming (LV OOP). Whilst the aproach of OOP brings many advantages to large application development, for many LabVIEW use cases this is overkill, and using native LabVIEW programming principles you can impletement the functionality you require with less development time.

The key to this example is using the LV VI Server architecture to load a VI Template. You define your process or "class" in a normal VI, but when saving it you save it as a ".vit" not a ".vi". When you then programatically open the VI, because it is a template, it copies the template and creates a new unique VI. If you manage the references to the launched VI's (or daemons) you are able to communicate with each instance through VI Server.


Requirements: LabVIEW 2012 (or compatible). Hardware: none.


Steps to Implement or Execute Code:

1. Select the path to Timer.vit template file.
2. Run the VI.
3. Create new timer.
4. Get Time from Selected Timer.
5. Stop Selected Timer.
6. Stop the VI.
7. Stop the timer's VI separately.


Additional Information or References:  

 

LabVIEW alternative 2OOP-Daemon Timer Example FP.png

 

LabVIEW alternative 2OOP-Daemon Timer Example BD.png


**This document has been updated to meet the current required format for the NI Code Exchange.** 

Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.

Comments
Jon_Kokott
Member
Member
on

Respectfully, this is a bad idea for an application of any size.

Maintaining an application with this type of pattern will be problematic at best, and time consuming to be certain.

Code execution will be orders of magnitude slower that of other OO by reference design patterns (GOOP/LCOD/DVR.)

~Jon

------------------------------------
Jon Kokott
CLA, CLED, CTD, MCP C#