Spawn a process in Labview 7.1

[H View Labs]

Interesting, but In <LabVIEW>\examples\viserver\runvi.llb\DateServerUsingReentrantRun.vi example the TCP connection references are passed to the reentrant handler instances exactly like that, using the Set Control Value Method! So, apparently, NI is convinced that this will work for sure, at least in a regular LV. Does it work on RT?

Stanislav Rumega, CLA

[shoneill]

Kevin,

Why don't you use the name of the spawned  VI as the queue name for passing values.  Each spawned VIT has a unique name in memory.  This name will be available to both the launching program and the VI itself.

This is what I do anyway when I want to do basically exactly what you've described previously.

Hope this helps

Shane.

[Kevin_Price]

Shane,

Thanks, but .vit templates aren't supported under RT, at least not for the Fieldpoint RT target.  I'm guessing you only saw my most recent post and not my earlier one that gives more detail and rationale about my migration from VIT's to poor-man's file-copying pseudo-VIT's, to reentrant vi's. 

So anyway, all the reentrant vi's would have the same name, no?  I'll check this out when I get back to the lab -- maybe you've found my magic bullet after all...

-Kevin P.

[H View Labs]

I think the most reasonable way is to use input/output queues' (RTFIFO's) for the communications between launched instances and the launcher, but those queues' names (or refnunums) should be passed to the instances using Set Control Value method just like in the already mentioned examples\viserver\runvi.llb\DateServerUsingReentrantRun.vi. 

Although in that example NI doesn't seem to share JP's concerns, before opening the next instance you can at least try to make sure that the instance you have just launched is really running  and, hence, most likely has already read the passed control value. You can do that by checking the instance VI's Execution.State property (loop until it becomes more or equal than "Run Top Level").

Stanislav Rumega, CLA

[JeanPierre]

---

H View Labs a écrit:

Interesting, but In \examples\viserver\runvi.llb\DateServerUsingReentrantRun.vi example the TCP connection references are passed to the reentrant handler instances exactly like that, using the Set Control Value Method! So, apparently, NI is convinced that this will work for sure, at least in a regular LV. Does it work on RT?

Stanislav Rumega, CLA

---

Well I just checked (I should have before posting above...) and indeed the prepare for reentrant run allows different data spaces for front panels of reentrant VIs.
I have opened two references to a reentrant VI, set a control value on one ref and get  the control value from the other ref. For non-reentrant references (VI instanciated once) and typed references (VI instanciated twice) , the value I get from one reference was the same I get on the other. For a reentrant run, I read different control values from the two references, indicating that they have distinct front panel data space.
 

[shoneill]

Sorry Kevin,

I only half-read your post.  I was still pondering other things whilst doing.

And yes, reentrant VIs will have the same name AFAIK.  I need to pay more attention. (I'll now move to the back of the class).

Another way would be to have a small routine listening for a QUEUE called whatever you like.  Then, launching the reentrant VI, it sends a name of a unique queue (type cast the VI reference to a string for example).  Then the host can send whatever info is required for the reentrant VI in this unique queue.

Then again, as I've said I know zip on RT, so maybe this is silly too.  Ah it's one of those days.

Hope this helps (or is funny, either way it's good)

Shane.

[Kevin_Price]

Folks,

Thanks for the help and for trying things out.  I was able to confirm that I could use Set Control Value and Get Control Value for controls on two instances of reentrant vi, but for some reason it didn't work right when I used Get Control Value on indicators that should have held different values after running the instances to completion.  I'll comb through the code more carefully though -- at this point I suspect it's my mistake.

-Kevin P.

[LabVU_Dog]

Hi all,

Sorry to butt in late, and with LV v8.0, but I have something to add.

I'd had some trouble in the past trying to dynamically create new instances of a reentrant subVI. I read somewhere (I think on this site) that it wouldn't work if you wanted to pass parameters and run it asynchronously. I used templates instead, but these are not supported on RT. So I took a look at this thread and tried the "serialization" of passing calling params to each instance. It works (I guess you came to the same conclusion)! I was able to pass different parameters to different instances, all thru the same FP (because all instances of a reentrant subVI share the same front panel). Attached is my prototyping code... sometimes a working example is worth a mint.

As I note, the general case would require synchronization to positively ensure that the FP values were read before the FOR loop could overwrite the controls on for the next instance. I have left that as an exercise for the user. Good luck!

[Beach_Comber]

Hello All,

I would like to again spawn a process, this time in Labview 8.2.  National has change things enough so that I have so far not figured out how to create a template (somefunction.vit).

I would like to launch another vi from a calling program and have it detach from the caller and run in its own thread. Can someone help me with this process again?

Thanx,

Karl