LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Communication between two fully independent VI's

Dear All,

I am designing LV program which will control a standard astronomy camera (ASI ZWO if someone is interested). I have designed one VI_1 based on Queued Message Handler template in order to control camera settings and monitor chip temperature. I need another independent VI_2 which will work in parallel, which will collect raw images from the first VI and execute some DSP calculations on this images. I need access to front panels of both VIs. I also want the VI_1 to work all the time since it also controls the camera cooler. Second VI_2 should work as kind of a plugin for VI_1 since the DSP methods will change over time depending on measurement in progress (most likely I will create some new VI's for every measurement type).

 

For that:

I have used a global variable to store a notifier output in VI_1 with UHD image data

Kris_T_0-1575014657270.png

VI_2 reads the notifier and does the DSP and displays the data continuously.

Kris_T_1-1575014728586.png

Lossy communication is ok for me. Is there any better way to do this (better means faster communication)? Without globals?

0 Kudos
Message 1 of 11
(315 Views)

If one loop writes, and the other reads, why would you create a notifier and put it in a global? You might as well put the data in a global!

 

If the two VIs are really completely independent, a global of some sort is required. This could be for instance a named queue.

 

A functional global would also work, and it can easily be extended with all the gold plating you want.

 

Are the two VIs started by the same parent? If so, they are not completely independent. You can create an (unnamed!) queue, and pass the reference to the two VIs. Of course a notifier can also be used. Or a channel wire, that is actually made for this. I'd wrap the queues and notifier solutions in a class, so I can easily switch implementation (even dynamically), but that's just icing on the cake.

Message 2 of 11
(292 Views)

My first thought was to use global, however, this solution was very slow. I also had to provide some timeout mechanism. Notifier seams to work better here. 

 

Both VIs are started separately, VI_1 is started first usually. There is no additional parent parent VI.

 

Anyway I will try with your suggestions, named que or channel wire. Classes maybe later 🙂

Thanks

0 Kudos
Message 3 of 11
(265 Views)

@Kris_T wrote:

My first thought was to use global, however, this solution was very slow. I also had to provide some timeout mechanism. Notifier seams to work better here. 


That is weird, globals should be pretty much as fast as you can get. You do get just a current value, so if you want any time out mechanism, they won't be an option.

 


@Kris_T wrote:

Both VIs are started separately, VI_1 is started first usually. There is no additional parent parent VI.


The parent (only one is needed for VIs 😉) can pass something to both VIs.

 


@Kris_T wrote:

Anyway I will try with your suggestions, named que or channel wire. Classes maybe later


Use a named queue if your parent can't pass a normal queue. Don't use named queues unless you require a global accessible queue. Naming a queue will make it global, and often it's not intentional.

 

If you can pass a channel wire, you can pass an unnamed queue.

Message 4 of 11
(261 Views)

This is definitely "do-able".  One thing to ask is what you mean by "independent" -- are these loops running in a single PC under a single invocation of LabVIEW (something LabVIEW supports quite nicely!), or are these two independent LabVIEW programs running on two independent PCs, both connected to the same network?

 

I've done both of these.  When running two (or, in one case, up to 25) parallel processes on a single LabVIEW PC, there is only a single Front Panel, showing Process 1's Front Panel that includes a sub-Panel in which the Front Panel of the other Process (or Processes) is presented.  I happen to use Messenger Channels (I'm something of a "nut" about Channel Wires) for communication (my routines are based on what I call a CMH Design Pattern, a "Channel Messenger Handler"), with some "tricks" if I want to have the "Slave" CMH be run via Start Asynchronous Call (you cannot pass a Channel Wire into an Asynchronous Call, but you can "Cheat").  My latest routine has the Master call the Slave directly, so I don't have to worry about this.

 

The other method, two PCs running totally independent routines, is similar to running LabVIEW Real Time -- your Host routine runs LabVIEW and is the main "Manager", typically doing overall control and often File I/O.  You start another program on another PC, with its own Front Panel (or not, if you are doing RealTime).  I use Network Streams to establish two-way communication between these routines.  The Host waits for the Remote to announce itself and make connections, then starts sending Requests or whatever you need to do.  The Remote, of course, has its own Front Panel (and its own Display, it's a separate PC, after all).

 

Bob Schor

Message 5 of 11
(258 Views)

wiebe@CARYA wrote:


That is weird, globals should be pretty much as fast as you can get. You do get just a current value, so if you want any time out mechanism, they won't be an option.

 


So when I wired 2d array buffer (3000 x 2000 x I32) as global and displayed this global on a graph in VI_2 everything got very slow maybe because I just used while loop. With global in a timed loop it got better. But the notifier worked best as the while loop was executed only when there was something in the que. At least I think its work like that.    

 

There is no parent here. In my previous version I tried to make VI_2 as a subVI of VI_1 but when VI_2 panel was "on" and continuously updated I could not use VI_1 panel. 

 

The reason for two VIs is quite trivial. I need one VI to control camera easily and this controls take half of my screen. I need whole screen to be able to display data from the camera and DSP results, This preview has to work kind of in a "real time". During the preview i need to be able to change camera settings in VI_1 as well.  I will create other versions of VI_2 (for different DSP calculations ) and I need to be able to easily connect them to VI_1 while it is executing. So just after starting some version of VI_2 while VI_1 is already on I can see the preview and results. I use only one computer, one LabView instance and one camera.

0 Kudos
Message 6 of 11
(251 Views)

@Kris_T wrote:

wiebe@CARYA wrote:


That is weird, globals should be pretty much as fast as you can get. You do get just a current value, so if you want any time out mechanism, they won't be an option.

 


So when I wired 2d array buffer (3000 x 2000 x I32) as global and displayed this global on a graph in VI_2 everything got very slow maybe because I just used while loop. With global in a timed loop it got better. But the notifier worked best as the while loop was executed only when there was something in the que. At least I think its work like that.    

That explains things. A queue or notifier seem like a better fit.

 


@Kris_T wrote:There is no parent here. In my previous version I tried to make VI_2 as a subVI of VI_1 but when VI_2 panel was "on" and continuously updated I could not use VI_1 panel. 

So you manually start the two VIs? That seems a bit inconvenient.

 

You should be able to use a sub VI in another VI, but without details, all that can be said is you probably did it the wrong way.

 


@Kris_T wrote:
The reason for two VIs is quite trivial. I need one VI to control camera easily and this controls take half of my screen. I need whole screen to be able to display data from the camera and DSP results, This preview has to work kind of in a "real time". During the preview i need to be able to change camera settings in VI_1 as well.  I will create other versions of VI_2 (for different DSP calculations ) and I need to be able to easily connect them to VI_1 while it is executing. So just after starting some version of VI_2 while VI_1 is already on I can see the preview and results. I use only one computer, one LabView instance and one camera

Separating the two processes seem like a good idea!

 

I'd make a parent, that start the two VIs. I'd probably put the two front panels in two sub panels as well (set to fit to pane with a splitter between them).

Message 7 of 11
(242 Views)

wiebe@CARYA wrote:

That explains things. A queue or notifier seem like a better fit.

So I decided to keep the global notifier...

 


wiebe@CARYA wrote:

So you manually start the two VIs? That seems a bit inconvenient.

It is, however I will modify my VI_2 during the measurement, and VI_1 has to work to keep the camera cooler on. From what I understand I can not easily modify the subVI or use another subVI (e.g. with different path) while the parent VI is on since I need to call particular subVI "declered" in asychronous call. Probably there is a way to do it dynamically, however seams more complicated than just using global notifier and manually start any VI I want. 

 


wiebe@CARYA wrote:

You should be able to use a sub VI in another VI, but without details, all that can be said is you probably did it the wrong way.

 

So you are right I did this wrong previously. I have dug up this example:

Running-and-Communicating-Between-Two-Front-Panels 

and it appeared I have made some mistakes in implementing asynchronous call and setting subVI properties.

 

Anyway thank you for your help and please let me know If you have any other good ideas.

0 Kudos
Message 8 of 11
(196 Views)

Here's a simple example project (saved for 2017) that hopefully shows what Wiebe was describing - a "Parent VI.vi" calls two other VIs, and passes a queue reference into each.

One produces data (i.e., it is your camera) and the other consumes the data (plotting an intensity graph and calculating a mean value).

Hopefully it illustrates the idea well enough.

There are comments on the block diagrams explaining some decisions and the way in which the front panels are opened.

Message 9 of 11
(142 Views)

cbutcher,

Thank you for this example. It clarifies some things, indeed this solution looks nice and "clean", probably better than what I was doing. However, I have found that IMAQ Vision Module has dedicated VIs to control display window. Seams quite simple and Ill give it a try now. 

0 Kudos
Message 10 of 11
(65 Views)