Calling schedule task on server

[jyang72211]

I coded up an example based on our discussion.    LockAE.vi,  the vi itself, not the exe, will reside on the server that does not have LabVIEW but has only run-time engine.  Lock1.vi and Lock2.vi will simulate two clients.  When I was playing with it, Lock1 and Lock2 were ran on the same PC.  Let me know what you think.

BTW, is the way that I call the vi correct?  I believe I am calling it by reference, but I can also call it dynamically, right?  Which is the best way? Thanks!

LabVIEW2011

[nathand]

---

@jyang72211 wrote:

I coded up an example based on our discussion.    LockAE.vi,  the vi itself, not the exe, will reside on the server that does not have LabVIEW but has only run-time engine.  Lock1.vi and Lock2.vi will simulate two clients.  When I was playing with it, Lock1 and Lock2 were ran on the same PC.  Let me know what you think.

BTW, is the way that I call the vi correct?  I believe I am calling it by reference, but I can also call it dynamically, right?  Which is the best way? Thanks!

---

That's the right idea.  LockAE.vi will need to be included in the exe on the server computer, even if it's never called.  You can use the "always included" build option, but it will probably be easier to put a static reference to it somewhere in the server VI, so that it will be loaded into memory when the server runs.  Then you can obtain a reference using a string with the VI name, instead of the full path (which gets tricky with executables).  Also, in your real situation you will need to use Open Application Reference to get a reference to the remote application, then pass that reference to Open VI Reference.  You can do this even on the local machine, just wire "localhost" as the machine name.  You'll need to make sure VI Server is set up to accept TCP connections, and set the port number.

On a LabVIEW style note, it's possible to clean up some of your boolean operations.  It's never necessary to compare a boolean value against a boolean constant using equals.  If comparing against FALSE, just insert a NOT in the boolean wire.  When you wire the same value to both the "s" and "t" terminals of a select, there's probably a single boolean operation to do what you want (in this case, try an OR).

[jyang72211]

I have a few more questions.

1. Why does LockAE.vi need to be made into an EXE?  I was able to call it remotely when it is just a vi.

2. What did you mean by "you can use the "always included" build option, but it will probably be easier to put a static reference to it somewhere in the server VI, so that it will be loaded into memory when the server runs. Then you can obtain a reference using a string with the VI name, instead of the full path (which gets tricky with executables)".

3. Why do I have to do open application referenece and then open vi reference?  I don't really understand the differences between the two.

4. How do I setup VI server to accept TCP connection?

Thanks for your note about style.  I will clean it up.  

[nathand]

---

jyang72211 wrote:

1. Why does LockAE.vi need to be made into an EXE?  I was able to call it remotely when it is just a vi.

---

In your example, you're not really calling it remotely - you're connecting to the local running LabVIEW instance and telling it to load your VI.  On the server computer, without LabVIEW, this won't work - there's no application to connect to.  You might be able to make the server application accept connections and tell it to load a VI outside the application, but I think it's a lot easier just to build it into the application.

---

jyang72211 wrote:

2. What did you mean by "you can use the "always included" build option, but it will probably be easier to put a static reference to it somewhere in the server VI, so that it will be loaded into memory when the server runs. Then you can obtain a reference using a string with the VI name, instead of the full path (which gets tricky with executables)".

---

There are a couple of ways to force a VI to be included in an application even if it's not called as a subVI.  One is the "always included" option in the build specification.  Another is to place a static reference to it on the block diagram of some VI that is in the application.  Once a VI has been loaded into memory within an application instance, you can get a reference to it by passing a string containing just the VI name, instead of a path containing the entire path to that VI.  Within a compiled application, the path to a VI may not match the path outside the application, so it's easier to reference the VI by name.

---

@jyang72211 wrote:

3. Why do I have to do open application referenece and then open vi reference?  I don't really understand the differences between the two.

4. How do I setup VI server to accept TCP connection?

---

Open application reference lets you connect to LabVIEW, or a compiled LabVIEW application, running on a remote machine.  Open VI reference connects to a specific VI within an application instance.  If you don't use open VI reference, you'll get a connection to the local application instance - the one in which "Open VI Reference" executes - which may not have access to the right VI, and in your case won't even be on the same computer.  You can set up a project to accept VI server connections over TCP by right-clicking on the project name EDIT: My Computer (or another target) within the Project Explorer, and choosing Properties.  For an application, you'll need to set the right values in the application's INI file - see the help.

[jyang72211]

Thanks!  I will try it in a week or so.  I will keep this thread open for now, since I probably will have a few more questions.