Actor Framework Discussions

Showing results for 
Search instead for 
Did you mean: 

Best Solution for Actors between different executables

Hello All!


So I have an application where I need to talk to some legacy code and then a new application I wrote completely in Actor Framework. 


To launch the actor from the legacy code I am using the command line VI and passing the arguments in that I need.


This works fine, however, I now have a request from the user to be able to send a message back from the actor application back to the legacy code....


The problem is, the legacy code is a QMH and I tried passing the queue reference across the cmd line via typecasting to a U32, then flattening to a string. On the actor side the launcher unflattens the data to the U32, then I typecast it back to the queue reference type. The numbers are coming across but no queue. 


To make a long story short....what is the best available technique or tool to use to handle this completely in AF? Is the Launch Remote Actor still a viable solution? Network Endpoints? 


I know in the legacy code I am going to have to launch an actor proxy to handle the messaging back and forth between the executables and to get the message onto the legacy QMH. 


I tried everything I know of doing it the old way through VI Server and nothing worked. 


Apologies if this is a duplicate topic, I did a search and didn't immediately see something that was specific to what I am looking for.





Appreciate constructive criticism, it is there to help you succeed.
0 Kudos
Message 1 of 6

Queue References are only valid within the same application instance. You could creatively use VI server to invoke an enqueue vi (within the correct application instance passed into the Open VI Reference). Pass the data using control value set before using the runvi method to run the enqueue vi. Note that any other references you try to pass across boundaries won't work either.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at
0 Kudos
Message 2 of 6

If you are willing to modify your legacy code to include an actor proxy, then I'd suggest network endpoints.  They're pretty straightforward.  Your proxy would receive messages from a nested endpoint, and then translate those messages to QMH messages; the proxy holds the queue to the QMH.  I'd probably go this route, because you'll just have (AF) actors talking to (QMH) actors.  Even though the two types of actors are constructed differently, they are conceptually pretty similar, so that should go pretty smoothly.


If you want to stick with VI Server, there is a trick that will let you access a queue in a remote application instance.  You'll need to add a functional global VI (while loop and shift register) that holds the queue of interest.  One of the modes of this VI puts your message on the target queue.  When you start your legacy application, you pass the queue to the functional global.  When you want to send a message, use VI Server to open a reference to that functional global VI (it's in memory, so you just need its qualified name), and pass in any data you want to send along.  Then run the functional global VI, which sends the message.  (Launch Remote Actor uses this trick.)  It's fiddley, and you get to play games with LabVIEW contexts and keeping VIs in memory (harder than it sounds in an EXE), but it works.


Personally, I'd go with network endpoints, but the VI Server trick is an option.



0 Kudos
Message 3 of 6



I have already started working on the network endpoints this morning as it made the most sense. I haven't dealt with this library very much and so obviously I am clunking through it. 

We went over it in the AF course you taught so I am going back through my manual as a reference. 


Both of these application executables will reside on the same PC and communicate through network streams so that shouldnt be a problem. 


What I always get lost on is I have a abstract message that I need to invoke on the target so that when a button is push, it sends the message back across the network, and the caller then runs that message to do what needs to be done.


The part I always get lost on...does the network stream have to have the msg class for this message or does it stay in the proxy?


Another question, on the caller side, I made a proxy that is just called a "handler", this proxy launches the network endpoint on the caller side. On the target side, I basically made the top level actor that gets launched when the app runs the proxy, and it launches the network endpoint. 


Did I miss anything? I just tried to run it and noticed that the network endpoint timed out...I have the names correct and for the address I entered "localhost".


The caller side is the listener, and I made the external launched application (target) the initiator. 


***Update*** I was able to get it to work in the development environment but not as an executable....I think I am missing something. Does it have to do with the stream and the context property?

Appreciate constructive criticism, it is there to help you succeed.
0 Kudos
Message 4 of 6

Thank you Allen for explaining the VI server trick much clearer than I did. I agree the Network endpoint is probably a better solution.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at
0 Kudos
Message 5 of 6

Hi, I have a similar application. I used a global variable to pass AF data back to legacy VI. 

0 Kudos
Message 6 of 6