Communication between two independently-running VIs launched through VI Server

[bmihura]

Here are two strategies for such communication, supposing you have a main VI and subVI launched through VI Server….

1. Using an Event Structure with no timeout, send User Events between the VIs.

Disadvantage: The “User Event” creating mechanism is very clumsy, scroll down in this link to see the picture:

http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/user_events/

2. Using an Event Structure with a small timeout (10 ms), poll for messages that are sent via queue and/or notifier.

[Trager]

What's wrong with the classical model using while loops and queue or notifier-based communication?  There's no reason to use an event structure with a timeout if you're using a receiver that can be set to timeout=-1 and thus will put the loop to sleep while waiting for a message.

[bmihura]

Nothing is wrong with the classical model; that's the way I've always done it. However, I've inherited a VI that has an Event structure and does not poll. I'd like to continue to not poll.

Setting the Event Structure's timeout to -1 causes it to never timeout, but it seems that the VI could still respond to queues and notifiers if they are placed outside the Event Structure. Is that the idea?

[Jarrod_S.]

User events are certainly a rather advanced topic in LabVIEW, but personally I really prefer them as a means of performing two-way communication between two VIs that already employ event structures. For instance, a great situation is where a parent VI loads a child VI into a subpanel. The parent VI can pass the child VI User Events created and registered in the parent VI so that the child VI can communicate to the parent VI, and also Event Registration refnums, so that the child VI can register them and receive communications from the parent. Great for two-way communication where you don't necessarily want a master/slave design architecture.

Queues and notifiers will also work perfectly well for you (I'd imagine) in a separate loop than the event structure. But at some point, you'll probably need to transfer that data into the event structure loop anyway, which will require either User Events or the Value (Signaling) property node for a control that has a Value Change event case registered.

[Joe_H]

Just to add something in here. correct me if I am wrong but I believe in LV8.20 you cannot have communication between EXE'S with named queues anylonger, because the EXE's are in different labview application instances.

[Jarrod_S.]

Could you ever communicate between two exe's using named queues? That would really surprise me. This should have nothing to do with LabVIEW's new concept of various application contexts. The idea is basicly that no two executables (LabVIEW-built or otherwise) can generally (there may be some exception) can share data held in their own memory space. Each application gets its own sandbox of memory that no other applications can touch.

So a Queue, named or not, resides in one exes sandbox and the other exe doesn't know it exists, period. Same thing with global variables or anything else stored in memory. What actually happens is that each LabVIEW-built executable loads a separate copy of the LabVIEW Run-Time engine into memory. At that point, they are completely independent entities.

Inter-application communication usually relies on some form of TCP communication. VI Server between built executables works this way.

Now, there are probably some instances where LabVIEW VIs themselves might lose direct communication pathways with each other due to being in different contexts. One example is an XControl, which runs in a separate application instance, and as such can't communicate with its owning VI through global variables and the like. That might be what you were thinking of. Hope this helps!

[RJW]

I've also been using extensively the Value (Signalling) property to communicate between multiple VIs, each of which uses event-structures, and all of which are running in a multithreaded configuration. The mechanism generally works well [impressively well] but I'm trying to create a simpler structure to test out some variations and in doing so  I find that the communication "hangs" and I am at a loss in understanding why.

In the main VI that handles the user interface there is a button [Main] that triggers an event that sets the Value (Signalling) property of another boolean control to true. There is a reference to this second boolean control and both VIs use it to access the control's state. In the second VI [running in parallel] there is a dynamic registration for the Value Change and an Event to handle it. In both VIs there are functions in the TimeOut events to increment and update display counters to confirm operation.  All of this seems as required and as specified in various Application notes, examples and manuals.

When I push the Main button the events in each VI are triggered sequentially [within several milliseconds] but this only works once: the user-interface is no longer responsive, the Stop button doesn't work and I have to push "Abort". However both VIs continue to run as the TimeOut events in each continue to increment & display the front panel counters. Presumably, as a guess, the front-panel is locked waiting for an event to complete but I don't know if that is the case and if it is how to ensure that it does complete. I've "fiddled" with the "Lock front panel until complete" on the event tab and the execution options for both VIs and various methods of setting / clearing each of the controls but without any success. The "structure" that I'm using in the mini-prototype-system seems to be identical to that in the main application but the former doesn't work but the latter does.

In passing, as a side question or observation on LabView [generally impressive], the company I work for has LabView 7 and we've purchased the upgrade to versions 8 / 8.2 which I've not yet had time to install. The application in LV7 has grown to the point of unmanageability [hence 8.2], partly due to bad programming practices [still learning]. However, part of the problem is that with the large number of controls & indicators on the front panel creating a new event means tediously scrolling through an overly long and unsorted list. As a suggestion or feature request [if not already implemented] sorting those available event sources and / or collapsing structures / clusters would be most useful - from my point of view anyway.

There is a ZIP file attached that provides some details of several variations.

Any assistance or suggestions for this problem will be most appreciated - thanks.

Jim