Queue are no longer working accross different context (App Instances) in LV 8.2

[PJM_labview]

I was about to report this as a bug until I read the following addendum to the obtain queue primitive.

"Note If you obtain a queue reference in one application instance, you cannot use that queue reference in another application instance. If you attempt to use a queue reference in another application instance, LabVIEW returns error 1491."

The problem I was experiencing appears to be tied to this help addendum (I am not entirely sure).

In my application, I had a process running in one app instance (basically the NI.LV.Dialog) which was communicating with another one running in whichever app instance the user is currently developing his code. I was using named queue. Suddenly the code stopped working in LV 8.2 (everything was working just fine in 8.0), and in my case there was no error 1491 since I was not attempting to reuse the same refnum but to create a new one referring the same named queue.

I think that this new "feature" (bug?) is really unfortunate.

PJM

Note: The Notifiers seam to also be affected by the same issue.

[Grampa_of_Oliva_n_Eden]

I did not like rading that either and have not tried getting around it. The only thought I had re: this issue was I wonder if I could open a ref to the app instance and then open a ref to a VI in the target context and use invoke nodes to ge at the queue.

Sorry it the only idea I had.

Ben

[Aristos Queue]

The new behavior is the behavior 8.0 should have had. It was a bug that the queues, notifiers and events worked across contexts. In fact, they didn't always work, only most of the time, and they will work even less in the future as we go forward with intended features.

The way to communicate data from Application Instance A to Application Instance B is using network protocols such as VI Server, the TCP/IP prims, data socket, etc. Basic rule of thumb: If a given communication method could be used to communicate between two different computers over the network then they can be used for communicating between App Instances. Any feature of LV that allows data to be passed between App Instances on the same machine that does not work when the App Instances are on different machines should be reported as a bug.

[PJM_labview]

The new behavior is the behavior 8.0 should have had...

Oh well, I was afraid of that. Thanks for the quick answer.

PJM

[Tomi Maila]

Oh well, I was afraid of that. Thanks for the quick answer.

Then I need to make a product suggestion for at least events that would be automatically routed to other application contexts.

EDIT: Below is the suggestion I posted to NI product suggestions.

Events and queues no longer work between application contexts in LV 8.20. There should be a method for communicating between application instances or applications on different computers asynchronously. Calling remote VI reference is not enough. What I suggest is that you add a "remote event" functionality to LabVIEW.

Any event reference could be passed to a remote application instance. When passing the event instance to the remote end, a network address and application reference would be added to the reference so that remote end knows in which application the event is expected to occur. When such a remote event is then registered at the remote end, the remote end sends information to the event generating end that "I'll be listening to this event." Then the event generating end knows that when ever such an event occurs, it needs to send information to all registered remote applications. The remote applications can then catch the event.

Tomi

[Aristos Queue]

The TCP/IP primitives and the VI Server prims already provide ways to do asynchronous signaling from one app context to another, whether on the same machine or a remote machine. Depending upon what you're doing, you can use those comm methods to spawn user-defined events for a local event structure. I suspect that writing a decent library for remote events is possible using the G available today.

The possibility of remote events -- and other remote communications channels like remote queues -- does exist in the future of LV. Not in its immediate future, but the preparation for a more distributed LV is one of the big reasons for isolating the queues and events that exist today to a single app instance.

Basic principle: An app instance should always be treated as a separate machine. If the code works in separate app instances, then it should work on separate machines. Behind the scenes, LV might cheat for two app instances on the same computer, but the same VIs must still work if the app instances aren't co-machine.