starting background task in labview

[MikeBowen]

Let me outline what I am looking to do.  I'm not sure if a background task is the best descriptor, but it's the one I'm coming up with.  it's tricky to explain, but here goes .....

When we start the program, we want to start the background task/alternate path/server (not sure which one best applies).  I do not want the program to wait for the background task to complete.  The program is then going to continue and do other processing.

The background task is going to do com port reads, filter them, and make the filtered results available to the original program.

Then when exiting the program the calling program would terminate the process.  An alternate process would also be needed for handle aborted cases.

Any ideas?

Mike

[Charles_CLA]

Sounds like a poster child for Actor Framework (www.ni.com/actorframework). If that's too complicated, then you can use an asynchronous call to start the VI.

[MikeBowen]

I was thinking of a server or a data socket.

[Charles_CLA]

Is there a specific requirement to run the tasks on separate machines? If not then I don't understand the overhead associated with data sockets. It is fairly simple to do a "Call and Forget" with LabVIEW where one program can invoke the other then move on without waiting for execution. In this mode, both the caller and the callee exist in the same application instance and simple data transfer mechanisms (queue, notifier) can be used to transfer data between the two. TCPIP and other methods are available but IMHO should be avoided if something simpler will work.

[MikeBowen]

There is more than one way to bake a cake, and with that said, the solution being presented here does solve other problems.  it is being used for a system where devices are stimulated and response is read on the com port.  When we scale it up we could conceivably be stimulating these devices on other computers.  In this case we could use the other machine to look for the data on the com port.  Hard to explain, but it does solve other problems. 

[Ben]

I suspect "VI Server >>> Run VI" method is at the bottom of the code linked by Charles.

Typically the VI is opened, controls are set using Set Control and then run using the method mentioned above.

Ben

[Charles_CLA]

As far as starting the process on another machine, I don't believe that is possible. You could make a small LabVIEW program that is design to run as a service and have it "listen" for a command to start the program. You could then transfer data via TCP, network shared variable, etc. Would it help for me to send you some code demonstrating asynchronous calls?

[MikeBowen]

Yes, please do.

Thanks

Mike

[Ben]

---

@Charles_CLA wrote:

As far as starting the process on another machine, I don't believe that is possible. You could make a small LabVIEW program that is design to run as a service and have it "listen" for a command to start the program. You could then transfer data via TCP, network shared variable, etc. Would it help for me to send you some code demonstrating asynchronous calls?

---

Hi Charles,

It USED TO BE POSSIBLE to use FTP to transfer VIs to remote machines then afterwards use VI Server to open (with complete file path) and run the VI on the remote machine.

Ben

[MikeBowen]

Why is it I know when I see the solution I'm going to go "SMACK, I COULD'VE HAD A V8?!?!?!?!?!?!?!?!?!?"