Jump to content

Threading in LabVIEW


Recommended Posts

In JAVA threads are programmed like this:

class ThreadDemo extends Thread {
   private Thread t;
   private String threadName;
   
   ThreadDemo( String name){
       threadName = name;
       System.out.println("Creating " +  threadName );
   }
   public void run() {
      System.out.println("Running " +  threadName );
      try {
         for(int i = 4; i > 0; i--) {
            System.out.println("Thread: " + threadName + ", " + i);
            // Let the thread sleep for a while.
            Thread.sleep(50);
         }
     } catch (InterruptedException e) {
         System.out.println("Thread " +  threadName + " interrupted.");
     }
     System.out.println("Thread " +  threadName + " exiting.");
   }
   
   public void start ()
   {
      System.out.println("Starting " +  threadName );
      if (t == null)
      {
         t = new Thread (this, threadName);
         t.start ();
      }
   }

}

public class TestThread {
   public static void main(String args[]) {
   
      ThreadDemo T1 = new ThreadDemo( "Thread-1");
      T1.start();
      
      ThreadDemo T2 = new ThreadDemo( "Thread-2");
      T2.start();
   }   
}

Executing above code will produce following result:

Creating Thread-1
Starting Thread-1
Creating Thread-2
Starting Thread-2
Running Thread-1
Thread: Thread-1, 4
Running Thread-2
Thread: Thread-2, 4
Thread: Thread-1, 3
Thread: Thread-2, 3
Thread: Thread-1, 2
Thread: Thread-2, 2
Thread: Thread-1, 1
Thread: Thread-2, 1
Thread Thread-1 exiting.
Thread Thread-2 exiting.

Is this possible in LabVIEW OO? If so where can I find some more information/ sample code?

I would like to have two classes, the thread and the class that starts the thread(s).

Thanks in advance!
 

Edited by barlaw
Link to comment

Is this possible in LabVIEW OO? If so where can I find some more information/ sample code?

I would like to have two classes, the thread and the class that starts the thread(s).

 

 

No and you can't (nor should you want to)

 

Text-based programmers must learn new, complex programming practices to create a multithreaded application. However, all LabVIEW applications are automatically multithreaded without any code modifications.

 

LabVIEW Threading Model.

 

For a detailed technical description see section 9.7 of this document

Edited by ShaunR
Link to comment

When I like to run things in different thread, and don’t like to make a fixed amount of while loops on my diagram. I use Active Objects.

I’ve created a demo application that does exactly what your Java Code is doing.

To be able to do this quick I use GDS which will make 80% of the code for me.

post-941-0-84804100-1411436999_thumb.png

 

Cheers,

Mike

Threads.zip

Link to comment

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

  • You create a worker class (a LabVIEW VI that does the actual work, e.g. calculations).
  • You start one or more instances of this worker-VI from you main VI (or even from the worker VI itself).

I use this technology to let my users choose, how many heavy-duty-threads a program should start: only one if they are actively using their computer or up to 8 if they run the program during their lunch break or a meeting and they don't need the computer.

 

In your JAVA-example, you use the call-and-forget strategy, e.g. the workers do not return anything. In LabVIEW you can also use the call-and-collect strategy. Here every worker returns values that you can receive via the wait-on-asynchronous-call node. This node can be placed anywhere in your program, it does not have to be in the VI that started the worker-VI.

 

Regards,

 

Sebastian

  • Like 1
Link to comment

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

  • You create a worker class (a LabVIEW VI that does the actual work, e.g. calculations).
  • You start one or more instances of this worker-VI from you main VI (or even from the worker VI itself).

I use this technology to let my users choose, how many heavy-duty-threads a program should start: only one if they are actively using their computer or up to 8 if they run the program during their lunch break or a meeting and they don't need the computer.

 

In your JAVA-example, you use the call-and-forget strategy, e.g. the workers do not return anything. In LabVIEW you can also use the call-and-collect strategy. Here every worker returns values that you can receive via the wait-on-asynchronous-call node. This node can be placed anywhere in your program, it does not have to be in the VI that started the worker-VI.

 

Regards,

 

Sebastian

 

I guess I was stuck in 8.6 for so long that I never learned this. Thanks!  :worshippy:

Link to comment

I guess I was stuck in 8.6 for so long that I never learned this. Thanks!  :worshippy:

Welcome to the future.  You probably don't need me saying this but 8.6 was released over 6 years ago.  Not that that means you need to upgrade but there's a bunch of good stuff since then.  Oh and I think things like Call and Forget and the Static VI reference were added in LabVIEW 2011, someone correct me if I'm wrong.

Link to comment

Just a warning about using ACBR nodes, as this was an issue I was bit by recently. It sometimes causes project hanging problems.

 

http://digital.ni.com/public.nsf/allkb/2EE8B4884922F2E686257D580053BDB1

 

The Knowledge Base article says it primarily affects 2013 and 2014, but I suspect that's because the bug is most apparent when using AF, and Launch Actor was modified in 2013.

 

I don't think that guarantees the bug wouldn't appear in older versions if you started using ACBR nodes in different ways, just that mostly AF users have noticed the bug. You PROBABLY won't ever see this problem arise, but if you do, the ACBR node is a good place to check for problems.

Link to comment

....... I think a lot of people would disagree with that, but that's probably a topic for another thread :)

LabVIEWs OOP (Think VI server) is nearly perfect IMHO. Incredibly readable and intuitive. LVOOP, however, has plenty of room for improvement. It is important to distinguish between the two.

 

We also get into questions of is LVOOP the problem or is the IDE the problem...

 

...and here we go....let me just trail off

Edited by GregFreeman
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.